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: Visa H. <vis...@gm...> - 2021-01-18 13:04:07
|
Actually, I seem to have made a typo in the code - sorry about the confusion! Visa ma 18. tammik. 2021 klo 14.56 Christoph John <chr...@ma...> kirjoitti: > Are you able to build the current snapshot version 2.2.1 from > https://github.com/quickfix-j/quickfixj ? > There is the following PR included which should improve start/stop > behaviour: https://github.com/quickfix-j/quickfixj/pull/324 > > Please let me know if it works as expected. > > Cheers, > Chris. > > > > On 18.01.21 13:51, Visa Holopainen wrote: > > I have now upgraded to 2.2.0, but the issue remains. > > -Visa > > On Mon, Jan 18, 2021 at 2:17 PM Christoph John <chr...@ma...> > wrote: > >> Hmm, there is no version 1.7.0 of QuickFIX/J. Are you sure that you are >> using the Java port of QuickFIX? >> Apart from that, yes upgrading could help since there were some race >> conditions fixed since version 1.6.4 (after which version 2.0.0 was >> released). >> >> Cheers, >> Chris. >> >> >> On 18.01.21 12:53, Visa Holopainen wrote: >> >> I am using version 1.7.0. Should I upgrade to for example 2.2.1? >> >> Thanks! >> Visa >> >> On Mon, Jan 18, 2021 at 1:15 PM Christoph John <chr...@ma...> >> wrote: >> >>> Hi, >>> >>> which version of QFJ are you using? Looks like a race condition to me. >>> >>> Cheers, >>> Chris. >>> >>> >>> On 18.01.21 11:46, Visa Holopainen wrote: >>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>> >>> >>> Hi! >>> >>> I have two FIX sessions, and two Initiators. >>> >>> private Initiator init1; >>> private Initiator init2; >>> >>> I create the Initiators, and start them: >>> >>> init1.start(); >>> init2.start(); >>> >>> Sometimes I need to stop the sessions (restart my software). In this >>> case I run: >>> >>> init1.stop(); >>> init2.stop(); >>> >>> Then, after I start again (run the start methods again) *one of the FIX >>> sessions gives "Session not found"* when trying to do: >>> >>> Session.sendToTarget(msg); >>> >>> Here is the FIX message sequence from the session that is working after >>> restart (I send a test request in that session at the beginning): >>> >>> 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | >>> 56=THEIREND1 | 98=0 | 108=11 | 10=158 | >>> 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:05.597 | 98=0 | 108=11 | 10=255 | >>> 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | >>> 52=20210118-07:30:07.578 | 56=THEIREND1 | 112=20210118083007 | 10=061 | >>> 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:07.581 | 112=20210118083007 | 10=099 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | >>> 56=THEIREND1 | 10=114 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:18.577 | 10=215 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | >>> 56=THEIREND1 | 10=117 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:29.577 | 10=218 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | >>> 56=THEIREND1 | 10=111 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:40.577 | 10=212 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | >>> 56=THEIREND1 | 10=114 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:30:51.577 | 10=215 | >>> 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | >>> 56=THEIREND1 | 10=116 | >>> 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:31:00.577 | 10=216 | >>> 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | >>> 56=THEIREND1 | 98=0 | 108=11 | 10=161 | >>> 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:31:32.601 | 98=0 | 108=11 | 10=249 | >>> 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | >>> 52=20210118-07:31:34.580 | 56=THEIREND1 | 112=20210118083134 | 10=063 | >>> 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:31:34.584 | 112=20210118083134 | 10=111 | >>> 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 >>> | 56=THEIREND1 | 10=167 | >>> 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:31:45.580 | 10=001 | >>> 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 >>> | 56=THEIREND1 | 10=170 | >>> 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | >>> 52=20210118-07:31:56.580 | 10=004 | >>> ... >>> >>> Here is the FIX message sequence from the session that gives the >>> "Session not found": >>> >>> 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | >>> 56=THEIREND2 | 98=0 | 108=30 | 10=105 | >>> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | >>> 52=20210118-07:30:05.599 | 98=0 | 108=30 | 10=110 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | >>> 52=20210118-07:30:35.600 | 10=052 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | >>> 56=THEIREND2 | 10=069 | >>> 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | >>> 56=THEIREND2 | 10=065 | >>> 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | >>> 52=20210118-07:31:01.581 | 58=Replying to logout | 10=242 | >>> 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | >>> 56=THEIREND2 | 98=0 | 108=30 | 10=114 | >>> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | >>> 52=20210118-07:31:32.604 | 98=0 | 108=30 | 10=101 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | >>> 52=20210118-07:32:02.604 | 10=055 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | >>> 56=THEIREND2 | 10=054 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | >>> 52=20210118-07:32:32.605 | 10=060 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | >>> 56=THEIREND2 | 10=058 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | >>> 52=20210118-07:33:02.605 | 10=059 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | >>> 56=THEIREND2 | 10=057 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | >>> 52=20210118-07:33:32.606 | 10=064 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | >>> 56=THEIREND2 | 10=062 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | >>> 52=20210118-07:34:02.606 | 10=063 | >>> ... >>> >>> Any idea what I'm doing wrong? >>> >>> -Visa >>> ... >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >> -- >> 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 >> >> > -- > 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-01-18 12:57:07
|
Are you able to build the current snapshot version 2.2.1 from https://github.com/quickfix-j/quickfixj ? There is the following PR included which should improve start/stop behaviour: https://github.com/quickfix-j/quickfixj/pull/324 Please let me know if it works as expected. Cheers, Chris. On 18.01.21 13:51, Visa Holopainen wrote: > I have now upgraded to 2.2.0, but the issue remains. > > -Visa > > On Mon, Jan 18, 2021 at 2:17 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hmm, there is no version 1.7.0 of QuickFIX/J. Are you sure that you are using the Java port of > QuickFIX? > Apart from that, yes upgrading could help since there were some race conditions fixed since > version 1.6.4 (after which version 2.0.0 was released). > > Cheers, > Chris. > > > On 18.01.21 12:53, Visa Holopainen wrote: >> I am using version 1.7.0. Should I upgrade to for example 2.2.1? >> >> Thanks! >> Visa >> >> On Mon, Jan 18, 2021 at 1:15 PM Christoph John <chr...@ma... >> <mailto:chr...@ma...>> wrote: >> >> Hi, >> >> which version of QFJ are you using? Looks like a race condition to me. >> >> Cheers, >> Chris. >> >> >> On 18.01.21 11:46, Visa Holopainen 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! >>> >>> I have two FIX sessions, and two Initiators. >>> >>> private Initiator init1; >>> private Initiator init2; >>> >>> I create the Initiators, and start them: >>> >>> init1.start(); >>> init2.start(); >>> >>> Sometimes I need to stop the sessions (restart my software). In this case I run: >>> >>> init1.stop(); >>> init2.stop(); >>> >>> Then, after I start again (run the start methods again) *one of the FIX sessions gives >>> "Session not found"* when trying to do: >>> >>> Session.sendToTarget(msg); >>> >>> Here is the FIX message sequence from the session that is working after restart (I send >>> a test request in that session at the beginning): >>> >>> 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | 56=THEIREND1 | >>> 98=0 | 108=11 | 10=158 | >>> 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:05.597 >>> | 98=0 | 108=11 | 10=255 | >>> 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:30:07.578 | >>> 56=THEIREND1 | 112=20210118083007 | 10=061 | >>> 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:07.581 >>> | 112=20210118083007 | 10=099 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | 56=THEIREND1 | >>> 10=114 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:18.577 >>> | 10=215 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | 56=THEIREND1 | >>> 10=117 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:29.577 >>> | 10=218 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | 56=THEIREND1 | >>> 10=111 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:40.577 >>> | 10=212 | >>> 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | 56=THEIREND1 | >>> 10=114 | >>> 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:51.577 >>> | 10=215 | >>> 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | 56=THEIREND1 | >>> 10=116 | >>> 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:00.577 >>> | 10=216 | >>> 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | 56=THEIREND1 | >>> 98=0 | 108=11 | 10=161 | >>> 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:32.601 >>> | 98=0 | 108=11 | 10=249 | >>> 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:31:34.580 | >>> 56=THEIREND1 | 112=20210118083134 | 10=063 | >>> 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:34.584 >>> | 112=20210118083134 | 10=111 | >>> 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 | 56=THEIREND1 | >>> 10=167 | >>> 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:45.580 >>> | 10=001 | >>> 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 | 56=THEIREND1 | >>> 10=170 | >>> 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:56.580 >>> | 10=004 | >>> ... >>> >>> Here is the FIX message sequence from the session that gives the "Session not found": >>> >>> 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | 56=THEIREND2 | >>> 98=0 | 108=30 | 10=105 | >>> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | 52=20210118-07:30:05.599 | >>> 98=0 | 108=30 | 10=110 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | 52=20210118-07:30:35.600 | >>> 10=052 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | 56=THEIREND2 | >>> 10=069 | >>> 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | 56=THEIREND2 | >>> 10=065 | >>> 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | 52=20210118-07:31:01.581 | >>> 58=Replying to logout | 10=242 | >>> 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | 56=THEIREND2 | >>> 98=0 | 108=30 | 10=114 | >>> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | 52=20210118-07:31:32.604 | >>> 98=0 | 108=30 | 10=101 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | 52=20210118-07:32:02.604 | >>> 10=055 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | 56=THEIREND2 | >>> 10=054 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | 52=20210118-07:32:32.605 | >>> 10=060 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | 56=THEIREND2 | >>> 10=058 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | 52=20210118-07:33:02.605 | >>> 10=059 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | 56=THEIREND2 | >>> 10=057 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | 52=20210118-07:33:32.606 | >>> 10=064 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | 56=THEIREND2 | >>> 10=062 | >>> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | 52=20210118-07:34:02.606 | >>> 10=063 | >>> ... >>> >>> Any idea what I'm doing wrong? >>> >>> -Visa >>> ... >>> >>> >>> _______________________________________________ >>> 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... <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: Visa H. <vis...@gm...> - 2021-01-18 12:52:09
|
I have now upgraded to 2.2.0, but the issue remains. -Visa On Mon, Jan 18, 2021 at 2:17 PM Christoph John <chr...@ma...> wrote: > Hmm, there is no version 1.7.0 of QuickFIX/J. Are you sure that you are > using the Java port of QuickFIX? > Apart from that, yes upgrading could help since there were some race > conditions fixed since version 1.6.4 (after which version 2.0.0 was > released). > > Cheers, > Chris. > > > On 18.01.21 12:53, Visa Holopainen wrote: > > I am using version 1.7.0. Should I upgrade to for example 2.2.1? > > Thanks! > Visa > > On Mon, Jan 18, 2021 at 1:15 PM Christoph John <chr...@ma...> > wrote: > >> Hi, >> >> which version of QFJ are you using? Looks like a race condition to me. >> >> Cheers, >> Chris. >> >> >> On 18.01.21 11:46, Visa Holopainen wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hi! >> >> I have two FIX sessions, and two Initiators. >> >> private Initiator init1; >> private Initiator init2; >> >> I create the Initiators, and start them: >> >> init1.start(); >> init2.start(); >> >> Sometimes I need to stop the sessions (restart my software). In this case >> I run: >> >> init1.stop(); >> init2.stop(); >> >> Then, after I start again (run the start methods again) *one of the FIX >> sessions gives "Session not found"* when trying to do: >> >> Session.sendToTarget(msg); >> >> Here is the FIX message sequence from the session that is working after >> restart (I send a test request in that session at the beginning): >> >> 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | >> 56=THEIREND1 | 98=0 | 108=11 | 10=158 | >> 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:05.597 | 98=0 | 108=11 | 10=255 | >> 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | >> 52=20210118-07:30:07.578 | 56=THEIREND1 | 112=20210118083007 | 10=061 | >> 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:07.581 | 112=20210118083007 | 10=099 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | >> 56=THEIREND1 | 10=114 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:18.577 | 10=215 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | >> 56=THEIREND1 | 10=117 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:29.577 | 10=218 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | >> 56=THEIREND1 | 10=111 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:40.577 | 10=212 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | >> 56=THEIREND1 | 10=114 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:30:51.577 | 10=215 | >> 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | >> 56=THEIREND1 | 10=116 | >> 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:31:00.577 | 10=216 | >> 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | >> 56=THEIREND1 | 98=0 | 108=11 | 10=161 | >> 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:31:32.601 | 98=0 | 108=11 | 10=249 | >> 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | >> 52=20210118-07:31:34.580 | 56=THEIREND1 | 112=20210118083134 | 10=063 | >> 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:31:34.584 | 112=20210118083134 | 10=111 | >> 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 | >> 56=THEIREND1 | 10=167 | >> 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:31:45.580 | 10=001 | >> 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 | >> 56=THEIREND1 | 10=170 | >> 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | >> 52=20210118-07:31:56.580 | 10=004 | >> ... >> >> Here is the FIX message sequence from the session that gives the "Session >> not found": >> >> 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | >> 56=THEIREND2 | 98=0 | 108=30 | 10=105 | >> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | >> 52=20210118-07:30:05.599 | 98=0 | 108=30 | 10=110 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | >> 52=20210118-07:30:35.600 | 10=052 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | >> 56=THEIREND2 | 10=069 | >> 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | >> 56=THEIREND2 | 10=065 | >> 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | >> 52=20210118-07:31:01.581 | 58=Replying to logout | 10=242 | >> 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | >> 56=THEIREND2 | 98=0 | 108=30 | 10=114 | >> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | >> 52=20210118-07:31:32.604 | 98=0 | 108=30 | 10=101 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | >> 52=20210118-07:32:02.604 | 10=055 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | >> 56=THEIREND2 | 10=054 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | >> 52=20210118-07:32:32.605 | 10=060 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | >> 56=THEIREND2 | 10=058 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | >> 52=20210118-07:33:02.605 | 10=059 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | >> 56=THEIREND2 | 10=057 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | >> 52=20210118-07:33:32.606 | 10=064 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | >> 56=THEIREND2 | 10=062 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | >> 52=20210118-07:34:02.606 | 10=063 | >> ... >> >> Any idea what I'm doing wrong? >> >> -Visa >> ... >> >> >> _______________________________________________ >> 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 >> >> > -- > 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-01-18 12:18:20
|
Hmm, there is no version 1.7.0 of QuickFIX/J. Are you sure that you are using the Java port of QuickFIX? Apart from that, yes upgrading could help since there were some race conditions fixed since version 1.6.4 (after which version 2.0.0 was released). Cheers, Chris. On 18.01.21 12:53, Visa Holopainen wrote: > I am using version 1.7.0. Should I upgrade to for example 2.2.1? > > Thanks! > Visa > > On Mon, Jan 18, 2021 at 1:15 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi, > > which version of QFJ are you using? Looks like a race condition to me. > > Cheers, > Chris. > > > On 18.01.21 11:46, Visa Holopainen 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! >> >> I have two FIX sessions, and two Initiators. >> >> private Initiator init1; >> private Initiator init2; >> >> I create the Initiators, and start them: >> >> init1.start(); >> init2.start(); >> >> Sometimes I need to stop the sessions (restart my software). In this case I run: >> >> init1.stop(); >> init2.stop(); >> >> Then, after I start again (run the start methods again) *one of the FIX sessions gives >> "Session not found"* when trying to do: >> >> Session.sendToTarget(msg); >> >> Here is the FIX message sequence from the session that is working after restart (I send a >> test request in that session at the beginning): >> >> 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | 56=THEIREND1 | 98=0 >> | 108=11 | 10=158 | >> 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:05.597 | >> 98=0 | 108=11 | 10=255 | >> 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:30:07.578 | >> 56=THEIREND1 | 112=20210118083007 | 10=061 | >> 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:07.581 | >> 112=20210118083007 | 10=099 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | 56=THEIREND1 | 10=114 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:18.577 | >> 10=215 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | 56=THEIREND1 | 10=117 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:29.577 | >> 10=218 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | 56=THEIREND1 | 10=111 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:40.577 | >> 10=212 | >> 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | 56=THEIREND1 | 10=114 | >> 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:51.577 | >> 10=215 | >> 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | 56=THEIREND1 | 10=116 | >> 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:00.577 | >> 10=216 | >> 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | 56=THEIREND1 | 98=0 >> | 108=11 | 10=161 | >> 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:32.601 | >> 98=0 | 108=11 | 10=249 | >> 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:31:34.580 | >> 56=THEIREND1 | 112=20210118083134 | 10=063 | >> 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:34.584 | >> 112=20210118083134 | 10=111 | >> 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 | 56=THEIREND1 | >> 10=167 | >> 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:45.580 | >> 10=001 | >> 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 | 56=THEIREND1 | >> 10=170 | >> 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:56.580 | >> 10=004 | >> ... >> >> Here is the FIX message sequence from the session that gives the "Session not found": >> >> 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | 56=THEIREND2 | 98=0 >> | 108=30 | 10=105 | >> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | 52=20210118-07:30:05.599 | 98=0 >> | 108=30 | 10=110 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | 52=20210118-07:30:35.600 | 10=052 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | 56=THEIREND2 | 10=069 | >> 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | 56=THEIREND2 | 10=065 | >> 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | 52=20210118-07:31:01.581 | >> 58=Replying to logout | 10=242 | >> 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | 56=THEIREND2 | 98=0 >> | 108=30 | 10=114 | >> 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | 52=20210118-07:31:32.604 | 98=0 >> | 108=30 | 10=101 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | 52=20210118-07:32:02.604 | 10=055 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | 56=THEIREND2 | 10=054 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | 52=20210118-07:32:32.605 | 10=060 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | 56=THEIREND2 | 10=058 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | 52=20210118-07:33:02.605 | 10=059 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | 56=THEIREND2 | 10=057 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | 52=20210118-07:33:32.606 | 10=064 | >> 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | 56=THEIREND2 | 10=062 | >> 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | 52=20210118-07:34:02.606 | 10=063 | >> ... >> >> Any idea what I'm doing wrong? >> >> -Visa >> ... >> >> >> _______________________________________________ >> 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: Visa H. <vis...@gm...> - 2021-01-18 11:53:53
|
I am using version 1.7.0. Should I upgrade to for example 2.2.1? Thanks! Visa On Mon, Jan 18, 2021 at 1:15 PM Christoph John <chr...@ma...> wrote: > Hi, > > which version of QFJ are you using? Looks like a race condition to me. > > Cheers, > Chris. > > > On 18.01.21 11:46, Visa Holopainen wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi! > > I have two FIX sessions, and two Initiators. > > private Initiator init1; > private Initiator init2; > > I create the Initiators, and start them: > > init1.start(); > init2.start(); > > Sometimes I need to stop the sessions (restart my software). In this case > I run: > > init1.stop(); > init2.stop(); > > Then, after I start again (run the start methods again) *one of the FIX > sessions gives "Session not found"* when trying to do: > > Session.sendToTarget(msg); > > Here is the FIX message sequence from the session that is working after > restart (I send a test request in that session at the beginning): > > 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | > 56=THEIREND1 | 98=0 | 108=11 | 10=158 | > 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:05.597 | 98=0 | 108=11 | 10=255 | > 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | > 52=20210118-07:30:07.578 | 56=THEIREND1 | 112=20210118083007 | 10=061 | > 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:07.581 | 112=20210118083007 | 10=099 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | > 56=THEIREND1 | 10=114 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:18.577 | 10=215 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | > 56=THEIREND1 | 10=117 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:29.577 | 10=218 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | > 56=THEIREND1 | 10=111 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:40.577 | 10=212 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | > 56=THEIREND1 | 10=114 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:30:51.577 | 10=215 | > 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | > 56=THEIREND1 | 10=116 | > 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:31:00.577 | 10=216 | > 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | > 56=THEIREND1 | 98=0 | 108=11 | 10=161 | > 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:31:32.601 | 98=0 | 108=11 | 10=249 | > 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | > 52=20210118-07:31:34.580 | 56=THEIREND1 | 112=20210118083134 | 10=063 | > 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:31:34.584 | 112=20210118083134 | 10=111 | > 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 | > 56=THEIREND1 | 10=167 | > 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:31:45.580 | 10=001 | > 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 | > 56=THEIREND1 | 10=170 | > 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | > 52=20210118-07:31:56.580 | 10=004 | > ... > > Here is the FIX message sequence from the session that gives the "Session > not found": > > 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | > 56=THEIREND2 | 98=0 | 108=30 | 10=105 | > 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | > 52=20210118-07:30:05.599 | 98=0 | 108=30 | 10=110 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | > 52=20210118-07:30:35.600 | 10=052 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | > 56=THEIREND2 | 10=069 | > 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | > 56=THEIREND2 | 10=065 | > 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | > 52=20210118-07:31:01.581 | 58=Replying to logout | 10=242 | > 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | > 56=THEIREND2 | 98=0 | 108=30 | 10=114 | > 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | > 52=20210118-07:31:32.604 | 98=0 | 108=30 | 10=101 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | > 52=20210118-07:32:02.604 | 10=055 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | > 56=THEIREND2 | 10=054 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | > 52=20210118-07:32:32.605 | 10=060 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | > 56=THEIREND2 | 10=058 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | > 52=20210118-07:33:02.605 | 10=059 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | > 56=THEIREND2 | 10=057 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | > 52=20210118-07:33:32.606 | 10=064 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | > 56=THEIREND2 | 10=062 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | > 52=20210118-07:34:02.606 | 10=063 | > ... > > Any idea what I'm doing wrong? > > -Visa > ... > > > _______________________________________________ > 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 > > |
|
From: Christoph J. <chr...@ma...> - 2021-01-18 11:15:56
|
Hi, which version of QFJ are you using? Looks like a race condition to me. Cheers, Chris. On 18.01.21 11:46, Visa Holopainen wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi! > > I have two FIX sessions, and two Initiators. > > private Initiator init1; > private Initiator init2; > > I create the Initiators, and start them: > > init1.start(); > init2.start(); > > Sometimes I need to stop the sessions (restart my software). In this case I run: > > init1.stop(); > init2.stop(); > > Then, after I start again (run the start methods again) *one of the FIX sessions gives "Session > not found"* when trying to do: > > Session.sendToTarget(msg); > > Here is the FIX message sequence from the session that is working after restart (I send a test > request in that session at the beginning): > > 8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 | 56=THEIREND1 | 98=0 | > 108=11 | 10=158 | > 8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:05.597 | 98=0 | > 108=11 | 10=255 | > 8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:30:07.578 | 56=THEIREND1 > | 112=20210118083007 | 10=061 | > 8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:07.581 | > 112=20210118083007 | 10=099 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 | 56=THEIREND1 | 10=114 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:18.577 | 10=215 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 | 56=THEIREND1 | 10=117 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:29.577 | 10=218 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 | 56=THEIREND1 | 10=111 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:40.577 | 10=212 | > 8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 | 56=THEIREND1 | 10=114 | > 8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:30:51.577 | 10=215 | > 8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 | 56=THEIREND1 | 10=116 | > 8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:00.577 | 10=216 | > 8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 | 56=THEIREND1 | 98=0 | > 108=11 | 10=161 | > 8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:32.601 | 98=0 | > 108=11 | 10=249 | > 8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 | 52=20210118-07:31:34.580 | 56=THEIREND1 > | 112=20210118083134 | 10=063 | > 8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:34.584 | > 112=20210118083134 | 10=111 | > 8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 | 56=THEIREND1 | 10=167 | > 8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:45.580 | 10=001 | > 8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 | 56=THEIREND1 | 10=170 | > 8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 | 52=20210118-07:31:56.580 | 10=004 | > ... > > Here is the FIX message sequence from the session that gives the "Session not found": > > 8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 | 56=THEIREND2 | 98=0 | > 108=30 | 10=105 | > 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 | 52=20210118-07:30:05.599 | 98=0 | > 108=30 | 10=110 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 | 52=20210118-07:30:35.600 | 10=052 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 | 56=THEIREND2 | 10=069 | > 8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 | 56=THEIREND2 | 10=065 | > 8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 | 52=20210118-07:31:01.581 | > 58=Replying to logout | 10=242 | > 8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 | 56=THEIREND2 | 98=0 | > 108=30 | 10=114 | > 8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 | 52=20210118-07:31:32.604 | 98=0 | > 108=30 | 10=101 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 | 52=20210118-07:32:02.604 | 10=055 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 | 56=THEIREND2 | 10=054 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 | 52=20210118-07:32:32.605 | 10=060 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 | 56=THEIREND2 | 10=058 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 | 52=20210118-07:33:02.605 | 10=059 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 | 56=THEIREND2 | 10=057 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 | 52=20210118-07:33:32.606 | 10=064 | > 8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 | 56=THEIREND2 | 10=062 | > 8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 | 52=20210118-07:34:02.606 | 10=063 | > ... > > Any idea what I'm doing wrong? > > -Visa > ... > > > _______________________________________________ > 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: Visa H. <vis...@gm...> - 2021-01-18 10:46:54
|
Hi!
I have two FIX sessions, and two Initiators.
private Initiator init1;
private Initiator init2;
I create the Initiators, and start them:
init1.start();
init2.start();
Sometimes I need to stop the sessions (restart my software). In this case I
run:
init1.stop();
init2.stop();
Then, after I start again (run the start methods again) *one of the FIX
sessions gives "Session not found"* when trying to do:
Session.sendToTarget(msg);
Here is the FIX message sequence from the session that is working after
restart (I send a test request in that session at the beginning):
8=FIX.4.2 | 9=64 | 35=A | 34=1 | 49=OUREND1 | 52=20210118-07:30:05.587 |
56=THEIREND1 | 98=0 | 108=11 | 10=158 |
8=FIX.4.2 | 9=0064 | 35=A | 34=1 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:05.597 | 98=0 | 108=11 | 10=255 |
8=FIX.4.2 | 9=81 | 35=1 | 34=2 | 49=OUREND1 | 50=AUTD01 |
52=20210118-07:30:07.578 | 56=THEIREND1 | 112=20210118083007 | 10=061 |
8=FIX.4.2 | 9=0071 | 35=0 | 34=2 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:07.581 | 112=20210118083007 | 10=099 |
8=FIX.4.2 | 9=52 | 35=0 | 34=3 | 49=OUREND1 | 52=20210118-07:30:18.572 |
56=THEIREND1 | 10=114 |
8=FIX.4.2 | 9=0052 | 35=0 | 34=3 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:18.577 | 10=215 |
8=FIX.4.2 | 9=52 | 35=0 | 34=4 | 49=OUREND1 | 52=20210118-07:30:29.572 |
56=THEIREND1 | 10=117 |
8=FIX.4.2 | 9=0052 | 35=0 | 34=4 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:29.577 | 10=218 |
8=FIX.4.2 | 9=52 | 35=0 | 34=5 | 49=OUREND1 | 52=20210118-07:30:40.572 |
56=THEIREND1 | 10=111 |
8=FIX.4.2 | 9=0052 | 35=0 | 34=5 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:40.577 | 10=212 |
8=FIX.4.2 | 9=52 | 35=0 | 34=6 | 49=OUREND1 | 52=20210118-07:30:51.572 |
56=THEIREND1 | 10=114 |
8=FIX.4.2 | 9=0052 | 35=0 | 34=6 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:30:51.577 | 10=215 |
8=FIX.4.2 | 9=52 | 35=5 | 34=7 | 49=OUREND1 | 52=20210118-07:31:00.573 |
56=THEIREND1 | 10=116 |
8=FIX.4.2 | 9=0052 | 35=5 | 34=7 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:31:00.577 | 10=216 |
8=FIX.4.2 | 9=64 | 35=A | 34=8 | 49=OUREND1 | 52=20210118-07:31:32.591 |
56=THEIREND1 | 98=0 | 108=11 | 10=161 |
8=FIX.4.2 | 9=0064 | 35=A | 34=8 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:31:32.601 | 98=0 | 108=11 | 10=249 |
8=FIX.4.2 | 9=81 | 35=1 | 34=9 | 49=OUREND1 | 50=AUTD01 |
52=20210118-07:31:34.580 | 56=THEIREND1 | 112=20210118083134 | 10=063 |
8=FIX.4.2 | 9=0071 | 35=0 | 34=9 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:31:34.584 | 112=20210118083134 | 10=111 |
8=FIX.4.2 | 9=53 | 35=0 | 34=10 | 49=OUREND1 | 52=20210118-07:31:45.577 |
56=THEIREND1 | 10=167 |
8=FIX.4.2 | 9=0053 | 35=0 | 34=10 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:31:45.580 | 10=001 |
8=FIX.4.2 | 9=53 | 35=0 | 34=11 | 49=OUREND1 | 52=20210118-07:31:56.577 |
56=THEIREND1 | 10=170 |
8=FIX.4.2 | 9=0053 | 35=0 | 34=11 | 49=THEIREND1 | 56=OUREND1 |
52=20210118-07:31:56.580 | 10=004 |
...
Here is the FIX message sequence from the session that gives the "Session
not found":
8=FIX.4.2 | 9=68 | 35=A | 34=1 | 49=OUREND2 | 52=20210118-07:30:05.594 |
56=THEIREND2 | 98=0 | 108=30 | 10=105 |
8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=1 |
52=20210118-07:30:05.599 | 98=0 | 108=30 | 10=110 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=2 |
52=20210118-07:30:35.600 | 10=052 |
8=FIX.4.2 | 9=56 | 35=0 | 34=2 | 49=OUREND2 | 52=20210118-07:30:35.599 |
56=THEIREND2 | 10=069 |
8=FIX.4.2 | 9=56 | 35=5 | 34=3 | 49=OUREND2 | 52=20210118-07:31:01.577 |
56=THEIREND2 | 10=065 |
8=FIX.4.2 | 9=78 | 35=5 | 49=THEIREND2 | 56=OUREND2 | 34=3 |
52=20210118-07:31:01.581 | 58=Replying to logout | 10=242 |
8=FIX.4.2 | 9=68 | 35=A | 34=4 | 49=OUREND2 | 52=20210118-07:31:32.599 |
56=THEIREND2 | 98=0 | 108=30 | 10=114 |
8=FIX.4.2 | 9=68 | 35=A | 49=THEIREND2 | 56=OUREND2 | 34=4 |
52=20210118-07:31:32.604 | 98=0 | 108=30 | 10=101 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=5 |
52=20210118-07:32:02.604 | 10=055 |
8=FIX.4.2 | 9=56 | 35=0 | 34=5 | 49=OUREND2 | 52=20210118-07:32:02.603 |
56=THEIREND2 | 10=054 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=6 |
52=20210118-07:32:32.605 | 10=060 |
8=FIX.4.2 | 9=56 | 35=0 | 34=6 | 49=OUREND2 | 52=20210118-07:32:32.603 |
56=THEIREND2 | 10=058 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=7 |
52=20210118-07:33:02.605 | 10=059 |
8=FIX.4.2 | 9=56 | 35=0 | 34=7 | 49=OUREND2 | 52=20210118-07:33:02.603 |
56=THEIREND2 | 10=057 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=8 |
52=20210118-07:33:32.606 | 10=064 |
8=FIX.4.2 | 9=56 | 35=0 | 34=8 | 49=OUREND2 | 52=20210118-07:33:32.604 |
56=THEIREND2 | 10=062 |
8=FIX.4.2 | 9=56 | 35=0 | 49=THEIREND2 | 56=OUREND2 | 34=9 |
52=20210118-07:34:02.606 | 10=063 |
...
Any idea what I'm doing wrong?
-Visa
...
|
|
From: Christoph J. <chr...@ma...> - 2021-01-18 10:41:41
|
Hi, additional to the point that Winfried noted: it could also be that your DataDictionary does not match the messages that your counterparty is sending. Cheers, Chris. On 18.01.21 04:51, JianHe Liao wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > The FXSWAP message received by QuickFixJ from Bloomberg is as following: > > <20210112-04:58:00, FIX.4.4:MAP_BOT_UAT->MAP_BLP_UAT, incoming> > (8=FIX.4.49=117935=849=MAP_BLP_UAT56=MAP_BOT_UAT34=301144=FX52=20210112-04:58:0130=XOFF60=20210112-04:58:00.353120=JPY150=F31=126.65151=032=100000064=202101146=126.651056=12665000037=3-2-806597788T-0-01057=Y38=1000000218=039=240=G460=41300=XOFF1390=011=3-2-806597788T-0-014=1000000194=126.65854=015=EUR75=20210112195=0.051917=3-2-806597788T-0-0167=FXSWAP797=Y22277=022280=054=B55=EUR/JPY119=126650000555=2600=EUR/JPY1788=1602=EUR/JPY603=6607=4609=FXSPOT624=2556=EUR687=1000000654=1587=0588=20210114637=126.651073=01074=126650000600=EUR/JPY1788=2602=EUR/JPY603=6607=4609=FXFWD624=1556=EUR687=1000000654=2587=6588=20210216637=126.70191073=0.05191074=12670190010009=110010=BGDM > Nts22486=022078=222079=1.214222080=2022081=1222079=0.00958622080=2022081=12453=4448=BTTF447=D452=13802=3523=BANK > OF TAIWAN803=1523=30025010803=2523=KOYAO TSENG803=9448=BGDM447=D452=1802=3523=TEST BLOOMBERG > DEMO803=1523=1638065803=2523=FXGO PRQA/CHRISTIAN L803=9448=PRODUCT TYPE447=D452=16802=1523=Dealing > (RFQ)803=4448=30025010447=D452=11768=2769=20210112-04:58:00.353770=1769=20210112-04:57:39.000770=1010=128) > > The FXSWAP message received by our client application from QuickFixJ is as following: > > 12:58:00,720 INFO [com.stp.quickFixJ.ClientApplication] (QFJ Message Processor) message: > 8=FIX.4.49=46135=834=30149=MAP_BLP_UAT52=20210112-04:58:0156=MAP_BOT_UAT144=FX6=126.6511=3-2-806597788T-0-014=100000015=EUR17=3-2-806597788T-0-030=XOFF31=126.6532=100000037=3-2-806597788T-0-038=100000039=240=G54=B55=EUR/JPY60=20210112-04:58:00.35364=2021011475=20210112119=126650000120=JPY150=F151=0167=FXSWAP194=126.65195=0.0519218=0460=4797=Y854=01056=1266500001057=Y1300=XOFF1390=022277=022280=0555=1600=EUR/JPY602=EUR/JPY1788=110=146 > > the same: e.g. > > 52=20210112-04:58:01 > > 194=126.65 > > the different: e.g. > > 9=1179 9=461 > > 555=2 555=1 > > Caller Hierarchy: > > fromApp(Message, SessionID) : void - com.stp.quickFixJ.ClientApplication > > fromCallback(String, Message, SessionID) : void - quickfix.Session > > verify(Message, boolean, boolean) : boolean - quickfix.Session > > We do not know what's wrong. > > Would you please help us? > > Best regards, > > Jianhe > > > > _______________________________________________ > 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: Winfried S. <Win...@de...> - 2021-01-18 08:10:27
|
<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"><div>Hello <span lang="EN-US">Jianhe,</span></div><div><br></div><div>is it possible that you did not specifiy a dictionary for the session?</div><div>It seems to me that the repeating groups are not copied from the incomning message.</div><div>Without the dictionary, quickfix/j does not interpret repeating entries as far as I know.</div><div><br></div><div>Best regards,</div><div>Winfried</div><div><br></div><div><span></span></div><span>Winfried Schleipen<br>Certified Senior IT Specialist<br>Global Business Services - Financial Services: Banking & Financial Markets<br>IBM Services<br>---------------------------------------------------------------------------------------<br>IBM Deutschland <br>Im Klapperhof 3-5<br>50670 Köln<br>Mobile: +49-(0)151-11762672<br>E-Mail: <a href="mailto:win...@de...">win...@de...</a><br>---------------------------------------------------------------------------------------<br>Vorsitzender des Aufsichtsrats: Sebastian Krause<br>Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, Norbert Janzen, Markus Koerner, Christian Noll, Nicole Reimer<br>Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940</span><br><br><font color="#990099">-----JianHe Liao <<a href="mailto:jia...@me..." target="_blank">jia...@me...</a>> wrote: -----</font><div class="iNotesHistory" style="padding-left:5px;"><div style="padding-right:0px;padding-left:5px;border-left:solid black 2px;">To: "<a href="mailto:qui...@li..." target="_blank">qui...@li...</a>" <<a href="mailto:qui...@li..." target="_blank">qui...@li...</a>><br>From: JianHe Liao <<a href="mailto:jia...@me..." target="_blank">jia...@me...</a>><br>Date: 01/18/2021 05:25AM<br>Subject: [EXTERNAL] [Quickfixj-users] QuickFixJ received the FXSWAP message(167=FXSWAP) from Bloomberg, then sent the different message to our client application.<br><br><div><font size="2" face="Courier New,Courier,monospace">QuickFIX/J Documentation: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=uO1pEVojrHRddyFdIIsaxXVAsK68jCqI2Y5Yd_pZ-8s&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=uO1pEVojrHRddyFdIIsaxXVAsK68jCqI2Y5Yd_pZ-8s&e=</a> <br>QuickFIX/J Support: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=MUvWj9ltaVLko88gH6Kwq98a-4H1aXCqiVbtmejPRq8&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=MUvWj9ltaVLko88gH6Kwq98a-4H1aXCqiVbtmejPRq8&e=</a> <br><br><br></font></div> <!-- BaNnErBlUrFlE-HeAdEr-start --> <!-- BaNnErBlUrFlE-HeAdEr-end --> <!--Notes ACF <meta http-equiv="Content-Type" content="text/html; charset=utf8">--> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1" /> </o:shapelayout></xml><![endif]--> <!-- BaNnErBlUrFlE-BoDy-start --> <!-- Preheader Text : BEGIN --> <!-- Preheader Text : END --> <!-- Email Banner : BEGIN --> <!-- Email Banner : END --> <!-- BaNnErBlUrFlE-BoDy-end --> <div class="WordSection1"><p class="MsoNormal"><span lang="EN-US">Hi,<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">The FXSWAP message received by QuickFixJ from Bloomberg is as following:<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><20210112-04:58:00, FIX.4.4:MAP_BOT_UAT->MAP_BLP_UAT, incoming> (8=FIX.4.4<font color="#00b050">9=1179</font>35=849=MAP_BLP_UAT56=MAP_BOT_UAT34=301144=FX<font color="#0070c0">52=20210112-04:58:01</font>30=XOFF60=20210112-04:58:00.353120=JPY150=F31=126.65151=032=100000064=202101146=126.651056=12665000037=3-2-806597788T-0-01057=Y38=1000000218=039=240=G460=41300=XOFF1390=011=3-2-806597788T-0-014=1000000<font color="#0070c0">194=126.65</font>854=015=EUR75=20210112195=0.051917=3-2-806597788T-0-0<font color="#7030a0">167=FXSWAP</font>797=Y22277=022280=054=B55=EUR/JPY119=126650000<font color="#00b050">555=2</font>600=EUR/JPY1788=1602=EUR/JPY603=6607=4609=FXSPOT624=2556=EUR687=1000000654=1587=0588=20210114637=126.651073=01074=126650000600=EUR/JPY1788=2602=EUR/JPY603=6607=4609=FXFWD624=1556=EUR687=1000000654=2587=6588=20210216637=126.70191073=0.05191074=12670190010009=110010=BGDM Nts22486=022078=222079=1.214222080=2022081=1222079=0.00958622080=2022081=12453=4448=BTTF447=D452=13802=3523=BANK OF TAIWAN803=1523=30025010803=2523=KOYAO TSENG803=9448=BGDM447=D452=1802=3523=TEST BLOOMBERG DEMO803=1523=1638065803=2523=FXGO PRQA/CHRISTIAN L803=9448=PRODUCT TYPE447=D452=16802=1523=Dealing (RFQ)803=4448=30025010447=D452=11768=2769=20210112-04:58:00.353770=1769=20210112-04:57:39.000770=1010=128)<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">The FXSWAP message received by our client application from QuickFixJ is as following:<p></p></span></p><p class="MsoNormal"><span lang="EN-US">12:58:00,720 INFO [com.stp.quickFixJ.ClientApplication] (QFJ Message Processor) message: 8=FIX.4.4<font color="#00b050">9=461</font>35=834=30149=MAP_BLP_UAT<font color="#0070c0">52=20210112-04:58:01</font>56=MAP_BOT_UAT144=FX6=126.6511=3-2-806597788T-0-014=100000015=EUR17=3-2-806597788T-0-030=XOFF31=126.6532=100000037=3-2-806597788T-0-038=100000039=240=G54=B55=EUR/JPY60=20210112-04:58:00.35364=2021011475=20210112119=126650000120=JPY150=F151=0<font color="#7030a0">167=FXSWAP</font><font color="#0070c0">194=126.65</font>195=0.0519218=0460=4797=Y854=01056=1266500001057=Y1300=XOFF1390=022277=022280=0<font color="#00b050">555=1</font>600=EUR/JPY602=EUR/JPY1788=110=146<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">the same: e.g. <p></p></span></p><p class="MsoNormal"><font color="#0070c0">52=20210112-04:58:01<p></p></font></p><p class="MsoNormal"><font color="#0070c0">194=126.65<p></p></font></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">the different: e.g.<p></p></span></p><p class="MsoNormal"><font color="#00b050">9=1179 9=461</font><span lang="EN-US"><p></p></span></p><p class="MsoNormal"><font color="#00b050">555=2 555=1</font><span lang="EN-US"><p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">Caller Hierarchy:<p></p></span></p><p class="MsoNormal"><span lang="EN-US">fromApp(Message, SessionID) : void - com.stp.quickFixJ.ClientApplication<p></p></span></p><p class="MsoNormal"><span lang="EN-US"> fromCallback(String, Message, SessionID) : void - quickfix.Session<p></p></span></p><p class="MsoNormal"><span lang="EN-US"> verify(Message, boolean, boolean) : boolean - quickfix.Session<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">We do not know what's wrong.<p></p></span></p><p class="MsoNormal"><span lang="EN-US">Would you please help us?<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US">Best regards,<p></p></span></p><p class="MsoNormal"><span lang="EN-US">Jianhe<p></p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p><p class="MsoNormal"><span lang="EN-US"><p> </p></span></p></div> <div><font size="2" face="Courier New,Courier,monospace">_______________________________________________<br>Quickfixj-users mailing list<br><a href="mailto:Qui...@li..." target="_blank">Qui...@li...</a><br><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=T__bWpCEyBXCRoU913fNUg5B0DuQzQneAFxAsYM31vM&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=0_zsdyIsoVzPVKOBoM5WFjfqDLWGil92G8vAk5dHT4k&m=nGDiOLskRvJUpGDuLvw8YTsCYRZZKYIoRKet1nDtlhk&s=T__bWpCEyBXCRoU913fNUg5B0DuQzQneAFxAsYM31vM&e=</a> <br></font></div></div></div></font><BR> |
|
From: JianHe L. <jia...@me...> - 2021-01-18 04:24:49
|
Hi,
The FXSWAP message received by QuickFixJ from Bloomberg is as following:
<20210112-04:58:00, FIX.4.4:MAP_BOT_UAT->MAP_BLP_UAT, incoming> (8=FIX.4.49=117935=849=MAP_BLP_UAT56=MAP_BOT_UAT34=301144=FX52=20210112-04:58:0130=XOFF60=20210112-04:58:00.353120=JPY150=F31=126.65151=032=100000064=202101146=126.651056=12665000037=3-2-806597788T-0-01057=Y38=1000000218=039=240=G460=41300=XOFF1390=011=3-2-806597788T-0-014=1000000194=126.65854=015=EUR75=20210112195=0.051917=3-2-806597788T-0-0167=FXSWAP797=Y22277=022280=054=B55=EUR/JPY119=126650000555=2600=EUR/JPY1788=1602=EUR/JPY603=6607=4609=FXSPOT624=2556=EUR687=1000000654=1587=0588=20210114637=126.651073=01074=126650000600=EUR/JPY1788=2602=EUR/JPY603=6607=4609=FXFWD624=1556=EUR687=1000000654=2587=6588=20210216637=126.70191073=0.05191074=12670190010009=110010=BGDM Nts22486=022078=222079=1.214222080=2022081=1222079=0.00958622080=2022081=12453=4448=BTTF447=D452=13802=3523=BANK OF TAIWAN803=1523=30025010803=2523=KOYAO TSENG803=9448=BGDM447=D452=1802=3523=TEST BLOOMBERG DEMO803=1523=1638065803=2523=FXGO PRQA/CHRISTIAN L803=9448=PRODUCT TYPE447=D452=16802=1523=Dealing (RFQ)803=4448=30025010447=D452=11768=2769=20210112-04:58:00.353770=1769=20210112-04:57:39.000770=1010=128)
The FXSWAP message received by our client application from QuickFixJ is as following:
12:58:00,720 INFO [com.stp.quickFixJ.ClientApplication] (QFJ Message Processor) message: 8=FIX.4.49=46135=834=30149=MAP_BLP_UAT52=20210112-04:58:0156=MAP_BOT_UAT144=FX6=126.6511=3-2-806597788T-0-014=100000015=EUR17=3-2-806597788T-0-030=XOFF31=126.6532=100000037=3-2-806597788T-0-038=100000039=240=G54=B55=EUR/JPY60=20210112-04:58:00.35364=2021011475=20210112119=126650000120=JPY150=F151=0167=FXSWAP194=126.65195=0.0519218=0460=4797=Y854=01056=1266500001057=Y1300=XOFF1390=022277=022280=0555=1600=EUR/JPY602=EUR/JPY1788=110=146
the same: e.g.
52=20210112-04:58:01
194=126.65
the different: e.g.
9=1179 9=461
555=2 555=1
Caller Hierarchy:
fromApp(Message, SessionID) : void - com.stp.quickFixJ.ClientApplication
fromCallback(String, Message, SessionID) : void - quickfix.Session
verify(Message, boolean, boolean) : boolean - quickfix.Session
We do not know what's wrong.
Would you please help us?
Best regards,
Jianhe
|
|
From: Colin D. <co...@ma...> - 2020-12-30 17:12:15
|
Yes, this is possible. You have to use whatever logging system you are
using in your application to format the log messages and the log files.
For example, we use SLF4J and Log4J2, which means we use an instance of
quickfix.SLF4JLogFactory when we create our FIX sessions with QFJ.
For SLF4J, one uses some variant of log4j2.xml (like log4j2.xml,
spring-log4j2.xml, log4j2.properties, etc).
Here's the entry in log4j2.xml for FIX messages:
<RollingRandomAccessFile name="FIX-OUTGOING"
fileName="target/logs/fix-outgoing${instanceName}.log"
filePattern="target/logs/fix-outgoing${instanceName}-%d{yyyy-MM-dd-HH}-%i.log.gz"
append="true">
<PatternLayout pattern="%d{DATE} %m%n"/>
<Policies>
<SizeBasedTriggeringPolicy size="100 MB"/>
</Policies>
<DefaultRolloverStrategy max="1000"/>
</RollingRandomAccessFile>
This puts the current date in the file name (in the rollover logs,
actually, but it should give you the idea.
On 12/29/20 10:05 PM, Minh Kha wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi team,
> Firstly, I am appreciated for such an amazing project that you made
> for the community.
> I have a question about writing message log function through
> FileLogFactory, FileLog
>
> Currently I had a FIX.4.4-TTL-TEST-VXTGW.messages.logs created through
> the api quickfix provided. But there is a need to name that file which
> would include CurrentDate into that. Is there any way to accomplish
> this? Please let me know.
>
> Thank you
>
> Best regards,
> Kha Phan
>
> --
> *Phan Nguyen Minh Kha*
> min...@gm... <mailto:min...@gm...> / 0938499460
>
>
> _______________________________________________
> 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: Minh K. <min...@gm...> - 2020-12-30 06:06:15
|
Hi team, Firstly, I am appreciated for such an amazing project that you made for the community. I have a question about writing message log function through FileLogFactory, FileLog Currently I had a FIX.4.4-TTL-TEST-VXTGW.messages.logs created through the api quickfix provided. But there is a need to name that file which would include CurrentDate into that. Is there any way to accomplish this? Please let me know. Thank you Best regards, Kha Phan -- *Phan Nguyen Minh Kha* min...@gm... / 0938499460 |
|
From: Christoph J. <chr...@ma...> - 2020-12-15 12:53:51
|
Hi, I think at the moment I cannot help you further without you doing some stack dumps or even tcpdumps when the problem occurs. In my opinion and from my experience this looks like the connection is broken but neither your end nor the other end notices it. I don't think that QFJ itself is blocking, but hard to tell from here. Are you able to test this with a Socks proxy? It could also be that it is a bug in MINA. There also is https://www.quickfixj.org/jira/browse/QFJ-997 which only seems to apply to http proxies. Cheers, Chris. On 07.12.20 19:06, Florian Leu wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > I assumed as much as well in the beginning, but I ruled this out since it doesn't happen with the > same message volume but without a proxy in between, and it also doesn't happen with the proxy but > the heartbeat interval configured as 100'000s, and lastly it also immediately stops when sending > out the heartbeat (and not after some timeout because the heartbeat arrives too late at the other > side and they close the connection because of it). There was never a time during testing where any > incoming message was processed after such a sent heartbeat and only then the disconnect happened, > the heartbeat message was always the last thing logged. > > The really weird part about for me is that there is absolutely no kind of error thrown or > anything. So it seems Quickfix/j still believes everything is fine even though the connection is > broken... > > On 07.12.2020 15:37, Colin DuPlantis wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Apologies if this has been asked and answered, but, is it possible the issue is related to your >> Application becoming overwhelmed with incoming messages and not sending out the heartbeat because >> it takes too long to respond to the incoming messages? >> >> I ask this because you say that it breaks "where the is lots of incoming traffic". >> >> One way to test this would be to have your receiver either not process incoming messages or stick >> them in an adjacent thread to process, thus freeing up the QFJ Application thread. >> >> On 12/7/20 6:34 AM, Florian Leu wrote: >>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>> >>> >>> >>> Hi Chris >>> >>> Sorry for the late reply and thanks for taking an interest in this issue. >>> >>> The connection doesn't break in quiet times, but in times where there is lots of incoming >>> traffic, while at the same time I try to send out a heartbeat message after the configured >>> interval. Since I'm only a message receiver, I never send out my own application messages and >>> therefore Quickfix/j produces the heartbeat messages regularly. But somehow sending out a >>> (heartbeat) messages via proxy while simultaneously receiving incoming (application) messages >>> seems to break the connection. I verified with the counter party that they never receive my >>> heartbeat in such a case and I stop receiving their messages as well. This behavior doesn't >>> happen when we connect directly without proxy, but it happens with the proxy in my development >>> environment as well as with the proxy at the client's production environment (where a direct >>> connection is not possible). >>> >>> The end of the log basically looks like this: >>> >>> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=31235=634=819143=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.209142=MADRID15=EUR22=423=Tag23-720127=2500000028=N44=97.78248=ES037015200354=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-126.22532=310=136 >>> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=32735=634=819243=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.210142=MADRID15=EUR22=423=Tag23-720227=220000028=N44=98.45248=ES036179601654=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.058488653854=0199=1104=E2529=12530=32531=-130.32532=310=116 >>> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=32735=634=819343=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720327=500000028=N44=100.1548=ES030524800954=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.124030151854=0199=1104=E2529=12530=32531=-124.82532=110=067 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=32735=634=819443=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720427=550000028=N44=99.75248=ES037015102154=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.013007278854=0199=1104=E2529=12530=32531=-126.52532=310=100 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=32635=634=819543=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720527=60000028=N44=96.99748=ES037798400254=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.103649457854=0199=1104=E2529=12530=32531=-126.82532=310=093 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=31235=634=819643=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720627=2500000028=N44=99.68148=ES037798800354=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-124.12532=310=162 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=35835=634=819743=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720727=200000028=N44=98.91448=XS105765983854=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103218=0.31235=MATURITY236=3.895172789699=XS1057659838761=4854=0199=1104=E2529=12530=32531=332.92532=110=221 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=35735=634=819843=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720827=870000028=N44=104.81748=ES031497023954=255=ALRSRU >>> 0 >>> 01/11/202060=20201125-07:00:07.103218=93.0235=MATURITY236=0.04773846699=DE0001141687761=4854=0199=1104=E2529=12530=32531=20.32532=310=064 >>> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> fromApp: >>> 8=FIXT.1.19=34635=634=819943=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720927=118526428=N44=103.59348=EU000A1U982954=255=ALUFP >>> 6.45 >>> 03/15/202960=20201125-07:00:07.103218=30.48235=MATURITY699=DE0001141703761=4854=0199=1104=E2529=12530=32531=-42.32532=310=065 >>> 2020-11-25 17:12:24.480 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : >>> toAdmin: 8=FIXT.1.19=6635=034=5049=<REPLACED>52=20201125-16:12:24.48056=<REPLACED>10=191 >>> 2020-11-25 17:12:24.622 INFO 19036 --- [ scheduling-1] c.unitek.fix_adapter.ScheduledTasks : >>> Saved [400] IOI messages. >>> >>> I get 1000s of incoming messages that I printed out for debugging purposes as "fromApp" log >>> statements....and then there is the first heartbeat that I send out, logged as "toAdmin", after >>> the configured interval (e.g. 30s after logging on). After that the incoming messages >>> immediately stop, as if the outgoing heartbeat message caused a disconnect of the connection, >>> but in a way that Quickfix/j doesn't even realize that something is wrong because no "recover >>> attempt" is done which I usually see when the counter party is e.g. really offline for a time, >>> then Quickfix/j usually tries to reconnect until the connection can be re-established. But in >>> case of this proxy-disconnect, the application is then in a state that Quickfix/j seems not to >>> be able to get out of again. But if I send out a heartbeat message in a time where there are no >>> incoming messages simultaneously, then the heartbeat goes through just fine and doesn't cause a >>> disconnect, so only when both incoming and outgoing messages occur together, this seems to be an >>> issue, as if the proxy were a one-way-street that shuts down if there is traffic from both sides >>> at the same time. >>> >>> The proxy settings used in my test environment initiator.cfg file are as follows: >>> >>> ProxyHost=194.191.110.6 ProxyPassword=test ProxyPort=3128 ProxyType=http ProxyUser=test >>> ProxyVersion=1.1 >>> >>> There are also config parameters ProxyDomain and ProxyWorkstation available in Quickfix/j, but I >>> didn't find out what they are used for. >>> >>> I implemented my own workaround now be initiating a logout/logon after not receiving an incoming >>> message for 3 minutes, but that only works because we know that we basically get a constant >>> stream of messages, so when we receive nothing for 3 minutes something must be wrong, but that's >>> more a workaround then a solution, same as setting heartbeat interval to 100'000 to avoid >>> getting into this situation in the first place. >>> >>> Regards, Florian >>> >>> PS: The newer answer in this mail-thread from Andrew Marlow seems to belong to another topic >>> altogether... >>> >>> >>> On 02.12.2020 15:28, Christoph John wrote: >>>> Hi, >>>> >>>> can you share some message and event logs? >>>> Are you saying that the connection only breaks when a Heartbeat *needs* to be sent, i.e. when >>>> there is always traffic the connection works, but in quiet times the connection will break? >>>> >>>> Cheers, >>>> Chris. >>>> >>>> >>>> On 24.11.20 09:57, Florian Leu wrote: >>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>>>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>>>> >>>>> >>>>> Hi everyone >>>>> >>>>> I have a weird issue that my quickfix initiator works fine when connecting directly to the >>>>> message supplier, but as soon as we connect via an HTTP proxy, it works for the first n >>>>> seconds and then the messages stop arriving. >>>>> >>>>> I've now managed to trace the problem to the fact that those n seconds are exactly what is >>>>> configured for the heartbeat interval, i.e. if I set this heartbeat interval higher, then it >>>>> works longer and if I set it e.g. to 5, then it already stops after 5 seconds. >>>>> >>>>> At first I assumed the counter-party just closes the connection if they don't receive the >>>>> heartbeat on time, but then I learned that after a missing heartbeat message first a test >>>>> request is sent out and only after that a connection would be closed. So it seems to me that >>>>> actually the sending out of the heartbeat from the Quickfix/j library (version 2.2.0) via >>>>> proxy somehow seems to block the incoming traffic, as though the proxy was a one way street. >>>>> Since the logon message exchange works, I know that communicating both ways actually works, >>>>> but it seems that sending out a heartbeat while simultaneously processing an incoming stream >>>>> of messages seems to somehow cut of this incoming stream for good. I can literally see in my >>>>> logs that the incoming messages are processed via the fromApp method exactly up to the point >>>>> that my first heartbeat is sent out, so logging this heartbeat via the toAdmin method is >>>>> always the last thing logged before the communication stops altogether....no new incoming or >>>>> outgoing messages are logged until the software is restarted. >>>>> >>>>> Has anyone come across a similar issue? And is there a solution for it? For the moment we >>>>> think about just disabling the heartbeat messages altogether (that seems to work for now), but >>>>> that it more of a hack workaround in my opinion and not an actual solution. >>>>> >>>>> Thanks for your support and regards, >>>>> Florian >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > > _______________________________________________ > 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: Florian L. <fl...@un...> - 2020-12-07 18:07:18
|
I assumed as much as well in the beginning, but I ruled this out since it doesn't happen with the same message volume but without a proxy in between, and it also doesn't happen with the proxy but the heartbeat interval configured as 100'000s, and lastly it also immediately stops when sending out the heartbeat (and not after some timeout because the heartbeat arrives too late at the other side and they close the connection because of it). There was never a time during testing where any incoming message was processed after such a sent heartbeat and only then the disconnect happened, the heartbeat message was always the last thing logged. The really weird part about for me is that there is absolutely no kind of error thrown or anything. So it seems Quickfix/j still believes everything is fine even though the connection is broken... On 07.12.2020 15:37, Colin DuPlantis wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Apologies if this has been asked and answered, but, is it possible the > issue is related to your Application becoming overwhelmed with > incoming messages and not sending out the heartbeat because it takes > too long to respond to the incoming messages? > > I ask this because you say that it breaks "where the is lots of > incoming traffic". > > One way to test this would be to have your receiver either not process > incoming messages or stick them in an adjacent thread to process, thus > freeing up the QFJ Application thread. > > On 12/7/20 6:34 AM, Florian Leu wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi Chris >> >> Sorry for the late reply and thanks for taking an interest in this issue. >> >> The connection doesn't break in quiet times, but in times where there >> is lots of incoming traffic, while at the same time I try to send out >> a heartbeat message after the configured interval. Since I'm only a >> message receiver, I never send out my own application messages and >> therefore Quickfix/j produces the heartbeat messages regularly. But >> somehow sending out a (heartbeat) messages via proxy while >> simultaneously receiving incoming (application) messages seems to >> break the connection. I verified with the counter party that they >> never receive my heartbeat in such a case and I stop receiving their >> messages as well. This behavior doesn't happen when we connect >> directly without proxy, but it happens with the proxy in my >> development environment as well as with the proxy at the client's >> production environment (where a direct connection is not possible). >> >> The end of the log basically looks like this: >> >> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=31235=634=819143=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.209142=MADRID15=EUR22=423=Tag23-720127=2500000028=N44=97.78248=ES037015200354=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-126.22532=310=136 >> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=32735=634=819243=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.210142=MADRID15=EUR22=423=Tag23-720227=220000028=N44=98.45248=ES036179601654=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.058488653854=0199=1104=E2529=12530=32531=-130.32532=310=116 >> 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=32735=634=819343=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720327=500000028=N44=100.1548=ES030524800954=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.124030151854=0199=1104=E2529=12530=32531=-124.82532=110=067 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=32735=634=819443=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720427=550000028=N44=99.75248=ES037015102154=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.013007278854=0199=1104=E2529=12530=32531=-126.52532=310=100 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=32635=634=819543=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720527=60000028=N44=96.99748=ES037798400254=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.103649457854=0199=1104=E2529=12530=32531=-126.82532=310=093 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=31235=634=819643=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720627=2500000028=N44=99.68148=ES037798800354=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-124.12532=310=162 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=35835=634=819743=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720727=200000028=N44=98.91448=XS105765983854=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103218=0.31235=MATURITY236=3.895172789699=XS1057659838761=4854=0199=1104=E2529=12530=32531=332.92532=110=221 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=35735=634=819843=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720827=870000028=N44=104.81748=ES031497023954=255=ALRSRU >> 0 >> 01/11/202060=20201125-07:00:07.103218=93.0235=MATURITY236=0.04773846699=DE0001141687761=4854=0199=1104=E2529=12530=32531=20.32532=310=064 >> 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : fromApp: >> 8=FIXT.1.19=34635=634=819943=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720927=118526428=N44=103.59348=EU000A1U982954=255=ALUFP >> 6.45 >> 03/15/202960=20201125-07:00:07.103218=30.48235=MATURITY699=DE0001141703761=4854=0199=1104=E2529=12530=32531=-42.32532=310=065 >> 2020-11-25 17:12:24.480 INFO 19036 --- [ssage Processor] >> c.u.fix_adapter.fix.FixApp : toAdmin: >> 8=FIXT.1.19=6635=034=5049=<REPLACED>52=20201125-16:12:24.48056=<REPLACED>10=191 >> 2020-11-25 17:12:24.622 INFO 19036 --- [ scheduling-1] >> c.unitek.fix_adapter.ScheduledTasks : Saved [400] IOI messages. >> >> I get 1000s of incoming messages that I printed out for debugging >> purposes as "fromApp" log statements....and then there is the first >> heartbeat that I send out, logged as "toAdmin", after the configured >> interval (e.g. 30s after logging on). After that the incoming >> messages immediately stop, as if the outgoing heartbeat message >> caused a disconnect of the connection, but in a way that Quickfix/j >> doesn't even realize that something is wrong because no "recover >> attempt" is done which I usually see when the counter party is e.g. >> really offline for a time, then Quickfix/j usually tries to reconnect >> until the connection can be re-established. But in case of this >> proxy-disconnect, the application is then in a state that Quickfix/j >> seems not to be able to get out of again. But if I send out a >> heartbeat message in a time where there are no incoming messages >> simultaneously, then the heartbeat goes through just fine and doesn't >> cause a disconnect, so only when both incoming and outgoing messages >> occur together, this seems to be an issue, as if the proxy were a >> one-way-street that shuts down if there is traffic from both sides at >> the same time. >> >> The proxy settings used in my test environment initiator.cfg file are >> as follows: >> >> ProxyHost=194.191.110.6 ProxyPassword=test ProxyPort=3128 >> ProxyType=http ProxyUser=test ProxyVersion=1.1 >> >> There are also config parameters ProxyDomain and ProxyWorkstation >> available in Quickfix/j, but I didn't find out what they are used for. >> >> I implemented my own workaround now be initiating a logout/logon >> after not receiving an incoming message for 3 minutes, but that only >> works because we know that we basically get a constant stream of >> messages, so when we receive nothing for 3 minutes something must be >> wrong, but that's more a workaround then a solution, same as setting >> heartbeat interval to 100'000 to avoid getting into this situation in >> the first place. >> >> Regards, Florian >> >> PS: The newer answer in this mail-thread from Andrew Marlow seems to >> belong to another topic altogether... >> >> >> On 02.12.2020 15:28, Christoph John wrote: >>> Hi, >>> >>> can you share some message and event logs? >>> Are you saying that the connection only breaks when a Heartbeat >>> *needs* to be sent, i.e. when there is always traffic the connection >>> works, but in quiet times the connection will break? >>> >>> Cheers, >>> Chris. >>> >>> >>> On 24.11.20 09:57, Florian Leu wrote: >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>>> >>>> >>>> Hi everyone >>>> >>>> I have a weird issue that my quickfix initiator works fine when >>>> connecting directly to the message supplier, but as soon as we >>>> connect via an HTTP proxy, it works for the first n seconds and >>>> then the messages stop arriving. >>>> >>>> I've now managed to trace the problem to the fact that those n >>>> seconds are exactly what is configured for the heartbeat interval, >>>> i.e. if I set this heartbeat interval higher, then it works longer >>>> and if I set it e.g. to 5, then it already stops after 5 seconds. >>>> >>>> At first I assumed the counter-party just closes the connection if >>>> they don't receive the heartbeat on time, but then I learned that >>>> after a missing heartbeat message first a test request is sent out >>>> and only after that a connection would be closed. So it seems to me >>>> that actually the sending out of the heartbeat from the Quickfix/j >>>> library (version 2.2.0) via proxy somehow seems to block the >>>> incoming traffic, as though the proxy was a one way street. Since >>>> the logon message exchange works, I know that communicating both >>>> ways actually works, but it seems that sending out a heartbeat >>>> while simultaneously processing an incoming stream of messages >>>> seems to somehow cut of this incoming stream for good. I can >>>> literally see in my logs that the incoming messages are processed >>>> via the fromApp method exactly up to the point that my first >>>> heartbeat is sent out, so logging this heartbeat via the toAdmin >>>> method is always the last thing logged before the communication >>>> stops altogether....no new incoming or outgoing messages are logged >>>> until the software is restarted. >>>> >>>> Has anyone come across a similar issue? And is there a solution for >>>> it? For the moment we think about just disabling the heartbeat >>>> messages altogether (that seems to work for now), but that it more >>>> of a hack workaround in my opinion and not an actual solution. >>>> >>>> Thanks for your support and regards, >>>> Florian >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 |
|
From: Colin D. <co...@ma...> - 2020-12-07 17:27:38
|
Apologies if this has been asked and answered, but, is it possible the issue is related to your Application becoming overwhelmed with incoming messages and not sending out the heartbeat because it takes too long to respond to the incoming messages? I ask this because you say that it breaks "where the is lots of incoming traffic". One way to test this would be to have your receiver either not process incoming messages or stick them in an adjacent thread to process, thus freeing up the QFJ Application thread. On 12/7/20 6:34 AM, Florian Leu wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi Chris > > Sorry for the late reply and thanks for taking an interest in this issue. > > The connection doesn't break in quiet times, but in times where there > is lots of incoming traffic, while at the same time I try to send out > a heartbeat message after the configured interval. Since I'm only a > message receiver, I never send out my own application messages and > therefore Quickfix/j produces the heartbeat messages regularly. But > somehow sending out a (heartbeat) messages via proxy while > simultaneously receiving incoming (application) messages seems to > break the connection. I verified with the counter party that they > never receive my heartbeat in such a case and I stop receiving their > messages as well. This behavior doesn't happen when we connect > directly without proxy, but it happens with the proxy in my > development environment as well as with the proxy at the client's > production environment (where a direct connection is not possible). > > The end of the log basically looks like this: > > 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=31235=634=819143=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.209142=MADRID15=EUR22=423=Tag23-720127=2500000028=N44=97.78248=ES037015200354=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-126.22532=310=136 > 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=32735=634=819243=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.210142=MADRID15=EUR22=423=Tag23-720227=220000028=N44=98.45248=ES036179601654=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.058488653854=0199=1104=E2529=12530=32531=-130.32532=310=116 > 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=32735=634=819343=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720327=500000028=N44=100.1548=ES030524800954=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.124030151854=0199=1104=E2529=12530=32531=-124.82532=110=067 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=32735=634=819443=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720427=550000028=N44=99.75248=ES037015102154=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.013007278854=0199=1104=E2529=12530=32531=-126.52532=310=100 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=32635=634=819543=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720527=60000028=N44=96.99748=ES037798400254=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.103649457854=0199=1104=E2529=12530=32531=-126.82532=310=093 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=31235=634=819643=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720627=2500000028=N44=99.68148=ES037798800354=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-124.12532=310=162 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=35835=634=819743=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720727=200000028=N44=98.91448=XS105765983854=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103218=0.31235=MATURITY236=3.895172789699=XS1057659838761=4854=0199=1104=E2529=12530=32531=332.92532=110=221 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=35735=634=819843=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720827=870000028=N44=104.81748=ES031497023954=255=ALRSRU > 0 > 01/11/202060=20201125-07:00:07.103218=93.0235=MATURITY236=0.04773846699=DE0001141687761=4854=0199=1104=E2529=12530=32531=20.32532=310=064 > 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : fromApp: > 8=FIXT.1.19=34635=634=819943=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720927=118526428=N44=103.59348=EU000A1U982954=255=ALUFP > 6.45 > 03/15/202960=20201125-07:00:07.103218=30.48235=MATURITY699=DE0001141703761=4854=0199=1104=E2529=12530=32531=-42.32532=310=065 > 2020-11-25 17:12:24.480 INFO 19036 --- [ssage Processor] > c.u.fix_adapter.fix.FixApp : toAdmin: > 8=FIXT.1.19=6635=034=5049=<REPLACED>52=20201125-16:12:24.48056=<REPLACED>10=191 > 2020-11-25 17:12:24.622 INFO 19036 --- [ scheduling-1] > c.unitek.fix_adapter.ScheduledTasks : Saved [400] IOI messages. > > I get 1000s of incoming messages that I printed out for debugging > purposes as "fromApp" log statements....and then there is the first > heartbeat that I send out, logged as "toAdmin", after the configured > interval (e.g. 30s after logging on). After that the incoming messages > immediately stop, as if the outgoing heartbeat message caused a > disconnect of the connection, but in a way that Quickfix/j doesn't > even realize that something is wrong because no "recover attempt" is > done which I usually see when the counter party is e.g. really offline > for a time, then Quickfix/j usually tries to reconnect until the > connection can be re-established. But in case of this > proxy-disconnect, the application is then in a state that Quickfix/j > seems not to be able to get out of again. But if I send out a > heartbeat message in a time where there are no incoming messages > simultaneously, then the heartbeat goes through just fine and doesn't > cause a disconnect, so only when both incoming and outgoing messages > occur together, this seems to be an issue, as if the proxy were a > one-way-street that shuts down if there is traffic from both sides at > the same time. > > The proxy settings used in my test environment initiator.cfg file are > as follows: > > ProxyHost=194.191.110.6 ProxyPassword=test ProxyPort=3128 > ProxyType=http ProxyUser=test ProxyVersion=1.1 > > There are also config parameters ProxyDomain and ProxyWorkstation > available in Quickfix/j, but I didn't find out what they are used for. > > I implemented my own workaround now be initiating a logout/logon after > not receiving an incoming message for 3 minutes, but that only works > because we know that we basically get a constant stream of messages, > so when we receive nothing for 3 minutes something must be wrong, but > that's more a workaround then a solution, same as setting heartbeat > interval to 100'000 to avoid getting into this situation in the first > place. > > Regards, Florian > > PS: The newer answer in this mail-thread from Andrew Marlow seems to > belong to another topic altogether... > > > On 02.12.2020 15:28, Christoph John wrote: >> Hi, >> >> can you share some message and event logs? >> Are you saying that the connection only breaks when a Heartbeat >> *needs* to be sent, i.e. when there is always traffic the connection >> works, but in quiet times the connection will break? >> >> Cheers, >> Chris. >> >> >> On 24.11.20 09:57, Florian Leu wrote: >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>> >>> >>> Hi everyone >>> >>> I have a weird issue that my quickfix initiator works fine when >>> connecting directly to the message supplier, but as soon as we >>> connect via an HTTP proxy, it works for the first n seconds and then >>> the messages stop arriving. >>> >>> I've now managed to trace the problem to the fact that those n >>> seconds are exactly what is configured for the heartbeat interval, >>> i.e. if I set this heartbeat interval higher, then it works longer >>> and if I set it e.g. to 5, then it already stops after 5 seconds. >>> >>> At first I assumed the counter-party just closes the connection if >>> they don't receive the heartbeat on time, but then I learned that >>> after a missing heartbeat message first a test request is sent out >>> and only after that a connection would be closed. So it seems to me >>> that actually the sending out of the heartbeat from the Quickfix/j >>> library (version 2.2.0) via proxy somehow seems to block the >>> incoming traffic, as though the proxy was a one way street. Since >>> the logon message exchange works, I know that communicating both >>> ways actually works, but it seems that sending out a heartbeat while >>> simultaneously processing an incoming stream of messages seems to >>> somehow cut of this incoming stream for good. I can literally see in >>> my logs that the incoming messages are processed via the fromApp >>> method exactly up to the point that my first heartbeat is sent out, >>> so logging this heartbeat via the toAdmin method is always the last >>> thing logged before the communication stops altogether....no new >>> incoming or outgoing messages are logged until the software is >>> restarted. >>> >>> Has anyone come across a similar issue? And is there a solution for >>> it? For the moment we think about just disabling the heartbeat >>> messages altogether (that seems to work for now), but that it more >>> of a hack workaround in my opinion and not an actual solution. >>> >>> Thanks for your support and regards, >>> Florian >>> >>> >>> >>> _______________________________________________ >>> 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: Florian L. <fl...@un...> - 2020-12-07 14:34:32
|
Hi Chris Sorry for the late reply and thanks for taking an interest in this issue. The connection doesn't break in quiet times, but in times where there is lots of incoming traffic, while at the same time I try to send out a heartbeat message after the configured interval. Since I'm only a message receiver, I never send out my own application messages and therefore Quickfix/j produces the heartbeat messages regularly. But somehow sending out a (heartbeat) messages via proxy while simultaneously receiving incoming (application) messages seems to break the connection. I verified with the counter party that they never receive my heartbeat in such a case and I stop receiving their messages as well. This behavior doesn't happen when we connect directly without proxy, but it happens with the proxy in my development environment as well as with the proxy at the client's production environment (where a direct connection is not possible). The end of the log basically looks like this: 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=31235=634=819143=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.209142=MADRID15=EUR22=423=Tag23-720127=2500000028=N44=97.78248=ES037015200354=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-126.22532=310=136 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=32735=634=819243=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.210142=MADRID15=EUR22=423=Tag23-720227=220000028=N44=98.45248=ES036179601654=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.058488653854=0199=1104=E2529=12530=32531=-130.32532=310=116 2020-11-25 17:12:24.448 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=32735=634=819343=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720327=500000028=N44=100.1548=ES030524800954=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.124030151854=0199=1104=E2529=12530=32531=-124.82532=110=067 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=32735=634=819443=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.211142=MADRID15=EUR22=423=Tag23-720427=550000028=N44=99.75248=ES037015102154=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.013007278854=0199=1104=E2529=12530=32531=-126.52532=310=100 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=32635=634=819543=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720527=60000028=N44=96.99748=ES037798400254=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY236=0.103649457854=0199=1104=E2529=12530=32531=-126.82532=310=093 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=31235=634=819643=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720627=2500000028=N44=99.68148=ES037798800354=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103235=MATURITY854=0199=1104=E2529=12530=32531=-124.12532=310=162 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=35835=634=819743=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720727=200000028=N44=98.91448=XS105765983854=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103218=0.31235=MATURITY236=3.895172789699=XS1057659838761=4854=0199=1104=E2529=12530=32531=332.92532=110=221 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=35735=634=819843=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720827=870000028=N44=104.81748=ES031497023954=255=ALRSRU 0 01/11/202060=20201125-07:00:07.103218=93.0235=MATURITY236=0.04773846699=DE0001141687761=4854=0199=1104=E2529=12530=32531=20.32532=310=064 2020-11-25 17:12:24.456 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : fromApp: 8=FIXT.1.19=34635=634=819943=Y49=<REPLACED>52=20201125-16:12:14.78156=<REPLACED>115=<REPLACED>122=20201125-07:00:10.213142=MADRID15=EUR22=423=Tag23-720927=118526428=N44=103.59348=EU000A1U982954=255=ALUFP 6.45 03/15/202960=20201125-07:00:07.103218=30.48235=MATURITY699=DE0001141703761=4854=0199=1104=E2529=12530=32531=-42.32532=310=065 2020-11-25 17:12:24.480 INFO 19036 --- [ssage Processor] c.u.fix_adapter.fix.FixApp : toAdmin: 8=FIXT.1.19=6635=034=5049=<REPLACED>52=20201125-16:12:24.48056=<REPLACED>10=191 2020-11-25 17:12:24.622 INFO 19036 --- [ scheduling-1] c.unitek.fix_adapter.ScheduledTasks : Saved [400] IOI messages. I get 1000s of incoming messages that I printed out for debugging purposes as "fromApp" log statements....and then there is the first heartbeat that I send out, logged as "toAdmin", after the configured interval (e.g. 30s after logging on). After that the incoming messages immediately stop, as if the outgoing heartbeat message caused a disconnect of the connection, but in a way that Quickfix/j doesn't even realize that something is wrong because no "recover attempt" is done which I usually see when the counter party is e.g. really offline for a time, then Quickfix/j usually tries to reconnect until the connection can be re-established. But in case of this proxy-disconnect, the application is then in a state that Quickfix/j seems not to be able to get out of again. But if I send out a heartbeat message in a time where there are no incoming messages simultaneously, then the heartbeat goes through just fine and doesn't cause a disconnect, so only when both incoming and outgoing messages occur together, this seems to be an issue, as if the proxy were a one-way-street that shuts down if there is traffic from both sides at the same time. The proxy settings used in my test environment initiator.cfg file are as follows: ProxyHost=194.191.110.6 ProxyPassword=test ProxyPort=3128 ProxyType=http ProxyUser=test ProxyVersion=1.1 There are also config parameters ProxyDomain and ProxyWorkstation available in Quickfix/j, but I didn't find out what they are used for. I implemented my own workaround now be initiating a logout/logon after not receiving an incoming message for 3 minutes, but that only works because we know that we basically get a constant stream of messages, so when we receive nothing for 3 minutes something must be wrong, but that's more a workaround then a solution, same as setting heartbeat interval to 100'000 to avoid getting into this situation in the first place. Regards, Florian PS: The newer answer in this mail-thread from Andrew Marlow seems to belong to another topic altogether... On 02.12.2020 15:28, Christoph John wrote: > Hi, > > can you share some message and event logs? > Are you saying that the connection only breaks when a Heartbeat > *needs* to be sent, i.e. when there is always traffic the connection > works, but in quiet times the connection will break? > > Cheers, > Chris. > > > On 24.11.20 09:57, Florian Leu wrote: >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hi everyone >> >> I have a weird issue that my quickfix initiator works fine when >> connecting directly to the message supplier, but as soon as we >> connect via an HTTP proxy, it works for the first n seconds and then >> the messages stop arriving. >> >> I've now managed to trace the problem to the fact that those n >> seconds are exactly what is configured for the heartbeat interval, >> i.e. if I set this heartbeat interval higher, then it works longer >> and if I set it e.g. to 5, then it already stops after 5 seconds. >> >> At first I assumed the counter-party just closes the connection if >> they don't receive the heartbeat on time, but then I learned that >> after a missing heartbeat message first a test request is sent out >> and only after that a connection would be closed. So it seems to me >> that actually the sending out of the heartbeat from the Quickfix/j >> library (version 2.2.0) via proxy somehow seems to block the incoming >> traffic, as though the proxy was a one way street. Since the logon >> message exchange works, I know that communicating both ways actually >> works, but it seems that sending out a heartbeat while simultaneously >> processing an incoming stream of messages seems to somehow cut of >> this incoming stream for good. I can literally see in my logs that >> the incoming messages are processed via the fromApp method exactly up >> to the point that my first heartbeat is sent out, so logging this >> heartbeat via the toAdmin method is always the last thing logged >> before the communication stops altogether....no new incoming or >> outgoing messages are logged until the software is restarted. >> >> Has anyone come across a similar issue? And is there a solution for >> it? For the moment we think about just disabling the heartbeat >> messages altogether (that seems to work for now), but that it more of >> a hack workaround in my opinion and not an actual solution. >> >> Thanks for your support and regards, >> Florian >> >> >> >> _______________________________________________ >> 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...> - 2020-12-03 11:26:29
|
I would be interested in message logs from the connection establishment. Sounds a little strange to me, but I am learning something new every day. :) Cheers, Chris. On 02.12.20 19:28, Andrew Marlow wrote: > I am pleased to report that one of our software engineers tried something today and that made it > work. We were told that the ECN side speaks FIX-5.0(SP2) so we used those classes from QFJ. They > also supplied us with a FIX5.0SP2 Data Dictionary. However, it turns out that in order to > establish the session properly we have to speak 4.4 but still use the 0.5SP2 DD. Now that we do > this, it works. And yes it works without having to login. The system engages in heartbeats, quite > frequently (lots of SSL noise when full debug is turned on). > > Once again, as a relative newcomer to FIX, I am disappointed that there isn't some sort of > protocol negotiation like there is with SSL/TLS. I know that in theory this is supposed to be > un-necessary because both sides should be talking to each other to sort these things out but > theory and practise differ. With the trade feeds that connect to ECNs that I have been involved in > recently there is little or no communication and connectivity details cannot be relied on to be > accurate. Why, in the last feed I worked on a few weeks back we found that the UTC datetime values > were coming over the wire with a spurious "Z" on the end, causing the messages to fail DD > validation. We had to write code to munge those fields. Gah! We also find that the DD is changed > without notice such that message validation fails. I know these things are not supposed to happen > but they do. It's a shame that FIX cannot do anything about it in its current form. > > On Wed, 2 Dec 2020 at 14:30, Christoph John via Quickfixj-users > <qui...@li... <mailto:qui...@li...>> 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, > > can you share some message and event logs? > Are you saying that the connection only breaks when a Heartbeat *needs* to be sent, i.e. when > there is always traffic the connection works, but in quiet times the connection will break? > > Cheers, > Chris. > > > On 24.11.20 09:57, Florian Leu 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 everyone >> >> I have a weird issue that my quickfix initiator works fine when connecting directly to the >> message supplier, but as soon as we connect via an HTTP proxy, it works for the first n >> seconds and then the messages stop arriving. >> >> I've now managed to trace the problem to the fact that those n seconds are exactly what is >> configured for the heartbeat interval, i.e. if I set this heartbeat interval higher, then it >> works longer and if I set it e.g. to 5, then it already stops after 5 seconds. >> >> At first I assumed the counter-party just closes the connection if they don't receive the >> heartbeat on time, but then I learned that after a missing heartbeat message first a test >> request is sent out and only after that a connection would be closed. So it seems to me that >> actually the sending out of the heartbeat from the Quickfix/j library (version 2.2.0) via >> proxy somehow seems to block the incoming traffic, as though the proxy was a one way street. >> Since the logon message exchange works, I know that communicating both ways actually works, >> but it seems that sending out a heartbeat while simultaneously processing an incoming stream >> of messages seems to somehow cut of this incoming stream for good. I can literally see in my >> logs that the incoming messages are processed via the fromApp method exactly up to the point >> that my first heartbeat is sent out, so logging this heartbeat via the toAdmin method is >> always the last thing logged before the communication stops altogether....no new incoming or >> outgoing messages are logged until the software is restarted. >> >> Has anyone come across a similar issue? And is there a solution for it? For the moment we >> think about just disabling the heartbeat messages altogether (that seems to work for now), >> but that it more of a hack workaround in my opinion and not an actual solution. >> >> Thanks for your support and regards, >> Florian >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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> > -- 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 M. <mar...@gm...> - 2020-12-02 18:29:14
|
I am pleased to report that one of our software engineers tried something today and that made it work. We were told that the ECN side speaks FIX-5.0(SP2) so we used those classes from QFJ. They also supplied us with a FIX5.0SP2 Data Dictionary. However, it turns out that in order to establish the session properly we have to speak 4.4 but still use the 0.5SP2 DD. Now that we do this, it works. And yes it works without having to login. The system engages in heartbeats, quite frequently (lots of SSL noise when full debug is turned on). Once again, as a relative newcomer to FIX, I am disappointed that there isn't some sort of protocol negotiation like there is with SSL/TLS. I know that in theory this is supposed to be un-necessary because both sides should be talking to each other to sort these things out but theory and practise differ. With the trade feeds that connect to ECNs that I have been involved in recently there is little or no communication and connectivity details cannot be relied on to be accurate. Why, in the last feed I worked on a few weeks back we found that the UTC datetime values were coming over the wire with a spurious "Z" on the end, causing the messages to fail DD validation. We had to write code to munge those fields. Gah! We also find that the DD is changed without notice such that message validation fails. I know these things are not supposed to happen but they do. It's a shame that FIX cannot do anything about it in its current form. On Wed, 2 Dec 2020 at 14:30, Christoph John via Quickfixj-users < qui...@li...> 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, > > can you share some message and event logs? > Are you saying that the connection only breaks when a Heartbeat *needs* to > be sent, i.e. when there is always traffic the connection works, but in > quiet times the connection will break? > > Cheers, > Chris. > > > On 24.11.20 09:57, Florian Leu wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi everyone > > I have a weird issue that my quickfix initiator works fine when connecting > directly to the message supplier, but as soon as we connect via an HTTP > proxy, it works for the first n seconds and then the messages stop > arriving. > > I've now managed to trace the problem to the fact that those n seconds are > exactly what is configured for the heartbeat interval, i.e. if I set this > heartbeat interval higher, then it works longer and if I set it e.g. to 5, > then it already stops after 5 seconds. > > At first I assumed the counter-party just closes the connection if they > don't receive the heartbeat on time, but then I learned that after a > missing heartbeat message first a test request is sent out and only after > that a connection would be closed. So it seems to me that actually the > sending out of the heartbeat from the Quickfix/j library (version 2.2.0) > via proxy somehow seems to block the incoming traffic, as though the proxy > was a one way street. Since the logon message exchange works, I know that > communicating both ways actually works, but it seems that sending out a > heartbeat while simultaneously processing an incoming stream of messages > seems to somehow cut of this incoming stream for good. I can literally see > in my logs that the incoming messages are processed via the fromApp method > exactly up to the point that my first heartbeat is sent out, so logging > this heartbeat via the toAdmin method is always the last thing logged > before the communication stops altogether....no new incoming or outgoing > messages are logged until the software is restarted. > > Has anyone come across a similar issue? And is there a solution for it? > For the moment we think about just disabling the heartbeat messages > altogether (that seems to work for now), but that it more of a hack > workaround in my opinion and not an actual solution. > > Thanks for your support and regards, > Florian > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://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 > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Christoph J. <chr...@ma...> - 2020-12-02 14:28:42
|
Hi, can you share some message and event logs? Are you saying that the connection only breaks when a Heartbeat *needs* to be sent, i.e. when there is always traffic the connection works, but in quiet times the connection will break? Cheers, Chris. On 24.11.20 09:57, Florian Leu wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi everyone > > I have a weird issue that my quickfix initiator works fine when connecting directly to the message > supplier, but as soon as we connect via an HTTP proxy, it works for the first n seconds and then > the messages stop arriving. > > I've now managed to trace the problem to the fact that those n seconds are exactly what is > configured for the heartbeat interval, i.e. if I set this heartbeat interval higher, then it works > longer and if I set it e.g. to 5, then it already stops after 5 seconds. > > At first I assumed the counter-party just closes the connection if they don't receive the > heartbeat on time, but then I learned that after a missing heartbeat message first a test request > is sent out and only after that a connection would be closed. So it seems to me that actually the > sending out of the heartbeat from the Quickfix/j library (version 2.2.0) via proxy somehow seems > to block the incoming traffic, as though the proxy was a one way street. Since the logon message > exchange works, I know that communicating both ways actually works, but it seems that sending out > a heartbeat while simultaneously processing an incoming stream of messages seems to somehow cut of > this incoming stream for good. I can literally see in my logs that the incoming messages are > processed via the fromApp method exactly up to the point that my first heartbeat is sent out, so > logging this heartbeat via the toAdmin method is always the last thing logged before the > communication stops altogether....no new incoming or outgoing messages are logged until the > software is restarted. > > Has anyone come across a similar issue? And is there a solution for it? For the moment we think > about just disabling the heartbeat messages altogether (that seems to work for now), but that it > more of a hack workaround in my opinion and not an actual solution. > > Thanks for your support and regards, > Florian > > > > _______________________________________________ > 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: Florian L. <fl...@un...> - 2020-11-24 09:15:45
|
Hi everyone I have a weird issue that my quickfix initiator works fine when connecting directly to the message supplier, but as soon as we connect via an HTTP proxy, it works for the first n seconds and then the messages stop arriving. I've now managed to trace the problem to the fact that those n seconds are exactly what is configured for the heartbeat interval, i.e. if I set this heartbeat interval higher, then it works longer and if I set it e.g. to 5, then it already stops after 5 seconds. At first I assumed the counter-party just closes the connection if they don't receive the heartbeat on time, but then I learned that after a missing heartbeat message first a test request is sent out and only after that a connection would be closed. So it seems to me that actually the sending out of the heartbeat from the Quickfix/j library (version 2.2.0) via proxy somehow seems to block the incoming traffic, as though the proxy was a one way street. Since the logon message exchange works, I know that communicating both ways actually works, but it seems that sending out a heartbeat while simultaneously processing an incoming stream of messages seems to somehow cut of this incoming stream for good. I can literally see in my logs that the incoming messages are processed via the fromApp method exactly up to the point that my first heartbeat is sent out, so logging this heartbeat via the toAdmin method is always the last thing logged before the communication stops altogether....no new incoming or outgoing messages are logged until the software is restarted. Has anyone come across a similar issue? And is there a solution for it? For the moment we think about just disabling the heartbeat messages altogether (that seems to work for now), but that it more of a hack workaround in my opinion and not an actual solution. Thanks for your support and regards, Florian |
|
From: <ma...@vo...> - 2020-11-17 21:48:20
|
Hello community! As a personal project I have developed spring-boot-quickfixj. https://github.com/gevoulga/spring-boot-quickfixj It is a spring-boot-starter extension for quickfixj. Briefly, to mention the key feature of the project: * Zero code: All the necessary beans get created for you, so you can @Autowire them. you ONLY need to do is defined your standard quickfixj.cfg and... ready! * Reactive extension of quickfixj: If you're a fan of reactive programming (cudos!), there's quickfixj-spring-boot-starter-flux for you!: Flux<Quote> quotes = fixSession.sendAndSubscribe(quoteRequest); * message-level interaction: Notice the example above. You don't have to implement Application interface. You can operate on the message level, making deducing business logic from code piece of cake! * health-checks and metrics: in spring-actuator fashion, you can integrate with any logging tools (grafana, prometheus,etc). * sourcing of session settings from data-source, in spring-data fashion. Some usage examples can be found here: https://github.com/gevoulga/spring-boot-quickfixj-examples I hope the project is of use to the community! Any feedback/remarks/ideas are more than welcome! Cheers Georgios |
|
From: <ma...@vo...> - 2020-11-17 01:16:33
|
Hello community! As a personal project I have developed spring-boot-quickfixj. It is a spring-boot-starter extension for quickfixj. Briefly, to mention the key feature of the project: * Zero code: All the necessary beans get created for you, so you can @Autowire them. you ONLY need to do is defined your standard quickfixj.cfg and... ready! * Reactive extension of quickfixj: If you're a fan of reactive programming (cudos!), there's quickfixj-spring-boot-starter-flux for you!: Flux<Quote> quotes = fixSession.sendAndSubscribe(quoteRequest); * message-level interaction: Notice the example above. You don't have to implement Application interface. You can operate on the message level, making deducing business logic from code piece of cake! * health-checks and metrics: in spring-actuator fashion, you can integrate with any logging tools (grafana, prometheus,etc). * sourcing of session settings from data-source, in spring-data fashion. Some usage examples can be found here: https://github.com/gevoulga/spring-boot-quickfixj-examples I hope the project is of use to the community! Any feedback/remarks/ideas are more than welcome! Cheers Georgios |
|
From: Christoph J. <chr...@ma...> - 2020-11-13 18:07:46
|
I think I know why this could be happening: does the broker resend the messages without setting PossDup? If yes, then that is the reason for the "too low" disconnection. I have created a short unit test which highlights this: https://gist.github.com/chrjohn/30bdcc0940846be18793d0f290c1c2d8 If the resent messages have the PossDup flag, the test completes successful. Otherwise it is failing as you described. So IMHO your counterparty is misbehaving. Cheers, Chris. On 13.11.20 02:20, Christoph John via Quickfixj-users wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > actually I have never seen this behaviour where the connection is dropped because the queued > messages are processed (and then are too low a sequence number). > I quickly checked our log files but could not find an occurrence where more than one app message > is resent. > I'd like to write a unit test to reproduce this behaviour but currently am a little too busy. :-/ > > Cheers, > Chris. > > On 10.11.20 12:09, Philip Whitehouse wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi all, >> >> In the FIX spec (FIX Session Layer Technical Specification) in "4.8.2 Request retransmission of >> messages" we see several scenarios. >> >> QFJ seems to operate based on a hybrid of the two which has a problem in certain scenarios. >> >> We enqueue messages received (per the second approach). But we also send an infinite resend request. >> >> Thus in the scenario provided if we receive 3,4,5 we will enqueue them. Then we will re-request 2 >> -> 0. >> A compliant broker then sends, 2,3,4,5 per the first approach. >> When we get 2, we process it then de-queue 3,4,5 and process them. Then when we process 3,4,5 >> from the broker we complain (in the form of a disconnect). >> >> Has anyone else seen this behaviour. >> >> My view is: >> >> 1. If we send an infinite resend request we should discard queued messages >> 2. If we send a finite resend request we should keep enqueuing messages >> >> I'm unclear how "ClosedResendInterval" should affect this - or is "ClosedResendInterval" >> essentially "follow the spec" (contrary to the docs). >> >> Best regards, >> >> Philip Whitehouse >> >> >> _______________________________________________ >> 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 -- 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...> - 2020-11-13 01:20:56
|
Hi, actually I have never seen this behaviour where the connection is dropped because the queued messages are processed (and then are too low a sequence number). I quickly checked our log files but could not find an occurrence where more than one app message is resent. I'd like to write a unit test to reproduce this behaviour but currently am a little too busy. :-/ Cheers, Chris. On 10.11.20 12:09, Philip Whitehouse wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi all, > > In the FIX spec (FIX Session Layer Technical Specification) in "4.8.2 Request retransmission of > messages" we see several scenarios. > > QFJ seems to operate based on a hybrid of the two which has a problem in certain scenarios. > > We enqueue messages received (per the second approach). But we also send an infinite resend request. > > Thus in the scenario provided if we receive 3,4,5 we will enqueue them. Then we will re-request 2 > -> 0. > A compliant broker then sends, 2,3,4,5 per the first approach. > When we get 2, we process it then de-queue 3,4,5 and process them. Then when we process 3,4,5 from > the broker we complain (in the form of a disconnect). > > Has anyone else seen this behaviour. > > My view is: > > 1. If we send an infinite resend request we should discard queued messages > 2. If we send a finite resend request we should keep enqueuing messages > > I'm unclear how "ClosedResendInterval" should affect this - or is "ClosedResendInterval" > essentially "follow the spec" (contrary to the docs). > > Best regards, > > Philip Whitehouse > > > _______________________________________________ > 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: Philip W. <Phi...@fl...> - 2020-11-10 14:45:12
|
Hi all, In the FIX spec (FIX Session Layer Technical Specification) in "4.8.2 Request retransmission of messages" we see several scenarios. QFJ seems to operate based on a hybrid of the two which has a problem in certain scenarios. We enqueue messages received (per the second approach). But we also send an infinite resend request. Thus in the scenario provided if we receive 3,4,5 we will enqueue them. Then we will re-request 2 -> 0. A compliant broker then sends, 2,3,4,5 per the first approach. When we get 2, we process it then de-queue 3,4,5 and process them. Then when we process 3,4,5 from the broker we complain (in the form of a disconnect). Has anyone else seen this behaviour. My view is: 1. If we send an infinite resend request we should discard queued messages 2. If we send a finite resend request we should keep enqueuing messages I'm unclear how "ClosedResendInterval" should affect this - or is "ClosedResendInterval" essentially "follow the spec" (contrary to the docs). Best regards, Philip Whitehouse |
103 messages has been excluded from this view by a project administrator.
