[Quickfix-developers] Re: ThreadedSocketInitiator vs SocketInitiator

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

Wow. I tried to get this information a year ago when I start using 
QuickFix. And now such a big surprise.
Thanks, Caleb.

Overall QF is doing pretty good but I do have dead locks in one heavy 
loaded multi-thread application.
In my application I have one (not threaded) initiator and an acceptor.
When I lost connection in the initiator, the application is stuck (not 
always, basically I can't reproduce it freely, but it happens often in 
production).
I stopped using ThreadedSocketInitiator because I have only one session 
in it.
Basically I thought the problem is that sessions list is static, and my 
acceptor and initiator share critical sections incorrectly.

I put threaded initiator to the production yesterday and will see if it 
help.

Thanks for the explanations again.

Regards,
		Alexey Zubko


>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator
> From:
> "Caleb Epstein" <cal...@gm...>
> Date:
> Tue, 9 May 2006 12:08:22 -0400
> To:
> "Nick Volpe" <ni...@ad...>
>
> To:
> "Nick Volpe" <ni...@ad...>
> CC:
> quickfix-developers <qui...@li...>
>
>
> I don't think this made it through the first time.
>
> On 5/9/06, Nick Volpe <ni...@ad...> wrote:
>>
>> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a
>> Socket Initiator?  I c an't seem to find much in the documentation or 
>> the
>> mailing list archives.  Any help would be greatly appreciated.
>
> The non-threaded SocketInitiator can actually get into a deadlock
> situation whereby your application will block forever.  I would
> recommend against anyone ever using it.
>
> This deadlock will happen if your application fills up a socket's
> sending buffer while the other side is doing the same (e.g. two
> non-threaded QuickFIX apps generating heavy traffic).  Neither side
> will end up reading from its side of the socket, being blocked in a
> send() call, and both sides will deadlock.
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>