Menu
▾
▴
Re: [Quickfixj-users] Need help to make Failover work with QuickFIX/J
|
From: Christoph J. <chr...@ma...> - 2018-03-28 07:25:25
|
That last message with the workflow that you quoted below did not make it through to the list. At least I didn't receive it. If you want to prevent sending a Logon from an Initiator then you should implement the canLogon() method from the ApplicationExtended interface. If you then return false from that method, the Initiator will not try to logon. Which version of QFJ are you using? There was a change to the behaviour of the used socket addresses with https://github.com/quickfix-j/quickfixj/pull/152 which will be part of QFJ 2.0.1. Maybe that iteration behaviour will fit better to your situation. Chris. On 28/03/18 08:33, Rekha Hindlekar wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hello All, > > Any leads.. > > On Tue, Mar 27, 2018 at 11:16 AM, Rekha Hindlekar <rek...@or... > <mailto:rek...@or...>> wrote: > > Hello All, > > I have attached the work flow. If its round robin then how can we prevent sending login > request to both hosts from initiator. > Since initiator and acceptor both are developed by us using quickfix/j > > On Mon, Mar 26, 2018 at 7:30 PM, Øyvind Matheson Wergeland <oyv...@om... > <mailto:oyv...@om...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> > > > > The QF/J initiator will try to connect to the configured endpoints round robin. I guess > this is the behavior you see. > > -Øyvind > > 26. mar. 2018 kl. 12:21 skrev Christoph John via Quickfixj-users > <qui...@li... <mailto:qui...@li...>>: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> Hi, >> >> sorry, I still don't get the problem. >> So you have ONE initiator. And this initiator connects alternatively to "host" and >> "host1". I assume this happens on a connection disruption. It should not connect to >> "host1" as long as there is a connection to "host" established. >> Or are you telling me that the initiator sends a Logon to "host" and "host1" at the same >> time? >> >> Chris. >> >> >> On 26/03/18 11:22, Rekha Hindlekar wrote: >>>> Hello Christoph, >>>> >>>> I am planning to implement Failover, >>>> >>>> I run two instances of my FIX Acceptor application on two hosts viz.,*Host*and*Host_1*. >>>> >>>> I did configuration in Initiator Session by specifying **/*SocketConnectHost=Host */and >>>> /*SocketConnectHost1=Host_1*(and specified corresponding ports)./// >>>> >>>> I ran all the applications i.e. Initiator and Acceptor on both hosts, initially >>>> Initiator got connected to Acceptor running on/*Host.*/ >>>> /Now when I shut the Acceptor running on /*Host*//, sessions were established with >>>> /Acceptor running on*Host_1*./// >>>> /// >>>> /// >>>> ///When I restarted the Acceptor running on/*Host*, then Logon request from the >>>> Initiator was alternately sent to both the Acceptors running*Host*/and /*Host1*.////// >>> >>> >>> On Mon, Mar 26, 2018 at 2:05 PM, Christoph John <chr...@ma... >>> <mailto:chr...@ma...>> wrote: >>> >>> Hi, >>> >>> >>>> This observation is not according to that noted in the documentation URL. >>> >>> Which documented behaviour do you mean? The documentation you mentioned is about >>> Acceptors and does not talk about any behaviour regarding Initiators. >>> >>> What is the exact problem that you're having? >>> >>> Chris. >>> >>> >> -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
