Thread: Re: [Quickfix-developers] Possible Bug w/ Duplicate SenderCompID's
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Jon D. <jd...@wi...> - 2004-10-26 14:08:47
|
Oren, I noticed the fix in CVS and was looking at it in a little more detail and I was wondering if there was anyway an exception could be thrown when unable to register the session - because there is already one registered for that SenderCompID. The reason being is, from an operational and troubleshooting standpoint this could be a nightmare if you don't know why the connection was dropped and the user simply states they can't connect to the Acceptor. Reference(hope the link doesn't break): http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/SocketConnection.cpp?r1=1.8&r2=1.9 Thanks, -jd- > We have corrected this bug and added acceptance tests which are now > passing for both the SocketAcceptor and ThreadedSocketAcceptor. > > --oren > > On Oct 5, 2004, at 10:30 AM, Jon Dahl wrote: > >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX FAQ: >> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor. >> >> -jd- >> >>> Are you using the SocketAcceptor? Looking at it it looks to me like >>> the ThreadedSocketAcceptor is handling this situation correctly by >>> registering Session usage, but SocketAcceptor doesn't appear to be >>> doing so. >>> >>> --oren >>> >>> On Oct 5, 2004, at 9:41 AM, Jon Dahl wrote: >>> >>>> QuickFIX Documentation: >>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>> QuickFIX FAQ: >>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >>>> QuickFIX Support: http://www.quickfixengine.org/services.html >>>> >>>> It seems that if a client connects to an Acceptor app with a >>>> SenderCompID >>>> already connected, it causes the MsgSeqNum to change to the new >>>> connection >>>> instead of just dropping the connection. >>>> >>>> Subsequently, the valid client can't enter valid messages until >>>> either >>>> it >>>> disconnects or the server is restarted. We reset our sequence >>>> numbers after disconnect and logoff. Those who don't, may run into >>>> a bigger problem. >>>> >>>> Anyone else run into this? >>>> >>>> QF 1.9.0 >>>> RHAS 2.1 >>>> gcc 3.04 >>>> -------- >>>> config: >>>> ..... >>>> ResetOnDisconnect=Y >>>> ResetOnLogout=Y >>>> >>>> -jd- >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: IT Product Guide on >>>> ITManagersJournal >>>> Use IT products in your business? Tell us what you think of them. >>>> Give >>>> us >>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>> out >>>> more >>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>> _______________________________________________ >>>> Quickfix-developers mailing list >>>> Qui...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> >> >> -- >> >> >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: IT Product Guide on >> ITManagersJournal >> Use IT products in your business? Tell us what you think of them. >> Give >> us >> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >> out >> more >> http://productguide.itmanagersjournal.com/guidepromo.tmpl >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers -- -- |
|
From: Oren M. <or...@qu...> - 2004-10-26 18:53:39
|
Yeah, what we could do is write to the event log when this happens, is this what you are getting at? --oren On Oct 26, 2004, at 9:08 AM, Jon Dahl wrote: > Oren, > > I noticed the fix in CVS and was looking at it in a little more detail > and I was wondering if there was anyway an exception could be thrown > when unable to register the session - because there is already one > registered for that SenderCompID. > > The reason being is, from an operational and troubleshooting standpoint > this could be a nightmare if you don't know why the connection was > dropped and the user simply states they can't connect to the Acceptor. > > Reference(hope the link doesn't break): > http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/ > SocketConnection.cpp?r1=1.8&r2=1.9 > > Thanks, > > -jd- > > >> We have corrected this bug and added acceptance tests which are now >> passing for both the SocketAcceptor and ThreadedSocketAcceptor. >> >> --oren >> >> On Oct 5, 2004, at 10:30 AM, Jon Dahl wrote: >> >>> QuickFIX Documentation: >>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>> QuickFIX FAQ: >>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor. >>> >>> -jd- >>> >>>> Are you using the SocketAcceptor? Looking at it it looks to me like >>>> the ThreadedSocketAcceptor is handling this situation correctly by >>>> registering Session usage, but SocketAcceptor doesn't appear to be >>>> doing so. >>>> >>>> --oren >>>> >>>> On Oct 5, 2004, at 9:41 AM, Jon Dahl wrote: >>>> >>>>> QuickFIX Documentation: >>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>>> QuickFIX FAQ: >>>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >>>>> QuickFIX Support: http://www.quickfixengine.org/services.html >>>>> >>>>> It seems that if a client connects to an Acceptor app with a >>>>> SenderCompID >>>>> already connected, it causes the MsgSeqNum to change to the new >>>>> connection >>>>> instead of just dropping the connection. >>>>> >>>>> Subsequently, the valid client can't enter valid messages until >>>>> either >>>>> it >>>>> disconnects or the server is restarted. We reset our sequence >>>>> numbers after disconnect and logoff. Those who don't, may run into >>>>> a bigger problem. >>>>> >>>>> Anyone else run into this? >>>>> >>>>> QF 1.9.0 >>>>> RHAS 2.1 >>>>> gcc 3.04 >>>>> -------- >>>>> config: >>>>> ..... >>>>> ResetOnDisconnect=Y >>>>> ResetOnLogout=Y >>>>> >>>>> -jd- >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------- >>>>> This SF.net email is sponsored by: IT Product Guide on >>>>> ITManagersJournal >>>>> Use IT products in your business? Tell us what you think of them. >>>>> Give >>>>> us >>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>>> out >>>>> more >>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>>> _______________________________________________ >>>>> Quickfix-developers mailing list >>>>> Qui...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >>> >>> -- >>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: IT Product Guide on >>> ITManagersJournal >>> Use IT products in your business? Tell us what you think of them. >>> Give >>> us >>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>> out >>> more >>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > -- > > > -- > > > > |
|
From: Jon D. <jd...@wi...> - 2004-10-26 19:15:59
|
The optimum would be to have a general log(or Message Handler) which wouldn't be specific to a SenderCompID but could log events like this or events that aren't necessarily specific to a SenderCompID. Needless to say, logging to the *.event file is fine. I can put together a script to monitor those files. Thanks, -jd- > Yeah, what we could do is write to the event log when this happens, is > this what you are getting at? > > --oren > > On Oct 26, 2004, at 9:08 AM, Jon Dahl wrote: > >> Oren, >> >> I noticed the fix in CVS and was looking at it in a little more detail >> and I was wondering if there was anyway an exception could be thrown >> when unable to register the session - because there is already one >> registered for that SenderCompID. >> >> The reason being is, from an operational and troubleshooting >> standpoint this could be a nightmare if you don't know why the >> connection was dropped and the user simply states they can't connect >> to the Acceptor. >> >> Reference(hope the link doesn't break): >> http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/ >> SocketConnection.cpp?r1=1.8&r2=1.9 >> >> Thanks, >> >> -jd- >> >> >>> We have corrected this bug and added acceptance tests which are now >>> passing for both the SocketAcceptor and ThreadedSocketAcceptor. >>> >>> --oren >>> >>> On Oct 5, 2004, at 10:30 AM, Jon Dahl wrote: >>> >>>> QuickFIX Documentation: >>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>> QuickFIX FAQ: >>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >>>> QuickFIX Support: http://www.quickfixengine.org/services.html >>>> >>>> Yes, I'm using SocketAcceptor, not ThreadedSocketAcceptor. >>>> >>>> -jd- >>>> >>>>> Are you using the SocketAcceptor? Looking at it it looks to me >>>>> like the ThreadedSocketAcceptor is handling this situation >>>>> correctly by registering Session usage, but SocketAcceptor doesn't >>>>> appear to be doing so. >>>>> >>>>> --oren >>>>> >>>>> On Oct 5, 2004, at 9:41 AM, Jon Dahl wrote: >>>>> >>>>>> QuickFIX Documentation: >>>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>>>> QuickFIX FAQ: >>>>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html >>>>>> >>>>>> It seems that if a client connects to an Acceptor app with a >>>>>> SenderCompID >>>>>> already connected, it causes the MsgSeqNum to change to the new >>>>>> connection >>>>>> instead of just dropping the connection. >>>>>> >>>>>> Subsequently, the valid client can't enter valid messages until >>>>>> either >>>>>> it >>>>>> disconnects or the server is restarted. We reset our sequence >>>>>> numbers after disconnect and logoff. Those who don't, may run into >>>>>> a bigger problem. >>>>>> >>>>>> Anyone else run into this? >>>>>> >>>>>> QF 1.9.0 >>>>>> RHAS 2.1 >>>>>> gcc 3.04 >>>>>> -------- >>>>>> config: >>>>>> ..... >>>>>> ResetOnDisconnect=Y >>>>>> ResetOnLogout=Y >>>>>> >>>>>> -jd- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> This SF.net email is sponsored by: IT Product Guide on >>>>>> ITManagersJournal >>>>>> Use IT products in your business? Tell us what you think of them. >>>>>> Give >>>>>> us >>>>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>>>> out >>>>>> more >>>>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>>>> _______________________________________________ >>>>>> Quickfix-developers mailing list >>>>>> Qui...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.net email is sponsored by: IT Product Guide on >>>> ITManagersJournal >>>> Use IT products in your business? Tell us what you think of them. >>>> Give >>>> us >>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find >>>> out >>>> more >>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl >>>> _______________________________________________ >>>> Quickfix-developers mailing list >>>> Qui...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> >> >> -- >> >> >> -- -- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X