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

[Colin D. <co...@ma...>]

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
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103 52066 Aachen, Germany  <https://maps.google.com/?q=Oppenhoffallee+103%0D%0A52066+Aachen,+Germany&entry=gmail&source=g>
>     www.macd.com  <http://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