|
From: Christoph J. <chr...@ma...> - 2021-03-27 00:43:56
|
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 |