Re: [Quickfixj-users] How to trigger a failover from the user code?

[Christoph J. <chr...@ma...>]

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