Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christoph J. <chr...@ma...> - 2021-03-30 17:52:18
|
You're welcome. Thanks for reporting back. Am 30. März 2021 19:48:34 MESZ schrieb M J <mje...@gm...>: >Solved. Was pointing to old config for 4.4 instead for 5.0. My mistake. >Sorry about that and thanks for your time. > >Regards > >Matjaz > >On Tue, 30 Mar 2021, 16:13 M J, <mje...@gm...> wrote: > >> Indeed that is what already tried. I also suspect it does not load >correct >> one. Maybe when starting acceptor I can test which file was loaded? >> >> Tnxs so much >> >> Kr >> Matjaz >> >> On Tue, 30 Mar 2021, 15:13 Christoph John, <chr...@ma...> >> wrote: >> >>> All I can say at the moment is to double check your changes. We >alter the >>> dictionary all the time with additional values and it is working as >>> intended. Are you sure you are referencing the correct dictionary? >Maybe >>> try passing an absolute path. >>> Cheers >>> Chris >>> >>> Am 30. März 2021 15:04:08 MESZ schrieb M J <mje...@gm...>: >>>> >>>> Hi >>>> >>>> For field number 423 I added value enum 20 with description. This >data >>>> dictionary was saved and referenced in acceptor and initiator cfg >file >>>> UseDataDictionary=Y >>>> DataDictionary=./fixfiles/FIX_mod.xml >>>> >>>> However I am still getting >>>> >>>> Value is incorrect (out of range) for this tag >>>> >>>> Tnx for help. >>>> >>>> Regards >>>> >>>> Matjaz >>>> >>> |
|
From: M J <mje...@gm...> - 2021-03-30 17:48:56
|
Solved. Was pointing to old config for 4.4 instead for 5.0. My mistake. Sorry about that and thanks for your time. Regards Matjaz On Tue, 30 Mar 2021, 16:13 M J, <mje...@gm...> wrote: > Indeed that is what already tried. I also suspect it does not load correct > one. Maybe when starting acceptor I can test which file was loaded? > > Tnxs so much > > Kr > Matjaz > > On Tue, 30 Mar 2021, 15:13 Christoph John, <chr...@ma...> > wrote: > >> All I can say at the moment is to double check your changes. We alter the >> dictionary all the time with additional values and it is working as >> intended. Are you sure you are referencing the correct dictionary? Maybe >> try passing an absolute path. >> Cheers >> Chris >> >> Am 30. März 2021 15:04:08 MESZ schrieb M J <mje...@gm...>: >>> >>> Hi >>> >>> For field number 423 I added value enum 20 with description. This data >>> dictionary was saved and referenced in acceptor and initiator cfg file >>> UseDataDictionary=Y >>> DataDictionary=./fixfiles/FIX_mod.xml >>> >>> However I am still getting >>> >>> Value is incorrect (out of range) for this tag >>> >>> Tnx for help. >>> >>> Regards >>> >>> Matjaz >>> >> |
|
From: M J <mje...@gm...> - 2021-03-30 14:14:18
|
Indeed that is what already tried. I also suspect it does not load correct one. Maybe when starting acceptor I can test which file was loaded? Tnxs so much Kr Matjaz On Tue, 30 Mar 2021, 15:13 Christoph John, <chr...@ma...> wrote: > All I can say at the moment is to double check your changes. We alter the > dictionary all the time with additional values and it is working as > intended. Are you sure you are referencing the correct dictionary? Maybe > try passing an absolute path. > Cheers > Chris > > Am 30. März 2021 15:04:08 MESZ schrieb M J <mje...@gm...>: >> >> Hi >> >> For field number 423 I added value enum 20 with description. This data >> dictionary was saved and referenced in acceptor and initiator cfg file >> UseDataDictionary=Y >> DataDictionary=./fixfiles/FIX_mod.xml >> >> However I am still getting >> >> Value is incorrect (out of range) for this tag >> >> Tnx for help. >> >> Regards >> >> Matjaz >> > |
|
From: Christoph J. <chr...@ma...> - 2021-03-30 13:22:51
|
All I can say at the moment is to double check your changes. We alter the dictionary all the time with additional values and it is working as intended. Are you sure you are referencing the correct dictionary? Maybe try passing an absolute path. Cheers Chris Am 30. März 2021 15:04:08 MESZ schrieb M J <mje...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: M J <mje...@gm...> - 2021-03-30 13:04:31
|
Hi For field number 423 I added value enum 20 with description. This data dictionary was saved and referenced in acceptor and initiator cfg file UseDataDictionary=Y DataDictionary=./fixfiles/FIX_mod.xml However I am still getting Value is incorrect (out of range) for this tag Tnx for help. Regards Matjaz |
|
From: Christoph J. <chr...@ma...> - 2021-03-29 18:39:54
|
So I understood you correctly in my former mail? But why does your QFJ not support it? IMHO this should be supported since version 1.0. Chris Am 29. März 2021 19:36:48 MESZ schrieb Robert Nicholson <rob...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >Looking at Session.java it seems to be doing this in response to a Test >Request. > >> On Mar 29, 2021, at 10:06 AM, Colin DuPlantis ><co...@ma...> wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> FWIW, I have never heard of this requirement. >> >> On 3/29/21 7:02 AM, Robert Nicholson wrote: >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>> >>> >>> I’ve got vendor who’s told me we need to match the heartbeat to the >test request ID? >>> >>> How common is that and is it configurable that quickfixj do this? If >so after what version is this possible since it’s not happening with >1.5.2/3 but maybe I haven’t configured it to do so? >>> >>> _______________________________________________ >>> 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 > > > >_______________________________________________ >Quickfixj-users mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Robert N. <rob...@gm...> - 2021-03-29 17:37:05
|
Looking at Session.java it seems to be doing this in response to a Test Request. > On Mar 29, 2021, at 10:06 AM, Colin DuPlantis <co...@ma...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > FWIW, I have never heard of this requirement. > > On 3/29/21 7:02 AM, Robert Nicholson wrote: >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> I’ve got vendor who’s told me we need to match the heartbeat to the test request ID? >> >> How common is that and is it configurable that quickfixj do this? If so after what version is this possible since it’s not happening with 1.5.2/3 but maybe I haven’t configured it to do so? >> >> _______________________________________________ >> 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 |
|
From: Christoph J. <chr...@ma...> - 2021-03-29 16:32:22
|
Either I'm totally misunderstanding you or I don't know. QFJ should automatically answer a TestRequest with a heartbeat and echo the request ID from the TestRequest. This is a basic protocol thing. Example message log? Cheers Chris. Am 29. März 2021 16:02:17 MESZ schrieb Robert Nicholson <rob...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >I’ve got vendor who’s told me we need to match the heartbeat to the >test request ID? > >How common is that and is it configurable that quickfixj do this? If so >after what version is this possible since it’s not happening with >1.5.2/3 but maybe I haven’t configured it to do so? > >_______________________________________________ >Quickfixj-users mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Colin D. <co...@ma...> - 2021-03-29 15:31:51
|
FWIW, I have never heard of this requirement. On 3/29/21 7:02 AM, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I’ve got vendor who’s told me we need to match the heartbeat to the test request ID? > > How common is that and is it configurable that quickfixj do this? If so after what version is this possible since it’s not happening with 1.5.2/3 but maybe I haven’t configured it to do so? > > _______________________________________________ > 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: Robert N. <rob...@gm...> - 2021-03-29 14:02:28
|
I’ve got vendor who’s told me we need to match the heartbeat to the test request ID? How common is that and is it configurable that quickfixj do this? If so after what version is this possible since it’s not happening with 1.5.2/3 but maybe I haven’t configured it to do so? |
|
From: charles m. <xl...@gm...> - 2021-03-28 02:45:38
|
Hi, Yeah, I agree with you . When I deleted ToAppRejectMessageHandler ,the program is work well . Thanks for your help ! Cheers. Christoph John <chr...@ma...> 于2021年3月26日周五 下午7:47写道： > Hi, > > I am not entirely sure since I cannot make sense of all of your logging > output but I think the problem is as follows: > You get this message: > > message=8=FIXT.1.1^9=369^35=8^34=55^43=Y^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=113^ > > and then seem to apply some logic to it in the > "ToAppRejectMessageHandler". After that the same ExecReport is logged but > with PossDup set to false (43=N): > > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : added > possDupFlag:8=FIXT.1.1^9=369^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=102^ > > And then I think you pass that ExecReport to QFJ instead of the original > one with PossDup=Y. > > This would support what I wrote in my initial mail that something about > the PossDup handling seems to be wrong. > When the PossDup flag is not set or set to false then the seqnum of that > message is checked against the next expected seqnum. Since the next > expected seqnum is 56 the session is getting logged out. > > In general I would not suggest to interfere with the session-level > processing but let QFJ do its job. :) > What do you think? Does this make sense to you? > > Cheers, > Chris. > > > > > On 26.03.21 09:46, charles meng wrote: > > > Here is the message log for 2.1.1. > > 2021-03-26 08:42:35.704 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.listener.FixApplicationListener : =>> Send toApp message to FIX > gateway, MsgType=ExecutionReport(8), MsgSeqNum=55 > sessionId=FIXT.1.1:Initiator->Acceptor > > message=8=FIXT.1.1^9=338^35=8^34=55^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=103^ > 2021-03-26 08:42:35.704 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.listener.SenderMessageCracker : ExecutionReport - handle > ExecutionReport message > 2021-03-26 08:42:35.707 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.d.handle.MessageHandlerContext : ===cracker type :TO_APP_REJECT > 2021-03-26 08:42:35.707 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.d.handle.MessageHandlerContext : ====do handle > 2021-03-26 08:42:35.707 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.d.h.ToAppRejectMessageHandler : ===not approved retransmit > 2021-03-26 08:42:35.708 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.listener.FixApplicationListener : added > possDupFlag:8=FIXT.1.1^9=343^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=086^ > 2021-03-26 08:42:35.708 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.listener.FixApplicationListener : possDubFlag:false > 2021-03-26 08:42:35.711 INFO 40318 --- [nio-9051-exec-2] > c.m.f.s.infra.SenderApplicationService : [API Call] > sendHigherSeqNoThanExcepted success，higherThanExpected=55, msgType=8 > 2021-03-26 08:42:35.714 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : <<= Initiator received fromAdmin > message, MsgType=Resend(2), MsgSeqNum=42 > sessionId: FIXT.1.1:Initiator->Acceptor > message: > 8=FIXT.1.1^9=78^35=2^34=42^49=Acceptor^52=20210326-08:42:35.711^56=Initiator^369=49^7=50^16=0^10=063^ > 2021-03-26 08:42:35.714 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.SenderMessageCracker : ResendRequest - from, > beginSeqNo=50, endSeqNo=0 > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : =>> Send toApp message to FIX > gateway, MsgType=ExecutionReport(8), MsgSeqNum=55 > sessionId=FIXT.1.1:Initiator->Acceptor > > message=8=FIXT.1.1^9=369^35=8^34=55^43=Y^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=113^ > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.SenderMessageCracker : ExecutionReport - handle > ExecutionReport message > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.d.handle.MessageHandlerContext : ===cracker type :TO_APP_REJECT > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.d.handle.MessageHandlerContext : ====do handle > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.d.h.ToAppRejectMessageHandler : ===not approved retransmit > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : added > possDupFlag:8=FIXT.1.1^9=369^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=102^ > 2021-03-26 08:42:35.718 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : possDubFlag:false > 2021-03-26 08:42:35.719 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : =>> Send toAdmin message to FIX > gateway, MsgType=SequenceReset(4), MsgSeqNum=50 > sessionId: FIXT.1.1:Initiator->Acceptor > message: > 8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^ > 2021-03-26 08:42:35.719 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.SenderMessageCracker : SequenceReset - to > 2021-03-26 08:42:35.719 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.SenderMessageCracker : expected sender num compare to > new seq no:true,NewSeqNo:55,ExpectedSenderNum:56 > 2021-03-26 08:42:35.719 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.SenderMessageCracker : SequenceReset > finally:8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^ > 2021-03-26 08:42:35.726 INFO 40318 --- [ssage Processor] > c.m.f.s.listener.FixApplicationListener : <<= Initiator received fromAdmin > message, MsgType=Logout(5), MsgSeqNum=43 > sessionId: FIXT.1.1:Initiator->Acceptor > message: > 8=FIXT.1.1^9=126^35=5^34=43^49=Acceptor^52=20210326-08:42:35.723^56=Initiator^369=55^1128=9^58=MsgSeqNum > too low, expecting 56 but received 55^10=010^ > > > Thanks > Best regards. > > Christoph John <chr...@ma...> 于2021年3月26日周五 下午2:43写道： > >> Just saw that you are using 2.1.1. The other side uses the same version? >> Could you maybe try to reproduce with version 2.2.0 and paste the >> relevant message log? Or at least paste the message log from your currently >> used version. >> Thanks >> >> Am 26. März 2021 07:40:23 MEZ schrieb Christoph John < >> chr...@ma...>: >>> >>> Hi, >>> which version of QFJ are you and the other side using? >>> Could you please directly paste the relevant message log from your side >>> and if possible also from the acceptor? >>> Thanks, >>> Chris. >> >> > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
|
From: Christoph J. <chr...@ma...> - 2021-03-28 00:28:32
|
Hi, there is no out-of-the-box solution but you could take a look at the tests in SessionTest. https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/test/java/quickfix/SessionTest.java For example this one takes some messages, alters seqnums and checks the result: https://github.com/quickfix-j/quickfixj/blob/1968f7abb981f486539a4cf3e4ae81fa5c554ec8/quickfixj-core/src/test/java/quickfix/SessionTest.java#L1962 All of the used methods in the Session class are public, so it is possible to copy that test more or less verbatim to your code base and test it with different versions by exchanging the quickfixj-core JAR file for example. There also is a test for QFJ-673 here https://github.com/quickfix-j/quickfixj/blob/1968f7abb981f486539a4cf3e4ae81fa5c554ec8/quickfixj-core/src/test/java/quickfix/SessionTest.java#L1403 But I don't know if that is the exact problem that you are encountering. Let me know how it went. Cheers, Chris. On 27.03.21 15:11, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Is there anything where by I can take a file from a FileLog replay it and observe the behavior of the FIX engine? > > I want to do this for different versions of the QuickFIXJ to see the behavior of the engine with a particular file. > > Which if any unit test would be one to start with if I wanted to play thru both admin and business messages and setting up the FileStore initially with the expected values. > > _______________________________________________ > 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 15:06:59
|
Keep in mind that the message store stores only outbound messages. On Sat, Mar 27, 2021, 7:12 AM Robert Nicholson <rob...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Is there anything where by I can take a file from a FileLog replay it and > observe the behavior of the FIX engine? > > I want to do this for different versions of the QuickFIXJ to see the > behavior of the engine with a particular file. > > Which if any unit test would be one to start with if I wanted to play thru > both admin and business messages and setting up the FileStore initially > with the expected values. > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Robert N. <rob...@gm...> - 2021-03-27 14:12:02
|
Is there anything where by I can take a file from a FileLog replay it and observe the behavior of the FIX engine? I want to do this for different versions of the QuickFIXJ to see the behavior of the engine with a particular file. Which if any unit test would be one to start with if I wanted to play thru both admin and business messages and setting up the FileStore initially with the expected values. |
|
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 |
|
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: Christoph J. <chr...@ma...> - 2021-03-27 00:54:59
|
Hi, it is not uncommon that old (resent) messages can be interleaved with new ones. All messages which have too high a seqnum need to be queued until the ResendRequest has been satisfied. Without browsing all closed issues since version 1.5.2 I could imagine that there *might* be a bug which does not handle this correctly. But to be really sure I guess I would need some more information like message logs. You had a similar issue back in September where I thought it could be related to https://www.quickfixj.org/jira/browse/QFJ-673 . But maybe it only sounds like it is the same issue. Cheers, Chris. On 26.03.21 22:42, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Does anybody know what the typical implementation is when an acceptor has to satisfy a resend request but also send you current message flow. > > Are there implementations that wait too see if they are going to get a resend request soon after logon before sending you current flow? > > I’m seeing with quickfixj at least one provider who may not be doing this and it seems to cause issues. where they haven’t fully satisfied by resend request before the begin sending me current messages. > > That said I don’t have any direct evidence that this is the problem just that only this one provider seems to have difficulty recovering the session and I know in their case they’ve implemented their own fix engine. > > and since I’m on an older version of quickfixj (1.5.2 with stack overflow resend fix) I’m trying to understand what the limitations are. > > _______________________________________________ > 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: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: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: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: Christoph J. <chr...@ma...> - 2021-03-27 00:12:05
|
Hi Matjaž, the dictionary was generated using the fix-orchestra-quickfix project on github. https://github.com/FIXTradingCommunity/fix-orchestra-quickfix#repository-quickfix Cheers, Chris. On 26.03.21 21:11, M J wrote: > Hi Chris, > > I hope you do not mind me asking how you generated this FixLatest.xml. > > Thanks for all the references. My fix is up and running. > > Nice weekend to you all. > Kind regards > > Matjaž > > > > V V sre., 24. mar. 2021 ob 13:39 je oseba Christoph John <chr...@ma... > <mailto:chr...@ma...>> napisala: > > As Philip pointed out there will be no third FIX5.0 ServicePack. Instead the "version" > FIXLatest will be used which will include subsequent EPs. > QFJ does not yet have full support for FIXLatest but you could simply use a generated > dictionary (see attached). On the wire FIXLatest will look like FIX5.0 but with ApplVerID 10 = > FIXLatest. > > Cheers, > Chris. > > > On 24.03.21 11:47, M J wrote: >> 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, >> >> Therefore I need to wait for quickfix/J will implement EP that includes this field? >> >> Kind regards >> >> Matjaz >> >> On Wed, 24 Mar 2021, 10:46 Philip Whitehouse, <ph...@wh... <mailto:ph...@wh...>> 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/> >> >> >> Following FIX 5.0, the FIX community has updated the spec with a series of extension >> packs, (EPs). >> >> A first and second batch of these EPs were collected into SP1 and SP2. >> >> However since SP2 many more extension packs have been released and there is no subsequent SP. >> >> It’s now most organised via negotiation with counter parties as to which precise EP-based >> spec to follow. >> >> Best, >> >> Philip Whitehouse >> >>> On 24 Mar 2021, at 08:48, Andrew Marlow <mar...@gm... >>> <mailto:mar...@gm...>> wrote: >>> >>> 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/> >>> >>> >>> Hello everyone, >>> >>> According to >>> https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html >>> <https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html> >>> this tag was added in fix50-sp2 107. I am not sure what the 107 means but maybe it is an >>> addition. The web site that I normally use to check FIX values, >>> https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html >>> <https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html>, doesn't have this >>> tag. Maybe it is a recent addition? >>> >>> >>> >>> On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm... <mailto:mje...@gm...>> 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/> >>> >>> >>> Hi, >>> >>> Using fix50sp2 I am missing field 1523 - TrdAckStatus. >>> >>> What did I miss? >>> >>> Thanks >>> >>> Matjaz >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... <mailto:Qui...@li...> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> >>> >>> >>> >>> -- >>> Regards, >>> >>> Andrew Marlow >>> http://www.andrewpetermarlow.co.uk <http://www.andrewpetermarlow.co.uk> >>> >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... <mailto:Qui...@li...> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> >> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <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 > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- 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: 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: Robert N. <rob...@gm...> - 2021-03-26 21:43:17
|
Does anybody know what the typical implementation is when an acceptor has to satisfy a resend request but also send you current message flow. Are there implementations that wait too see if they are going to get a resend request soon after logon before sending you current flow? I’m seeing with quickfixj at least one provider who may not be doing this and it seems to cause issues. where they haven’t fully satisfied by resend request before the begin sending me current messages. That said I don’t have any direct evidence that this is the problem just that only this one provider seems to have difficulty recovering the session and I know in their case they’ve implemented their own fix engine. and since I’m on an older version of quickfixj (1.5.2 with stack overflow resend fix) I’m trying to understand what the limitations are. |
|
From: M J <mje...@gm...> - 2021-03-26 20:12:34
|
Hi Chris, I hope you do not mind me asking how you generated this FixLatest.xml. Thanks for all the references. My fix is up and running. Nice weekend to you all. Kind regards Matjaž V V sre., 24. mar. 2021 ob 13:39 je oseba Christoph John < chr...@ma...> napisala: > As Philip pointed out there will be no third FIX5.0 ServicePack. Instead > the "version" FIXLatest will be used which will include subsequent EPs. > QFJ does not yet have full support for FIXLatest but you could simply use > a generated dictionary (see attached). On the wire FIXLatest will look like > FIX5.0 but with ApplVerID 10 = FIXLatest. > > Cheers, > Chris. > > > On 24.03.21 11:47, M J wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > Therefore I need to wait for quickfix/J will implement EP that includes > this field? > > Kind regards > > Matjaz > > On Wed, 24 Mar 2021, 10:46 Philip Whitehouse, <ph...@wh...> wrote: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ >> >> >> Following FIX 5.0, the FIX community has updated the spec with a series >> of extension packs, (EPs). >> >> A first and second batch of these EPs were collected into SP1 and SP2. >> >> However since SP2 many more extension packs have been released and there >> is no subsequent SP. >> >> It’s now most organised via negotiation with counter parties as to which >> precise EP-based spec to follow. >> >> Best, >> >> Philip Whitehouse >> >> On 24 Mar 2021, at 08:48, Andrew Marlow <mar...@gm...> wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hello everyone, >> >> According to >> https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html >> this tag was added in fix50-sp2 107. I am not sure what the 107 means but >> maybe it is an addition. The web site that I normally use to check FIX >> values, https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html, >> doesn't have this tag. Maybe it is a recent addition? >> >> >> >> On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm...> wrote: >> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >>> http://www.quickfixj.org/support/ >>> >>> >>> Hi, >>> >>> Using fix50sp2 I am missing field 1523 - TrdAckStatus. >>> >>> What did I miss? >>> >>> Thanks >>> >>> Matjaz >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> >> >> >> -- >> Regards, >> >> Andrew Marlow >> http://www.andrewpetermarlow.co.uk >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> > > > _______________________________________________ > Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
103 messages has been excluded from this view by a project administrator.
