[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 G. <ig...@ho...>]

Hi,
=20
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 re=
mote engine never send messages in right order. When I switch to new versio=
n I found that our Application every other connection timeout. After debugg=
ing I have found that we impose on ourselves application's 2 second timeout=
 and disconnect immediately if no Logon message from remote party been deli=
vered to us. And new version of QuicFIX sometimes take bit less than 2 seco=
nds and sometimes more. When I have return previous engine back it turn-aro=
und 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.
=20
=20
The turn-around time for logon I would define as a time it took to (and I h=
ave modified QuickFIX a bit to be able to do it on demand) from enable sess=
ion and call Initiator::connect() and when the remote site send FIX::Applic=
ation::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 cli=
net thread Logon message generation sending happens on the different thread=
.=20
=20
On that different thread (different from an Application's main thread) ther=
e 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 equ=
al to 1 second. After "select" invocation strategy.onTimeout() is being cal=
led which eventually call Session::generateLogon() etc. The bazaar part is =
that although SocketMonitor::block() methods (and other SocketMonitor metho=
ds) 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.
=20
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 d=
ifference. Where is other 0.6 second difference I do not know.
=20
I was able to shorten Logon turn-around time significantly when I call onTi=
meout() directly (and consequently generateLogon()) on the application's ma=
in thread and so far it works great, but I am afraid that this may cause so=
me nasty concurrency problem. It seems to me that asynchronous Logon() in t=
he unmodified QuickFIX makes full sense because it seems to be done only on=
ce per day/week. Because I have modified QuickFIX to create/logon/logout se=
ssion on demand to me it rather waste of time
=20
Thank you
=20
Len.
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Liv=
e Toolbar Today!
http://get.live.com/toolbar/overview=