RE: [Quickfix-developers] Decoder callback not invoked

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

We have only seen this in production and are unable to attach to the process
(we can't reproduct in dev).

 

So, instead of attaching, I put some logging (to the event log) inside the
Session class. I put a log at the beginning of Session::next(const Message&,
bool) among other places. The results were, after a few hours of trading I
get a MassQuote in the incoming fix log but no logging in the event log to
represent the next(message, bool) function begin called. 

 

As it looks to me (so that I'm not confused about what part of the code is
running), the only place anything gets logged to the incoming fix log is in
Session::next( const std::string&, bool). So assuming we've made it this far
the previous callback has completed and we are no longer inside my code: The
parser has pulled a complete message (string) off of the queue and we are
processing that. So what happens after m_state.onIncoming(msg) ?



Is it possible that something is throwing during the creation of the fix
message (from the string) and the exception is getting swallowed in
ThreadedSocketConnection::readQueue().

 

Any ideas?

 

-Nick

 

  _____  

From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Thursday, March 23, 2006 9:11 PM
To: Nicholas Murdock
Cc: quickfix-developers
Subject: Re: [Quickfix-developers] Decoder callback not invoked

 

On 3/23/06, Nicholas Murdock <nic...@ch...
<mailto:nic...@ch...>  > wrote:

Using quickfix 1.10.2, ThreadedSocket, after about 3 hours of heavy use the
message decoder callback for an incoming message isn't being called. We see
the message (mass quote) in the incoming log but the callback isn't invoked.
The thread seems to hang as it does not process any further incoming data
(the thread pulling data of the socket seems to be working, though, as the
client never blocks on send). The server continues to send info back to the
client on the same session.

What is the ThreadedSocketConnection's m_queueThread, the one that is
reading from the m_queue built up by the socket-reading thread, doing?  This
is the thread from which your callbacks will be fired, so perhaps your
Application code has deadlocked? 


-- 
Caleb Epstein
caleb dot epstein at gmail dot com