quickfixj-users — General mailing list for QuickFIX/J topics.

Re: [Quickfixj-users] How to quickly terminate FIX event loop

[Colin D. <co...@ma...>]

You can get the Session object with a SessionID:

Session session = Session.lookupSession(sessionID)

You're right: the doc does say this. We actually have an initiator for 
each session and we stop the initiator.

On 3/26/21 10:38 AM, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello,
>
> On Fri, 26 Mar 2021 at 13:54, Colin DuPlantis <co...@ma... 
> <mailto:co...@ma...>> 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/>
>     [snip]
>
>     As for stopping processing, we would just end the session with
>     Session.disconnect. Given that we restart the session where we
>     want it to start, compelling the counter to resend some messages,
>     we don't really worry about ending a session immediately. Use your
>     flag to determine whether you should process messages or not. That
>     way, the session can continue for a few seconds after you want it
>     to end and you'll just drop those messages, knowing you'll get
>     them back on restart.
>
>     This approach doesn't require and config changes. On restart, the
>     system will automatically orient itself and restart where it's
>     supposed to.
>
> Indeed. That sounds good. Thank you for your quick response.
>
> I'd like to do this but without a Session object, I can't. The 
> disconnect method is not static so an object is required. Where would 
> I get one? In the callback where the error is detected I only have a 
> SessionId. Also the documentation for the disconnect method says you 
> should not use it.
>
>     On 3/26/21 6:36 AM, Andrew Marlow wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/  <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support:http://www.quickfixj.org/support/  <http://www.quickfixj.org/support/>
>>
>>
>>
>>     Hello everyone,
>>
>>     Please excuse my ignorance regarding FIX programming. I know that
>>     when a FIX session is initiated a thread runs asynchronously,
>>     dispatching callbacks until the main application terminates. But
>>     I need a way to shutdown that thread as soon as I detect a
>>     particular error. My message handler which contains the callbacks
>>     has a state variable that can be queried by the main app. The
>>     main app has a polling loop rather than sleeping forever. That
>>     loop enables it to periodically check the state of the message
>>     handler. If it has got into a bad state then the main app shuts
>>     down. The trouble with this is that there is a window during
>>     which any number of FIX messages may be received. This is causing
>>     trouble. Those messages do not get replayed when the app is
>>     restarted because the remote FIX end thinks that because they
>>     were picked up they do not need to be replayed.
>>
>>     I am able to jig things such that old messages can be seen again.
>>     I have a config parameter datetime for subscription. On restart I
>>     can set this back in time. There also the sequence numbers,
>>     another aspect controlled by configuration. While this worked
>>     fine during development it is no good for production. This is
>>     because any config change in production requires people to jump
>>     through hoops of fire. So I need to find a better way, that
>>     causes the FIX processing to cease as soon as the error is
>>     detected. Any ideas? Other than calling sys.exit(1) of course.
>>     That would be a bit like stopping your car by driving it straight
>>     into a brick wall, rather than taking your foot off the gas and
>>     applying the brake in the traditional way. :-)
>>
>>     -- 
>>     Regards,
>>
>>     Andrew Marlow
>>     http://www.andrewpetermarlow.co.uk
>>     <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

Re: [Quickfixj-users] How to quickly terminate FIX event loop

[Andrew M. <mar...@gm...>]

Hello,

On Fri, 26 Mar 2021 at 13:54, Colin DuPlantis <co...@ma...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
> [snip]



> As for stopping processing, we would just end the session with
> Session.disconnect. Given that we restart the session where we want it to
> start, compelling the counter to resend some messages, we don't really
> worry about ending a session immediately. Use your flag to determine
> whether you should process messages or not. That way, the session can
> continue for a few seconds after you want it to end and you'll just drop
> those messages, knowing you'll get them back on restart.
>
> This approach doesn't require and config changes. On restart, the system
> will automatically orient itself and restart where it's supposed to.
>
Indeed. That sounds good. Thank you for your quick response.

I'd like to do this but without a Session object, I can't. The disconnect
method is not static so an object is required. Where would I get one? In
the callback where the error is detected I only have a SessionId. Also the
documentation for the disconnect method says you should not use it.

On 3/26/21 6:36 AM, Andrew Marlow wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello everyone,
>
> Please excuse my ignorance regarding FIX programming. I know that when a
> FIX session is initiated a thread runs asynchronously, dispatching
> callbacks until the main application terminates. But I need a way to
> shutdown that thread as soon as I detect a particular error. My message
> handler which contains the callbacks has a state variable that can be
> queried by the main app. The main app has a polling loop rather than
> sleeping forever. That loop enables it to periodically check the state of
> the message handler. If it has got into a bad state then the main app shuts
> down. The trouble with this is that there is a window during which any
> number of FIX messages may be received. This is causing trouble. Those
> messages do not get replayed when the app is restarted because the remote
> FIX end thinks that because they were picked up they do not need to be
> replayed.
>
> I am able to jig things such that old messages can be seen again. I have a
> config parameter datetime for subscription. On restart I can set this back
> in time. There also the sequence numbers, another aspect controlled by
> configuration. While this worked fine during development it is no good for
> production. This is because any config change in production requires people
> to jump through hoops of fire. So I need to find a better way, that causes
> the FIX processing to cease as soon as the error is detected. Any ideas?
> Other than calling sys.exit(1) of course. That would be a bit like stopping
> your car by driving it straight into a brick wall, rather than taking your
> foot off the gas and applying the brake in the traditional way. :-)
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
>

Re: [Quickfixj-users] How to quickly terminate FIX event loop

[Colin D. <co...@ma...>]

The way we handle such things are that we have a definitive way to 
indicate that a particular message has been processed. For example, if a 
row in table x exists, then the message with seq num y was processed. On 
start, we look for the row in table x that has the highest sequence 
number. That's the most recent message that we're sure we've processed. 
We set the session sequence numbers to match this row, after the session 
is created and before it is started. You must have the means to handle 
duplicate messages, though, since the process must allow for the fact 
that a particular message might have been processed all the way until 
the final step, create the row in table x. Also, if you process some 
messages in parallel, you must consider that there may be gaps in the 
sequence numbers in table x.

As for stopping processing, we would just end the session with 
Session.disconnect. Given that we restart the session where we want it 
to start, compelling the counter to resend some messages, we don't 
really worry about ending a session immediately. Use your flag to 
determine whether you should process messages or not. That way, the 
session can continue for a few seconds after you want it to end and 
you'll just drop those messages, knowing you'll get them back on restart.

This approach doesn't require and config changes. On restart, the system 
will automatically orient itself and restart where it's supposed to.

On 3/26/21 6:36 AM, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello everyone,
>
> Please excuse my ignorance regarding FIX programming. I know that when 
> a FIX session is initiated a thread runs asynchronously, dispatching 
> callbacks until the main application terminates. But I need a way to 
> shutdown that thread as soon as I detect a particular error. My 
> message handler which contains the callbacks has a state variable that 
> can be queried by the main app. The main app has a polling loop rather 
> than sleeping forever. That loop enables it to periodically check the 
> state of the message handler. If it has got into a bad state then the 
> main app shuts down. The trouble with this is that there is a window 
> during which any number of FIX messages may be received. This is 
> causing trouble. Those messages do not get replayed when the app is 
> restarted because the remote FIX end thinks that because they were 
> picked up they do not need to be replayed.
>
> I am able to jig things such that old messages can be seen again. I 
> have a config parameter datetime for subscription. On restart I can 
> set this back in time. There also the sequence numbers, another aspect 
> controlled by configuration. While this worked fine during development 
> it is no good for production. This is because any config change in 
> production requires people to jump through hoops of fire. So I need to 
> find a better way, that causes the FIX processing to cease as soon as 
> the error is detected. Any ideas? Other than calling sys.exit(1) of 
> course. That would be a bit like stopping your car by driving it 
> straight into a brick wall, rather than taking your foot off the gas 
> and applying the brake in the traditional way. :-)
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk <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

[Quickfixj-users] How to quickly terminate FIX event loop

[Andrew M. <mar...@gm...>]

Hello everyone,

Please excuse my ignorance regarding FIX programming. I know that when a
FIX session is initiated a thread runs asynchronously, dispatching
callbacks until the main application terminates. But I need a way to
shutdown that thread as soon as I detect a particular error. My message
handler which contains the callbacks has a state variable that can be
queried by the main app. The main app has a polling loop rather than
sleeping forever. That loop enables it to periodically check the state of
the message handler. If it has got into a bad state then the main app shuts
down. The trouble with this is that there is a window during which any
number of FIX messages may be received. This is causing trouble. Those
messages do not get replayed when the app is restarted because the remote
FIX end thinks that because they were picked up they do not need to be
replayed.

I am able to jig things such that old messages can be seen again. I have a
config parameter datetime for subscription. On restart I can set this back
in time. There also the sequence numbers, another aspect controlled by
configuration. While this worked fine during development it is no good for
production. This is because any config change in production requires people
to jump through hoops of fire. So I need to find a better way, that causes
the FIX processing to cease as soon as the error is detected. Any ideas?
Other than calling sys.exit(1) of course. That would be a bit like stopping
your car by driving it straight into a brick wall, rather than taking your
foot off the gas and applying the brake in the traditional way. :-)

-- 
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[Christoph J. <chr...@ma...>]

Hi,

I am not entirely sure since I cannot make sense of all of your logging output but I think the 
problem is as follows:
You get this message:
message=8=FIXT.1.1^9=369^35=8^34=55^43=Y^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=113^

and then seem to apply some logic to it in the "ToAppRejectMessageHandler". After that the same 
ExecReport is logged but with PossDup set to false (43=N):

2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener  : 
added 
possDupFlag:8=FIXT.1.1^9=369^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=102^

And then I think you pass that ExecReport to QFJ instead of the original one with PossDup=Y.

This would support what I wrote in my initial mail that something about the PossDup handling seems 
to be wrong.
When the PossDup flag is not set or set to false then the seqnum of that message is checked against 
the next expected seqnum. Since the next expected seqnum is 56 the session is getting logged out.

In general I would not suggest to interfere with the session-level processing but let QFJ do its job. :)
What do you think? Does this make sense to you?

Cheers,
Chris.




On 26.03.21 09:46, charles meng wrote:
>
> Here is the message log for 2.1.1.
>
> 2021-03-26 08:42:35.704  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.listener.FixApplicationListener 
>  : =>> Send toApp message to FIX gateway, MsgType=ExecutionReport(8), MsgSeqNum=55
> sessionId=FIXT.1.1:Initiator->Acceptor
> message=8=FIXT.1.1^9=338^35=8^34=55^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=103^
> 2021-03-26 08:42:35.704  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.listener.SenderMessageCracker   
>  : ExecutionReport - handle ExecutionReport message
> 2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.d.handle.MessageHandlerContext   
> : ===cracker type :TO_APP_REJECT
> 2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.d.handle.MessageHandlerContext   
> : ====do handle
> 2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.d.h.ToAppRejectMessageHandler   
>  : ===not approved retransmit
> 2021-03-26 08:42:35.708  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.listener.FixApplicationListener 
>  : added 
> possDupFlag:8=FIXT.1.1^9=343^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=086^
> 2021-03-26 08:42:35.708  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.listener.FixApplicationListener 
>  : possDubFlag:false
> 2021-03-26 08:42:35.711  INFO 40318 --- [nio-9051-exec-2] c.m.f.s.infra.SenderApplicationService   
> : [API Call] sendHigherSeqNoThanExcepted success，higherThanExpected=55, msgType=8
> 2021-03-26 08:42:35.714  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : <<= Initiator received fromAdmin message, MsgType=Resend(2), MsgSeqNum=42
> sessionId: FIXT.1.1:Initiator->Acceptor
> message: 
> 8=FIXT.1.1^9=78^35=2^34=42^49=Acceptor^52=20210326-08:42:35.711^56=Initiator^369=49^7=50^16=0^10=063^
> 2021-03-26 08:42:35.714  INFO 40318 --- [ssage Processor] c.m.f.s.listener.SenderMessageCracker   
>  : ResendRequest - from, beginSeqNo=50, endSeqNo=0
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : =>> Send toApp message to FIX gateway, MsgType=ExecutionReport(8), MsgSeqNum=55
> sessionId=FIXT.1.1:Initiator->Acceptor
> message=8=FIXT.1.1^9=369^35=8^34=55^43=Y^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=113^
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.listener.SenderMessageCracker   
>  : ExecutionReport - handle ExecutionReport message
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.d.handle.MessageHandlerContext   
> : ===cracker type :TO_APP_REJECT
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.d.handle.MessageHandlerContext   
> : ====do handle
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.d.h.ToAppRejectMessageHandler   
>  : ===not approved retransmit
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : added 
> possDupFlag:8=FIXT.1.1^9=369^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=102^
> 2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : possDubFlag:false
> 2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : =>> Send toAdmin message to FIX gateway, MsgType=SequenceReset(4), MsgSeqNum=50
> sessionId: FIXT.1.1:Initiator->Acceptor
> message: 
> 8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^
> 2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor] c.m.f.s.listener.SenderMessageCracker   
>  : SequenceReset - to
> 2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor] c.m.f.s.listener.SenderMessageCracker   
>  : expected sender num compare to new seq no:true,NewSeqNo:55,ExpectedSenderNum:56
> 2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor] c.m.f.s.listener.SenderMessageCracker   
>  : SequenceReset 
> finally:8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^
> 2021-03-26 08:42:35.726  INFO 40318 --- [ssage Processor] c.m.f.s.listener.FixApplicationListener 
>  : <<= Initiator received fromAdmin message, MsgType=Logout(5), MsgSeqNum=43
> sessionId: FIXT.1.1:Initiator->Acceptor
> message: 
> 8=FIXT.1.1^9=126^35=5^34=43^49=Acceptor^52=20210326-08:42:35.723^56=Initiator^369=55^1128=9^58=MsgSeqNum 
> too low, expecting 56 but received 55^10=010^
>
>
> Thanks
> Best regards.
>
> Christoph John <chr...@ma... <mailto:chr...@ma...>> 于2021年3月26日周五 
> 下午2:43写道：
>
>     Just saw that you are using 2.1.1. The other side uses the same version?
>     Could you maybe try to reproduce with version 2.2.0 and paste the relevant message log? Or at
>     least paste the message log from your currently used version.
>     Thanks
>
>     Am 26. März 2021 07:40:23 MEZ schrieb Christoph John <chr...@ma...
>     <mailto:chr...@ma...>>:
>
>         Hi,
>         which version of QFJ are you and the other side using?
>         Could you please directly paste the relevant message log from your side and if possible
>         also from the acceptor?
>         Thanks,
>         Chris.
>

-- 
Christoph John
Software Engineering
T +49 241 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

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[charles m. <xl...@gm...>]

Here is the message log for 2.1.1.

2021-03-26 08:42:35.704  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.listener.FixApplicationListener  : =>> Send toApp message to FIX
gateway, MsgType=ExecutionReport(8), MsgSeqNum=55
sessionId=FIXT.1.1:Initiator->Acceptor
message=8=FIXT.1.1^9=338^35=8^34=55^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=103^
2021-03-26 08:42:35.704  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.listener.SenderMessageCracker    : ExecutionReport - handle
ExecutionReport message
2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.d.handle.MessageHandlerContext   : ===cracker type :TO_APP_REJECT
2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.d.handle.MessageHandlerContext   : ====do handle
2021-03-26 08:42:35.707  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.d.h.ToAppRejectMessageHandler    : ===not approved retransmit
2021-03-26 08:42:35.708  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.listener.FixApplicationListener  : added
possDupFlag:8=FIXT.1.1^9=343^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.703^56=Acceptor^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=086^
2021-03-26 08:42:35.708  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.listener.FixApplicationListener  : possDubFlag:false
2021-03-26 08:42:35.711  INFO 40318 --- [nio-9051-exec-2]
c.m.f.s.infra.SenderApplicationService   : [API Call]
sendHigherSeqNoThanExcepted success，higherThanExpected=55, msgType=8
2021-03-26 08:42:35.714  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : <<= Initiator received fromAdmin
message, MsgType=Resend(2), MsgSeqNum=42
sessionId: FIXT.1.1:Initiator->Acceptor
message:
8=FIXT.1.1^9=78^35=2^34=42^49=Acceptor^52=20210326-08:42:35.711^56=Initiator^369=49^7=50^16=0^10=063^
2021-03-26 08:42:35.714  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.SenderMessageCracker    : ResendRequest - from,
beginSeqNo=50, endSeqNo=0
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : =>> Send toApp message to FIX
gateway, MsgType=ExecutionReport(8), MsgSeqNum=55
sessionId=FIXT.1.1:Initiator->Acceptor
message=8=FIXT.1.1^9=369^35=8^34=55^43=Y^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=113^
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.SenderMessageCracker    : ExecutionReport - handle
ExecutionReport message
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.d.handle.MessageHandlerContext   : ===cracker type :TO_APP_REJECT
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.d.handle.MessageHandlerContext   : ====do handle
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.d.h.ToAppRejectMessageHandler    : ===not approved retransmit
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : added
possDupFlag:8=FIXT.1.1^9=369^35=8^34=55^43=N^49=Initiator^52=20210326-08:42:35.718^56=Acceptor^122=20210326-08:42:35.703^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=102^
2021-03-26 08:42:35.718  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : possDubFlag:false
2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : =>> Send toAdmin message to FIX
gateway, MsgType=SequenceReset(4), MsgSeqNum=50
sessionId: FIXT.1.1:Initiator->Acceptor
message:
8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^
2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.SenderMessageCracker    : SequenceReset - to
2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.SenderMessageCracker    : expected sender num compare to
new seq no:true,NewSeqNo:55,ExpectedSenderNum:56
2021-03-26 08:42:35.719  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.SenderMessageCracker    : SequenceReset
finally:8=FIXT.1.1^9=104^35=4^34=50^43=Y^49=Initiator^52=20210326-08:42:35.719^56=Acceptor^122=20210326-08:42:35.718^36=55^123=Y^10=182^
2021-03-26 08:42:35.726  INFO 40318 --- [ssage Processor]
c.m.f.s.listener.FixApplicationListener  : <<= Initiator received fromAdmin
message, MsgType=Logout(5), MsgSeqNum=43
sessionId: FIXT.1.1:Initiator->Acceptor
message:
8=FIXT.1.1^9=126^35=5^34=43^49=Acceptor^52=20210326-08:42:35.723^56=Initiator^369=55^1128=9^58=MsgSeqNum
too low, expecting 56 but received 55^10=010^


Thanks
Best regards.

Christoph John <chr...@ma...> 于2021年3月26日周五 下午2:43写道：

> Just saw that you are using 2.1.1. The other side uses the same version?
> Could you maybe try to reproduce with version 2.2.0 and paste the relevant
> message log? Or at least paste the message log from your currently used
> version.
> Thanks
>
> Am 26. März 2021 07:40:23 MEZ schrieb Christoph John <
> chr...@ma...>:
>>
>> Hi,
>> which version of QFJ are you and the other side using?
>> Could you please directly paste the relevant message log from your side
>> and if possible also from the acceptor?
>> Thanks,
>> Chris.
>
>

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[Christoph J. <chr...@ma...>]

Just saw that you are using 2.1.1. The other side uses the same version?
Could you maybe try to reproduce with version 2.2.0 and paste the relevant message log? Or at least paste the message log from your currently used version. 
Thanks

Am 26. März 2021 07:40:23 MEZ schrieb Christoph John <chr...@ma...>:
>Hi,
>which version of QFJ are you and the other side using?
>Could you please directly paste the relevant message log from your side
>and if possible also from the acceptor?
>Thanks,
>Chris.

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[Christoph J. <chr...@ma...>]

Hi,
which version of QFJ are you and the other side using?
Could you please directly paste the relevant message log from your side and if possible also from the acceptor?
Thanks,
Chris. 

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[charles m. <xl...@gm...>]

Hi,Christoph,
First of all Thanks for your reply!
Yes ,the Acceptor also a QFJ engine.

Based on the QFJ version I use, the order of sending the message is to send
SequenceReset first, and then resend the ExecReport with a sequence of 646.
See the code below, I made a note in the key position. Since EndSeqNo=0 in
the ResendRequest sent by the Acceptor, so When resend, the message with
sequence 646 will also be resent.


private void resendMessages(Message receivedMessage, int beginSeqNo, int
endSeqNo)
            throws IOException, InvalidMessage, FieldNotFound {

        final ArrayList<String> messages = new ArrayList<>();
        try {
            state.get(beginSeqNo, endSeqNo, messages);
        } catch (final IOException e) {
            if (forceResendWhenCorruptedStore) {
                LOG.error("Cannot read messages from stores, resend
HeartBeats", e);
                for (int i = beginSeqNo; i < endSeqNo; i++) {
                    final Message heartbeat =
messageFactory.create(sessionID.getBeginString(),
                            MsgType.HEARTBEAT);
                    initializeHeader(heartbeat.getHeader());
                    heartbeat.getHeader().setInt(MsgSeqNum.FIELD, i);
                    messages.add(heartbeat.toString());
                }
            } else {
                throw e;
            }
        }

        int msgSeqNum = 0;
        int begin = 0;
*        int current = beginSeqNo;  // current = 641*
        boolean appMessageJustSent = false;

        for (final String message : messages) {
            appMessageJustSent = false;
            final Message msg;
            try {
                // QFJ-626
                msg = parseMessage(message);
               * msgSeqNum = msg.getHeader().getInt(MsgSeqNum.FIELD);  //
msgSeqNum = 646*
            } catch (final Exception e) {
                getLog().onErrorEvent(
                        "Error handling ResendRequest: failed to parse
message (" + e.getMessage()
                        + "): " + message);
                // Note: a SequenceReset message will be generated to fill
the gap
                continue;
            }



* if ((current != msgSeqNum) && begin == 0) {                begin =
current;            }*

            final String msgType = msg.getHeader().getString(MsgType.FIELD);

            if (MessageUtils.isAdminMessage(msgType) &&
!forceResendWhenCorruptedStore) {
                if (begin == 0) {
                    begin = msgSeqNum;
                }
            } else {
                initializeResendFields(msg);







*if (resendApproved(msg)) {                    if (begin != 0) {
            generateSequenceReset(receivedMessage, begin, msgSeqNum);
              }                    getLog().onEvent("Resending message: " +
msgSeqNum);                    send(msg.toString());
begin = 0;                    appMessageJustSent = true;*
                } else {
                    if (begin == 0) {
                        begin = msgSeqNum;
                    }
                }
            }
            current = msgSeqNum + 1;
        }


Best regards.

Christoph John <chr...@ma...> 于2021年3月25日周四 下午8:36写道：

> Who owns the other side? Is it also a QFJ engine?
> BTW your order in your mail is wrong. Based on field 52/SendingTime the
> ExecReport with seqnum 646 is resent first and then the SequenceReset is
> sent out. That is also the order I would expect.
> From briefly looking at it it looks as if the opposing side does not
> consider the PossDup flag that is set on the resent message with seqnum 646
> and does incorrectly report it as too low.
>
> Cheers,
> Chris.
>
>
> On 25.03.21 09:41, charles meng wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi guys:
>
> I encountered a very strange problem. I just want to simulate a scenario
> where the sequence number exceeds the expected sequence number to trigger
> resend, but every time I receive an unexpected logout message. The detailed
> information is as follows:
>
> My service is in the role of Initiatator.
> Version:quickfix:2.1.1, FIX:FIX50SP2
>
> Initiator senderSeqNo:640
>
> 1, Initiator sends a request with a higher sequence number than expected:
> 8=FIXT.1.1^9=331^35=8^34=646^49=test1^52=20210325-08:23:21.810^56=TEST^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=219^
>
> 2, Initiator receives the resend
> request:8=FIXT.1.1^9=73^35=2^34=453^49=TEST^52=20210325-08:23:21.814^56=test1^369=640^7=641^16=0^10=029^
>
> 3, Initiator sends a sequenceReset
> request:8=FIXT.1.1^9=98^35=4^34=641^43=Y^49=test1^52=20210325-08:23:21.832^56=TEST^122=20210325-08:23:21.831^36=646^123=Y^10=053^
>
> 4, The Initiator resends the first message (because this is a simulated
> scenario that exceeds the expected seqNum, so there is no other data
> between 641 and
> 646):8=FIXT.1.1^9=362^35=8^34=646^43=Y^49=test1^52=20210325-08:23:21.830^56=TEST^122=20210325-08:23:21.810^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=217^
>
> 4, Initiator receives Logout
> message:8=FIXT.1.1^9=121^35=5^34=454^49=TEST^52=20210325-08:23:21.837^56=test^369=646^1128=9^58=MsgSeqNum
> too low, expecting 647 but received 646^10=248^
>
>
> Thanks in advance!
>
>
>
> _______________________________________________
> 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
>
>

Re: [Quickfixj-users] JDBC MessageStore with several number of sessions / connection pooling library

[Christoph J. <chr...@ma...>]

Hi Colin,

thanks for sharing this, it was interesting to see how you implemented the store.

Cheers,
Chris.

On 22.02.21 17:24, Colin DuPlantis wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Not sure if this helps, exactly, but, we replaced the JDBC message store with a Hibernate-based 
> one that's fronted by the in-memory message store.
>
> It's fundamentally Spring-based, so allows you to swap in your own pool. We've used Hikari and 
> C3P0 successfully.
>
> Here are the pieces:
>
> https://github.com/Marketcetera/marketcetera/blob/master/fix/fix-core/src/main/java/org/marketcetera/fix/store/ 
>
>
>
> On 2/22/21 3:24 AM, Christoph John via Quickfixj-users wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> does anyone have the JDBC MessageStore in use with a larger number of sessions? Let's say 50+ 
>> sessions?
>> I currently struggle to use it because the connection pooling lib Proxool (which QFJ uses) is not 
>> maintained anymore and if I ran into issues then probably there would be no bug fixes.
>>
>> Probably it would be not such a big deal to replace it with something better, e.g. HikariCP...?
>> Did someone already replace Proxool with something different?
>>
>> Feedback is highly appreciated.
>>
>> There also is https://github.com/quickfix-j/quickfixj/discussions/373 if you want to leave 
>> comments on Github.
>>
>> Thanks,
>> Chris.
>>

-- 
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

Re: [Quickfixj-users] JDBC MessageStore with several number of sessions / connection pooling library

[Christoph J. <chr...@ma...>]

Hi Ajay,

thanks for this, I totally forgot that it is quite simple to override the built-in Jdbc stuff. Been 
using FileStore most of the time...

Cheers,
Chris.


On 22.02.21 17:05, Ajay Patwardhan wrote:
> Yes Chris
> we use c3p0. https://www.mchange.com/projects/c3p0/ <https://www.mchange.com/projects/c3p0/>
> We configure it in our code and manually set it into the factories where we need it
> ((JdbcStoreFactory)storeFactory).setDataSource(ourDatasource);
> ((JdbcLogFactory)jdbcLogFactory).setDataSource(ourDatasource);
>
> We manually run over 500 sessions spread across about 10 processes in prod between staging and 
> dropcopy connections and have had no issues.
>
>
> Ajay Patwardhan
> Enfusion LLC
> 125 South Clark Street, Suite 750, Chicago, IL 60603
> Main  : 312-253-9800
> Direct: 312-253-7659
> Fax   : 312-253-9888
> email : ap...@en... <mailto:ap...@en...>
>
>
> On Mon, Feb 22, 2021 at 5:25 AM 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,
>
>     does anyone have the JDBC MessageStore in use with a larger number of sessions? Let's say 50+
>     sessions?
>     I currently struggle to use it because the connection pooling lib Proxool (which QFJ uses) is not
>     maintained anymore and if I ran into issues then probably there would be no bug fixes.
>
>     Probably it would be not such a big deal to replace it with something better, e.g. HikariCP...?
>     Did someone already replace Proxool with something different?
>
>     Feedback is highly appreciated.
>
>     There also is https://github.com/quickfix-j/quickfixj/discussions/373
>     <https://github.com/quickfix-j/quickfixj/discussions/373> if you want to leave comments
>     on Github.
>
>     Thanks,
>     Chris.
>
>     -- 
>     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>
>
>
> <https://www.linkedin.com/uas/login?session_redirect=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fenfusion-systems-llc%2Fmycompany> 
> <https://twitter.com/enfusion>
> _Agility-on-demand. What is it as applied to middle and back office operations, when do you need 
> it, and how can you get it? Read more here 
> <https://www.enfusion.com/how-agile-is-your-asset-management-team/> and follow us for future 
> insights. 

-- 
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

Re: [Quickfixj-users] Unexpected "MsgSeqNum too low, expecting X but received Y"

[Christoph J. <chr...@ma...>]

Who owns the other side? Is it also a QFJ engine?
BTW your order in your mail is wrong. Based on field 52/SendingTime the ExecReport with seqnum 646 
is resent first and then the SequenceReset is sent out. That is also the order I would expect.
 From briefly looking at it it looks as if the opposing side does not consider the PossDup flag that 
is set on the resent message with seqnum 646 and does incorrectly report it as too low.

Cheers,
Chris.


On 25.03.21 09:41, charles meng wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi guys:
>
> I encountered a very strange problem. I just want to simulate a scenario where the sequence number 
> exceeds the expected sequence number to trigger resend, but every time I receive an unexpected 
> logout message. The detailed information is as follows:
>
> My service is in the role of Initiatator.
> Version:quickfix:2.1.1, FIX:FIX50SP2
>
> Initiator senderSeqNo:640
>
> 1, Initiator sends a request with a higher sequence number than expected: 
> 8=FIXT.1.1^9=331^35=8^34=646^49=test1^52=20210325-08:23:21.810^56=TEST^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=219^
>
> 2, Initiator receives the resend 
> request:8=FIXT.1.1^9=73^35=2^34=453^49=TEST^52=20210325-08:23:21.814^56=test1^369=640^7=641^16=0^10=029^
>
> 3, Initiator sends a sequenceReset 
> request:8=FIXT.1.1^9=98^35=4^34=641^43=Y^49=test1^52=20210325-08:23:21.832^56=TEST^122=20210325-08:23:21.831^36=646^123=Y^10=053^
>
> 4, The Initiator resends the first message (because this is a simulated scenario that exceeds the 
> expected seqNum, so there is no other data between 641 and 
> 646):8=FIXT.1.1^9=362^35=8^34=646^43=Y^49=test1^52=20210325-08:23:21.830^56=TEST^122=20210325-08:23:21.810^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=217^
>
> 4, Initiator receives Logout 
> message:8=FIXT.1.1^9=121^35=5^34=454^49=TEST^52=20210325-08:23:21.837^56=test^369=646^1128=9^58=MsgSeqNum 
> too low, expecting 647 but received 646^10=248^
>
>
> Thanks in advance!
>
>
>
> _______________________________________________
> 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

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Christoph J. <chr...@ma...>]

Currently no plans for the next release, probably due in some weeks.
Fix for that problem will not be included unless someone submits a PR for it or I'll find some time 
(unlikely ;)).

Cheers,
Chris.

On 25.03.21 04:15, Minh Kha wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Thank you Philip
>
> Let me apply this change and test. By the way, do you have any plan for the next 
> release, including the fix for it ?
>
> Best regards,
> Kha Phan
>
> Vào Th 5, 25 thg 3, 2021 vào lúc 00:08 Philip Whitehouse <ph...@wh... 
> <mailto:ph...@wh...>> đã viết:
>
>     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/>
>
>
>     As Chris said, the TransactionTime field isn’t behaving correctly in the current code.
>
>     Please use
>>
>>
>>             msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));
>>
>
>     instead to set the transaction time on the message
>
>
>     Best,
>
>     Philip Whitehouse
>
>>     On 24 Mar 2021, at 17:04, Minh Kha <min...@gm... <mailto:min...@gm...>>
>>     wrote:
>>
>>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>     <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>>
>>
>>     Hi Chris,
>>
>>     Because the TransactionTime with the code: new TransactionTime() is seems in in the future
>>     when compare with SendingTime. Dont know why it behave like that. Any idea?
>>
>>     Best regards
>>     Kha Phan
>>
>>     Vào Th 5, 25 thg 3, 2021 vào lúc 00:00 Minh Kha <min...@gm...
>>     <mailto:min...@gm...>> đã viết:
>>
>>         Hi Chris,
>>
>>         Thanks for your reply, so u mean the constructor now have problem ?
>>         Moreover, the TransactionTime in my case seems it is UTC +8, which is my local time. Do u
>>         know how can prevent it from using local time, because I remember there is a
>>         configuration UseLocalTime = Y or N
>>         Is that config using for that purpose ?
>>
>>         Best regards
>>         Kha Phan
>>
>>         Vào Th 4, 24 thg 3, 2021 vào lúc 20:23 Christoph John via Quickfixj-users
>>         <qui...@li... <mailto:qui...@li...>> đã
>>         viết:
>>
>>             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/>
>>
>>
>>             Yes, I think there is something wrong about the constructor. When I just tested it
>>             there was a UTC date but in ISO notation:
>>
>>             quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759
>>
>>             So please use the following:
>>             Message msg = new Message();
>>             msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));
>>
>>
>>             Don't know when this got broken...
>>
>>             Cheers,
>>             Chris.
>>
>>
>>             On 24.03.21 13:09, philip wrote:
>>>             Given the use of `new TransactionTime()` I wonder if we are not correctly generating
>>>             the time correctly/not outputting in UTC in UTC when you do it like that (whereas
>>>             SendingTime is definitely set correctly to UTC).
>>>
>>>             - Philip
>>>
>>>             On 2021-03-24 11:44, Christoph John via Quickfixj-users 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,
>>>>
>>>>             how do you initialize the TransactTime in your code?
>>>>             SendingTime is set by the engine when the message is sent out.
>>>>
>>>>             Cheers,
>>>>             Chris.
>>>>
>>>>             On 24.03.21 12:06, Minh Kha 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 team,
>>>>>
>>>>>             I got a problem when message is showing different time between tag
>>>>>             52 and tag 60
>>>>>
>>>>>             _|parse:
>>>>>
>>>>             8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_
>>>>
>>>>>
>>>>>
>>>>>             Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
>>>>>             cannot find the place init it, and think that would be set by
>>>>>             default in quickfix ?
>>>>>
>>>>>             Could you please give me some advice about this ?
>>>>>
>>>>>             Thank you
>>>>>
>>>>>             Best regards,
>>>>>             Kha Phan
>>>>>
>>>>>             -- 
>>>>>
>>>>>             PHAN NGUYEN MINH KHA
>>>>>             min...@gm... <mailto:min...@gm...> / 0938499460
>>>>>
>>>>>             _______________________________________________
>>>>>             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> [1]
>>>>
>>>>             Amtsgericht Aachen: HRB 8151
>>>>             Ust.-Id: DE 813021663
>>>>             Geschäftsführer: George Macdonald
>>>>
>>>>
>>>>             Links:
>>>>             ------
>>>>             [1] http://www.macd.com <http://www.macd.com>
>>>>             _______________________________________________
>>>>             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>
>>
>>
>>
>>         -- 
>>         *Phan Nguyen Minh Kha*
>>         min...@gm... <mailto:min...@gm...> / 0938499460
>>
>>
>>
>>     -- 
>>     *Phan Nguyen Minh Kha*
>>     min...@gm... <mailto:min...@gm...> / 0938499460
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li... <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>     _______________________________________________
>     Quickfixj-users mailing list
>     Qui...@li... <mailto:Qui...@li...>
>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
>
>
> -- 
> *Phan Nguyen Minh Kha*
> min...@gm... <mailto:min...@gm...> / 0938499460
>
>
> _______________________________________________
> 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] Unexpected "MsgSeqNum too low, expecting X but received Y"

[charles m. <xl...@gm...>]

Hi guys:

I encountered a very strange problem. I just want to simulate a scenario
where the sequence number exceeds the expected sequence number to trigger
resend, but every time I receive an unexpected logout message. The detailed
information is as follows:

My service is in the role of Initiatator.
Version:quickfix:2.1.1, FIX:FIX50SP2

Initiator senderSeqNo:640

1, Initiator sends a request with a higher sequence number than expected:
8=FIXT.1.1^9=331^35=8^34=646^49=test1^52=20210325-08:23:21.810^56=TEST^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=219^

2, Initiator receives the resend
request:8=FIXT.1.1^9=73^35=2^34=453^49=TEST^52=20210325-08:23:21.814^56=test1^369=640^7=641^16=0^10=029^

3, Initiator sends a sequenceReset
request:8=FIXT.1.1^9=98^35=4^34=641^43=Y^49=test1^52=20210325-08:23:21.832^56=TEST^122=20210325-08:23:21.831^36=646^123=Y^10=053^

4, The Initiator resends the first message (because this is a simulated
scenario that exceeds the expected seqNum, so there is no other data
between 641 and
646):8=FIXT.1.1^9=362^35=8^34=646^43=Y^49=test1^52=20210325-08:23:21.830^56=TEST^122=20210325-08:23:21.810^1=108331^14=0^15=USD^17=1115569_1615646513221_927^22=971^37=1115569^38=1^39=0^40=4^44=290.2^48=BCH/USD^54=1^55=BCHUSD^59=1^60=20210313-14:41:53.099^150=0^151=1^167=CRYPTSPOT^423=3^460=15^581=1^965=1^1084=4^1138=0^453=2^448=MATX^447=G^452=22^448=MEHSAG1601PIND90805^447=D^452=3^10=217^

4, Initiator receives Logout
message:8=FIXT.1.1^9=121^35=5^34=454^49=TEST^52=20210325-08:23:21.837^56=test^369=646^1128=9^58=MsgSeqNum
too low, expecting 647 but received 646^10=248^


Thanks in advance!

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Minh K. <min...@gm...>]

Thank you Philip

Let me apply this change and test. By the way, do you have any plan for the
next release, including the fix for it ?

Best regards,
Kha Phan

Vào Th 5, 25 thg 3, 2021 vào lúc 00:08 Philip Whitehouse <ph...@wh...>
đã viết:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> As Chris said, the TransactionTime field isn’t behaving correctly in the
> current code.
>
> Please use
>
>
>>> msg.setUtcTimeStamp(TransactTime.FIELD,
>>> LocalDateTime.now(ZoneOffset.UTC));
>>>
>>
> instead to set the transaction time on the message
>
>
> Best,
>
> Philip Whitehouse
>
> On 24 Mar 2021, at 17:04, Minh Kha <min...@gm...> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi Chris,
>
> Because the TransactionTime with the code: new TransactionTime() is seems
> in in the future when compare with SendingTime. Dont know why it
> behave like that. Any idea?
>
> Best regards
> Kha Phan
>
> Vào Th 5, 25 thg 3, 2021 vào lúc 00:00 Minh Kha <min...@gm...>
> đã viết:
>
>> Hi Chris,
>>
>> Thanks for your reply, so u mean the constructor now have problem ?
>> Moreover, the TransactionTime in my case seems it is UTC +8, which is my
>> local time. Do u know how can prevent it from using local time, because I
>> remember there is a configuration UseLocalTime = Y or N
>> Is that config using for that purpose ?
>>
>> Best regards
>> Kha Phan
>>
>> Vào Th 4, 24 thg 3, 2021 vào lúc 20:23 Christoph John via
>> Quickfixj-users <qui...@li...> đã viết:
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>>> http://www.quickfixj.org/support/
>>>
>>>
>>> Yes, I think there is something wrong about the constructor. When I just
>>> tested it there was a UTC date but in ISO notation:
>>>
>>> quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759
>>>
>>> So please use the following:
>>> Message msg = new Message();
>>> msg.setUtcTimeStamp(TransactTime.FIELD,
>>> LocalDateTime.now(ZoneOffset.UTC));
>>>
>>
>>> Don't know when this got broken...
>>>
>>> Cheers,
>>> Chris.
>>>
>>>
>>> On 24.03.21 13:09, philip wrote:
>>>
>>> Given the use of `new TransactionTime()` I wonder if we are not
>>> correctly generating the time correctly/not outputting in UTC in UTC when
>>> you do it like that (whereas SendingTime is definitely set correctly to
>>> UTC).
>>>
>>> - Philip
>>>
>>> On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>  Hi,
>>>
>>> how do you initialize the TransactTime in your code?
>>> SendingTime is set by the engine when the message is sent out.
>>>
>>> Cheers,
>>> Chris.
>>>
>>> On 24.03.21 12:06, Minh Kha wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>> Hi team,
>>>
>>> I got a problem when message is showing different time between tag
>>> 52 and tag 60
>>>
>>> _|parse:
>>>
>>> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_
>>>
>>>
>>>
>>>
>>> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
>>> cannot find the place init it, and think that would be set by
>>> default in quickfix ?
>>>
>>> Could you please give me some advice about this ?
>>>
>>> Thank you
>>>
>>> Best regards,
>>> Kha Phan
>>>
>>> --
>>>
>>> PHAN NGUYEN MINH KHA
>>> min...@gm... / 0938499460
>>>
>>> _______________________________________________
>>> 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 [1]
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://www.macd.com
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>> *Phan Nguyen Minh Kha*
>> min...@gm... / 0938499460
>>
>
>
> --
> *Phan Nguyen Minh Kha*
> min...@gm... / 0938499460
> _______________________________________________
> 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
>


-- 
*Phan Nguyen Minh Kha*
min...@gm... / 0938499460

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Philip W. <ph...@wh...>]

As Chris said, the TransactionTime field isn’t behaving correctly in the current code.

Please use 
>>> 
>>> msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));

instead to set the transaction time on the message


Best,

Philip Whitehouse

> On 24 Mar 2021, at 17:04, Minh Kha <min...@gm...> wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> Hi Chris,
> 
> Because the TransactionTime with the code: new TransactionTime() is seems in in the future when compare with SendingTime. Dont know why it behave like that. Any idea?
> 
> Best regards
> Kha Phan
> 
> Vào Th 5, 25 thg 3, 2021 vào lúc 00:00 Minh Kha <min...@gm...> đã viết:
>> Hi Chris,
>> 
>> Thanks for your reply, so u mean the constructor now have problem ?
>> Moreover, the TransactionTime in my case seems it is UTC +8, which is my local time. Do u know how can prevent it from using local time, because I remember there is a configuration UseLocalTime = Y or N
>> Is that config using for that purpose ?
>> 
>> Best regards
>> Kha Phan
>> 
>> Vào Th 4, 24 thg 3, 2021 vào lúc 20:23 Christoph John via Quickfixj-users <qui...@li...> đã viết:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>> 
>>> 
>>> Yes, I think there is something wrong about the constructor. When I just tested it there was a UTC date but in ISO notation:
>>> 
>>> quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759
>>> 
>>> So please use the following:
>>> Message msg = new Message();
>>> msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));
>>> 
>>> Don't know when this got broken...
>>> 
>>> Cheers,
>>> Chris.
>>> 
>>> 
>>>> On 24.03.21 13:09, philip wrote:
>>>> Given the use of `new TransactionTime()` I wonder if we are not correctly generating the time correctly/not outputting in UTC in UTC when you do it like that (whereas SendingTime is definitely set correctly to UTC). 
>>>> 
>>>> - Philip 
>>>> 
>>>>> On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote: 
>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ 
>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/ 
>>>>> 
>>>>> 
>>>>> 
>>>>>  Hi, 
>>>>> 
>>>>> how do you initialize the TransactTime in your code? 
>>>>> SendingTime is set by the engine when the message is sent out. 
>>>>> 
>>>>> Cheers, 
>>>>> Chris. 
>>>>> 
>>>>> On 24.03.21 12:06, Minh Kha wrote: 
>>>>> 
>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/ 
>>>>>> 
>>>>>> Hi team, 
>>>>>> 
>>>>>> I got a problem when message is showing different time between tag 
>>>>>> 52 and tag 60 
>>>>>> 
>>>>>> _|parse: 
>>>>>> 
>>>>> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_ 
>>>>>> 
>>>>>> 
>>>>>> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I 
>>>>>> cannot find the place init it, and think that would be set by 
>>>>>> default in quickfix ? 
>>>>>> 
>>>>>> Could you please give me some advice about this ? 
>>>>>> 
>>>>>> Thank you 
>>>>>> 
>>>>>> Best regards, 
>>>>>> Kha Phan 
>>>>>> 
>>>>>> -- 
>>>>>> 
>>>>>> PHAN NGUYEN MINH KHA 
>>>>>> min...@gm... / 0938499460 
>>>>>> 
>>>>>> _______________________________________________ 
>>>>>> 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 [1] 
>>>>> 
>>>>> Amtsgericht Aachen: HRB 8151 
>>>>> Ust.-Id: DE 813021663 
>>>>> Geschäftsführer: George Macdonald 
>>>>> 
>>>>> 
>>>>> Links: 
>>>>> ------ 
>>>>> [1] http://www.macd.com 
>>>>> _______________________________________________ 
>>>>> Quickfixj-users mailing list 
>>>>> Qui...@li... 
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users 
>>> 
>>> -- 
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557080-28
>>> chr...@ma...
>>> 
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germany
>>> www.macd.com
>>> 
>>> Amtsgericht Aachen: HRB 8151 
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> 
>> 
>> -- 
>> Phan Nguyen Minh Kha
>> min...@gm... / 0938499460
> 
> 
> -- 
> Phan Nguyen Minh Kha
> min...@gm... / 0938499460
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Minh K. <min...@gm...>]

Hi Chris,

Because the TransactionTime with the code: new TransactionTime() is seems
in in the future when compare with SendingTime. Dont know why it
behave like that. Any idea?

Best regards
Kha Phan

Vào Th 5, 25 thg 3, 2021 vào lúc 00:00 Minh Kha <min...@gm...>
đã viết:

> Hi Chris,
>
> Thanks for your reply, so u mean the constructor now have problem ?
> Moreover, the TransactionTime in my case seems it is UTC +8, which is my
> local time. Do u know how can prevent it from using local time, because I
> remember there is a configuration UseLocalTime = Y or N
> Is that config using for that purpose ?
>
> Best regards
> Kha Phan
>
> Vào Th 4, 24 thg 3, 2021 vào lúc 20:23 Christoph John via
> Quickfixj-users <qui...@li...> đã viết:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>> http://www.quickfixj.org/support/
>>
>>
>> Yes, I think there is something wrong about the constructor. When I just
>> tested it there was a UTC date but in ISO notation:
>>
>> quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759
>>
>> So please use the following:
>> Message msg = new Message();
>> msg.setUtcTimeStamp(TransactTime.FIELD,
>> LocalDateTime.now(ZoneOffset.UTC));
>>
>> Don't know when this got broken...
>>
>> Cheers,
>> Chris.
>>
>>
>> On 24.03.21 13:09, philip wrote:
>>
>> Given the use of `new TransactionTime()` I wonder if we are not correctly
>> generating the time correctly/not outputting in UTC in UTC when you do it
>> like that (whereas SendingTime is definitely set correctly to UTC).
>>
>> - Philip
>>
>> On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>  Hi,
>>
>> how do you initialize the TransactTime in your code?
>> SendingTime is set by the engine when the message is sent out.
>>
>> Cheers,
>> Chris.
>>
>> On 24.03.21 12:06, Minh Kha wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>> Hi team,
>>
>> I got a problem when message is showing different time between tag
>> 52 and tag 60
>>
>> _|parse:
>>
>> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_
>>
>>
>>
>>
>> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
>> cannot find the place init it, and think that would be set by
>> default in quickfix ?
>>
>> Could you please give me some advice about this ?
>>
>> Thank you
>>
>> Best regards,
>> Kha Phan
>>
>> --
>>
>> PHAN NGUYEN MINH KHA
>> min...@gm... / 0938499460
>>
>> _______________________________________________
>> 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 [1]
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
>> Links:
>> ------
>> [1] http://www.macd.com
>> _______________________________________________
>> 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
>>
>
>
> --
> *Phan Nguyen Minh Kha*
> min...@gm... / 0938499460
>


-- 
*Phan Nguyen Minh Kha*
min...@gm... / 0938499460

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Minh K. <min...@gm...>]

Hi Chris,

Thanks for your reply, so u mean the constructor now have problem ?
Moreover, the TransactionTime in my case seems it is UTC +8, which is my
local time. Do u know how can prevent it from using local time, because I
remember there is a configuration UseLocalTime = Y or N
Is that config using for that purpose ?

Best regards
Kha Phan

Vào Th 4, 24 thg 3, 2021 vào lúc 20:23 Christoph John via Quickfixj-users
<qui...@li...> đã viết:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Yes, I think there is something wrong about the constructor. When I just
> tested it there was a UTC date but in ISO notation:
>
> quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759
>
> So please use the following:
> Message msg = new Message();
> msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));
>
> Don't know when this got broken...
>
> Cheers,
> Chris.
>
>
> On 24.03.21 13:09, philip wrote:
>
> Given the use of `new TransactionTime()` I wonder if we are not correctly
> generating the time correctly/not outputting in UTC in UTC when you do it
> like that (whereas SendingTime is definitely set correctly to UTC).
>
> - Philip
>
> On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>  Hi,
>
> how do you initialize the TransactTime in your code?
> SendingTime is set by the engine when the message is sent out.
>
> Cheers,
> Chris.
>
> On 24.03.21 12:06, Minh Kha wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
> Hi team,
>
> I got a problem when message is showing different time between tag
> 52 and tag 60
>
> _|parse:
>
> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_
>
>
>
>
> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
> cannot find the place init it, and think that would be set by
> default in quickfix ?
>
> Could you please give me some advice about this ?
>
> Thank you
>
> Best regards,
> Kha Phan
>
> --
>
> PHAN NGUYEN MINH KHA
> min...@gm... / 0938499460
>
> _______________________________________________
> 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 [1]
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
> Links:
> ------
> [1] http://www.macd.com
> _______________________________________________
> 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
>


-- 
*Phan Nguyen Minh Kha*
min...@gm... / 0938499460

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[Christoph J. <chr...@ma...>]

Yes, I think there is something wrong about the constructor. When I just tested it there was a UTC 
date but in ISO notation:

quickfix.MessageTest.testTransactTime() 60=2021-03-24T12:48:25.778759

So please use the following:
Message msg = new Message();
msg.setUtcTimeStamp(TransactTime.FIELD, LocalDateTime.now(ZoneOffset.UTC));

Don't know when this got broken...

Cheers,
Chris.


On 24.03.21 13:09, philip wrote:
> Given the use of `new TransactionTime()` I wonder if we are not correctly generating the time 
> correctly/not outputting in UTC in UTC when you do it like that (whereas SendingTime is definitely 
> set correctly to UTC).
>
> - Philip
>
> On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>>
>>  Hi,
>>
>> how do you initialize the TransactTime in your code?
>> SendingTime is set by the engine when the message is sent out.
>>
>> Cheers,
>> Chris.
>>
>> On 24.03.21 12:06, Minh Kha wrote:
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>> Hi team,
>>>
>>> I got a problem when message is showing different time between tag
>>> 52 and tag 60
>>>
>>> _|parse:
>>>
>> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_ 
>>
>>>
>>>
>>> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
>>> cannot find the place init it, and think that would be set by
>>> default in quickfix ?
>>>
>>> Could you please give me some advice about this ?
>>>
>>> Thank you
>>>
>>> Best regards,
>>> Kha Phan
>>>
>>> -- 
>>>
>>> PHAN NGUYEN MINH KHA
>>> min...@gm... / 0938499460
>>>
>>> _______________________________________________
>>> 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 [1]
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
>> Links:
>> ------
>> [1] http://www.macd.com
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Field 1523

[M J <mje...@gm...>]

Hi

Indeed this is the way I will follow.

Many thanks for all replies.

Kind regards

Matjaz

On Wed, 24 Mar 2021, 13:03 philip, <ph...@wh...> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> No, you can:
>
> 1) Use a custom XML data dictionary and set the field via looser API
> methods:
>
> message.setString(1523, "VALUE")
> message.isSetField(1523)
> message.getString(1523)
>
> There's rough tooling to generate an actual dictionary from the
> published spec's technical documents (available for download from the
> FIX Trading Community website) (which is done in a different XML
> format).
>
> 2) Generate your own messages JAR / class that includes the field.
>
> QuickFIXJ offers high support for the published versions but you can use
> the APIs to accept/read whatever spec you like.
>
> Best regards,
> Philip Whitehouse
>
> On 2021-03-24 10:47, M J wrote:
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> >
> >
> >
> > Hi,
> >
> > Therefore I need to wait for quickfix/J will implement EP that
> > includes this field?
> >
> > Kind regards
> >
> > Matjaz
> >
> > On Wed, 24 Mar 2021, 10:46 Philip Whitehouse, <ph...@wh...>
> > wrote:
> >
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >> Following FIX 5.0, the FIX community has updated the spec with a
> >> series of extension packs, (EPs).
> >>
> >> A first and second batch of these EPs were collected into SP1 and
> >> SP2.
> >>
> >> However since SP2 many more extension packs have been released and
> >> there is no subsequent SP.
> >>
> >> It’s now most organised via negotiation with counter parties as to
> >> which precise EP-based spec to follow.
> >>
> >> Best,
> >>
> >> Philip Whitehouse
> >>
> >>> On 24 Mar 2021, at 08:48, Andrew Marlow <mar...@gm...>
> >>> wrote:
> >>
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >> Hello everyone,
> >>
> >> According to
> >>
> >
> https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html
> >> this tag was added in fix50-sp2 107. I am not sure what the 107
> >> means but maybe it is an addition. The web site that I normally use
> >> to check FIX values,
> >> https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html,
> >> doesn't have this tag. Maybe it is a recent addition?
> >>
> >> On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm...> wrote:
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >> Hi,
> >>
> >> Using fix50sp2 I am missing field 1523 - TrdAckStatus.
> >>
> >> What did I miss?
> >>
> >> Thanks
> >>
> >> Matjaz _______________________________________________
> >> Quickfixj-users mailing list
> >> Qui...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >>
> >> --
> >> Regards,
> >>
> >> Andrew Marlow
> >> http://www.andrewpetermarlow.co.uk
> >>
> >> _______________________________________________
> >> Quickfixj-users mailing list
> >> Qui...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >  _______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> > _______________________________________________
> > Quickfixj-users mailing 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
>

Re: [Quickfixj-users] Field 1523

[Christoph J. <chr...@ma...>]

I suggest to always use https://fiximate.fixtrading.org/index.html which has the latest 
ExtensionPacks included.

Cheers,
Chris.

On 24.03.21 09:47, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello everyone,
>
> According to https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html 
> <https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html> this tag 
> was added in fix50-sp2 107. I am not sure what the 107 means but maybe it is an addition. The web 
> site that I normally use to check FIX values, 
> https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html 
> <https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html>, doesn't have this tag. Maybe it 
> is a recent addition?
>
>
>
> On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm... <mailto:mje...@gm...>> wrote:
>
>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>     http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>
>
>     Hi,
>
>     Using fix50sp2 I am missing field 1523 - TrdAckStatus.
>
>     What did I miss?
>
>     Thanks
>
>     Matjaz
>     _______________________________________________
>     Quickfixj-users mailing list
>     Qui...@li... <mailto:Qui...@li...>
>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
>
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk <http://www.andrewpetermarlow.co.uk>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> 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

Re: [Quickfixj-users] Field 1523

[Christoph J. <chr...@ma...>]

As Philip pointed out there will be no third FIX5.0 ServicePack. Instead the "version" FIXLatest 
will be used which will include subsequent EPs.
QFJ does not yet have full support for FIXLatest but you could simply adapt your dictionary with the 
tags you need. On the wire FIXLatest will look like FIX5.0 but with ApplVerID 10 = FIXLatest.

Cheers,
Chris.


On 24.03.21 11:47, M J wrote:
> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
> QuickFIX/J Support:http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> Therefore I need to wait for quickfix/J will implement EP that includes this field?
>
> Kind regards
>
> Matjaz
>
> On Wed, 24 Mar 2021, 10:46 Philip Whitehouse, <ph...@wh... <mailto:ph...@wh...>> wrote:
>
>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>     http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>
>
>     Following FIX 5.0, the FIX community has updated the spec with a series of extension packs,
>     (EPs).
>
>     A first and second batch of these EPs were collected into SP1 and SP2.
>
>     However since SP2 many more extension packs have been released and there is no subsequent SP.
>
>     It’s now most organised via negotiation with counter parties as to which precise EP-based spec
>     to follow.
>
>     Best,
>
>     Philip Whitehouse
>
>>     On 24 Mar 2021, at 08:48, Andrew Marlow <mar...@gm...
>>     <mailto:mar...@gm...>> wrote:
>>
>>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>     <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>>
>>
>>     Hello everyone,
>>
>>     According to
>>     https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html
>>     <https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html> this
>>     tag was added in fix50-sp2 107. I am not sure what the 107 means but maybe it is an addition.
>>     The web site that I normally use to check FIX values,
>>     https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html
>>     <https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html>, doesn't have this tag.
>>     Maybe it is a recent addition?
>>
>>
>>
>>     On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm... <mailto:mje...@gm...>> wrote:
>>
>>         QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>         QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>>         http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>>
>>
>>         Hi,
>>
>>         Using fix50sp2 I am missing field 1523 - TrdAckStatus.
>>
>>         What did I miss?
>>
>>         Thanks
>>
>>         Matjaz
>>         _______________________________________________
>>         Quickfixj-users mailing list
>>         Qui...@li... <mailto:Qui...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>         <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>>
>>
>>
>>     -- 
>>     Regards,
>>
>>     Andrew Marlow
>>     http://www.andrewpetermarlow.co.uk <http://www.andrewpetermarlow.co.uk>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li... <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>     _______________________________________________
>     Quickfixj-users mailing list
>     Qui...@li... <mailto:Qui...@li...>
>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> 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

Re: [Quickfixj-users] The time of SendingTime and TransactionTime is different

[philip <ph...@wh...>]

Given the use of `new TransactionTime()` I wonder if we are not 
correctly generating the time correctly/not outputting in UTC in UTC 
when you do it like that (whereas SendingTime is definitely set 
correctly to UTC).

- Philip

On 2021-03-24 11:44, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> 
>  Hi,
> 
> how do you initialize the TransactTime in your code?
> SendingTime is set by the engine when the message is sent out.
> 
> Cheers,
> Chris.
> 
> On 24.03.21 12:06, Minh Kha wrote:
> 
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> Hi team,
>> 
>> I got a problem when message is showing different time between tag
>> 52 and tag 60
>> 
>> _|parse:
>> 
> 8=FIX.4.2^A9=158^A35=D^A34=3^A49=CMB^A52=20210322-11:33:19.923^A56=CITI^A11=20210322-14051690^A21=1^A38=3000^A40=2^A44=15.2^A54=2^A55=DOYU^A58=20334649^A59=0^A60=20210322-19:33:19.904^A207=N^A10=105^A_
>> 
>> 
>> Tag 60 I just initialize: new TransactionTime(), as for tag 52 I
>> cannot find the place init it, and think that would be set by
>> default in quickfix ?
>> 
>> Could you please give me some advice about this ?
>> 
>> Thank you
>> 
>> Best regards,
>> Kha Phan
>> 
>> --
>> 
>> PHAN NGUYEN MINH KHA
>> min...@gm... / 0938499460
>> 
>> _______________________________________________
>> 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 [1]
> 
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
> 
> 
> Links:
> ------
> [1] http://www.macd.com
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Quickfix-core-2.1.1-sources.jar

[philip <ph...@wh...>]

This is normal, QuickFIXJ-Core only contains the base API.

There are messages JARs for each FIX version (e.g. 
quickfixj-messages-fix50) and there's also a 'quickfixj-messages-all' 
JAR which contains the combination of each version the project has 
pre-generated fields for.

You might like to look at the GitHub repository to see the entire 
project scope: https://github.com/quickfix-j/quickfixj

Best regards,
Philip Whitehouse

On 2021-03-24 10:50, M J wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> 
> Dear All
> 
> I have Quickfix-core-2.1.1-sources.jar but it does not have sources
> java files for fields. Normal or i need something more?
> 
> Thanks
> 
> Regards
> 
> Matjaz
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Field 1523

[philip <ph...@wh...>]

No, you can:

1) Use a custom XML data dictionary and set the field via looser API 
methods:

message.setString(1523, "VALUE")
message.isSetField(1523)
message.getString(1523)

There's rough tooling to generate an actual dictionary from the 
published spec's technical documents (available for download from the 
FIX Trading Community website) (which is done in a different XML 
format).

2) Generate your own messages JAR / class that includes the field.

QuickFIXJ offers high support for the published versions but you can use 
the APIs to accept/read whatever spec you like.

Best regards,
Philip Whitehouse

On 2021-03-24 10:47, M J wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> 
> Hi,
> 
> Therefore I need to wait for quickfix/J will implement EP that
> includes this field?
> 
> Kind regards
> 
> Matjaz
> 
> On Wed, 24 Mar 2021, 10:46 Philip Whitehouse, <ph...@wh...>
> wrote:
> 
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> Following FIX 5.0, the FIX community has updated the spec with a
>> series of extension packs, (EPs).
>> 
>> A first and second batch of these EPs were collected into SP1 and
>> SP2.
>> 
>> However since SP2 many more extension packs have been released and
>> there is no subsequent SP.
>> 
>> It’s now most organised via negotiation with counter parties as to
>> which precise EP-based spec to follow.
>> 
>> Best,
>> 
>> Philip Whitehouse
>> 
>>> On 24 Mar 2021, at 08:48, Andrew Marlow <mar...@gm...>
>>> wrote:
>> 
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> Hello everyone,
>> 
>> According to
>> 
> https://www.inforeachinc.com/fix-dictionary/FIX.5.0SP2_EP240/fields/TrdAckStatus.html
>> this tag was added in fix50-sp2 107. I am not sure what the 107
>> means but maybe it is an addition. The web site that I normally use
>> to check FIX values,
>> https://www.onixs.biz/fix-dictionary/5.0.SP2/fields_by_tag.html,
>> doesn't have this tag. Maybe it is a recent addition?
>> 
>> On Wed, 24 Mar 2021 at 08:26, M J <mje...@gm...> wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> Hi,
>> 
>> Using fix50sp2 I am missing field 1523 - TrdAckStatus.
>> 
>> What did I miss?
>> 
>> Thanks
>> 
>> Matjaz _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> 
>> --
>> Regards,
>> 
>> Andrew Marlow
>> http://www.andrewpetermarlow.co.uk
>> 
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>  _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users