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...>]

Hi, I seem to found at least partial possible explanation. One of the
crucial differences of two versions is that new version miss at least one
beat of blocked call because it first put connection object in the list of
pending connection (m_pendingConnections) which promoted to the connected
connection (m_connections) list only after first SocketMonitor::block()
call. 
 
Moreover when I have replace code in the SocketInitiator::doConnect()
 
From:
    setPending( s );
 
    m_pendingConnections[ result ] 
          = new SocketConnection( *this, s, result,
&m_connector.getMonitor() );
 
To 
    setConnected(s);
 
    m_connections[ result ] 
          = new SocketConnection( *this, s, result,
&m_connector.getMonitor() );
 
It started to behave as old version at least as far as timing of Logon
turn-around is concerned.
 
It would be very interesting to learn the reason behind of pending
connections.
 
Thank you.
 
Len.
 
  _____  

From: Leonid Gamburg [mailto:ig...@ho...] 
Sent: Thursday, August 24, 2006 10:04 AM
To: qui...@li...
Subject: QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around
and I do not know why
 
Hi,
 
I am trying to switch from QuickFIX version 1.11.1 to QuickFIX version
1.12.2 because that version fixed bug when session could not timeout even if
remote engine never send messages in right order. When I switch to new
version I found that our Application every other connection timeout. After
debugging I have found that we impose on ourselves application's 2 second
timeout and disconnect immediately if no Logon message from remote party
been delivered to us. And new version of QuicFIX sometimes take bit less
than 2 seconds and sometimes more. When I have return previous engine back
it turn-around time (more on my definition of this term later) was around 1
second. I did a little bit more debugging but was not able to pinpoint the
reason for that discrepancy, but I am publishing information if other
developers have more clues.
 
 
The turn-around time for logon I would define as a time it took to (and I
have modified QuickFIX a bit to be able to do it on demand) from enable
session and call Initiator::connect() and when the remote site send
FIX::Application::onLogon() propagated back to our application code. The
mater here is bit complicated due to asynchronous nature of Logon() message
generation. Although enabling session and socket connection happens on the
invoking clinet thread Logon message generation sending happens on the
different thread. 
 
On that different thread (different from an Application's main thread) there
is a SocketMonitor::block() method which is being invoked in the loop. If
there no activity on the sockets it will be blocked for for
SocketMonitor::getTimeval() microseconds which in both version returns the
same value equal to 1 second. After "select" invocation strategy.onTimeout()
is being called which eventually call Session::generateLogon() etc. The
bazaar part is that although SocketMonitor::block() methods (and other
SocketMonitor methods) are very similar that select() call takes exactly 1
second on the 1.12.2 version and almost always 0.6 seconds on the 1.11.1.
 
Although I do not know why this happens (may be there some sockets in the
1.11.1 version signal prior to 1 second timeout) that explains 0.4 seconds
difference. Where is other 0.6 second difference I do not know.
 
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.
  _____  

Search from any Web page with powerful protection. Get the FREE Windows Live
Toolbar Today! Try it now! <http://get.live.com/toolbar/overview>