quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Anybody still using Visual Studio 6

[eng c. (s. by Nabble.com) <li...@na...>]

hi oren,

yes, we are still using vc6 at this moment, and not sure when we will move up to vc7 or 2005 yet. how long do you plan to continue supporting vc6?

thanks,

eng


Oren Miller wrote: 
> 
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> I'd like to stop maintaining the project files for Visual Studio 6 if it's 
> not being used anymore.  Are people still using this development 
> environment?
> 
> --oren 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
>
--
View this message in context: http://www.nabble.com/Anybody-still-using-Visual-Studio-6-t881579.html#a2355646
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] Re: Anybody still using Visual Studio 6

[Alexey Z. <ale...@gm...>]

Oren,

So, do you want to deprecate VC6 and VC7 in particular or the whole VC 
(windows) branch?
I converted the VC6 project to VC8, but we are going to use VC6 version 
for a while.
If it's just a question of files adding - no problem, I can change the 
projects.

Regards,
		Alexey Zubko



Oren Miller wrote:

> The project files need to be maintained.  So in windows, everytime a 
> change is made, like adding a new source file, it needs to be done in 
> three different places using three different tools (VC6, VC7, and 
> 2005).  Plus of course the unix build scripts, so 4 really.
>
> --oren
>
> ----- Original Message ----- From: "Alexey Zubko" 
> <ale...@gm...>
> To: <qui...@li...>
> Sent: Tuesday, January 10, 2006 8:37 AM
> Subject: [Quickfix-developers] Re: Anybody still using Visual Studio 6
>
>
>> QuickFIX Documentation: 
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello Oren,
>>
>> We are using VC6.
>> What do you mean by stopping maintaining?
>>
>>
>> Regards,
>> Alexey Zubko
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through 
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>

Re: [Quickfix-developers] Re: Anybody still using Visual Studio 6

[Oren M. <or...@qu...>]

The project files need to be maintained.  So in windows, everytime a change 
is made, like adding a new source file, it needs to be done in three 
different places using three different tools (VC6, VC7, and 2005).  Plus of 
course the unix build scripts, so 4 really.

--oren

----- Original Message ----- 
From: "Alexey Zubko" <ale...@gm...>
To: <qui...@li...>
Sent: Tuesday, January 10, 2006 8:37 AM
Subject: [Quickfix-developers] Re: Anybody still using Visual Studio 6


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello Oren,
>
> We are using VC6.
> What do you mean by stopping maintaining?
>
>
> Regards,
> Alexey Zubko
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

[Quickfix-developers] Re: Anybody still using Visual Studio 6

[Alexey Z. <ale...@gm...>]

Hello Oren,

We are using VC6.
What do you mean by stopping maintaining?


Regards,
		Alexey Zubko

Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Caleb E. <cal...@gm...>]

On 1/9/06, Scott Harrington <sco...@fo...> wrote:
>
> I'm pretty sure the state.setResendRange(0,0) is in the patch I attached
> previously.  I was working from a diff of revisions 1.84 to 1.86.  Oddly,


Yes, you're of course right.  I missed it in my first reading.

I cannot access revision 1.87 of Session.cpp in CVS at the moment (nor in
> the web-based ViewCVS), so I did miss Oren's latest patch.


I suspect its the lag between developer CVS and anonymous CVS thats at work
here.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] Anybody still using Visual Studio 6

[Oren M. <or...@qu...>]

I'd like to stop maintaining the project files for Visual Studio 6 if it's 
not being used anymore.  Are people still using this development 
environment?

--oren 

Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Scott H. <sco...@fo...>]

I'm pretty sure the state.setResendRange(0,0) is in the patch I attached 
previously.  I was working from a diff of revisions 1.84 to 1.86.  Oddly, 
I cannot access revision 1.87 of Session.cpp in CVS at the moment (nor in 
the web-based ViewCVS), so I did miss Oren's latest patch.

On Mon, 9 Jan 2006, Caleb Epstein wrote:

> On 1/9/06, Scott Harrington <sco...@fo...> wrote:
>>
>> Thanks for patching the Session.cpp code to fix my problem.  I just today
>> caught up to things and have ported your fix to my local copy of
>> quickfixj/src/quickfix/Session.java.  The patch is attached; could we ask
>> Steve to review it and check it in to quickfixj?
>
>
> This looks like half of the fix, but you're missing the logic to reset the
> SessionState's resendRange back to (0,0) in Session::verify.  Here's the
> relevant section of the patch, which includes another fix Oren recently made
> for handling Logon messages containing ResetSeqNumFlag=Y
>
> --- Session.cpp 2 Jan 2006 21:26:37 -0000       1.85
> +++ Session.cpp 9 Jan 2006 16:04:56 -0000       1.87
> @@ -235,7 +235,7 @@
>
>   MsgSeqNum msgSeqNum;
>   logon.getHeader().getField( msgSeqNum );
> -  if ( isTargetTooHigh( msgSeqNum ) )
> +  if ( isTargetTooHigh( msgSeqNum ) && !resetSeqNumFlag )
>   {
>     doTargetTooHigh( logon );
>   }
> @@ -964,6 +964,20 @@
>       doTargetTooLow( msg );
>       return false;
>     }
> +
> +    if ( (checkTooHigh || checkTooLow) && m_state.resendRequested() )
> +    {
> +      SessionState::ResendRange range = m_state.resendRange();
> +
> +      if ( msgSeqNum >= range.second )
> +      {
> +        m_state.onEvent ("ResendRequest for messages FROM: " +
> +                         IntConvertor::convert (range.first) + " TO: " +
> +                         IntConvertor::convert (range.second) +
> +                         " has been satisfied.");
> +        m_state.resendRange (0, 0);
> +      }
> +    }
>   }
>   catch ( std::exception& e )
>   {
>
>
> --
> Caleb Epstein
> caleb dot epstein at gmail dot com
>

Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Caleb E. <cal...@gm...>]

On 1/9/06, Scott Harrington <sco...@fo...> wrote:
>
> Thanks for patching the Session.cpp code to fix my problem.  I just today
> caught up to things and have ported your fix to my local copy of
> quickfixj/src/quickfix/Session.java.  The patch is attached; could we ask
> Steve to review it and check it in to quickfixj?


This looks like half of the fix, but you're missing the logic to reset the
SessionState's resendRange back to (0,0) in Session::verify.  Here's the
relevant section of the patch, which includes another fix Oren recently mad=
e
for handling Logon messages containing ResetSeqNumFlag=3DY

--- Session.cpp 2 Jan 2006 21:26:37 -0000       1.85
+++ Session.cpp 9 Jan 2006 16:04:56 -0000       1.87
@@ -235,7 +235,7 @@

   MsgSeqNum msgSeqNum;
   logon.getHeader().getField( msgSeqNum );
-  if ( isTargetTooHigh( msgSeqNum ) )
+  if ( isTargetTooHigh( msgSeqNum ) && !resetSeqNumFlag )
   {
     doTargetTooHigh( logon );
   }
@@ -964,6 +964,20 @@
       doTargetTooLow( msg );
       return false;
     }
+
+    if ( (checkTooHigh || checkTooLow) && m_state.resendRequested() )
+    {
+      SessionState::ResendRange range =3D m_state.resendRange();
+
+      if ( msgSeqNum >=3D range.second )
+      {
+        m_state.onEvent ("ResendRequest for messages FROM: " +
+                         IntConvertor::convert (range.first) + " TO: " +
+                         IntConvertor::convert (range.second) +
+                         " has been satisfied.");
+        m_state.resendRange (0, 0);
+      }
+    }
   }
   catch ( std::exception& e )
   {


--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] client cannot reconnect after disconnect

[Caleb E. <cal...@gm...>]

On 1/9/06, Oren Miller <or...@qu...> wrote:
>
> The server is disconnecting you for some reason.  You need to see the
> server logs in order to find out why this is happening.  The Created Sess=
ion
> is not relevant.  The session is only created once when the process is
> loaded.
>


I'd actually suspect that the thread on your Server that handles this clien=
t
connection has become deadlocked or is in some sort of busy-wait.  This
would explain the TEST request sent by the client and the subsequent
inability to re-connect, since QuickFIX believes (on the Server side) that
the connection is still active.  We actually had a similar situation in an
applicaiton here and this was pretty much exactly what we saw happen.

Best bet is to attach to your server with the debugger when this condition
happens to see what it is doing.

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Scott H. <sco...@fo...>]

Dear Caleb:

Thanks for patching the Session.cpp code to fix my problem.  I just today 
caught up to things and have ported your fix to my local copy of 
quickfixj/src/quickfix/Session.java.  The patch is attached; could we ask 
Steve to review it and check it in to quickfixj?

My underlying message length error (in netty2?) that caused my 
ResendRequest in the first place was intermittent and I haven't rigged a 
testbed to force it to happen on command.  But once it does happen (I saw 
it every other day or so before, and once several times in one day), I 
will know that the new code is working when I see the new "ResendRequest 
has been satisfied" message.  I guess then I will have to tackle the 
underlying problem before I can switch to QuickFIX/J in production....

Scott


On Tue, 3 Jan 2006, Caleb Epstein wrote:

> On 1/3/06, Oren Miller <or...@qu...> wrote:
>>
>> Well, the initiator sent a resend request from 197648 to 0 after logging
>> in, and the acceptor responded with a sequence reset from 197648 to
>> 197651.  No messages would have been queued, so no queued messages would
>> have been processed.  So yeah, I would think that it is not being reset
>> in the correct place.
>
>
> Ah that explains it.  I didn't read the log closely enough and missed this
> reset.
>
> It looks like the right place for the "have we satisfied an outstanding
> resend request" logic is in Session::verify.  I've just committed a change
> that moves this logic from Session::nextQueued to here and it passes all
> user and acceptance tests.  There will be a new event logged when this
> happens:  "ResendRequest for messages FROM: # TO: # has been satisfied.".
>
> Shifting gears slightly, this raises (again) the queueing of messages from
> the counterparty.  In Scott's case I'm pretty sure there was at least one
> message sitting in the SessionState's m_queue that would never be emptied
> out (#197650) until the session disconnected.
>
> I've posted before about the potential problems associated with queueing
> messages, specifically Admin-type messages (see
> http://sourceforge.net/mailarchive/forum.php?thread_id=7090286&forum_id=103
> ), and I'm wondering if it might not make sense to remove the queueing logic
> from the Session entirely.  Its a potential performance optimization that
> has the potential to cause a memory leak (e.g. queued messages that are
> skipped by a SequenceReset) and worse, incorrect behavior (see email thread
> linked previously).
>
> Removing the queue would also simplify the code in the Session class, which
> is always a good thing IMHO.  Failing that, Admin-type messages should
> probably not be enqueued, based on the reasons I outlined in the email
> thread from April.  Oren, what do you think of this?
>
> --
> Caleb Epstein
> caleb dot epstein at gmail dot com

Re: [Quickfix-developers] client cannot reconnect after disconnect

[Oren M. <or...@qu...>]

The server is disconnecting you for some reason.  You need to see the =
server logs in order to find out why this is happening.  The Created =
Session is not relevant.  The session is only created once when the =
process is loaded.

--oren
  ----- Original Message -----=20
  From: Nicholas Murdock=20
  To: quickfix-developers=20
  Sent: Monday, January 09, 2006 9:21 AM
  Subject: [Quickfix-developers] client cannot reconnect after =
disconnect


  Here is our situation. We are using a c# client and a c++ server, both =
using quickfix 1.10.2. Several times during the day the client gets =
disconnected from the server and cannot reconnect without bouncing the =
server process.=20

  =20

  The event logs from both sides are:

  client:

  20060109-14:20:02 : Sent test request TEST

  20060109-14:20:14 : Timed out waiting for heartbeat

  20060109-14:20:14 : Disconnecting

  20060109-14:20:14 : Socket Error

  20060109-14:20:19 : Connecting to ecbotoe on port 6336

  20060109-14:20:19 : Connection succeeded

  20060109-14:20:19 : Initiated logon request

  20060109-14:20:24 : Socket Error: Connection reset by peer.

  20060109-14:20:24 : Disconnecting

  20060109-14:20:29 : Connecting to ecbotoe on port 6336

  20060109-14:20:29 : Connection succeeded

  20060109-14:20:29 : Initiated logon request

  20060109-14:20:34 : Socket Error: Connection reset by peer.

  20060109-14:20:34 : Disconnecting

  20060109-14:20:39 : Connecting to ecbotoe on port 6336

  20060109-14:20:39 : Connection succeeded

  20060109-14:20:39 : Initiated logon request

  20060109-14:20:44 : Socket Error: Connection reset by peer.

  20060109-14:20:44 : Disconnecting

  20060109-14:20:49 : Connecting to ecbotoe on port 6336

  20060109-14:20:49 : Connection succeeded

  20060109-14:20:49 : Initiated logon request

  20060109-14:20:54 : Socket Error: Connection reset by peer.

  20060109-14:20:54 : Disconnecting

  .

  =20

  =20

  Server:

  20060109-14:19:25 : Socket Error: Connection reset by peer.

  20060109-14:19:25 : Disconnecting

  20060109-14:21:19 : Created session   =DF only after bouncing the =
server

  =20

  =20

  Can anyone tell me why this is happening? What is the socket error =
following the missed heartbeat and subsequent test request? Is this =
socket error causing the loop that follows where the client seems to =
create a socket and send a logon (the outgoing log shows logon messages =
from the client during this loop) but then disconnects because the =
socket is bad?

  =20

  I can provide more logs if necessary. All help is appreciated.

  =20

  -- -- --

  Nicholas Murdock

  Chicago Trading Company

  =20

  nic...@ch...

  312-863-4653

  =20

[Quickfix-developers] client cannot reconnect after disconnect

[Nicholas M. <nic...@ch...>]

Here is our situation. We are using a c# client and a c++ server, both using
quickfix 1.10.2. Several times during the day the client gets disconnected
from the server and cannot reconnect without bouncing the server process. 

 

The event logs from both sides are:

client:

20060109-14:20:02 : Sent test request TEST

20060109-14:20:14 : Timed out waiting for heartbeat

20060109-14:20:14 : Disconnecting

20060109-14:20:14 : Socket Error

20060109-14:20:19 : Connecting to ecbotoe on port 6336

20060109-14:20:19 : Connection succeeded

20060109-14:20:19 : Initiated logon request

20060109-14:20:24 : Socket Error: Connection reset by peer.

20060109-14:20:24 : Disconnecting

20060109-14:20:29 : Connecting to ecbotoe on port 6336

20060109-14:20:29 : Connection succeeded

20060109-14:20:29 : Initiated logon request

20060109-14:20:34 : Socket Error: Connection reset by peer.

20060109-14:20:34 : Disconnecting

20060109-14:20:39 : Connecting to ecbotoe on port 6336

20060109-14:20:39 : Connection succeeded

20060109-14:20:39 : Initiated logon request

20060109-14:20:44 : Socket Error: Connection reset by peer.

20060109-14:20:44 : Disconnecting

20060109-14:20:49 : Connecting to ecbotoe on port 6336

20060109-14:20:49 : Connection succeeded

20060109-14:20:49 : Initiated logon request

20060109-14:20:54 : Socket Error: Connection reset by peer.

20060109-14:20:54 : Disconnecting

...

 

 

Server:

20060109-14:19:25 : Socket Error: Connection reset by peer.

20060109-14:19:25 : Disconnecting

20060109-14:21:19 : Created session   <-- only after bouncing the server

 

 

Can anyone tell me why this is happening? What is the socket error following
the missed heartbeat and subsequent test request? Is this socket error
causing the loop that follows where the client seems to create a socket and
send a logon (the outgoing log shows logon messages from the client during
this loop) but then disconnects because the socket is bad?

 

I can provide more logs if necessary. All help is appreciated.

 

-- -- --

Nicholas Murdock

Chicago Trading Company

 

nic...@ch...

312-863-4653

 

[Quickfix-developers] Getting Session Start Time

[Nick V. <ni...@ad...>]

I'm using QF 1.10.2 with Java and want to get the value of the session 
start time programmatically.  Any ideas?

Thanks.

 
Nicholas Volpe
Treasury Department
Abu Dhabi Investment Authority

Extension:         2511
Telephone:        +971 2 613 2511
Mobile:              +971 50 592 8047
Email:                ni...@ad...
 
**************************************************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any  unauthorized use of the information contained
in this email or its attachments is prohibited.  If this email is received in
error, please contact the sender and delete the material from your
computer systems. Do not use, copy, or disclose the contents of this
email or any attachments.
Abu Dhabi Investment Authority (ADIA) accepts no responsibility for
the content of this email to the extent that the same consists of
statements and opinions made which are the senders own and not
made on behalf of ADIA.  Nor does ADIA accept any liability for any
errors or omissions in the content of this email caused by electronic
and technical failures.
Although ADIA has taken reasonable precautions to ensure that no
viruses are present in this email, ADIA accepts no responsibility for
any loss or damage arising from the use of this email or its
attachments.
**************************************************************************************************************

Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Yeah, I'm not sure about removing the queue completely. [...]

Hi Oren, hi Caleb,

we recently added a configuration option to QuickFIX/J, which controls whether QFJ should 
use ResendRequest to INFINITY or fixed-range ResendRequest messages to re-request missed 
messages.

I know the FPL recommends to use INFINITY in any case, and you changed the QF code quite a 
while ago. But this is a requirement from EMX London, which we are connecting to. Maybe 
other counterparty also have this restriction...

To keep QF and QFJ compatible, it would be good to "backport" this change to QF. But I 
think that fixed-range ResendRequests need the queue.

On the other hand, getting rid of unneeded code makes things easier and less error-prone.

Can you both think of a way to accomplish this?

Happy New Year and

cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-developers] QF compilation in VS 2005

[Oren M. <or...@qu...>]

I've actually taken the throw clauses out of the .NET library in source 
control.  It rather makes sense since the other .NET languages do not 
support throw clauses, so there really isn't any reason for Managed C++ 
to support them.  The unmanaged throw clauses are still supported.

--oren

Caleb Epstein wrote:

> On 1/5/06, *Andrei Goldchleger* <an...@gm... 
> <mailto:an...@gm...>> wrote:
>
>     I am running into problems when compiling QF (1.10.2) solution in the
>     new VS 2005. The C++ compiler seem to dislike throw clauses at method
>     declarations on managed C++, or something like that.
>
>     http://msdn2.microsoft.com/library/7tfey5a9.aspx
>
>     Does anyone know if this can be overridden in any way?
>
>
> I ran into this myself, and I don't think there's any way to disable 
> it.  I think all the throw decls will need to be conditionally 
> compiled-out when building for .NET.
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com 

Re: [Quickfix-developers] QF compilation in VS 2005

[Caleb E. <cal...@gm...>]

On 1/5/06, Andrei Goldchleger <an...@gm...> wrote:

> I am running into problems when compiling QF (1.10.2) solution in the
> new VS 2005. The C++ compiler seem to dislike throw clauses at method
> declarations on managed C++, or something like that.
>
> http://msdn2.microsoft.com/library/7tfey5a9.aspx
>
> Does anyone know if this can be overridden in any way?


I ran into this myself, and I don't think there's any way to disable it.  I
think all the throw decls will need to be conditionally compiled-out when
building for .NET.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] QF compilation in VS 2005

[Andrei G. <an...@gm...>]

Hi there,

I am running into problems when compiling QF (1.10.2) solution in the
new VS 2005. The C++ compiler seem to dislike throw clauses at method
declarations on managed C++, or something like that.

http://msdn2.microsoft.com/library/7tfey5a9.aspx

Does anyone know if this can be overridden in any way?

[Quickfix-developers] terminate the session thread

[Fabien G. <fab...@pr...>]

Hello all,

I work with version 1.10.2 of QF under Java (with JNI).
I can see that each time i connect my acceptor, a new thread is created =
(of course).
The problem is that i cant terminate this thread properly and this is =
very annoying for our project.
I tried all of these methods :
- Acceptor.stop(true/false)
- Acceptor.getSessions().clear() (?)
- Session.logout()
- Session.reset()
- set Acceptor/Session objects to null and force garbage collector

Anyway, i still cant terminate this thread.
How can i solve this ?
At least, is it possible ?


Thanks for your help,

Fabien

Re: [Quickfix-developers] QF hanging in resend scenario

[adrien1977 (s. by Nabble.com) <li...@na...>]

Ok
Our first initial test seem to be working.
Looking at the code, we missed the Queuing part.
We really appreciate your help and keep you posted on the results

thanks
Adrien
--
View this message in context: http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2210927
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] QF hanging in resend scenario

[adrien1977 (s. by Nabble.com) <li...@na...>]

Ok then
We are going to do a quick test with a simulator to see if it is the case.
We were able to reprocuce the scenario with a simulator and not the other party's server.

I'll get back to you guys and thanks for the help


--
View this message in context: http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2210513
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] QF hanging in resend scenario

[Caleb E. <cal...@gm...>]

On 1/4/06, adrien1977 (sent by Nabble.com) <li...@na...> wrote:
>
> We use a socket initiator and not the threaded one.
> However we do not think that it would solve the issue because what the
> threadSocketInitiator does is to spawn a thread for each session. Our
> adapter only has one session so it would not matter.


Yes, it would.

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] QF hanging in resend scenario

[Oren M. <or...@qu...>]

Two for each session.  One is dedicated to pulling messages off the 
socket.  Are using 1.10.2?

--oren

adrien1977 (sent by Nabble.com) wrote:

> We use a socket initiator and not the threaded one.
> However we do not think that it would solve the issue because what the 
> threadSocketInitiator does is to spawn a thread for each session. Our 
> adapter only has one session so it would not matter.
>
> View this message in context: Re: QF hanging in resend scenario 
> <http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2210275>
> Sent from the QuickFIX - Dev 
> <http://www.nabble.com/QuickFIX---Dev-f1041.html> forum at Nabble.com. 

Re: [Quickfix-developers] QF hanging in resend scenario

[adrien1977 (s. by Nabble.com) <li...@na...>]

We use a socket initiator and not the threaded one.
However we do not think that it would solve the issue because what the threadSocketInitiator does is to spawn a thread for each session. Our adapter only has one session so it would not matter.

--
View this message in context: http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2210275
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] QF hanging in resend scenario

[Oren M. <or...@qu...>]

Are you using the SocketInitiator or ThreadedSocketInitiator?

--oren

adrien1977 (sent by Nabble.com) wrote:

> Hi
>
> We are implementing a component that uses quickfix to connect to 
> another quickfix server.
>
> We have noticed a weird scenario that causes our adapter and the 
> server to hang (may because entering a deadlock)
>
>  
>
> We Connect for the first time to the server and send 2000 messages and 
> get the responses.
>
> We disconnect and reset the sequence on the server to 1 but keep our 
> sequence the same.
>
> We reconnect and obviously we received a resend request from  the server.
>
> We start blasting the 2000 messages and the server processes them and 
> start sending the messages back to us.
>
> However we do not receive these messages (or may be they are queued in 
> QF) because they do not show in the log (but they are in the network. 
> We could see them using a sniffer)
>
>  
>
> While still sending the messages, our adapter stop sending more, and 
> this is because the TCP window on the receiving side is full.
>
> However the server is still sending messages that we do not receive.
>
>  
>
> After a while our adapter start sending back message, then stops 
> starts again and finally stops and nothing else happens.
>
>  
>
> I would like to know if it is normal.
>
>  
>
> We are thinking that the thread that received the resend request is 
> the same thread that processes the resend of messages.
>
> Since the receiving thread is busy sending the messages if cannot 
> receive any this causing a queue in our side.
>
>  
>
> Is it normal that the receiving thread is blocked when processing a 
> resend? Should not it allowed more messages to come??
>
>  
>
> We are using the C++ version with Java wrapper.
>
>  
>
> thanks
>
>  
>
>  
>
> adrien
>
>  
>
> View this message in context: QF hanging in resend scenario 
> <http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2209923>
> Sent from the QuickFIX - Dev 
> <http://www.nabble.com/QuickFIX---Dev-f1041.html> forum at Nabble.com. 

[Quickfix-developers] QF hanging in resend scenario

[adrien1977 (s. by Nabble.com) <li...@na...>]

Hi

We are implementing a component that uses quickfix to connect to another quickfix server.

We have noticed a weird scenario that causes our adapter and the server to hang (may because entering a deadlock)

 

We Connect for the first time to the server and send 2000 messages and get the responses.

We disconnect and reset the sequence on the server to 1 but keep our sequence the same.

We reconnect and obviously we received a resend request from  the server.

We start blasting the 2000 messages and the server processes them and start sending the messages back to us.

However we do not receive these messages (or may be they are queued in QF) because they do not show in the log (but they are in the network. We could see them using a sniffer)

 

While still sending the messages, our adapter stop sending more, and this is because the TCP window on the receiving side is full.

However the server is still sending messages that we do not receive.

 

After a while our adapter start sending back message, then stops starts again and finally stops and nothing else happens.

 

I would like to know if it is normal.

 

We are thinking that the thread that received the resend request is the same thread that processes the resend of messages.

Since the receiving thread is busy sending the messages if cannot receive any this causing a queue in our side.

 

Is it normal that the receiving thread is blocked when processing a resend? Should not it allowed more messages to come??

 

We are using the C++ version with Java wrapper.

 

thanks

 

 

adrien

 

--
View this message in context: http://www.nabble.com/QF-hanging-in-resend-scenario-t852464.html#a2209923
Sent from the QuickFIX - Dev forum at Nabble.com.