Re: [Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around and I do not know why

[iglen <ig...@ho...>]

Thank you Oren
 
That last line did the trick. Are you saying that previous version was not
100% safe in that regard? Because my for-test-modifications are similar to
version 1.11.1. 
 
About 2 second time-out. I do not know for sure. It was implemented before I
came aboard. Our C++ application until recently used some commercial Java
based FIX Engine and had to communicated with it through TCP/IP. Basically
after user manually via menu command issue Connect command it fall asleep
for 2 seconds (with message looping) and after awaking check if it received
logon, and if no logon has been received it forcefully disconnect during
waiting time a user cannot click on anything. It may be not the best
approach but it works reasonably well. 
 
I still need to prevent a user until connection confirmed from doing
anything with application. What LogonTimeout would be me in regards of that
-  the only help I see is to re-align application and engine time-outs and
would avoid an oddity such as QuickFIX has been connected bit later than 2
second and had to be forcefully disconnect. On the other hand due to
difference in timers start time it still would not work precise enough.
 
Len.
 
 
  _____  

From: Oren Miller [mailto:or...@qu...] 
Sent: Thursday, August 24, 2006 4:27 PM
To: Leonid Gamburg
Cc: qui...@li...
Subject: Re: [Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than
1.11.1 on Logon turn-around and I do not know why
 
Leonid,
 
This is basically what should be done. I think this is a side effect of the
non-blocking socket implementation. The socket is being added to the select
statement which results in a call to SocketInitiator::OnConnect. The socket
is then placed in as a read statement, but since it is an initiator it has
nothing to read and doesn't do anything until the timeout interval forces a
logon to go out. Since the select statement can timeout anywhere between 0
and 1 seconds, I can see how the connection time might vary.
 
What should be done is in the SocketInitiator::OnConnect call, their should
be a call to pSocketConnection->onTimeout() which will force the logon to be
sent out immediately. You're hack is essentially doing this in a more
roundabout way, but this approach is more direct and would be done directly
in the QuickFIX thread. Below is the full method with the change. Let me
know if there is an improvement.
 
Also, any reason why you are doing the 2 second check at the application
level? QuickFIX has a LogonTimeout setting that you could set for 2 seconds
and would have taken into account the timing discrepency.
 
void SocketInitiator::onConnect( SocketConnector&, int s )
{ QF_STACK_PUSH(SocketInitiator::onConnect)
 
SocketConnections::iterator i = m_pendingConnections.find( s );
if( i == m_pendingConnections.end() ) return;
SocketConnection* pSocketConnection = i->second;
 
m_connections[s] = pSocketConnection;
m_pendingConnections.erase( i );
setConnected( pSocketConnection->getSession()->getSessionID() );
pSocketConnection->onTimeout();
 
QF_STACK_POP
}
 
I was able to shorten Logon turn-around time significantly when I call
onTimeout() directly (and consequently generateLogon()) on the application's
main thread and so far it works great, but I am afraid that this may cause
some nasty concurrency problem. It seems to me that asynchronous Logon() in
the unmodified QuickFIX makes full sense because it seems to be done only
once per day/week. Because I have modified QuickFIX to create/logon/logout
session on demand to me it rather waste of time

Thank you

Len.