Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christoph J. <chr...@ma...> - 2020-11-10 13:29:13
|
1604 was added in one of the later expansion packs. Yes, the process could be improved in any case. On the other hand, it should be no problem for any counterparty to have a mailing list or other technical means to publish changes to their dictionary. I never worked with a counterparty which did not provide this, as far as I remember. Cheers, Chris. On 10.11.20 14:17, Andrew Marlow wrote: > oh dear, this is very disappointing. The trade feed I am working on now is not the first FIX feed > I have worked on. All of them have been subject to this issue. I can't be the first person to be > hit by this issue. I'm not sure about adding ApplicationSystemVersion. Is it tag number 1604. I > cannot find that tag number. I am using FIX 4.4. > > It seems a great omission to me that FIX provides no way for each side to agree on the version of > the data dictionary that is in use or even to know which version is in use. > > On Tue, 10 Nov 2020 at 13:00, Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi, > > no, there is no such thing. If your counterparty is nice they might at least add > 1604/ApplicationSystemVersion to their Logon message to indicate when something changed on > their side. > But after all you are really dependent on your counterparty. > > You could of course disable some validation options to process the messages anyway but this is > of course just a work-around. > > Cheers, > Chris. > > On 09.11.20 12:56, Andrew Marlow wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hello everyone, >> >> I have run into a problem developing a trade feed that uses FIX. I am using quickfixj 2.1.1. >> The problem is that after our side has completed implementation the remote side changes their >> data dictionary and do not tell us. I want to know how this might be detected more reliably >> than just when a message fails to validate. >> >> Is there any notion in FIX as to the version of a data dictionary? Or maybe a date/time when >> it was last changed? >> >> -- >> Regards, >> >> Andrew Marlow >> http://www.andrewpetermarlow.co.uk >> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > > -- > Regards, > > Andrew Marlow > 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-11-10 13:17:52
|
oh dear, this is very disappointing. The trade feed I am working on now is not the first FIX feed I have worked on. All of them have been subject to this issue. I can't be the first person to be hit by this issue. I'm not sure about adding ApplicationSystemVersion. Is it tag number 1604. I cannot find that tag number. I am using FIX 4.4. It seems a great omission to me that FIX provides no way for each side to agree on the version of the data dictionary that is in use or even to know which version is in use. On Tue, 10 Nov 2020 at 13:00, Christoph John <chr...@ma...> wrote: > Hi, > > no, there is no such thing. If your counterparty is nice they might at > least add 1604/ApplicationSystemVersion to their Logon message to indicate > when something changed on their side. > But after all you are really dependent on your counterparty. > > You could of course disable some validation options to process the > messages anyway but this is of course just a work-around. > > Cheers, > Chris. > > On 09.11.20 12:56, Andrew Marlow wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello everyone, > > I have run into a problem developing a trade feed that uses FIX. I am > using quickfixj 2.1.1. The problem is that after our side has completed > implementation the remote side changes their data dictionary and do not > tell us. I want to know how this might be detected more reliably than just > when a message fails to validate. > > Is there any notion in FIX as to the version of a data dictionary? Or > maybe a date/time when it was last changed? > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > 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 > > -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Christoph J. <chr...@ma...> - 2020-11-10 13:01:08
|
Hi, no, there is no such thing. If your counterparty is nice they might at least add 1604/ApplicationSystemVersion to their Logon message to indicate when something changed on their side. But after all you are really dependent on your counterparty. You could of course disable some validation options to process the messages anyway but this is of course just a work-around. Cheers, Chris. On 09.11.20 12:56, Andrew Marlow wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello everyone, > > I have run into a problem developing a trade feed that uses FIX. I am using quickfixj 2.1.1. The > problem is that after our side has completed implementation the remote side changes their data > dictionary and do not tell us. I want to know how this might be detected more reliably than just > when a message fails to validate. > > Is there any notion in FIX as to the version of a data dictionary? Or maybe a date/time when it > was last changed? > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > 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-09 13:21:00
|
Hi This does not sound like something that is specific to QFJ. Could you maybe post some excerpts from the message log highlighting the flow? Cheers, Chris. Am 9. November 2020 13:06:57 MEZ schrieb Andrew Marlow <mar...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: Andrew M. <mar...@gm...> - 2020-11-09 12:07:20
|
Hello everyone, I have run into another problem with my trade feed. Perhaps it is a limitation of FIX. I hope someone can help/advise. I subscribe to AE message at startup and when one arrives I subscribe to the corresponding BA message. However it seems that only one subscription at a time actually works. If I receive two AEs and thus send off two subscription requests, one for each of the associated BAs, it looks like only one gets honoured. Is that right? It doesn't seem right to me. I've worked with other pub-sub frameworks that have no such limitations. -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Andrew M. <mar...@gm...> - 2020-11-09 11:56:38
|
Hello everyone, I have run into a problem developing a trade feed that uses FIX. I am using quickfixj 2.1.1. The problem is that after our side has completed implementation the remote side changes their data dictionary and do not tell us. I want to know how this might be detected more reliably than just when a message fails to validate. Is there any notion in FIX as to the version of a data dictionary? Or maybe a date/time when it was last changed? -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Colin D. <co...@ma...> - 2020-11-05 18:33:06
|
Sounds like a confirmation test with a particular German bank. You can call Session.logout On 11/5/20 7:57 AM, Andrew Marlow wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello everyone, > > This might seem like a beginners question but please be patient: how > do I logout of a quickfixj session? I haven't needed to do that until > just now. Normally if a logout occurs it is initiated by the other end > due to some error condition. We watch out for it so we can report it > properly but we expect to finish when our shutdown time arrives and we > just close the app. But our app has to have a special test mode where > we do particular things for a specific test and the test has to > conclude with us logging out, otherwise we cannot proceed to the next > test. > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > 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: Andrew M. <mar...@gm...> - 2020-11-05 15:58:18
|
Hello everyone, This might seem like a beginners question but please be patient: how do I logout of a quickfixj session? I haven't needed to do that until just now. Normally if a logout occurs it is initiated by the other end due to some error condition. We watch out for it so we can report it properly but we expect to finish when our shutdown time arrives and we just close the app. But our app has to have a special test mode where we do particular things for a specific test and the test has to conclude with us logging out, otherwise we cannot proceed to the next test. -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Christoph J. <chr...@ma...> - 2020-11-04 23:18:08
|
Hmm, never used this message type but looking at its spec: did you generate a unique 568/TradeRequestID for each request? Otherwise I could imagine that the counterparty simply ignores or rejects subsequent requests. Cheers, Chris. On 05.11.20 00:12, Andrew Marlow wrote: > Hello Christoph, > > I have a function that creates a TradeCaptureReportRequest and then it says: > Session.sendToTarget(tcrRequest, sessionId); > The tcrRequest has the field set for the secondary tradeId of interest. In the onLogon callback I > invoke this function. It works in that I get onMessage called for the TCR that I am after. But if > I call that function more than once in onLogon I only get the TCR for the first one. > > On Wed, 4 Nov 2020 at 22:48, Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi Andrew, > > I am not quite understanding what you mean. What do you mean by "one active subscription at a > time"? Do you subscribe against market data? Or which subscription request? > Could you please elaborate? > > Thanks, > Chris. > > > On 04.11.20 23:17, Andrew Marlow wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hello everyone, >> >> I've just seen something very strange with a FIX application I am working on. It seems that >> after login I can only have one active subscription at a time. If I send multiple >> subscription requests, one at a time, on a given session, I only get onMessage callbacks for >> the first one. Is this expected? I didn't expect it. >> >> -- >> Regards, >> >> Andrew Marlow >> http://www.andrewpetermarlow.co.uk >> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > > -- > Regards, > > Andrew Marlow > 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-11-04 23:13:06
|
Hello Christoph, I have a function that creates a TradeCaptureReportRequest and then it says: Session.sendToTarget(tcrRequest, sessionId); The tcrRequest has the field set for the secondary tradeId of interest. In the onLogon callback I invoke this function. It works in that I get onMessage called for the TCR that I am after. But if I call that function more than once in onLogon I only get the TCR for the first one. On Wed, 4 Nov 2020 at 22:48, Christoph John <chr...@ma...> wrote: > Hi Andrew, > > I am not quite understanding what you mean. What do you mean by "one > active subscription at a time"? Do you subscribe against market data? Or > which subscription request? > Could you please elaborate? > > Thanks, > Chris. > > > On 04.11.20 23:17, Andrew Marlow wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello everyone, > > I've just seen something very strange with a FIX application I am working > on. It seems that after login I can only have one active subscription at a > time. If I send multiple subscription requests, one at a time, on a given > session, I only get onMessage callbacks for the first one. Is this > expected? I didn't expect it. > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > 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 > > -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Colin D. <co...@ma...> - 2020-11-04 23:01:06
|
Can you elaborate what you mean by 'subscription' in this context? What 'onMessage' callback are you referring to? On 11/4/20 2:17 PM, Andrew Marlow wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello everyone, > > I've just seen something very strange with a FIX application I am > working on. It seems that after login I can only have one active > subscription at a time. If I send multiple subscription requests, one > at a time, on a given session, I only get onMessage callbacks for the > first one. Is this expected? I didn't expect it. > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |
|
From: Christoph J. <chr...@ma...> - 2020-11-04 22:48:38
|
Hi Andrew, I am not quite understanding what you mean. What do you mean by "one active subscription at a time"? Do you subscribe against market data? Or which subscription request? Could you please elaborate? Thanks, Chris. On 04.11.20 23:17, Andrew Marlow wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello everyone, > > I've just seen something very strange with a FIX application I am working on. It seems that after > login I can only have one active subscription at a time. If I send multiple subscription requests, > one at a time, on a given session, I only get onMessage callbacks for the first one. Is this > expected? I didn't expect it. > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk > > > > _______________________________________________ > 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: Andrew M. <mar...@gm...> - 2020-11-04 22:17:58
|
Hello everyone, I've just seen something very strange with a FIX application I am working on. It seems that after login I can only have one active subscription at a time. If I send multiple subscription requests, one at a time, on a given session, I only get onMessage callbacks for the first one. Is this expected? I didn't expect it. -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk |
|
From: Christoph J. <chr...@ma...> - 2020-10-19 11:31:05
|
Hi, you're welcome. Thanks for the update, glad that you could fix it. Cheers, Chris. On 19.10.20 04:57, Darren wrote: > > Hi everyone, > > After reviewing my toApp/toAdmin implementations, > > and Session.sendRaw(), SessionConnector.startSessionTimer(), > > I think I identified this bug is a thread-safe issue, > > I didn't notice the heartbeat process would go through my toAdmin/toApp implementations, > > and they modified the message without making sure it's thread-safe. > > thanks for Chris's great help :) > > > Regard, > > Darren > > > Christoph John 於 2020/10/16 上午 12:51 寫道: >> And again, it's me: would it be possible for you to share the content of your toApp/toAdmin >> implementations? >> Otherwise I cannot imagine where the messages could get altered. >> Would be good to have a reproducible test case. :) Never seen this behaviour and we have some >> installations with 100+ sessions in one VM. >> >> Chris. >> >> On 15.10.20 15:05, Christoph John wrote: >>> Just asking because the Heartbeat might only be a logging issue, unless you have proof that the >>> Heartbeat was sent out like shown in your log. But if that was the case I would expect the >>> counterparty rejected it. >>> >>> >>> >>> On 15.10.20 14:27, Christoph John via Quickfixj-users wrote: >>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>> >>>> >>>> >>>> Hi, >>>> >>>> one more thing, could you post the original message log? Did I get it right that the heartbeat >>>> was not rejected although it contains invalid tags? >>>> >>>> Thanks, >>>> Chris. >>>> >>>> On 14.10.20 05:00, Darren wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> thanks for the reply, >>>>> >>>>> My application just create one session only, and it's a single thread process to send request, >>>>> >>>>> I encounter this error after upgrade quickfixj to version 2.1.1, >>>>> >>>>> never seem this error when still using 1.5.3, >>>>> >>>>> I cant figure out what cause this error so I tried to update to the latest version 2.2.0, >>>>> >>>>> but it seems still happened... >>>>> >>>>> yes this looks like heartbeat msg is blocked by something, >>>>> >>>>> and i think it's not a big deal, but my request content is modified, that's a serious problem XD >>>>> >>>>> I traced the message creation process, there is no way one message will be affected by another, >>>>> >>>>> especially by the heartbeat message, >>>>> >>>>> Session.java >>>>> >>>>> public void generateHeartbeat() { >>>>> final Message heartbeat = messageFactory.create(sessionID.getBeginString(), >>>>> MsgType.HEARTBEAT); >>>>> initializeHeader(heartbeat.getHeader()); >>>>> sendRaw(heartbeat, 0); >>>>> } >>>>> >>>>> this heartbeat generation process looks straightforward and simple, >>>>> >>>>> how this heartbeat message get tags from my order request content? >>>>> >>>>> checked the sendRaw method but everything looks fine to me XD >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Darren >>>>> >>>>> >>>>> Christoph John 於 2020/10/13 下午 08:53 寫道: >>>>>> Hi, >>>>>> >>>>>> some thoughts/questions: >>>>>> >>>>>> How many sessions do you operate in the same JVM? >>>>>> So you are saying you did not encounter that error with older versions of QFJ? >>>>>> Are you sending messages from several threads concurrently to the same session? >>>>>> >>>>>> It could be that heartbeats are off by some time since they are triggered by the timer thread >>>>>> which runs about once per second. 200ms is a bit large a delay however. >>>>>> Since the heartbeat is sent in the same millisecond as the order message it looks like >>>>>> something was blocking. >>>>>> >>>>>> Cheers, >>>>>> Chris. >>>>>> >>>>>> >>>>>> >>>>>> On 13.10.20 08:24, Darren wrote: >>>>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>>>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> I update my quickfixj-developed project to version 2.2.0 recently, >>>>>>> >>>>>>> after a couple of weeks later, i was reported a order request issue, >>>>>>> >>>>>>> receive error message(tag58) shows 'Missing Account(1)' >>>>>>> >>>>>>> after checking msg log, I noticed the order request and heartbeat message sent at the same time >>>>>>> >>>>>>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 >>>>>>> 77=O 10=240 >>>>>>> >>>>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX >>>>>>> 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>>>> >>>>>>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE >>>>>>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 >>>>>>> 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 >>>>>>> 59=0 32=0 31=0 151=0 14=06=0 60=20201008-13:09:36.457 77=O 58=Missing Account(1) >>>>>>> 21=110=017 >>>>>>> >>>>>>> and a few tags from my order request was missing, so server responsed error msg with Missing >>>>>>> Account(1). >>>>>>> >>>>>>> I checked the heartbeat msg log before this request >>>>>>> >>>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 >>>>>>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 >>>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 >>>>>>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 >>>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 >>>>>>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 >>>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 >>>>>>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O >>>>>>> 10=240 >>>>>>> >>>>>>> my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent >>>>>>> at around 20201008-13:09:36.153, >>>>>>> >>>>>>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, >>>>>>> >>>>>>> after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, >>>>>>> >>>>>>> and why this heartbeat msg contains tag37, tag59 and tag77, >>>>>>> >>>>>>> these tags looks like copied from my order request, and a few tags from my order request is >>>>>>> missing >>>>>>> >>>>>>> normal request: >>>>>>> >>>>>>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 >>>>>>> 51=XXXX 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 >>>>>>> 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 >>>>>>> 11028=Y 16142=TW18205=A110=182 >>>>>>> >>>>>>> abnormal request: >>>>>>> >>>>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX >>>>>>> 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>>>> >>>>>>> this issue happens about once a month, difficult to duplicate, >>>>>>> >>>>>>> any thoughts / ideas would be appreciated. :) >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Darren >>>>>>> >>>>>>> >>> >>> -- >>> 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 >> >> -- >> 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 > -- > 盧賢豪 Darren Lu > Software Engineer > 艾揚科技股份有限公司 > ICE Technology Corporation > Tel:02-25583242 ext 153 > E-mail:da...@ic... -- 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: Darren <da...@ic...> - 2020-10-19 03:04:26
|
Hi everyone, After reviewing my toApp/toAdmin implementations, and Session.sendRaw(), SessionConnector.startSessionTimer(), I think I identified this bug is a thread-safe issue, I didn't notice the heartbeat process would go through my toAdmin/toApp implementations, and they modified the message without making sure it's thread-safe. thanks for Chris's great help :) Regard, Darren Christoph John 於 2020/10/16 上午 12:51 寫道: > And again, it's me: would it be possible for you to share the content > of your toApp/toAdmin implementations? > Otherwise I cannot imagine where the messages could get altered. > Would be good to have a reproducible test case. :) Never seen this > behaviour and we have some installations with 100+ sessions in one VM. > > Chris. > > On 15.10.20 15:05, Christoph John wrote: >> Just asking because the Heartbeat might only be a logging issue, >> unless you have proof that the Heartbeat was sent out like shown in >> your log. But if that was the case I would expect the counterparty >> rejected it. >> >> >> >> On 15.10.20 14:27, Christoph John via Quickfixj-users wrote: >>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>> >>> >>> >>> Hi, >>> >>> one more thing, could you post the original message log? Did I get >>> it right that the heartbeat was not rejected although it contains >>> invalid tags? >>> >>> Thanks, >>> Chris. >>> >>> On 14.10.20 05:00, Darren wrote: >>>> >>>> Hi Chris, >>>> >>>> thanks for the reply, >>>> >>>> My application just create one session only, and it's a single >>>> thread process to send request, >>>> >>>> I encounter this error after upgrade quickfixj to version 2.1.1, >>>> >>>> never seem this error when still using 1.5.3, >>>> >>>> I cant figure out what cause this error so I tried to update to the >>>> latest version 2.2.0, >>>> >>>> but it seems still happened... >>>> >>>> yes this looks like heartbeat msg is blocked by something, >>>> >>>> and i think it's not a big deal, but my request content is >>>> modified, that's a serious problem XD >>>> >>>> I traced the message creation process, there is no way one message >>>> will be affected by another, >>>> >>>> especially by the heartbeat message, >>>> >>>> Session.java >>>> >>>> public void generateHeartbeat() { >>>> final Message heartbeat = >>>> messageFactory.create(sessionID.getBeginString(), >>>> MsgType.HEARTBEAT); >>>> initializeHeader(heartbeat.getHeader()); >>>> sendRaw(heartbeat, 0); >>>> } >>>> >>>> this heartbeat generation process looks straightforward and simple, >>>> >>>> how this heartbeat message get tags from my order request content? >>>> >>>> checked the sendRaw method but everything looks fine to me XD >>>> >>>> >>>> Regards, >>>> >>>> Darren >>>> >>>> >>>> Christoph John 於 2020/10/13 下午 08:53 寫道: >>>>> Hi, >>>>> >>>>> some thoughts/questions: >>>>> >>>>> How many sessions do you operate in the same JVM? >>>>> So you are saying you did not encounter that error with older >>>>> versions of QFJ? >>>>> Are you sending messages from several threads concurrently to the >>>>> same session? >>>>> >>>>> It could be that heartbeats are off by some time since they are >>>>> triggered by the timer thread which runs about once per second. >>>>> 200ms is a bit large a delay however. >>>>> Since the heartbeat is sent in the same millisecond as the order >>>>> message it looks like something was blocking. >>>>> >>>>> Cheers, >>>>> Chris. >>>>> >>>>> >>>>> >>>>> On 13.10.20 08:24, Darren wrote: >>>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>>>> >>>>>> >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I update my quickfixj-developed project to version 2.2.0 recently, >>>>>> >>>>>> after a couple of weeks later, i was reported a order request issue, >>>>>> >>>>>> receive error message(tag58) shows 'Missing Account(1)' >>>>>> >>>>>> after checking msg log, I noticed the order request and heartbeat >>>>>> message sent at the same time >>>>>> >>>>>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX >>>>>> 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O 10=240 >>>>>> >>>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX >>>>>> 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 >>>>>> 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>>> >>>>>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 >>>>>> 52=20201008-13:09:36.457 129=NONE >>>>>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 >>>>>> 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb 20=0 150=8 39=8 >>>>>> 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 >>>>>> 14=06=0 60=20201008-13:09:36.457 77=O 58=Missing Account(1) >>>>>> 21=110=017 >>>>>> >>>>>> and a few tags from my order request was missing, so server >>>>>> responsed error msg with Missing Account(1). >>>>>> >>>>>> I checked the heartbeat msg log before this request >>>>>> >>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX >>>>>> 34=232052=20201008-13:08:06.185 10=191 >>>>>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 >>>>>> 56=XXXX 10=053 >>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX >>>>>> 34=232152=20201008-13:08:36.185 10=195 >>>>>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 >>>>>> 56=XXXX 10=056 >>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX >>>>>> 34=232252=20201008-13:09:06.185 10=194 >>>>>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 >>>>>> 56=XXXX 10=045 >>>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX >>>>>> 34=232352=20201008-13:09:36.185 10=198 >>>>>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 >>>>>> 56=XXXX 38=1 59=0 77=O 10=240 >>>>>> >>>>>> my heartbeat interval setting is 30sec, so I thought the last >>>>>> heartbeat msg should be sent at around 20201008-13:09:36.153, >>>>>> >>>>>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms >>>>>> delayed, >>>>>> >>>>>> after checking the source of quickfixj, I still cant figure out >>>>>> who delayed the heartbeat msg, >>>>>> >>>>>> and why this heartbeat msg contains tag37, tag59 and tag77, >>>>>> >>>>>> these tags looks like copied from my order request, and a few >>>>>> tags from my order request is missing >>>>>> >>>>>> normal request: >>>>>> >>>>>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 >>>>>> 56=XXXX 57=170886 51=XXXX >>>>>> 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 >>>>>> 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME >>>>>> 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182 >>>>>> >>>>>> abnormal request: >>>>>> >>>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX >>>>>> 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 >>>>>> 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>>> >>>>>> this issue happens about once a month, difficult to duplicate, >>>>>> >>>>>> any thoughts / ideas would be appreciated. :) >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Darren >>>>>> >>>>>> >> >> -- >> 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 > > -- > 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 -- 盧賢豪 Darren Lu Software Engineer 艾揚科技股份有限公司 ICE Technology Corporation Tel:02-25583242 ext 153 E-mail: da...@ic... |
|
From: Christoph J. <chr...@ma...> - 2020-10-15 16:52:00
|
And again, it's me: would it be possible for you to share the content of your toApp/toAdmin implementations? Otherwise I cannot imagine where the messages could get altered. Would be good to have a reproducible test case. :) Never seen this behaviour and we have some installations with 100+ sessions in one VM. Chris. On 15.10.20 15:05, Christoph John wrote: > Just asking because the Heartbeat might only be a logging issue, unless you have proof that the > Heartbeat was sent out like shown in your log. But if that was the case I would expect the > counterparty rejected it. > > > > On 15.10.20 14:27, Christoph John via Quickfixj-users wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi, >> >> one more thing, could you post the original message log? Did I get it right that the heartbeat >> was not rejected although it contains invalid tags? >> >> Thanks, >> Chris. >> >> On 14.10.20 05:00, Darren wrote: >>> >>> Hi Chris, >>> >>> thanks for the reply, >>> >>> My application just create one session only, and it's a single thread process to send request, >>> >>> I encounter this error after upgrade quickfixj to version 2.1.1, >>> >>> never seem this error when still using 1.5.3, >>> >>> I cant figure out what cause this error so I tried to update to the latest version 2.2.0, >>> >>> but it seems still happened... >>> >>> yes this looks like heartbeat msg is blocked by something, >>> >>> and i think it's not a big deal, but my request content is modified, that's a serious problem XD >>> >>> I traced the message creation process, there is no way one message will be affected by another, >>> >>> especially by the heartbeat message, >>> >>> Session.java >>> >>> public void generateHeartbeat() { >>> final Message heartbeat = messageFactory.create(sessionID.getBeginString(), >>> MsgType.HEARTBEAT); >>> initializeHeader(heartbeat.getHeader()); >>> sendRaw(heartbeat, 0); >>> } >>> >>> this heartbeat generation process looks straightforward and simple, >>> >>> how this heartbeat message get tags from my order request content? >>> >>> checked the sendRaw method but everything looks fine to me XD >>> >>> >>> Regards, >>> >>> Darren >>> >>> >>> Christoph John 於 2020/10/13 下午 08:53 寫道: >>>> Hi, >>>> >>>> some thoughts/questions: >>>> >>>> How many sessions do you operate in the same JVM? >>>> So you are saying you did not encounter that error with older versions of QFJ? >>>> Are you sending messages from several threads concurrently to the same session? >>>> >>>> It could be that heartbeats are off by some time since they are triggered by the timer thread >>>> which runs about once per second. 200ms is a bit large a delay however. >>>> Since the heartbeat is sent in the same millisecond as the order message it looks like >>>> something was blocking. >>>> >>>> Cheers, >>>> Chris. >>>> >>>> >>>> >>>> On 13.10.20 08:24, Darren wrote: >>>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>>> >>>>> >>>>> >>>>> Hi everyone, >>>>> >>>>> I update my quickfixj-developed project to version 2.2.0 recently, >>>>> >>>>> after a couple of weeks later, i was reported a order request issue, >>>>> >>>>> receive error message(tag58) shows 'Missing Account(1)' >>>>> >>>>> after checking msg log, I noticed the order request and heartbeat message sent at the same time >>>>> >>>>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 >>>>> 77=O 10=240 >>>>> >>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 >>>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>> >>>>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE >>>>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb >>>>> 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0 >>>>> 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017 >>>>> >>>>> and a few tags from my order request was missing, so server responsed error msg with Missing >>>>> Account(1). >>>>> >>>>> I checked the heartbeat msg log before this request >>>>> >>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 >>>>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 >>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 >>>>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 >>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 >>>>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 >>>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 >>>>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O >>>>> 10=240 >>>>> >>>>> my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at >>>>> around 20201008-13:09:36.153, >>>>> >>>>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, >>>>> >>>>> after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, >>>>> >>>>> and why this heartbeat msg contains tag37, tag59 and tag77, >>>>> >>>>> these tags looks like copied from my order request, and a few tags from my order request is >>>>> missing >>>>> >>>>> normal request: >>>>> >>>>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 >>>>> 51=XXXX 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 >>>>> 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 >>>>> 11028=Y 16142=TW18205=A110=182 >>>>> >>>>> abnormal request: >>>>> >>>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 >>>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>>> >>>>> this issue happens about once a month, difficult to duplicate, >>>>> >>>>> any thoughts / ideas would be appreciated. :) >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Darren >>>>> >>>>> > > -- > 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 -- 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-10-15 13:05:38
|
Just asking because the Heartbeat might only be a logging issue, unless you have proof that the Heartbeat was sent out like shown in your log. But if that was the case I would expect the counterparty rejected it. On 15.10.20 14:27, Christoph John via Quickfixj-users wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > one more thing, could you post the original message log? Did I get it right that the heartbeat was > not rejected although it contains invalid tags? > > Thanks, > Chris. > > On 14.10.20 05:00, Darren wrote: >> >> Hi Chris, >> >> thanks for the reply, >> >> My application just create one session only, and it's a single thread process to send request, >> >> I encounter this error after upgrade quickfixj to version 2.1.1, >> >> never seem this error when still using 1.5.3, >> >> I cant figure out what cause this error so I tried to update to the latest version 2.2.0, >> >> but it seems still happened... >> >> yes this looks like heartbeat msg is blocked by something, >> >> and i think it's not a big deal, but my request content is modified, that's a serious problem XD >> >> I traced the message creation process, there is no way one message will be affected by another, >> >> especially by the heartbeat message, >> >> Session.java >> >> public void generateHeartbeat() { >> final Message heartbeat = messageFactory.create(sessionID.getBeginString(), >> MsgType.HEARTBEAT); >> initializeHeader(heartbeat.getHeader()); >> sendRaw(heartbeat, 0); >> } >> >> this heartbeat generation process looks straightforward and simple, >> >> how this heartbeat message get tags from my order request content? >> >> checked the sendRaw method but everything looks fine to me XD >> >> >> Regards, >> >> Darren >> >> >> Christoph John 於 2020/10/13 下午 08:53 寫道: >>> Hi, >>> >>> some thoughts/questions: >>> >>> How many sessions do you operate in the same JVM? >>> So you are saying you did not encounter that error with older versions of QFJ? >>> Are you sending messages from several threads concurrently to the same session? >>> >>> It could be that heartbeats are off by some time since they are triggered by the timer thread >>> which runs about once per second. 200ms is a bit large a delay however. >>> Since the heartbeat is sent in the same millisecond as the order message it looks like something >>> was blocking. >>> >>> Cheers, >>> Chris. >>> >>> >>> >>> On 13.10.20 08:24, Darren wrote: >>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>>> >>>> >>>> >>>> Hi everyone, >>>> >>>> I update my quickfixj-developed project to version 2.2.0 recently, >>>> >>>> after a couple of weeks later, i was reported a order request issue, >>>> >>>> receive error message(tag58) shows 'Missing Account(1)' >>>> >>>> after checking msg log, I noticed the order request and heartbeat message sent at the same time >>>> >>>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O >>>> 10=240 >>>> >>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 >>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>> >>>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE >>>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb >>>> 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0 >>>> 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017 >>>> >>>> and a few tags from my order request was missing, so server responsed error msg with Missing >>>> Account(1). >>>> >>>> I checked the heartbeat msg log before this request >>>> >>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 >>>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 >>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 >>>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 >>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 >>>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 >>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 >>>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O >>>> 10=240 >>>> >>>> my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at >>>> around 20201008-13:09:36.153, >>>> >>>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, >>>> >>>> after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, >>>> >>>> and why this heartbeat msg contains tag37, tag59 and tag77, >>>> >>>> these tags looks like copied from my order request, and a few tags from my order request is missing >>>> >>>> normal request: >>>> >>>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 51=XXXX >>>> 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 60=20201008-13:07:35.953 >>>> 77=O 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182 >>>> >>>> abnormal request: >>>> >>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 >>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 >>>> >>>> this issue happens about once a month, difficult to duplicate, >>>> >>>> any thoughts / ideas would be appreciated. :) >>>> >>>> >>>> Regards, >>>> >>>> Darren >>>> >>>> -- 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-10-15 12:27:58
|
Hi,
one more thing, could you post the original message log? Did I get it right that the heartbeat was
not rejected although it contains invalid tags?
Thanks,
Chris.
On 14.10.20 05:00, Darren wrote:
>
> Hi Chris,
>
> thanks for the reply,
>
> My application just create one session only, and it's a single thread process to send request,
>
> I encounter this error after upgrade quickfixj to version 2.1.1,
>
> never seem this error when still using 1.5.3,
>
> I cant figure out what cause this error so I tried to update to the latest version 2.2.0,
>
> but it seems still happened...
>
> yes this looks like heartbeat msg is blocked by something,
>
> and i think it's not a big deal, but my request content is modified, that's a serious problem XD
>
> I traced the message creation process, there is no way one message will be affected by another,
>
> especially by the heartbeat message,
>
> Session.java
>
> public void generateHeartbeat() {
> final Message heartbeat = messageFactory.create(sessionID.getBeginString(),
> MsgType.HEARTBEAT);
> initializeHeader(heartbeat.getHeader());
> sendRaw(heartbeat, 0);
> }
>
> this heartbeat generation process looks straightforward and simple,
>
> how this heartbeat message get tags from my order request content?
>
> checked the sendRaw method but everything looks fine to me XD
>
>
> Regards,
>
> Darren
>
>
> Christoph John 於 2020/10/13 下午 08:53 寫道:
>> Hi,
>>
>> some thoughts/questions:
>>
>> How many sessions do you operate in the same JVM?
>> So you are saying you did not encounter that error with older versions of QFJ?
>> Are you sending messages from several threads concurrently to the same session?
>>
>> It could be that heartbeats are off by some time since they are triggered by the timer thread
>> which runs about once per second. 200ms is a bit large a delay however.
>> Since the heartbeat is sent in the same millisecond as the order message it looks like something
>> was blocking.
>>
>> Cheers,
>> Chris.
>>
>>
>>
>> On 13.10.20 08:24, Darren wrote:
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>> Hi everyone,
>>>
>>> I update my quickfixj-developed project to version 2.2.0 recently,
>>>
>>> after a couple of weeks later, i was reported a order request issue,
>>>
>>> receive error message(tag58) shows 'Missing Account(1)'
>>>
>>> after checking msg log, I noticed the order request and heartbeat message sent at the same time
>>>
>>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O
>>> 10=240
>>>
>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675
>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121
>>>
>>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE
>>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb
>>> 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0
>>> 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017
>>>
>>> and a few tags from my order request was missing, so server responsed error msg with Missing
>>> Account(1).
>>>
>>> I checked the heartbeat msg log before this request
>>>
>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191
>>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053
>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195
>>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056
>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194
>>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045
>>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198
>>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O 10=240
>>>
>>> my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at
>>> around 20201008-13:09:36.153,
>>>
>>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed,
>>>
>>> after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg,
>>>
>>> and why this heartbeat msg contains tag37, tag59 and tag77,
>>>
>>> these tags looks like copied from my order request, and a few tags from my order request is missing
>>>
>>> normal request:
>>>
>>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 51=XXXX
>>> 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 60=20201008-13:07:35.953 77=O
>>> 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182
>>>
>>> abnormal request:
>>>
>>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675
>>> 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121
>>>
>>> this issue happens about once a month, difficult to duplicate,
>>>
>>> any thoughts / ideas would be appreciated. :)
>>>
>>>
>>> Regards,
>>>
>>> Darren
>>>
>>>
>>
>> --
>> 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
--
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: Darren <da...@ic...> - 2020-10-14 03:00:53
|
Hi Chris,
thanks for the reply,
My application just create one session only, and it's a single thread
process to send request,
I encounter this error after upgrade quickfixj to version 2.1.1,
never seem this error when still using 1.5.3,
I cant figure out what cause this error so I tried to update to the
latest version 2.2.0,
but it seems still happened...
yes this looks like heartbeat msg is blocked by something,
and i think it's not a big deal, but my request content is modified,
that's a serious problem XD
I traced the message creation process, there is no way one message will
be affected by another,
especially by the heartbeat message,
Session.java
public void generateHeartbeat() {
final Message heartbeat =
messageFactory.create(sessionID.getBeginString(),
MsgType.HEARTBEAT);
initializeHeader(heartbeat.getHeader());
sendRaw(heartbeat, 0);
}
this heartbeat generation process looks straightforward and simple,
how this heartbeat message get tags from my order request content?
checked the sendRaw method but everything looks fine to me XD
Regards,
Darren
Christoph John 於 2020/10/13 下午 08:53 寫道:
> Hi,
>
> some thoughts/questions:
>
> How many sessions do you operate in the same JVM?
> So you are saying you did not encounter that error with older versions
> of QFJ?
> Are you sending messages from several threads concurrently to the same
> session?
>
> It could be that heartbeats are off by some time since they are
> triggered by the timer thread which runs about once per second. 200ms
> is a bit large a delay however.
> Since the heartbeat is sent in the same millisecond as the order
> message it looks like something was blocking.
>
> Cheers,
> Chris.
>
>
>
> On 13.10.20 08:24, Darren wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Hi everyone,
>>
>> I update my quickfixj-developed project to version 2.2.0 recently,
>>
>> after a couple of weeks later, i was reported a order request issue,
>>
>> receive error message(tag58) shows 'Missing Account(1)'
>>
>> after checking msg log, I noticed the order request and heartbeat
>> message sent at the same time
>>
>> 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386
>> 56=XXXXX 38= 159=0 77=O 10=240
>>
>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386
>> 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM
>> 59=060=20201008-13:09:36.386 77=O 10=121
>>
>> 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324
>> 52=20201008-13:09:36.457 129=NONE
>> 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675
>> 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb 20=0 150=8 39=8 103=99
>> 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0
>> 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017
>>
>> and a few tags from my order request was missing, so server responsed
>> error msg with Missing Account(1).
>>
>> I checked the heartbeat msg log before this request
>>
>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX
>> 34=232052=20201008-13:08:06.185 10=191
>> 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155
>> 56=XXXX 10=053
>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX
>> 34=232152=20201008-13:08:36.185 10=195
>> 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154
>> 56=XXXX 10=056
>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX
>> 34=232252=20201008-13:09:06.185 10=194
>> 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153
>> 56=XXXX 10=045
>> 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX
>> 34=232352=20201008-13:09:36.185 10=198
>> 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386
>> 56=XXXX 38=1 59=0 77=O 10=240
>>
>> my heartbeat interval setting is 30sec, so I thought the last
>> heartbeat msg should be sent at around 20201008-13:09:36.153,
>>
>> but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed,
>>
>> after checking the source of quickfixj, I still cant figure out who
>> delayed the heartbeat msg,
>>
>> and why this heartbeat msg contains tag37, tag59 and tag77,
>>
>> these tags looks like copied from my order request, and a few tags
>> from my order request is missing
>>
>> normal request:
>>
>> 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953
>> 56=XXXX 57=170886 51=XXXX
>> 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0
>> 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME 454=1
>> 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182
>>
>> abnormal request:
>>
>> 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386
>> 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM
>> 59=060=20201008-13:09:36.386 77=O 10=121
>>
>> this issue happens about once a month, difficult to duplicate,
>>
>> any thoughts / ideas would be appreciated. :)
>>
>>
>> Regards,
>>
>> Darren
>>
>>
>
> --
> 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-10-13 12:54:05
|
Hi, some thoughts/questions: How many sessions do you operate in the same JVM? So you are saying you did not encounter that error with older versions of QFJ? Are you sending messages from several threads concurrently to the same session? It could be that heartbeats are off by some time since they are triggered by the timer thread which runs about once per second. 200ms is a bit large a delay however. Since the heartbeat is sent in the same millisecond as the order message it looks like something was blocking. Cheers, Chris. On 13.10.20 08:24, Darren wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi everyone, > > I update my quickfixj-developed project to version 2.2.0 recently, > > after a couple of weeks later, i was reported a order request issue, > > receive error message(tag58) shows 'Missing Account(1)' > > after checking msg log, I noticed the order request and heartbeat message sent at the same time > > 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O > 10=240 > > 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 > 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 > > 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE > 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb > 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0 > 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017 > > and a few tags from my order request was missing, so server responsed error msg with Missing > Account(1). > > I checked the heartbeat msg log before this request > > 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 > 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 > 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 > 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 > 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 > 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 > 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 > 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O 10=240 > > my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at > around 20201008-13:09:36.153, > > but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, > > after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, > > and why this heartbeat msg contains tag37, tag59 and tag77, > > these tags looks like copied from my order request, and a few tags from my order request is missing > > normal request: > > 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 51=XXXX > 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 60=20201008-13:07:35.953 77=O > 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182 > > abnormal request: > > 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 > 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 > > this issue happens about once a month, difficult to duplicate, > > any thoughts / ideas would be appreciated. :) > > > Regards, > > Darren > > -- 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: Darren <da...@ic...> - 2020-10-13 07:28:55
|
Hi everyone, I update my quickfixj-developed project to version 2.2.0 recently, after a couple of weeks later, i was reported a order request issue, receive error message(tag58) shows 'Missing Account(1)' after checking msg log, I noticed the order request and heartbeat message sent at the same time 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O 10=240 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017 and a few tags from my order request was missing, so server responsed error msg with Missing Account(1). I checked the heartbeat msg log before this request 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O 10=240 my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at around 20201008-13:09:36.153, but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, and why this heartbeat msg contains tag37, tag59 and tag77, these tags looks like copied from my order request, and a few tags from my order request is missing normal request: 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 51=XXXX 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182 abnormal request: 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 this issue happens about once a month, difficult to duplicate, any thoughts / ideas would be appreciated. :) Regards, Darren |
|
From: Darren <da...@ic...> - 2020-10-13 05:22:05
|
Hi everyone, I update my quickfixj-developed project to version 2.2.0 recently, after a couple of weeks later, i was reported a order request issue, receive error message(tag58) shows 'Missing Account(1)' after checking msg log, I noticed the order request and heartbeat message sent at the same time 8=FIX.4.2 9=77 35=0 34=2161 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 38= 159=0 77=O 10=240 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 8=FIX.4.2 9=00296 35=8 49=XXXXX 56=XXXXX 34=2324 52=20201008-13:09:36.457 129=NONE 37=3040153c-7a98-4249-bc8f-5f881fb9af4111=1602107675 17=7626495d-aa27-49ae-a4d4-935e2d9e9abb 20=0 150=8 39=8 103=99 55=YM 54=1 38=1 40=3 59=0 32=0 31=0 151=0 14=06=0 60=20201008-13:09:36.457 77=O 58=Missing Account(1) 21=110=017 and a few tags from my order request was missing, so server responsed error msg with Missing Account(1). I checked the heartbeat msg log before this request 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232052=20201008-13:08:06.185 10=191 8=FIX.4.2 9=62 35=034=2158 49=XXXX 52=20201008-13:08:06.155 56=XXXX 10=053 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232152=20201008-13:08:36.185 10=195 8=FIX.4.2 9=62 35=034=2159 49=XXXX 52=20201008-13:08:36.154 56=XXXX 10=056 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232252=20201008-13:09:06.185 10=194 8=FIX.4.2 9=62 35=034=2160 49=XXXX 52=20201008-13:09:06.153 56=XXXX 10=045 8=FIX.4.2 9=00062 35=0 49=XXXX 56=XXXX 34=232352=20201008-13:09:36.185 10=198 8=FIX.4.2 9=77 35=034=2161 49=XXXX 52=20201008-13:09:36.386 56=XXXX 38=1 59=0 77=O 10=240 my heartbeat interval setting is 30sec, so I thought the last heartbeat msg should be sent at around 20201008-13:09:36.153, but log shows it was sent at 20201008-13:09:36.386, about 200 ms delayed, after checking the source of quickfixj, I still cant figure out who delayed the heartbeat msg, and why this heartbeat msg contains tag37, tag59 and tag77, these tags looks like copied from my order request, and a few tags from my order request is missing normal request: 8=FIX.4.2 9=265 35=D 34=215749=XXXX 52=20201008-13:07:35.953 56=XXXX 57=170886 51=XXXX 11=160210767421=138=140=244=2834450=XXXX 54=1 55=YM 59=0 60=20201008-13:07:35.953 77=O 116=XXXX 167=FUT 207=CME 454=1 455=YM Dec20 456=97 11028=Y 16142=TW18205=A110=182 abnormal request: 8=FIX.4.2 9=137 35=D 34=2162 49=XXXXX 52=20201008-13:09:36.386 56=XXXXX 11=1602107675 21=1 38=1 40=3 54=1 55=YM 59=060=20201008-13:09:36.386 77=O 10=121 this issue happens about once a month, difficult to duplicate, any thoughts / ideas would be appreciated. :) Regards, Darren |
|
From: Christoph J. <chr...@ma...> - 2020-10-07 12:03:21
|
Hi, hmm, strange. QFJ did not create OSGi bundles until version 1.6.0, so not sure where your OSGi bundle for version 1.5.3 came from. The saxon JAR that is shipped with the QFJ distribution is no OSGi bundle. But you can download it here: https://mvnrepository.com/artifact/org.daisy.libs/saxon-he/9.8.0.8 Hope that helps. Cheers, Chris. On 07.10.20 02:38, Merly Anne Tio wrote: > Hi Christoph, > > We were using the old version before, QuickFixJ-1.5.3.97.jar and is working properly. > > Now I'm trying the new versions, either 2.0.0 or 2.2.0 is okay for me to use but they have the > same issue (missing dependency jar saxon). > We are using the osgi bundle and not maven in our project, i believe the new versions is not > compatible with the osgi framework? > > I only replaced the jar file from QuickFixJ-1.5.3.97 to quickfixj-all-2.0.0, updated the > "timestamp" class with the quickfix change and put the jar inside the bundle, it's just > straightforward update. > I'm not sure if i have to do some additional configurations. > > > > On Tue, Oct 6, 2020 at 8:51 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi, > > did this work before? > What is strange is that your log output shows "quickfixj-all-2.0.0", so not version 2.2.0?! > > Cheers, > Chris. > > On 06.10.20 11:34, Merly Anne Tio wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi, >> >> Good day! >> >> I'm trying to update the quickfixj library to this new version. >> 1. I added the jar file in my osgi bundle, in my bnd file "import-package", i can see the >> manifest that quickfix-all_2.2.0 jar was there, However it seems there are some missing jar >> "net.sf.saxon" when i try to run the program. >> 2. I tried to add the jar (Saxon-HE-9.8.0-4.jar) in my bnd as well and in my bundle folder. >> Still missing requirements. >> >> *Log:* >> -> ERROR: Bundle org.quickfixj.all [12] Error starting >> file:{path}/bundle/quickfixj-all-2.0.0.jar (org.osgi.framework.BundleException: Unresolved >> constraint in bundle org.quickfixj.all [12]: Unable to resolve 12.0: missing requirement >> [12.0] osgi.wiring.package; (osgi.wiring.package=net.sf.saxon)) >> >> Appreciate your help on this matter. >> >> Regards, >> >> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > 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: Merly A. T. <mer...@gm...> - 2020-10-07 00:39:26
|
Hi Christoph, We were using the old version before, QuickFixJ-1.5.3.97.jar and is working properly. Now I'm trying the new versions, either 2.0.0 or 2.2.0 is okay for me to use but they have the same issue (missing dependency jar saxon). We are using the osgi bundle and not maven in our project, i believe the new versions is not compatible with the osgi framework? I only replaced the jar file from QuickFixJ-1.5.3.97 to quickfixj-all-2.0.0, updated the "timestamp" class with the quickfix change and put the jar inside the bundle, it's just straightforward update. I'm not sure if i have to do some additional configurations. On Tue, Oct 6, 2020 at 8:51 PM Christoph John <chr...@ma...> wrote: > Hi, > > did this work before? > What is strange is that your log output shows "quickfixj-all-2.0.0", so > not version 2.2.0?! > > Cheers, > Chris. > > On 06.10.20 11:34, Merly Anne Tio wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > Good day! > > I'm trying to update the quickfixj library to this new version. > 1. I added the jar file in my osgi bundle, in my bnd file > "import-package", i can see the manifest that quickfix-all_2.2.0 jar was > there, However it seems there are some missing jar "net.sf.saxon" when i > try to run the program. > 2. I tried to add the jar (Saxon-HE-9.8.0-4.jar) in my bnd as well and in > my bundle folder. Still missing requirements. > > *Log:* > -> ERROR: Bundle org.quickfixj.all [12] Error starting > file:{path}/bundle/quickfixj-all-2.0.0.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > org.quickfixj.all [12]: Unable to resolve 12.0: missing requirement [12.0] > osgi.wiring.package; (osgi.wiring.package=net.sf.saxon)) > > Appreciate your help on this matter. > > Regards, > > > > > _______________________________________________ > 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...> - 2020-10-06 12:52:18
|
Hi, did this work before? What is strange is that your log output shows "quickfixj-all-2.0.0", so not version 2.2.0?! Cheers, Chris. On 06.10.20 11:34, Merly Anne Tio wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > Good day! > > I'm trying to update the quickfixj library to this new version. > 1. I added the jar file in my osgi bundle, in my bnd file "import-package", i can see the > manifest that quickfix-all_2.2.0 jar was there, However it seems there are some missing jar > "net.sf.saxon" when i try to run the program. > 2. I tried to add the jar (Saxon-HE-9.8.0-4.jar) in my bnd as well and in my bundle folder. Still > missing requirements. > > *Log:* > -> ERROR: Bundle org.quickfixj.all [12] Error starting file:{path}/bundle/quickfixj-all-2.0.0.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle org.quickfixj.all [12]: > Unable to resolve 12.0: missing requirement [12.0] osgi.wiring.package; > (osgi.wiring.package=net.sf.saxon)) > > Appreciate your help on this matter. > > Regards, > > > > > _______________________________________________ > 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 |
103 messages has been excluded from this view by a project administrator.
