Re: [Quickfixj-users] Initiator failover due to acceptor compID already in use

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

This is exactly like we have implemented it some time ago. But we never came around using it.


On 19/11/2018 17:18, Colin DuPlantis wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> No, I think you would be better off with a hot-warm configuration than a hot-hot one.
>
> We manage this by having one running process with an active FIX initiator and one running process 
> with the same settings but the initiator hasn't been started. If the first process goes down, the 
> second one automatically starts the FIX initiator. The first process actively suppresses the start 
> in the second, so, if the first process goes away, the second process will automatically start the 
> FIX sessions.
>
> On 11/19/18 8:05 AM, Tsz Shun Chow wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Yes. It’s basically our system tried to use a live-live (a pair of) FIX connections with the same 
>> targetCompID.
>>
>> Let’s say I run two instances (processes) of the app for redundancy. And they both have two 
>> addresses to initiate connections. So the remote peer has the connection with one of them. The 
>> another one is now stuck on trying the first because of the git commit I mentioned.
>>
>> Is it architecturally desirable using the same compID this way? We used the same to avoid two of 
>> our apps connecting to the same remote acceptor.
>>
>> On Mon, 19 Nov 2018 at 15:31, Christoph John <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>>     Hi,
>>
>>     sorry, I do not understand what you mean. When you say:
>>
>>>     when acceptor compID already in use by another initiator.
>>
>>     do you mean that the remote peer already has an established connection with another
>>     counterparty (instead of you)?
>>
>>     Chris.
>>
>>
>>
>>     On 19/11/2018 12:20, Tsz Shun Chow wrote:
>>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>     Hi all,
>>>
>>>     We have recently found a problem that Initiator failover was stuck with the first address
>>>     when acceptor compID already in use by another initiator.
>>>
>>>     It seem to be related to this, though I think the change only exposed the bug, not created it.
>>>
>>>     https://github.com/quickfix-j/quickfixj/commit/622b858d4a6d972b0d2006b5029f2be354d1dcdc
>>>
>>>     In the case of targetCompID in use, the session was connected and active, so the address
>>>     index set to one, even it was dropped afterwards. Then the initiator will try and fail
>>>     forever until the session of the targetCompID is available again.
>>>
>>>     How could the initiator detect the targetCompID in use and therefore could try next address
>>>     in the list?
>>>
>>>     Cheers
>>>     Jason
>>>

-- 
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