|
From: Colin D. <co...@ma...> - 2021-03-27 01:06:31
|
Yeah, I can do it. Let me take a look at the PR you indicated and I'll see if I can figure out where to stick in the changes and tests. On 3/26/21 5:57 PM, Christoph John wrote: > That was also the idea in the PR I mentioned but was not done at that > time. > Sounds like a good idea to me. How should we do it? Would you like to > create a draft PR which we can work on or what kind of help would you > need from me? > > Thanks in advance! > > > On 27.03.21 01:51, Colin DuPlantis wrote: >> >> The solution I would prefer (and I would be willing to help work on >> it) would be to rely on an interface which provides a selection >> strategy. The simplest one could simply round-robin and OP could sub >> in a more complicated one with arbitrary inputs. >> >> On 3/26/21 5:43 PM, Christoph John wrote: >>> This is a valid point. I think neither logic can satisfy all cases. >>> Actually the current logic was introduced only two versions ago with >>> https://github.com/quickfix-j/quickfixj/pull/152 and would switch >>> back to the first host after a disconnection, no matter what. E.g. >>> if there was a seqnum-too-low mismatch at host 3 (after host 1 and 2 >>> were unreachable) it would then switch back to host 1, so no >>> difference there. >>> >>> Cheers, >>> Chris. >>> >>> >>> >>> On 27.03.21 01:34, Colin DuPlantis wrote: >>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>> >>>> >>>> >>>> I would think we would want to be careful about introducing >>>> semantics where a successful network connection still resulted in >>>> switching to the next host if the counter disconnected. >>>> >>>> For example, what if the wrong sequence number is sent? We wouldn't >>>> want to fail to the next host then, right? How would we tell the >>>> difference between that usecase and this one where the counter is >>>> disconnecting a valid network connection for business reasons. >>>> >>>> On 3/26/21 5:31 PM, Christoph John via Quickfixj-users wrote: >>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> unfortunately it is not possible to do this. >>>>> The only thing I could think of at the moment is to configure two >>>>> separate sessions, each with its own SocketConnectHost and do the >>>>> failover between the two sessions in the application logic. Or >>>>> simply let both run and CME reject one of the sessions when it >>>>> tries to connect. >>>>> >>>>> The failover logic in QFJ only works when the connection is >>>>> unsuccessful. However, by CME accepting the connection the logic >>>>> is getting tricked. >>>>> I think it would be not so difficult to change this. We could >>>>> introduce a configuration which switches between the current >>>>> behaviour (Next connection attempt after a successful connection >>>>> will start at first defined connection again) and a round-robin >>>>> one which cycles through the hosts regardless of whether the last >>>>> connection was successful or not. >>>>> >>>>> Cheers, >>>>> Chris. >>>>> >>>>> >>>>> >>>>> On 26.03.21 23:39, Andrew Gurinovich wrote: >>>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>>>> >>>>>> >>>>>> >>>>>> Hi. >>>>>> When you connect and try to LOGIN to secondary(backup) IP address >>>>>> for CME fix dropcopy while the primary host is active, you are >>>>>> getting an LOGOUT: >>>>>> >>>>>> "8=FIX.4.2|35=5|49=CME|58=Backup session not allowed. Logout >>>>>> forced". >>>>>> >>>>>> You are supposed to failover to the other host then. >>>>>> >>>>>> We can handle the logout event in Application.fromAdmin, but i >>>>>> cant seem to find a way to failover to another SocketConnectHost >>>>>> manually - the Session does not expose >>>>>> IoSessionInitiator.getNextSocketAddress(where the address is >>>>>> updated). And even if it was exposed, after the LOGOUT happens >>>>>> the initiator is recreated, starting with the same first >>>>>> SocketConnectHost. >>>>>> >>>>>> Is there a way to trigger a failover manually in fromAdmin method >>>>>> in the Application? >>>>>> Thanks! >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Quickfixj-users mailing list >>>>>> Qui...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>>>> >>>>> -- >>>>> Christoph John >>>>> Software Engineering >>>>> T +49 241 557080-28 >>>>> chr...@ma... >>>>> >>>>> MACD GmbH >>>>> Oppenhoffallee 103 >>>>> 52066 Aachen, Germany >>>>> www.macd.com >>>>> >>>>> Amtsgericht Aachen: HRB 8151 >>>>> Ust.-Id: DE 813021663 >>>>> Geschäftsführer: George Macdonald >>>>> >>>>> >>>>> _______________________________________________ >>>>> Quickfixj-users mailing list >>>>> Qui...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>>> -- >>>> Colin DuPlantis >>>> Chief Architect, Marketcetera >>>> Download, Run, Trade >>>> 888.868.4884 >>>> https://www.marketcetera.com >>>> >>>> >>>> _______________________________________________ >>>> Quickfixj-users mailing list >>>> Qui...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> >>> -- >>> Christoph John >>> Software Engineering >>> T +49 241 557080-28 >>> chr...@ma... >>> >>> MACD GmbH >>> Oppenhoffallee 103 >>> 52066 Aachen, Germany >>> www.macd.com >>> >>> Amtsgericht Aachen: HRB 8151 >>> Ust.-Id: DE 813021663 >>> Geschäftsführer: George Macdonald >> -- >> Colin DuPlantis >> Chief Architect, Marketcetera >> Download, Run, Trade >> 888.868.4884 >> https://www.marketcetera.com > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |