From: Andrew G. <al...@gm...> - 2021-03-26 22:39:53
|
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! |
From: Christoph J. <chr...@ma...> - 2021-03-27 00:31:51
|
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 |
From: Colin D. <co...@ma...> - 2021-03-27 00:34:54
|
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 |
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 |
From: Colin D. <co...@ma...> - 2021-03-27 00:51:51
|
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 |
From: Christoph J. <chr...@ma...> - 2021-03-27 00:57:45
|
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 |
From: Colin D. <co...@ma...> - 2021-03-27 01:06:31
|
Yeah, I can do it. Let me take a look at the PR you indicated and I'll see if I can figure out where to stick in the changes and tests. On 3/26/21 5:57 PM, Christoph John wrote: > 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 -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |