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

[Quickfixj-users] Reading QF/J messages

[Nenge M. <geo...@gm...>]

Dear Devs.

Thank you so much for your help, I was finally able to send party details
list request  messages to the server and get the response...

However, the response message does not come through fromApp method but I
can see all data in my  message logs and this is because  same tag has been
called more than once(according to vendor design), this is the message....
"58=Tag appears more than once, field=1517371=1517372=CG373=1310=232"...

My question is,, Is there a way to read the messages that does not come
through fromApp? because I can see all data in my log but I dont know how
to get them apart from getting them in fromApp method.

Thanks.

Re: [Quickfixj-users] Multiple logons/connections for this session are not allowed

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

Hi,

when all clients are affected at the same time it could still be a network issue, right? :)
As said, QFJ does not handle the TCP connection stuff by itself but uses MINA which is a stable and 
mature library. Of course, it still could have bugs. But your description rather sounds like all 
client's connection get closed and go into TIME_WAIT or CLOSE_WAIT state.
https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states

Did you check "netstat" or similar tool when the connection problem occurs?

If you were to implement the logic that you proposed that would mean that someone could do a simple 
attack against your server which would not only end the new malicious session but only the one that 
is rightfully connected. Are you sure you want to follow that way? ;)

Cheers,
Chris.

On 06.08.20 13:27, Vipin Chaudhary wrote:
> Hi guys.
>
> I am still facing this issue and now the frequency is very high. I am also not able to detect any 
> networking issue.
>
> One more point is, it is happening with all clients at same time.  This does not resolve without 
> the restart of application.
> One more strange thing is if I don't restart, then the client which was disconnected at the time 
> of this issue, when try to connect at their session time also facing this issue.
>
> So now I am highly suspecting this as quickfix bug.
>
> As per me quickfixj should close old session if it detect that old session is still running when 
> it receive new logon. To achieve the same I am thinking to edit *AcceptorIoHandler.java.*
>
> Class : AcceptorIoHandler.java
> Line no 69
> if (qfSession.hasResponder()) {
>              // Session is already bound to another connection
>              sessionLog.onErrorEvent("Multiple logons/connections for this session are not allowed");
>              protocolSession.closeNow();
> *//TODO Close old session here*
>              return;
>   }
>
> There are many methods to close the session in Session class as following
>
>  1.    qfSession.close();
>  2.    qfSession.disconnect("Closing Old session", true);
>  3.    qfSession.logout("Closing old session to accommodate new session");
>  4.    qfSession.generateLogout();
>  5.    qfSession.reset();
>
> Which of the above method I should opt for, that can serve my purpose ?
>
> Thanks
> Vipin
>
>
> On Mon, May 4, 2020 at 3:47 PM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     if VPN rekeying is not the problem then maybe differing MTU sizes or asymmetric routing. Or of
>     course it could also be another problem. Just said what the problems mostly were in our case.
>     But I think if you describe the problem to your and your counterparty's network team (since
>     you only seem to have this problem with some of your sessions) they should be able to debug
>     it. Maybe your team need to do some tcp dumps around the time of the problem.
>
>     It would be nice if you could reply to the user group (not me privately) if you found
>     something out. This could help other users as well.
>
>     Cheers,
>     Chris.
>
>
>     On 04.05.20 08:28, Vipin Chaudhary wrote:
>>     Hi Christoph,
>>
>>     I double checked from the network team and find that no initiator use VPN to connect to us.
>>
>>     In that case, Can you help me on what should I request to network team to fix the network
>>     connections?
>>
>>     Thanks
>>     Vipin Chaudhary
>>
>>     On Thu, Apr 30, 2020 at 3:49 PM Christoph John <chr...@ma...
>>     <mailto:chr...@ma...>> wrote:
>>
>>         The only solution is to fix the network connection. Everything else is only a workaround.
>>         You could try to increase socket timeouts on both sides of the connection. Maybe it helps
>>         (depends on the cause of the problem) but as said this will only work around the problem.
>>
>>         Cheers,
>>         Chris.
>>
>>         On 30.04.20 12:11, Vipin Chaudhary wrote:
>>>         Hi Christoph,
>>>
>>>         Thanks for your input,
>>>
>>>         We have multiple sessions and this problems does not happens with all sessions
>>>         simultaneously. Mostly we see this problem with one session and rarely with other session.
>>>
>>>         As far as I know initiator connect directly with us over internet (have ssl). Will
>>>         double check on this with network team.
>>>
>>>         Meanwhile any solution you think of this problem ?
>>>
>>>         Thanks
>>>         Vipin Chaudhary
>>>
>>>         On Thu, Apr 30, 2020 at 3:31 PM Christoph John <chr...@ma...
>>>         <mailto:chr...@ma...>> wrote:
>>>
>>>             Addition: if VPN rekeying is the problem you will probably see this message every
>>>             hour (or whatever the rekey interval is)
>>>
>>>             Chris.
>>>
>>>             On 30.04.20 12:00, Christoph John wrote:
>>>>             Hi,
>>>>
>>>>             did you change QFJ version or why do you think it is QFJ related? Do you only have
>>>>             one FIX session? If not, do all sessions show this behaviour?
>>>>             (apart from that, the TCP/IP stuff is done via the MINA framework and not within
>>>>             QFJ itself)
>>>>
>>>>             This message appears when the initiator side of the connection considers the
>>>>             connection broken and tries to reconnect. But the acceptor still considers it a
>>>>             vital connection (probably until the connection timeout kicks in).
>>>>
>>>>             From my experience this happens mostly on VPN connections via internet. Reasons for
>>>>             this were one of:
>>>>              - different MTU sizes on both sides of the connection or on a router/firewall in
>>>>             between
>>>>              - asymmetric routing
>>>>              - differing VPN parameters leading to different rekeying behaviour on both ends of
>>>>             the connection.
>>>>
>>>>             Hope that helps,
>>>>             Chris.
>>>>
>>>>
>>>>             On 30.04.20 05:51, Vipin Chaudhary wrote:
>>>>>             QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>>             QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>>
>>>>>             Hi Team,
>>>>>
>>>>>             We are facing strange issue with quickfixj.
>>>>>
>>>>>             We are SessionAcceptor, sometime when initiator disconnect, then quickfixj is not
>>>>>             able to recognize the disconnection. So when client logon next time it say
>>>>>             " Multiple logons/connections for this session are not allowed".
>>>>>               Although in reality client is disconnected.
>>>>>             Earlier it was very rare and happening once in a while but nowadays its happening
>>>>>             like once in week.
>>>>>             Quickfixj is not able to recover from this and we need to restart our application
>>>>>
>>>>>             *Do anyone have seen/fix this ?*
>>>>>
>>>>>             Thanks
>>>>>             Vipin Chaudhary
>>>>>
>>>>>
>>>>>             _______________________________________________
>>>>>             Quickfixj-users mailing list
>>>>>             Qui...@li...  <mailto:Qui...@li...>
>>>>>             https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>>             -- 
>>>>             Christoph John
>>>>             Software Engineering
>>>>             T +49 241 557080-28
>>>>             chr...@ma...  <mailto:chr...@ma...>
>>>>
>>>>             MACD GmbH
>>>>             Oppenhoffallee 103
>>>>             52066 Aachen, Germany
>>>>             www.macd.com  <http://www.macd.com>
>>>>
>>>>             Amtsgericht Aachen: HRB 8151
>>>>             Ust.-Id: DE 813021663
>>>>             Geschäftsführer: George Macdonald
>>>
>>>             -- 
>>>             Christoph John
>>>             Software Engineering
>>>             T +49 241 557080-28
>>>             chr...@ma...  <mailto:chr...@ma...>
>>>
>>>             MACD GmbH
>>>             Oppenhoffallee 103
>>>             52066 Aachen, Germany
>>>             www.macd.com  <http://www.macd.com>
>>>
>>>             Amtsgericht Aachen: HRB 8151
>>>             Ust.-Id: DE 813021663
>>>             Geschäftsführer: George Macdonald
>>>
>>
>>         -- 
>>         Christoph John
>>         Software Engineering
>>         T +49 241 557080-28
>>         chr...@ma...  <mailto:chr...@ma...>
>>
>>         MACD GmbH
>>         Oppenhoffallee 103
>>         52066 Aachen, Germany
>>         www.macd.com  <http://www.macd.com>
>>
>>         Amtsgericht Aachen: HRB 8151
>>         Ust.-Id: DE 813021663
>>         Geschäftsführer: George Macdonald
>>
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

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

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

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

Re: [Quickfixj-users] QuickFix response using spring boot

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

Actually you "only" need to get the QFJ sources from here: https://github.com/quickfix-j/quickfixj
Build instructions here: https://github.com/quickfix-j/quickfixj#build-instructions
Then swap out the dictionary in FIX5.0SP2 module with your updated version and rebuild.

If you use maven for your project, then the more sophisticated but yet to be documented way would be 
to use the code generator Maven plugin:
https://github.com/quickfix-j/quickfixj/tree/master/quickfixj-codegenerator/src/main/java/org/quickfixj/codegenerator

Cheers,
Chris.

On 06.08.20 15:20, Nenge Masoya wrote:
> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
> QuickFIX/J Support:http://www.quickfixj.org/support/
>
>
>
>
> Hello guys...
>
>
> Any help on regeneration and rebuild of QF/J codes regarding with party Details List Request 
> message? (CF)
>
> Thanks.
>
> On Fri, Jul 31, 2020 at 12:56 PM Grant Birchmeier <gbi...@co... 
> <mailto:gbi...@co...>> wrote:
>
>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>     http://www.quickfixj.org/support/
>
>
>     I haven't regenerated the code in a very long time (not since before QF/j changed to
>     Maven).  I'm surprised that I can't find anything directly addressing this in the README.  Is
>     it built-in to the main Maven build target?
>
>     Can someone else help Mr. Masoya with this one?  How do you kick off the code generator?
>
>
>
>     On Fri, Jul 31, 2020 at 7:37 AM Nenge Masoya <geo...@gm...
>     <mailto:geo...@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/
>
>
>         Hello Grant,
>
>         Thanks four your reply.
>
>         I was able to update my DD as per your suggestion,, now how do I regenerate and rebuild
>         QF/J sources.
>
>
>         Thanks
>
>         On Thu, Jul 30, 2020 at 10:25 PM Grant Birchmeier <gbi...@co...
>         <mailto:gbi...@co...>> wrote:
>
>             QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>             QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>             http://www.quickfixj.org/support/
>
>
>             That message is "CF", but it looks like the QF/j FIX50SP2 dictionary wasn't updated
>             past "CE".
>
>             Probably the best thing to do would be to edit your DD to add CF and regenerate the
>             QF/j source and rebuild.
>
>             On Thu, Jul 30, 2020 at 3:37 PM Nenge Masoya <geo...@gm...
>             <mailto:geo...@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/
>
>
>                 Hello Devs,
>
>                 I want to send "Party Details List Request" in quickfix/J unfortunately I was not
>                 able to find this api... I am using quickfix/J core 2.2.0.
>
>                 Is the there any alternative to use this because I wish I could have  this api?.
>
>                 Any help will be appreciated.
>
>                 Thanks,
>
>                 Nenge Masoya
>

-- 
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] QuickFix response using spring boot

[Nenge M. <geo...@gm...>]

Hello guys...


Any help on regeneration and rebuild of QF/J codes regarding with party
Details List Request message? (CF)

Thanks.

On Fri, Jul 31, 2020 at 12:56 PM Grant Birchmeier <gbi...@co...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> I haven't regenerated the code in a very long time (not since before QF/j
> changed to Maven).  I'm surprised that I can't find anything directly
> addressing this in the README.  Is it built-in to the main Maven build
> target?
>
> Can someone else help Mr. Masoya with this one?  How do you kick off the
> code generator?
>
>
>
> On Fri, Jul 31, 2020 at 7:37 AM Nenge Masoya <geo...@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/
>>
>>
>> Hello Grant,
>>
>> Thanks four your reply.
>>
>> I was able to update my DD as per your suggestion,, now how do I
>> regenerate and rebuild QF/J sources.
>>
>>
>> Thanks
>>
>> On Thu, Jul 30, 2020 at 10:25 PM Grant Birchmeier <
>> gbi...@co...> wrote:
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>>> http://www.quickfixj.org/support/
>>>
>>>
>>> That message is "CF", but it looks like the QF/j FIX50SP2 dictionary
>>> wasn't updated past "CE".
>>>
>>> Probably the best thing to do would be to edit your DD to add CF and
>>> regenerate the QF/j source and rebuild.
>>>
>>> On Thu, Jul 30, 2020 at 3:37 PM Nenge Masoya <geo...@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/
>>>>
>>>>
>>>> Hello Devs,
>>>>
>>>> I want to send "Party Details List Request" in quickfix/J unfortunately
>>>> I was not able to find this api... I am using quickfix/J core 2.2.0.
>>>>
>>>> Is the there any alternative to use this because I wish I could have
>>>> this api?.
>>>>
>>>> Any help will be appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Nenge Masoya
>>>>
>>>> On Sat, Jun 20, 2020 at 2:23 AM Nenge Masoya <geo...@gm...>
>>>> wrote:
>>>>
>>>>>
>>>>> On Sat, 20 Jun 2020, 02:01 Christoph John, <chr...@ma...>
>>>>> wrote:
>>>>>
>>>>>> Looking at the stack trace, I think your problem is that you are
>>>>>> trying to crack admin messages (at
>>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)).
>>>>>> This is not required.
>>>>>> You only need to do this for application messages, i.e. in your
>>>>>> fromApp() callback.
>>>>>>
>>>>>> Cheers,
>>>>>> Chris.
>>>>>>
>>>>>> On 18.06.20 15:36, Nenge Masoya wrote:
>>>>>>
>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>
>>>>>>
>>>>>> Hello Devs,
>>>>>>
>>>>>> I am still facing the issues in reading messages returned from other
>>>>>> party (server) which is using FIX.5.0SP2.... this is my errors message from
>>>>>> events logs
>>>>>>
>>>>>> 20200617-14:19:45: Session FIXT.1.1:CLIENT->SERVER schedule is daily,
>>>>>> 00:00:00-UTC - 22:50:00-UTC
>>>>>> 20200617-14:19:45: Created session: FIXT.1.1:CLIENT->SERVER
>>>>>> 20200617-14:19:45: Configured socket addresses for session:
>>>>>> [/"server-address here"]
>>>>>> 20200617-14:19:45: MINA session created: local=/192.168.91.98:39322,
>>>>>> class org.apache.mina.transport.socket.nio.NioSocketSession,
>>>>>> remote=/"server-address here"
>>>>>> 20200617-14:19:46: Initiated logon request
>>>>>> 20200617-14:19:46: Invalid message: Can't determine ApplVerID from
>>>>>> message 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>>>>>> 56=CLIENT 7=1 16=0 10=149
>>>>>> 20200617-14:19:46: Setting DefaultApplVerID (1137=8) from Logon
>>>>>> 20200617-14:19:46: Error during message processing
>>>>>> quickfix.RuntimeError: java.lang.ClassCastException:
>>>>>> quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>>>>> at quickfix.Session.next(Session.java:1157)
>>>>>> at quickfix.Session.next(Session.java:1204)
>>>>>> at
>>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>>>> at
>>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>> Caused by: java.lang.ClassCastException: quickfix.fixt11.Logon cannot
>>>>>> be cast to quickfix.fix50sp2.Message
>>>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>>>> at
>>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>>>> at quickfix.Session.verify(Session.java:1791)
>>>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>>>> at quickfix.Session.next(Session.java:1026)
>>>>>> ... 4 more
>>>>>> Cause: quickfix.fixt11.Logon cannot be cast to
>>>>>> quickfix.fix50sp2.Message
>>>>>> java.lang.ClassCastException: quickfix.fixt11.Logon cannot be cast to
>>>>>> quickfix.fix50sp2.Message
>>>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>>>> at
>>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>>>> at quickfix.Session.verify(Session.java:1791)
>>>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>>>> at quickfix.Session.next(Session.java:1026)
>>>>>> at quickfix.Session.next(Session.java:1204)
>>>>>> at
>>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>>>> at
>>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>>
>>>>>> I tried to follow the reference provided here here no success..
>>>>>>
>>>>>> https://stackoverflow.com/questions/30074850/quickfix-message-cannot-be-cast-to-quickfix-fix50sp2-message
>>>>>>
>>>>>> And this is my log messages
>>>>>>
>>>>>> 8=FIXT.1.1 9=75 35=A 34=2 49=CLIENT 52=20200617-14:19:46.103
>>>>>> 56=SERVER 98=0 108=30 1137=9 10=139
>>>>>> 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>>>>>> 56=CLIENT 7=1 16=0 10=149
>>>>>> 8=FIXT.1.1 9=112 35=A 34=2 49=SERVER 52=20200617-14:21:08.242
>>>>>> 56=CLIENT 58=Logon Successful. 98=0 108=60 553=STT 554=SERVER 1137=8 10=117
>>>>>>
>>>>>>
>>>>>> Any one with the help will be appreciated guys... It make me mad for
>>>>>> sure!
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Nenge
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 2, 2020 at 6:47 PM 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/
>>>>>>>
>>>>>>>
>>>>>>> What do you mean by "response data"? Do you mean messages returned
>>>>>>> by the other party? If so, those will be received in your Application
>>>>>>> implementation in fromApp.
>>>>>>> On 6/2/20 5:56 AM, Nenge Masoya wrote:
>>>>>>>
>>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>>
>>>>>>>
>>>>>>> Dear team,
>>>>>>>
>>>>>>> I am new with quickfixJ and I Im kindy requesting your help on this,
>>>>>>> from what I see the response of client QuickFixJTemplate when sending
>>>>>>> message is boolean which tells whether the  message was successful
>>>>>>> delivered or not.
>>>>>>>
>>>>>>> For instance,
>>>>>>>
>>>>>>>  @Autowired
>>>>>>> private QuickFixJTemplate clientQuickFixJTemplate;
>>>>>>>
>>>>>>> //send message
>>>>>>>
>>>>>>> boolean send = clientQuickFixJTemplate.send(fixMessage, sessionID);
>>>>>>>
>>>>>>> Now, how can I get response data for further implementation?
>>>>>>>
>>>>>>> Thank in advance.
>>>>>>>
>>>>>>> Nenge Masoya
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>>
>>>>>>> --
>>>>>>> Colin DuPlantis
>>>>>>> Chief Architect, Marketcetera
>>>>>>> Download, Run, Trade
>>>>>>> 888.868.4884https://www.marketcetera.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Quickfixj-users mailing list
>>>>>>> Qui...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christoph John
>>>>>> Software Engineering
>>>>>> T +49 241 557...@ma...
>>>>>>
>>>>>> MACD GmbH
>>>>>> Oppenhoffallee 103
>>>>>> 52066 Aachen, Germanywww.macd.com
>>>>>>
>>>>>> Amtsgericht Aachen: HRB 8151
>>>>>> Ust.-Id: DE 813021663
>>>>>> Geschäftsführer: George Macdonald
>>>>>>
>>>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>
>>>
>>> --
>>> Grant Birchmeier
>>> *Connamara Systems, LLC*
>>> *Made-To-Measure Trading Solutions.*
>>> Exactly what you need. No more. No less.
>>> http://connamara.com
>>>
>>> This email, along with any attachments, is confidential. If you believe
>>> you received this message in error, please contact the sender immediately
>>> and delete all copies of the message. Thank you from Connamara Systems, LLC.
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.
> http://connamara.com
>
> This email, along with any attachments, is confidential. If you believe
> you received this message in error, please contact the sender immediately
> and delete all copies of the message. Thank you from Connamara Systems, LLC.
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Multiple logons/connections for this session are not allowed

[Vipin C. <vip...@gm...>]

Hi guys.

I am still facing this issue and now the frequency is very high. I am also
not able to detect any networking issue.

One more point is, it is happening with all clients at same time.  This
does not resolve without the restart of application.
One more strange thing is if I don't restart, then the client which was
disconnected at the time of this issue, when try to connect at their
session time also facing this issue.

So now I am highly suspecting this as quickfix bug.

As per me quickfixj should close old session if it detect that old session
is still running when it receive new logon. To achieve the same I am
thinking to edit *AcceptorIoHandler.java.*

Class :  AcceptorIoHandler.java
Line no 69
if (qfSession.hasResponder()) {
             // Session is already bound to another connection
             sessionLog.onErrorEvent("Multiple logons/connections for this
session are not allowed");
             protocolSession.closeNow();
             *//TODO Close old session here*
             return;
  }

There are many methods to close the session in Session class as following

   1.    qfSession.close();
   2.    qfSession.disconnect("Closing Old session", true);
   3.    qfSession.logout("Closing old session to accommodate new session");
   4.    qfSession.generateLogout();
   5.    qfSession.reset();

Which of the above method I should opt for, that can serve my purpose ?

Thanks
Vipin


On Mon, May 4, 2020 at 3:47 PM Christoph John <chr...@ma...>
wrote:

> Hi,
>
> if VPN rekeying is not the problem then maybe differing MTU sizes or
> asymmetric routing. Or of course it could also be another problem. Just
> said what the problems mostly were in our case.
> But I think if you describe the problem to your and your counterparty's
> network team (since you only seem to have this problem with some of your
> sessions) they should be able to debug it. Maybe your team need to do some
> tcp dumps around the time of the problem.
>
> It would be nice if you could reply to the user group (not me privately)
> if you found something out. This could help other users as well.
>
> Cheers,
> Chris.
>
>
> On 04.05.20 08:28, Vipin Chaudhary wrote:
>
> Hi Christoph,
>
> I double checked from the network team and find that no initiator use VPN
> to connect to us.
>
> In that case, Can you help me on what should I request to network team to
> fix the network connections?
>
> Thanks
> Vipin Chaudhary
>
> On Thu, Apr 30, 2020 at 3:49 PM Christoph John <chr...@ma...>
> wrote:
>
>> The only solution is to fix the network connection. Everything else is
>> only a workaround.
>> You could try to increase socket timeouts on both sides of the
>> connection. Maybe it helps (depends on the cause of the problem) but as
>> said this will only work around the problem.
>>
>> Cheers,
>> Chris.
>>
>> On 30.04.20 12:11, Vipin Chaudhary wrote:
>>
>> Hi Christoph,
>>
>> Thanks for your input,
>>
>> We have multiple sessions and this problems does not happens with all
>> sessions simultaneously. Mostly we see this problem with one session and
>> rarely with other session.
>>
>> As far as I know initiator connect directly with us over internet (have
>> ssl). Will double check on this with network team.
>>
>> Meanwhile any solution you think of this problem ?
>>
>> Thanks
>> Vipin Chaudhary
>>
>> On Thu, Apr 30, 2020 at 3:31 PM Christoph John <chr...@ma...>
>> wrote:
>>
>>> Addition: if VPN rekeying is the problem you will probably see this
>>> message every hour (or whatever the rekey interval is)
>>>
>>> Chris.
>>>
>>> On 30.04.20 12:00, Christoph John wrote:
>>>
>>> Hi,
>>>
>>> did you change QFJ version or why do you think it is QFJ related? Do you
>>> only have one FIX session? If not, do all sessions show this behaviour?
>>> (apart from that, the TCP/IP stuff is done via the MINA framework and
>>> not within QFJ itself)
>>>
>>> This message appears when the initiator side of the connection considers
>>> the connection broken and tries to reconnect. But the acceptor still
>>> considers it a vital connection (probably until the connection timeout
>>> kicks in).
>>>
>>> From my experience this happens mostly on VPN connections via internet.
>>> Reasons for this were one of:
>>>  - different MTU sizes on both sides of the connection or on a
>>> router/firewall in between
>>>  - asymmetric routing
>>>  - differing VPN parameters leading to different rekeying behaviour on
>>> both ends of the connection.
>>>
>>> Hope that helps,
>>> Chris.
>>>
>>>
>>> On 30.04.20 05:51, Vipin Chaudhary wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi Team,
>>>
>>> We are facing strange issue with quickfixj.
>>>
>>> We are SessionAcceptor, sometime when initiator disconnect, then
>>> quickfixj is not able to recognize the disconnection. So when client logon
>>> next time it say
>>> " Multiple logons/connections for this session are not allowed".
>>>   Although in reality client is disconnected.
>>> Earlier it was very rare and happening once in a while but nowadays its
>>> happening like once in week.
>>> Quickfixj is not able to recover from this and we need to restart our
>>> application
>>>
>>> *Do anyone have seen/fix this ?*
>>>
>>> Thanks
>>> Vipin Chaudhary
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
> --
> 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] QuickFix response using spring boot

[Grant B. <gbi...@co...>]

I haven't regenerated the code in a very long time (not since before QF/j
changed to Maven).  I'm surprised that I can't find anything directly
addressing this in the README.  Is it built-in to the main Maven build
target?

Can someone else help Mr. Masoya with this one?  How do you kick off the
code generator?



On Fri, Jul 31, 2020 at 7:37 AM Nenge Masoya <geo...@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/
>
>
> Hello Grant,
>
> Thanks four your reply.
>
> I was able to update my DD as per your suggestion,, now how do I
> regenerate and rebuild QF/J sources.
>
>
> Thanks
>
> On Thu, Jul 30, 2020 at 10:25 PM Grant Birchmeier <
> gbi...@co...> wrote:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>> http://www.quickfixj.org/support/
>>
>>
>> That message is "CF", but it looks like the QF/j FIX50SP2 dictionary
>> wasn't updated past "CE".
>>
>> Probably the best thing to do would be to edit your DD to add CF and
>> regenerate the QF/j source and rebuild.
>>
>> On Thu, Jul 30, 2020 at 3:37 PM Nenge Masoya <geo...@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/
>>>
>>>
>>> Hello Devs,
>>>
>>> I want to send "Party Details List Request" in quickfix/J unfortunately
>>> I was not able to find this api... I am using quickfix/J core 2.2.0.
>>>
>>> Is the there any alternative to use this because I wish I could have
>>> this api?.
>>>
>>> Any help will be appreciated.
>>>
>>> Thanks,
>>>
>>> Nenge Masoya
>>>
>>> On Sat, Jun 20, 2020 at 2:23 AM Nenge Masoya <geo...@gm...>
>>> wrote:
>>>
>>>>
>>>> On Sat, 20 Jun 2020, 02:01 Christoph John, <chr...@ma...>
>>>> wrote:
>>>>
>>>>> Looking at the stack trace, I think your problem is that you are
>>>>> trying to crack admin messages (at
>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)).
>>>>> This is not required.
>>>>> You only need to do this for application messages, i.e. in your
>>>>> fromApp() callback.
>>>>>
>>>>> Cheers,
>>>>> Chris.
>>>>>
>>>>> On 18.06.20 15:36, Nenge Masoya wrote:
>>>>>
>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>> Hello Devs,
>>>>>
>>>>> I am still facing the issues in reading messages returned from other
>>>>> party (server) which is using FIX.5.0SP2.... this is my errors message from
>>>>> events logs
>>>>>
>>>>> 20200617-14:19:45: Session FIXT.1.1:CLIENT->SERVER schedule is daily,
>>>>> 00:00:00-UTC - 22:50:00-UTC
>>>>> 20200617-14:19:45: Created session: FIXT.1.1:CLIENT->SERVER
>>>>> 20200617-14:19:45: Configured socket addresses for session:
>>>>> [/"server-address here"]
>>>>> 20200617-14:19:45: MINA session created: local=/192.168.91.98:39322,
>>>>> class org.apache.mina.transport.socket.nio.NioSocketSession,
>>>>> remote=/"server-address here"
>>>>> 20200617-14:19:46: Initiated logon request
>>>>> 20200617-14:19:46: Invalid message: Can't determine ApplVerID from
>>>>> message 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>>>>> 56=CLIENT 7=1 16=0 10=149
>>>>> 20200617-14:19:46: Setting DefaultApplVerID (1137=8) from Logon
>>>>> 20200617-14:19:46: Error during message processing
>>>>> quickfix.RuntimeError: java.lang.ClassCastException:
>>>>> quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>>>> at quickfix.Session.next(Session.java:1157)
>>>>> at quickfix.Session.next(Session.java:1204)
>>>>> at
>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>>> at
>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>> Caused by: java.lang.ClassCastException: quickfix.fixt11.Logon cannot
>>>>> be cast to quickfix.fix50sp2.Message
>>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>>> at
>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>>> at quickfix.Session.verify(Session.java:1791)
>>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>>> at quickfix.Session.next(Session.java:1026)
>>>>> ... 4 more
>>>>> Cause: quickfix.fixt11.Logon cannot be cast to
>>>>> quickfix.fix50sp2.Message
>>>>> java.lang.ClassCastException: quickfix.fixt11.Logon cannot be cast to
>>>>> quickfix.fix50sp2.Message
>>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>>> at
>>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>>> at quickfix.Session.verify(Session.java:1791)
>>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>>> at quickfix.Session.next(Session.java:1026)
>>>>> at quickfix.Session.next(Session.java:1204)
>>>>> at
>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>>> at
>>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>>> at java.lang.Thread.run(Thread.java:748)
>>>>>
>>>>> I tried to follow the reference provided here here no success..
>>>>>
>>>>> https://stackoverflow.com/questions/30074850/quickfix-message-cannot-be-cast-to-quickfix-fix50sp2-message
>>>>>
>>>>> And this is my log messages
>>>>>
>>>>> 8=FIXT.1.1 9=75 35=A 34=2 49=CLIENT 52=20200617-14:19:46.103 56=SERVER
>>>>> 98=0 108=30 1137=9 10=139
>>>>> 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234 56=CLIENT
>>>>> 7=1 16=0 10=149
>>>>> 8=FIXT.1.1 9=112 35=A 34=2 49=SERVER 52=20200617-14:21:08.242
>>>>> 56=CLIENT 58=Logon Successful. 98=0 108=60 553=STT 554=SERVER 1137=8 10=117
>>>>>
>>>>>
>>>>> Any one with the help will be appreciated guys... It make me mad for
>>>>> sure!
>>>>>
>>>>> Thanks
>>>>>
>>>>> Nenge
>>>>>
>>>>>
>>>>> On Tue, Jun 2, 2020 at 6:47 PM 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/
>>>>>>
>>>>>>
>>>>>> What do you mean by "response data"? Do you mean messages returned by
>>>>>> the other party? If so, those will be received in your Application
>>>>>> implementation in fromApp.
>>>>>> On 6/2/20 5:56 AM, Nenge Masoya wrote:
>>>>>>
>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>
>>>>>>
>>>>>> Dear team,
>>>>>>
>>>>>> I am new with quickfixJ and I Im kindy requesting your help on this,
>>>>>> from what I see the response of client QuickFixJTemplate when sending
>>>>>> message is boolean which tells whether the  message was successful
>>>>>> delivered or not.
>>>>>>
>>>>>> For instance,
>>>>>>
>>>>>>  @Autowired
>>>>>> private QuickFixJTemplate clientQuickFixJTemplate;
>>>>>>
>>>>>> //send message
>>>>>>
>>>>>> boolean send = clientQuickFixJTemplate.send(fixMessage, sessionID);
>>>>>>
>>>>>> Now, how can I get response data for further implementation?
>>>>>>
>>>>>> Thank in advance.
>>>>>>
>>>>>> Nenge Masoya
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>
>>>>>> --
>>>>>> Colin DuPlantis
>>>>>> Chief Architect, Marketcetera
>>>>>> Download, Run, Trade
>>>>>> 888.868.4884https://www.marketcetera.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixj-users mailing list
>>>>>> Qui...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>
>>>>>
>>>>> --
>>>>> Christoph John
>>>>> Software Engineering
>>>>> T +49 241 557...@ma...
>>>>>
>>>>> MACD GmbH
>>>>> Oppenhoffallee 103
>>>>> 52066 Aachen, Germanywww.macd.com
>>>>>
>>>>> Amtsgericht Aachen: HRB 8151
>>>>> Ust.-Id: DE 813021663
>>>>> Geschäftsführer: George Macdonald
>>>>>
>>>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>
>>
>> --
>> Grant Birchmeier
>> *Connamara Systems, LLC*
>> *Made-To-Measure Trading Solutions.*
>> Exactly what you need. No more. No less.
>> http://connamara.com
>>
>> This email, along with any attachments, is confidential. If you believe
>> you received this message in error, please contact the sender immediately
>> and delete all copies of the message. Thank you from Connamara Systems, LLC.
>> _______________________________________________
>> 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
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com

-- 
This email, along with any attachments, is confidential. If you believe you 
received this message in error, please contact the sender immediately and 
delete all copies of the message. Thank you from Connamara Systems, LLC.

Re: [Quickfixj-users] QuickFix response using spring boot

[Nenge M. <geo...@gm...>]

Hello Grant,

Thanks four your reply.

I was able to update my DD as per your suggestion,, now how do I regenerate
and rebuild QF/J sources.


Thanks

On Thu, Jul 30, 2020 at 10:25 PM Grant Birchmeier <gbi...@co...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> That message is "CF", but it looks like the QF/j FIX50SP2 dictionary
> wasn't updated past "CE".
>
> Probably the best thing to do would be to edit your DD to add CF and
> regenerate the QF/j source and rebuild.
>
> On Thu, Jul 30, 2020 at 3:37 PM Nenge Masoya <geo...@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/
>>
>>
>> Hello Devs,
>>
>> I want to send "Party Details List Request" in quickfix/J unfortunately I
>> was not able to find this api... I am using quickfix/J core 2.2.0.
>>
>> Is the there any alternative to use this because I wish I could have
>> this api?.
>>
>> Any help will be appreciated.
>>
>> Thanks,
>>
>> Nenge Masoya
>>
>> On Sat, Jun 20, 2020 at 2:23 AM Nenge Masoya <geo...@gm...> wrote:
>>
>>>
>>> On Sat, 20 Jun 2020, 02:01 Christoph John, <chr...@ma...>
>>> wrote:
>>>
>>>> Looking at the stack trace, I think your problem is that you are trying
>>>> to crack admin messages (at
>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)).
>>>> This is not required.
>>>> You only need to do this for application messages, i.e. in your
>>>> fromApp() callback.
>>>>
>>>> Cheers,
>>>> Chris.
>>>>
>>>> On 18.06.20 15:36, Nenge Masoya wrote:
>>>>
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>> Hello Devs,
>>>>
>>>> I am still facing the issues in reading messages returned from other
>>>> party (server) which is using FIX.5.0SP2.... this is my errors message from
>>>> events logs
>>>>
>>>> 20200617-14:19:45: Session FIXT.1.1:CLIENT->SERVER schedule is daily,
>>>> 00:00:00-UTC - 22:50:00-UTC
>>>> 20200617-14:19:45: Created session: FIXT.1.1:CLIENT->SERVER
>>>> 20200617-14:19:45: Configured socket addresses for session:
>>>> [/"server-address here"]
>>>> 20200617-14:19:45: MINA session created: local=/192.168.91.98:39322,
>>>> class org.apache.mina.transport.socket.nio.NioSocketSession,
>>>> remote=/"server-address here"
>>>> 20200617-14:19:46: Initiated logon request
>>>> 20200617-14:19:46: Invalid message: Can't determine ApplVerID from
>>>> message 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>>>> 56=CLIENT 7=1 16=0 10=149
>>>> 20200617-14:19:46: Setting DefaultApplVerID (1137=8) from Logon
>>>> 20200617-14:19:46: Error during message processing
>>>> quickfix.RuntimeError: java.lang.ClassCastException:
>>>> quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>>> at quickfix.Session.next(Session.java:1157)
>>>> at quickfix.Session.next(Session.java:1204)
>>>> at
>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>> at
>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>> Caused by: java.lang.ClassCastException: quickfix.fixt11.Logon cannot
>>>> be cast to quickfix.fix50sp2.Message
>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>> at
>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>> at quickfix.Session.verify(Session.java:1791)
>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>> at quickfix.Session.next(Session.java:1026)
>>>> ... 4 more
>>>> Cause: quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>>> java.lang.ClassCastException: quickfix.fixt11.Logon cannot be cast to
>>>> quickfix.fix50sp2.Message
>>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>>> at
>>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>>> at quickfix.Session.fromCallback(Session.java:1845)
>>>> at quickfix.Session.verify(Session.java:1791)
>>>> at quickfix.Session.nextLogon(Session.java:2129)
>>>> at quickfix.Session.next(Session.java:1026)
>>>> at quickfix.Session.next(Session.java:1204)
>>>> at
>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>>> at
>>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>>
>>>> I tried to follow the reference provided here here no success..
>>>>
>>>> https://stackoverflow.com/questions/30074850/quickfix-message-cannot-be-cast-to-quickfix-fix50sp2-message
>>>>
>>>> And this is my log messages
>>>>
>>>> 8=FIXT.1.1 9=75 35=A 34=2 49=CLIENT 52=20200617-14:19:46.103 56=SERVER
>>>> 98=0 108=30 1137=9 10=139
>>>> 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234 56=CLIENT
>>>> 7=1 16=0 10=149
>>>> 8=FIXT.1.1 9=112 35=A 34=2 49=SERVER 52=20200617-14:21:08.242 56=CLIENT
>>>> 58=Logon Successful. 98=0 108=60 553=STT 554=SERVER 1137=8 10=117
>>>>
>>>>
>>>> Any one with the help will be appreciated guys... It make me mad for
>>>> sure!
>>>>
>>>> Thanks
>>>>
>>>> Nenge
>>>>
>>>>
>>>> On Tue, Jun 2, 2020 at 6:47 PM 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/
>>>>>
>>>>>
>>>>> What do you mean by "response data"? Do you mean messages returned by
>>>>> the other party? If so, those will be received in your Application
>>>>> implementation in fromApp.
>>>>> On 6/2/20 5:56 AM, Nenge Masoya wrote:
>>>>>
>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>> Dear team,
>>>>>
>>>>> I am new with quickfixJ and I Im kindy requesting your help on this,
>>>>> from what I see the response of client QuickFixJTemplate when sending
>>>>> message is boolean which tells whether the  message was successful
>>>>> delivered or not.
>>>>>
>>>>> For instance,
>>>>>
>>>>>  @Autowired
>>>>> private QuickFixJTemplate clientQuickFixJTemplate;
>>>>>
>>>>> //send message
>>>>>
>>>>> boolean send = clientQuickFixJTemplate.send(fixMessage, sessionID);
>>>>>
>>>>> Now, how can I get response data for further implementation?
>>>>>
>>>>> Thank in advance.
>>>>>
>>>>> Nenge Masoya
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>
>>>>> --
>>>>> Colin DuPlantis
>>>>> Chief Architect, Marketcetera
>>>>> Download, Run, Trade
>>>>> 888.868.4884https://www.marketcetera.com
>>>>>
>>>>> _______________________________________________
>>>>> Quickfixj-users mailing list
>>>>> Qui...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>>
>>>> --
>>>> Christoph John
>>>> Software Engineering
>>>> T +49 241 557...@ma...
>>>>
>>>> MACD GmbH
>>>> Oppenhoffallee 103
>>>> 52066 Aachen, Germanywww.macd.com
>>>>
>>>> Amtsgericht Aachen: HRB 8151
>>>> Ust.-Id: DE 813021663
>>>> Geschäftsführer: George Macdonald
>>>>
>>>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.
> http://connamara.com
>
> This email, along with any attachments, is confidential. If you believe
> you received this message in error, please contact the sender immediately
> and delete all copies of the message. Thank you from Connamara Systems, LLC.
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] QuickFix response using spring boot

[Grant B. <gbi...@co...>]

That message is "CF", but it looks like the QF/j FIX50SP2 dictionary wasn't
updated past "CE".

Probably the best thing to do would be to edit your DD to add CF and
regenerate the QF/j source and rebuild.

On Thu, Jul 30, 2020 at 3:37 PM Nenge Masoya <geo...@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/
>
>
> Hello Devs,
>
> I want to send "Party Details List Request" in quickfix/J unfortunately I
> was not able to find this api... I am using quickfix/J core 2.2.0.
>
> Is the there any alternative to use this because I wish I could have  this
> api?.
>
> Any help will be appreciated.
>
> Thanks,
>
> Nenge Masoya
>
> On Sat, Jun 20, 2020 at 2:23 AM Nenge Masoya <geo...@gm...> wrote:
>
>>
>> On Sat, 20 Jun 2020, 02:01 Christoph John, <chr...@ma...>
>> wrote:
>>
>>> Looking at the stack trace, I think your problem is that you are trying
>>> to crack admin messages (at
>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)).
>>> This is not required.
>>> You only need to do this for application messages, i.e. in your
>>> fromApp() callback.
>>>
>>> Cheers,
>>> Chris.
>>>
>>> On 18.06.20 15:36, Nenge Masoya wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hello Devs,
>>>
>>> I am still facing the issues in reading messages returned from other
>>> party (server) which is using FIX.5.0SP2.... this is my errors message from
>>> events logs
>>>
>>> 20200617-14:19:45: Session FIXT.1.1:CLIENT->SERVER schedule is daily,
>>> 00:00:00-UTC - 22:50:00-UTC
>>> 20200617-14:19:45: Created session: FIXT.1.1:CLIENT->SERVER
>>> 20200617-14:19:45: Configured socket addresses for session:
>>> [/"server-address here"]
>>> 20200617-14:19:45: MINA session created: local=/192.168.91.98:39322,
>>> class org.apache.mina.transport.socket.nio.NioSocketSession,
>>> remote=/"server-address here"
>>> 20200617-14:19:46: Initiated logon request
>>> 20200617-14:19:46: Invalid message: Can't determine ApplVerID from
>>> message 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>>> 56=CLIENT 7=1 16=0 10=149
>>> 20200617-14:19:46: Setting DefaultApplVerID (1137=8) from Logon
>>> 20200617-14:19:46: Error during message processing
>>> quickfix.RuntimeError: java.lang.ClassCastException:
>>> quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>> at quickfix.Session.next(Session.java:1157)
>>> at quickfix.Session.next(Session.java:1204)
>>> at
>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>> at
>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by: java.lang.ClassCastException: quickfix.fixt11.Logon cannot be
>>> cast to quickfix.fix50sp2.Message
>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>> at
>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>> at quickfix.Session.fromCallback(Session.java:1845)
>>> at quickfix.Session.verify(Session.java:1791)
>>> at quickfix.Session.nextLogon(Session.java:2129)
>>> at quickfix.Session.next(Session.java:1026)
>>> ... 4 more
>>> Cause: quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>>> java.lang.ClassCastException: quickfix.fixt11.Logon cannot be cast to
>>> quickfix.fix50sp2.Message
>>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>>> at
>>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>>> at quickfix.Session.fromCallback(Session.java:1845)
>>> at quickfix.Session.verify(Session.java:1791)
>>> at quickfix.Session.nextLogon(Session.java:2129)
>>> at quickfix.Session.next(Session.java:1026)
>>> at quickfix.Session.next(Session.java:1204)
>>> at
>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>>> at
>>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>>> at java.lang.Thread.run(Thread.java:748)
>>>
>>> I tried to follow the reference provided here here no success..
>>>
>>> https://stackoverflow.com/questions/30074850/quickfix-message-cannot-be-cast-to-quickfix-fix50sp2-message
>>>
>>> And this is my log messages
>>>
>>> 8=FIXT.1.1 9=75 35=A 34=2 49=CLIENT 52=20200617-14:19:46.103 56=SERVER
>>> 98=0 108=30 1137=9 10=139
>>> 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234 56=CLIENT
>>> 7=1 16=0 10=149
>>> 8=FIXT.1.1 9=112 35=A 34=2 49=SERVER 52=20200617-14:21:08.242 56=CLIENT
>>> 58=Logon Successful. 98=0 108=60 553=STT 554=SERVER 1137=8 10=117
>>>
>>>
>>> Any one with the help will be appreciated guys... It make me mad for
>>> sure!
>>>
>>> Thanks
>>>
>>> Nenge
>>>
>>>
>>> On Tue, Jun 2, 2020 at 6:47 PM 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/
>>>>
>>>>
>>>> What do you mean by "response data"? Do you mean messages returned by
>>>> the other party? If so, those will be received in your Application
>>>> implementation in fromApp.
>>>> On 6/2/20 5:56 AM, Nenge Masoya wrote:
>>>>
>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>
>>>>
>>>> Dear team,
>>>>
>>>> I am new with quickfixJ and I Im kindy requesting your help on this,
>>>> from what I see the response of client QuickFixJTemplate when sending
>>>> message is boolean which tells whether the  message was successful
>>>> delivered or not.
>>>>
>>>> For instance,
>>>>
>>>>  @Autowired
>>>> private QuickFixJTemplate clientQuickFixJTemplate;
>>>>
>>>> //send message
>>>>
>>>> boolean send = clientQuickFixJTemplate.send(fixMessage, sessionID);
>>>>
>>>> Now, how can I get response data for further implementation?
>>>>
>>>> Thank in advance.
>>>>
>>>> Nenge Masoya
>>>>
>>>>
>>>> _______________________________________________
>>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>> --
>>>> Colin DuPlantis
>>>> Chief Architect, Marketcetera
>>>> Download, Run, Trade
>>>> 888.868.4884https://www.marketcetera.com
>>>>
>>>> _______________________________________________
>>>> Quickfixj-users mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>>
>>> --
>>> Christoph John
>>> Software Engineering
>>> T +49 241 557...@ma...
>>>
>>> MACD GmbH
>>> Oppenhoffallee 103
>>> 52066 Aachen, Germanywww.macd.com
>>>
>>> Amtsgericht Aachen: HRB 8151
>>> Ust.-Id: DE 813021663
>>> Geschäftsführer: George Macdonald
>>>
>>> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com

-- 
This email, along with any attachments, is confidential. If you believe you 
received this message in error, please contact the sender immediately and 
delete all copies of the message. Thank you from Connamara Systems, LLC.

Re: [Quickfixj-users] QuickFix response using spring boot

[Nenge M. <geo...@gm...>]

Hello Devs,

I want to send "Party Details List Request" in quickfix/J unfortunately I
was not able to find this api... I am using quickfix/J core 2.2.0.

Is the there any alternative to use this because I wish I could have  this
api?.

Any help will be appreciated.

Thanks,

Nenge Masoya

On Sat, Jun 20, 2020 at 2:23 AM Nenge Masoya <geo...@gm...> wrote:

>
> On Sat, 20 Jun 2020, 02:01 Christoph John, <chr...@ma...>
> wrote:
>
>> Looking at the stack trace, I think your problem is that you are trying
>> to crack admin messages (at
>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)).
>> This is not required.
>> You only need to do this for application messages, i.e. in your fromApp()
>> callback.
>>
>> Cheers,
>> Chris.
>>
>> On 18.06.20 15:36, Nenge Masoya wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hello Devs,
>>
>> I am still facing the issues in reading messages returned from other
>> party (server) which is using FIX.5.0SP2.... this is my errors message from
>> events logs
>>
>> 20200617-14:19:45: Session FIXT.1.1:CLIENT->SERVER schedule is daily,
>> 00:00:00-UTC - 22:50:00-UTC
>> 20200617-14:19:45: Created session: FIXT.1.1:CLIENT->SERVER
>> 20200617-14:19:45: Configured socket addresses for session:
>> [/"server-address here"]
>> 20200617-14:19:45: MINA session created: local=/192.168.91.98:39322,
>> class org.apache.mina.transport.socket.nio.NioSocketSession,
>> remote=/"server-address here"
>> 20200617-14:19:46: Initiated logon request
>> 20200617-14:19:46: Invalid message: Can't determine ApplVerID from
>> message 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234
>> 56=CLIENT 7=1 16=0 10=149
>> 20200617-14:19:46: Setting DefaultApplVerID (1137=8) from Logon
>> 20200617-14:19:46: Error during message processing
>> quickfix.RuntimeError: java.lang.ClassCastException:
>> quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>> at quickfix.Session.next(Session.java:1157)
>> at quickfix.Session.next(Session.java:1204)
>> at
>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>> at
>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by: java.lang.ClassCastException: quickfix.fixt11.Logon cannot be
>> cast to quickfix.fix50sp2.Message
>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>> at
>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>> at quickfix.Session.fromCallback(Session.java:1845)
>> at quickfix.Session.verify(Session.java:1791)
>> at quickfix.Session.nextLogon(Session.java:2129)
>> at quickfix.Session.next(Session.java:1026)
>> ... 4 more
>> Cause: quickfix.fixt11.Logon cannot be cast to quickfix.fix50sp2.Message
>> java.lang.ClassCastException: quickfix.fixt11.Logon cannot be cast to
>> quickfix.fix50sp2.Message
>> at quickfix.fix50sp2.MessageCracker.crack(MessageCracker.java:1446)
>> at
>> tz.go.mtp.ats.ClientApplicationAdapter.fromAdmin(ClientApplicationAdapter.java:68)
>> at quickfix.Session.fromCallback(Session.java:1845)
>> at quickfix.Session.verify(Session.java:1791)
>> at quickfix.Session.nextLogon(Session.java:2129)
>> at quickfix.Session.next(Session.java:1026)
>> at quickfix.Session.next(Session.java:1204)
>> at
>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchingThread.doRun(ThreadPerSessionEventHandlingStrategy.java:214)
>> at
>> quickfix.mina.ThreadPerSessionEventHandlingStrategy$ThreadAdapter.run(ThreadPerSessionEventHandlingStrategy.java:142)
>> at java.lang.Thread.run(Thread.java:748)
>>
>> I tried to follow the reference provided here here no success..
>>
>> https://stackoverflow.com/questions/30074850/quickfix-message-cannot-be-cast-to-quickfix-fix50sp2-message
>>
>> And this is my log messages
>>
>> 8=FIXT.1.1 9=75 35=A 34=2 49=CLIENT 52=20200617-14:19:46.103 56=SERVER
>> 98=0 108=30 1137=9 10=139
>> 8=FIXT.1.1 9=65 35=2 34=1 49=SERVER 52=20200617-14:21:08.234 56=CLIENT
>> 7=1 16=0 10=149
>> 8=FIXT.1.1 9=112 35=A 34=2 49=SERVER 52=20200617-14:21:08.242 56=CLIENT
>> 58=Logon Successful. 98=0 108=60 553=STT 554=SERVER 1137=8 10=117
>>
>>
>> Any one with the help will be appreciated guys... It make me mad for sure!
>>
>> Thanks
>>
>> Nenge
>>
>>
>> On Tue, Jun 2, 2020 at 6:47 PM 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/
>>>
>>>
>>> What do you mean by "response data"? Do you mean messages returned by
>>> the other party? If so, those will be received in your Application
>>> implementation in fromApp.
>>> On 6/2/20 5:56 AM, Nenge Masoya wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Dear team,
>>>
>>> I am new with quickfixJ and I Im kindy requesting your help on this,
>>> from what I see the response of client QuickFixJTemplate when sending
>>> message is boolean which tells whether the  message was successful
>>> delivered or not.
>>>
>>> For instance,
>>>
>>>  @Autowired
>>> private QuickFixJTemplate clientQuickFixJTemplate;
>>>
>>> //send message
>>>
>>> boolean send = clientQuickFixJTemplate.send(fixMessage, sessionID);
>>>
>>> Now, how can I get response data for further implementation?
>>>
>>> Thank in advance.
>>>
>>> Nenge Masoya
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>> --
>>> Colin DuPlantis
>>> Chief Architect, Marketcetera
>>> Download, Run, Trade
>>> 888.868.4884https://www.marketcetera.com
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>

Re: [Quickfixj-users] Reset Sequnces Design

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

IIRC, setting the ResetOn flags controls whether the ResetSeqNumFlag is 
set on the appropriate messages.

On 7/15/20 4:11 AM, Liubov Efremova wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> One more question about /*ResetSeqNumFlag*/ behavior.
> Does */ResetOnXXX=Y/ *options enforce to set */ResetSeqNumFlag/* in 
> the logon message (both cases, acceptor and initiator) or not (just 
> provide in/out sequences reset to 1)?
>
> ср, 8 июл. 2020 г. в 12:39, Liubov Efremova <liu...@gm... 
> <mailto:liu...@gm...>>:
>
>     Got it. Thank you for the clarification!
>
>
>     вт, 7 июл. 2020 г. в 12:57, Christoph John
>     <chr...@ma... <mailto:chr...@ma...>>:
>
>         Hi,
>
>         yes, it will be checked on session start whether the session
>         needs to be reset. Actually it will be checked periodically
>         because the session needs to disconnected and reset when the
>         end time is reached.
>
>         Your example:
>         1. reset will be done
>         2. no reset will be done.
>
>         Cheers,
>         Chris.
>
>         On 07.07.20 10:21, Liubov Efremova wrote:
>>         Hi,
>>
>>         Thank you for your explanation.
>>
>>         One more question: imagine the situation of engine restart
>>         during the trade day. Will the necessity of sequences reset
>>         be checked during the engine start? In other words, does the
>>         engine care on the start if there is a first connection
>>         inside the defined trade day or not?
>>
>>         Example:
>>         /StartTime=03:00:00
>>         EndTime=06:00:00/
>>
>>         /1) Engine starts for the first time at 04:00:00/
>>         /2) Engine restarts at 05:00:00/
>>         /
>>         /
>>         What will be the sequence behavior in these two cases?
>>         /
>>         /
>>
>>         вт, 7 июл. 2020 г. в 02:04, Christoph John
>>         <chr...@ma... <mailto:chr...@ma...>>:
>>
>>             Hi,
>>
>>             1) no, the engine will not send Logon with ResetSeqNum=Y
>>             (unless you configure it that way). The session time
>>             should be agreed between the two counterparties. Once the
>>             session time is over the session should get reset implicitly.
>>             2) Please check the documentation. There are slight
>>             differences between ResetOnLogon/Logout/Disconnect/Error.
>>             https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
>>             TBH, I never used one of the options apart from
>>             "ResetOnLogon" in the last years. However, I recall we
>>             once had a counterparty (about 10 years ago) which wanted
>>             to reset sequence numbers only if there was a normal
>>             Logout (not an unsolicited disconnection) and not every
>>             time a Logon was sent.
>>
>>             Cheers,
>>             Chris.
>>
>>             On 03.07.20 13:31, Liubov Efremova wrote:
>>>             QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>             QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>             Hi,
>>>
>>>             Please clarify the following questions about QuickFIX/J
>>>             session configuration:
>>>             1) How does the reset of sequences occur on /StartTime/
>>>             session events? Does the engine send the logon with the
>>>             enabled ResetSeqNum flag?
>>>             2) What is the purpose of /ResetOnLogout/ property? Why
>>>             not use /ResetOnLogon/ instead?
>>>
>>>             -- 
>>>             Kind regards,
>>>             Liubov Efremova.
>>>
>>>
>>>             _______________________________________________
>>>             Quickfixj-users mailing list
>>>             Qui...@li...  <mailto:Qui...@li...>
>>>             https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>             -- 
>>             Christoph John
>>             Software Engineering
>>             T +49 241 557080-28
>>             chr...@ma...  <mailto:chr...@ma...>
>>
>>             MACD GmbH
>>             Oppenhoffallee 103
>>             52066 Aachen, Germany
>>             www.macd.com  <http://www.macd.com>
>>
>>             Amtsgericht Aachen: HRB 8151
>>             Ust.-Id: DE 813021663
>>             Geschäftsführer: George Macdonald
>>
>>
>>
>>         -- 
>>         Kind regards,
>>         Liubov Efremova.
>
>         -- 
>         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
>
>
>
>     -- 
>     Kind regards,
>     Liubov Efremova.
>
>
>
> -- 
> Kind regards,
> Liubov Efremova.
>
>
> _______________________________________________
> 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] Reset Sequnces Design

[Liubov E. <liu...@gm...>]

Hi,

One more question about *ResetSeqNumFlag* behavior.
Does *ResetOnXXX=Y *options enforce to set *ResetSeqNumFlag* in the logon
message (both cases, acceptor and initiator) or not (just provide in/out
sequences reset to 1)?

ср, 8 июл. 2020 г. в 12:39, Liubov Efremova <liu...@gm...>:

> Got it. Thank you for the clarification!
>
>
> вт, 7 июл. 2020 г. в 12:57, Christoph John <chr...@ma...>:
>
>> Hi,
>>
>> yes, it will be checked on session start whether the session needs to be
>> reset. Actually it will be checked periodically because the session needs
>> to disconnected and reset when the end time is reached.
>>
>> Your example:
>> 1. reset will be done
>> 2. no reset will be done.
>>
>> Cheers,
>> Chris.
>>
>> On 07.07.20 10:21, Liubov Efremova wrote:
>>
>> Hi,
>>
>> Thank you for your explanation.
>>
>> One more question: imagine the situation of engine restart during the
>> trade day. Will the necessity of sequences reset be checked during the
>> engine start? In other words, does the engine care on the start if there is
>> a first connection inside the defined trade day or not?
>>
>> Example:
>>
>> * StartTime=03:00:00 EndTime=06:00:00*
>>
>> *1) Engine starts for the first time at 04:00:00*
>> *2) Engine restarts at 05:00:00*
>>
>> What will be the sequence behavior in these two cases?
>>
>>
>> вт, 7 июл. 2020 г. в 02:04, Christoph John <chr...@ma...>:
>>
>>> Hi,
>>>
>>> 1) no, the engine will not send Logon with ResetSeqNum=Y (unless you
>>> configure it that way). The session time should be agreed between the two
>>> counterparties. Once the session time is over the session should get reset
>>> implicitly.
>>> 2) Please check the documentation. There are slight differences between
>>> ResetOnLogon/Logout/Disconnect/Error.
>>>
>>> https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
>>> TBH, I never used one of the options apart from "ResetOnLogon" in the
>>> last years. However, I recall we once had a counterparty (about 10 years
>>> ago) which wanted to reset sequence numbers only if there was a normal
>>> Logout (not an unsolicited disconnection) and not every time a Logon was
>>> sent.
>>>
>>> Cheers,
>>> Chris.
>>>
>>> On 03.07.20 13:31, Liubov Efremova wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Hi,
>>>
>>> Please clarify the following questions about QuickFIX/J session
>>> configuration:
>>> 1) How does the reset of sequences occur on *StartTime* session events?
>>> Does the engine send the logon with the enabled ResetSeqNum flag?
>>> 2) What is the purpose of  *ResetOnLogout* property? Why not use
>>> *ResetOnLogon* instead?
>>>
>>> --
>>> Kind regards,
>>> Liubov Efremova.
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> --
>> Kind regards,
>> Liubov Efremova.
>>
>>
>> --
>> 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
>>
>>
>
> --
> Kind regards,
> Liubov Efremova.
>


-- 
Kind regards,
Liubov Efremova.

Re: [Quickfixj-users] quickfix.Application.onLogout(SessionID) v quickfix.SessionStateListener.onLogout()

[Browne, S. <Sam...@cm...>]

Thanks Chris,

Yea, it was the wrapping of the call to stateListener.onLogout(); inside the “if (logonReceived || logonSent)” block that meant it wasn’t guaranteed to be called, I’ve since moved the “cleanup” code into the stateListener.onDisconnect hook.

Thanks,
Sam

From: Christoph John <chr...@ma...>
Organisation: MACD
Reply to: "chr...@ma..." <chr...@ma...>
Date: Monday, 13 July 2020 at 15:56
To: "qui...@li..." <qui...@li...>, "Browne, Sam" <Sam...@cm...>
Subject: Re: [Quickfixj-users] quickfix.Application.onLogout(SessionID) v quickfix.SessionStateListener.onLogout()

Exercise Caution: This email is from an external source.


Hi Sam,

actually, both Application.onLogout() and SessionStateListener.onLogout() are similar in this case. You can see this here:
https://github.com/quickfix-j/quickfixj/blob/655b3e459dfce0a0dbd42897619cc01d62a2a58b/quickfixj-core/src/main/java/quickfix/Session.java#L2074-L2081

Both callbacks have some overlaps, but SessionStateListener has some more network-level checks, e.g. you have callbacks onConnect() or onDisconnect() there.

Personally I'd also implement the SessionStateListener.onDisconnect() callback to be able to get notified of every disconnection since onLogout() will only be called if the session was logged on before. This will not cover the case e.g. where a Logon has been sent and the connection drops right afterwards. Also see https://stackoverflow.com/questions/61868398/quickfix-j-how-to-detect-when-connection-fails

Cheers,
Chris.



On 09.07.20 14:24, Browne, Sam wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/

QuickFIX/J Support: http://www.quickfixj.org/support/






Hi,

The Java doc for quickfix.Application.onLogout(SessionID) states:

“This callback notifies you when an FIX session is no longer online. This could happen during a normal logout exchange or because of a forced termination or a loss of network connection.”

Does the same apply to quickfix.SessionStateListener.onLogout() or does the separate quickfix.SessionStateListener.onDisconnect() method need to be implemented to handle the latter case of “forced termination or a loss of network connection”

Thanks,
Sam
________________________________
NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.




_______________________________________________

Quickfixj-users mailing list

Qui...@li...<mailto:Qui...@li...>

https://lists.sourceforge.net/lists/listinfo/quickfixj-users



--

Christoph John

Software Engineering

T +49 241 557080-28

chr...@ma...<mailto:chr...@ma...>



MACD GmbH

Oppenhoffallee 103

52066 Aachen, Germany

www.macd.com<http://www.macd.com>



Amtsgericht Aachen: HRB 8151

Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald

Re: [Quickfixj-users] quickfix.Application.onLogout(SessionID) v quickfix.SessionStateListener.onLogout()

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

Hi Sam,

actually, both Application.onLogout() and SessionStateListener.onLogout() are similar in this case. 
You can see this here:
https://github.com/quickfix-j/quickfixj/blob/655b3e459dfce0a0dbd42897619cc01d62a2a58b/quickfixj-core/src/main/java/quickfix/Session.java#L2074-L2081

Both callbacks have some overlaps, but SessionStateListener has some more network-level checks, e.g. 
you have callbacks onConnect() or onDisconnect() there.

Personally I'd also implement the SessionStateListener.onDisconnect() callback to be able to get 
notified of every disconnection since onLogout() will only be called if the session was logged on 
before. This will not cover the case e.g. where a Logon has been sent and the connection drops right 
afterwards. Also see 
https://stackoverflow.com/questions/61868398/quickfix-j-how-to-detect-when-connection-fails

Cheers,
Chris.




On 09.07.20 14:24, Browne, Sam wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> The Java doc for quickfix.Application.onLogout(SessionID) states:
>
> “This callback notifies you when an FIX session is no longer online. This could happen during a 
> normal logout exchange or because of a forced termination or a loss of network connection.”
>
> Does the same apply to quickfix.SessionStateListener.onLogout() or does the separate 
> quickfix.SessionStateListener.onDisconnect() method need to be implemented to handle the latter 
> case of “forced termination or a loss of network connection”
>
> Thanks,
>
> Sam
>
> ----------------------------------------------------------------------------------------------------
>
> */NOTICE: /*/This message, and any attachments, are for the intended recipient(s) only, may 
> contain information that is privileged, confidential and/or proprietary and subject to important 
> terms and conditions available at E-Communication Disclaimer 
> <http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you 
> are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve 
> the right to monitor all email communications that occur on CME Group information systems./
>
>
>
> _______________________________________________
> 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] quickfix.Application.onLogout(SessionID) v quickfix.SessionStateListener.onLogout()

[Browne, S. <Sam...@cm...>]

Hi,

The Java doc for quickfix.Application.onLogout(SessionID) states:

“This callback notifies you when an FIX session is no longer online. This could happen during a normal logout exchange or because of a forced termination or a loss of network connection.”

Does the same apply to quickfix.SessionStateListener.onLogout() or does the separate quickfix.SessionStateListener.onDisconnect() method need to be implemented to handle the latter case of “forced termination or a loss of network connection”

Thanks,
Sam
________________________________
NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.

Re: [Quickfixj-users] Reset Sequnces Design

[Liubov E. <liu...@gm...>]

Got it. Thank you for the clarification!


вт, 7 июл. 2020 г. в 12:57, Christoph John <chr...@ma...>:

> Hi,
>
> yes, it will be checked on session start whether the session needs to be
> reset. Actually it will be checked periodically because the session needs
> to disconnected and reset when the end time is reached.
>
> Your example:
> 1. reset will be done
> 2. no reset will be done.
>
> Cheers,
> Chris.
>
> On 07.07.20 10:21, Liubov Efremova wrote:
>
> Hi,
>
> Thank you for your explanation.
>
> One more question: imagine the situation of engine restart during the
> trade day. Will the necessity of sequences reset be checked during the
> engine start? In other words, does the engine care on the start if there is
> a first connection inside the defined trade day or not?
>
> Example:
>
> * StartTime=03:00:00 EndTime=06:00:00*
>
> *1) Engine starts for the first time at 04:00:00*
> *2) Engine restarts at 05:00:00*
>
> What will be the sequence behavior in these two cases?
>
>
> вт, 7 июл. 2020 г. в 02:04, Christoph John <chr...@ma...>:
>
>> Hi,
>>
>> 1) no, the engine will not send Logon with ResetSeqNum=Y (unless you
>> configure it that way). The session time should be agreed between the two
>> counterparties. Once the session time is over the session should get reset
>> implicitly.
>> 2) Please check the documentation. There are slight differences between
>> ResetOnLogon/Logout/Disconnect/Error.
>>
>> https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
>> TBH, I never used one of the options apart from "ResetOnLogon" in the
>> last years. However, I recall we once had a counterparty (about 10 years
>> ago) which wanted to reset sequence numbers only if there was a normal
>> Logout (not an unsolicited disconnection) and not every time a Logon was
>> sent.
>>
>> Cheers,
>> Chris.
>>
>> On 03.07.20 13:31, Liubov Efremova wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi,
>>
>> Please clarify the following questions about QuickFIX/J session
>> configuration:
>> 1) How does the reset of sequences occur on *StartTime* session events?
>> Does the engine send the logon with the enabled ResetSeqNum flag?
>> 2) What is the purpose of  *ResetOnLogout* property? Why not use
>> *ResetOnLogon* instead?
>>
>> --
>> Kind regards,
>> Liubov Efremova.
>>
>>
>> _______________________________________________
>> 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
>>
>>
>
> --
> Kind regards,
> Liubov Efremova.
>
>
> --
> 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
>
>

-- 
Kind regards,
Liubov Efremova.

Re: [Quickfixj-users] Reset Sequnces Design

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

Hi,

yes, it will be checked on session start whether the session needs to be reset. Actually it will be 
checked periodically because the session needs to disconnected and reset when the end time is reached.

Your example:
1. reset will be done
2. no reset will be done.

Cheers,
Chris.

On 07.07.20 10:21, Liubov Efremova wrote:
> Hi,
>
> Thank you for your explanation.
>
> One more question: imagine the situation of engine restart during the trade day. Will the 
> necessity of sequences reset be checked during the engine start? In other words, does the engine 
> care on the start if there is a first connection inside the defined trade day or not?
>
> Example:
> /StartTime=03:00:00
> EndTime=06:00:00/
>
> /1) Engine starts for the first time at 04:00:00/
> /2) Engine restarts at 05:00:00/
> /
> /
> What will be the sequence behavior in these two cases?
> /
> /
>
> вт, 7 июл. 2020 г. в 02:04, Christoph John <chr...@ma... <mailto:chr...@ma...>>:
>
>     Hi,
>
>     1) no, the engine will not send Logon with ResetSeqNum=Y (unless you configure it that way).
>     The session time should be agreed between the two counterparties. Once the session time is
>     over the session should get reset implicitly.
>     2) Please check the documentation. There are slight differences between
>     ResetOnLogon/Logout/Disconnect/Error.
>     https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
>     TBH, I never used one of the options apart from "ResetOnLogon" in the last years. However, I
>     recall we once had a counterparty (about 10 years ago) which wanted to reset sequence numbers
>     only if there was a normal Logout (not an unsolicited disconnection) and not every time a
>     Logon was sent.
>
>     Cheers,
>     Chris.
>
>     On 03.07.20 13:31, Liubov Efremova wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hi,
>>
>>     Please clarify the following questions about QuickFIX/J session configuration:
>>     1) How does the reset of sequences occur on /StartTime/ session events? Does the engine send
>>     the logon with the enabled ResetSeqNum flag?
>>     2) What is the purpose of /ResetOnLogout/ property? Why not use /ResetOnLogon/ instead?
>>
>>     -- 
>>     Kind regards,
>>     Liubov Efremova.
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> -- 
> Kind regards,
> Liubov Efremova.

-- 
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] Reset Sequnces Design

[Liubov E. <liu...@gm...>]

Hi,

Thank you for your explanation.

One more question: imagine the situation of engine restart during the trade
day. Will the necessity of sequences reset be checked during the engine
start? In other words, does the engine care on the start if there is a
first connection inside the defined trade day or not?

Example:

* StartTime=03:00:00 EndTime=06:00:00*

*1) Engine starts for the first time at 04:00:00*
*2) Engine restarts at 05:00:00*

What will be the sequence behavior in these two cases?


вт, 7 июл. 2020 г. в 02:04, Christoph John <chr...@ma...>:

> Hi,
>
> 1) no, the engine will not send Logon with ResetSeqNum=Y (unless you
> configure it that way). The session time should be agreed between the two
> counterparties. Once the session time is over the session should get reset
> implicitly.
> 2) Please check the documentation. There are slight differences between
> ResetOnLogon/Logout/Disconnect/Error.
>
> https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
> TBH, I never used one of the options apart from "ResetOnLogon" in the last
> years. However, I recall we once had a counterparty (about 10 years ago)
> which wanted to reset sequence numbers only if there was a normal Logout
> (not an unsolicited disconnection) and not every time a Logon was sent.
>
> Cheers,
> Chris.
>
> On 03.07.20 13:31, Liubov Efremova wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> Please clarify the following questions about QuickFIX/J session
> configuration:
> 1) How does the reset of sequences occur on *StartTime* session events?
> Does the engine send the logon with the enabled ResetSeqNum flag?
> 2) What is the purpose of  *ResetOnLogout* property? Why not use
> *ResetOnLogon* instead?
>
> --
> Kind regards,
> Liubov Efremova.
>
>
> _______________________________________________
> 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
>
>

-- 
Kind regards,
Liubov Efremova.

Re: [Quickfixj-users] Reset Sequnces Design

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

Hi,

1) no, the engine will not send Logon with ResetSeqNum=Y (unless you configure it that way). The 
session time should be agreed between the two counterparties. Once the session time is over the 
session should get reset implicitly.
2) Please check the documentation. There are slight differences between 
ResetOnLogon/Logout/Disconnect/Error.
https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html#Miscellaneous
TBH, I never used one of the options apart from "ResetOnLogon" in the last years. However, I recall 
we once had a counterparty (about 10 years ago) which wanted to reset sequence numbers only if there 
was a normal Logout (not an unsolicited disconnection) and not every time a Logon was sent.

Cheers,
Chris.

On 03.07.20 13:31, Liubov Efremova wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> Please clarify the following questions about QuickFIX/J session configuration:
> 1) How does the reset of sequences occur on /StartTime/ session events? Does the engine send the 
> logon with the enabled ResetSeqNum flag?
> 2) What is the purpose of /ResetOnLogout/ property? Why not use /ResetOnLogon/ instead?
>
> -- 
> Kind regards,
> Liubov Efremova.
>
>
> _______________________________________________
> 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] Reset Sequnces Design

[Liubov E. <liu...@gm...>]

Hi,

Please clarify the following questions about QuickFIX/J session
configuration:
1) How does the reset of sequences occur on *StartTime* session events?
Does the engine send the logon with the enabled ResetSeqNum flag?
2) What is the purpose of  *ResetOnLogout* property? Why not use
*ResetOnLogon* instead?

-- 
Kind regards,
Liubov Efremova.

[Quickfixj-users] NonStopSession config usage

[Browne, S. <Sam...@cm...>]

It looks like setting NonStopSession=Y in the config still causes misleading logging such as:

2020.07.02T01:58:55.704-0500 [logLvl=INFO] [thr=NioProcessor-2 ctgy='quickfixj.event.FIX.4.4:/STP->IEYE: ' - Session FIX.4.4:/STP->IEYE schedule is daily, 00:00:00-UTC - 00:00:00-UTC

Caused by the passing of NOT_SET in the quickfix.DefaultSessionSchedule.DefaultSessionSchedule(SessionSettings, SessionID) constructor:


        if (isNonStopSession) {

            isWeekdaySession = false;

            weekdayOffsets = new int[0];

            startTime = endTime = new TimeEndPoint(NOT_SET, 0, 0, 0, defaultTimeZone);

            return;

        } else {

            isWeekdaySession = settings.isSetting(sessionID, Session.SETTING_WEEKDAYS);

        }

The toString calls quickfix.DefaultSessionSchedule.formatTimeInterval(StringBuilder, TimeInterval, SimpleDateFormat, boolean) which doesn’t take isNonStopSession into account and instead relies on the startDay/endDay having been set to indicate a non daily session:

        if (isWeekdaySession) {
            try {
                for (int i = 0; i < weekdayOffsets.length; i++) {
                    buf.append(DayConverter.toString(weekdayOffsets[i]));
                    buf.append(", ");
                }
            } catch (ConfigError ex) {
                // this can't happen as these are created using DayConverter.toInteger
            }
        } else if (!isDailySession()) {
            buf.append("weekly, ");
            formatDayOfWeek(buf, startTime.getDay());
            buf.append(" ");
        } else {
            buf.append("daily, ");
        }


    private boolean isDailySession() {
        return !isSet(startTime.getDay()) && !isSet(endTime.getDay());
    }


Regards,
Sam
________________________________
NOTICE: This message, and any attachments, are for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at E-Communication Disclaimer<http://www.cmegroup.com/tools-information/communications/e-communication-disclaimer.html>. If you are not the intended recipient, please delete this message. CME Group and its subsidiaries reserve the right to monitor all email communications that occur on CME Group information systems.

Re: [Quickfixj-users] QuickFix/J and oracle

[Alexandre G. <aga...@sa...>]

After some work (it was my first java compilation, after of course a
proudly printf('Hello World') ;-) ), I changed the class and call
JdbcStoreFactory. Now, Oracle and QFJ are working well together inside a
BANZAI-EXECUTOR dialog.

Thanks all for your help.
Alexandre


Le mar. 23 juin 2020 à 08:34, Alexandre GALMICHE <
aga...@sa...> a écrit :

> As I'm starting from the very beginning, I'm still using banzai (and
> executor) to fully understand the engine.
>
> The main class has :
>
>         OrderTableModel orderTableModel = new OrderTableModel();
>         ExecutionTableModel executionTableModel = new
> ExecutionTableModel();
>         BanzaiApplication application = new
> BanzaiApplication(orderTableModel, executionTableModel);
>        /* this one ??? ==> */  MessageStoreFactory messageStoreFactory =
> new FileStoreFactory(settings);
>         LogFactory logFactory = new ScreenLogFactory(true, true, true,
> logHeartbeats);
>         MessageFactory messageFactory = new DefaultMessageFactory();
>
>
> Le 20/06/2020 à 02:40, Christoph John a écrit :
>
> Good point. This made me think that Alexandre might have used a
> FileStoreFactory all along.
> Alexandre, could you double check that you are using a JdbcStoreFactory in
> your application code? The behaviour you are describing (no error messages,
> no data in tables) sure sound a little like you are actually using a
> FileStore or MemoryStore.
>
> Cheers,
> Chris.
>
> On 19.06.20 15:51, Grant Birchmeier wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> What is the symptom of the failure?  You say it's not working -- did it
> throw an exception?  Did you see any messages received on the other side?
> What malfunction do you actually see?
>
> Got a message log?  Do you see any logon messages being sent out?
>
> And just for our sanity: Does it work when you use a FileStoreFactory?
> e.g. does it connect when you don't use the DB at all?
>
>
>
> On Fri, Jun 19, 2020 at 8:43 AM Alexandre Galmiche <
> aga...@sa...> wrote:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>> http://www.quickfixj.org/support/
>>
>>
>> Here is my log file :
>> 19 juin 2020 13:10:08,342 INFO [main] quickfix.DefaultSessionSchedule -
>> [FIX.4.2:CLIENT1->EXECUTOR] daily, 00:00:00-UTC - 00:00:00-UTC
>> 19 juin 2020 13:10:08,377 INFO [main] quickfix.mina.NetworkingOptions -
>> Socket option: SocketTcpNoDelay=true
>> 19 juin 2020 13:10:08,377 INFO [main] quickfix.mina.NetworkingOptions -
>> Socket option: SocketSynchronousWrites=false
>> 19 juin 2020 13:10:08,378 INFO [main] quickfix.mina.NetworkingOptions -
>> Socket option: SocketSynchronousWriteTimeout=30000
>> 19 juin 2020 13:10:08,406 INFO [main] quickfix.SocketInitiator -
>> SessionTimer started
>> 19 juin 2020 13:10:08,409 INFO [QFJ Message Processor]
>> quickfix.SocketInitiator - Started QFJ Message Processor
>> 19 juin 2020 13:10:09,538 DEBUG [NioProcessor-2]
>> org.apache.mina.filter.codec.ProtocolCodecFilter - Processing a
>> MESSAGE_RECEIVED for session 1
>> 19 juin 2020 13:10:09,540 DEBUG [NioProcessor-2]
>> quickfix.mina.message.FIXMessageDecoder - detected header:
>> pos=0,lim=98,rem=98,offset=0,state=1
>> 19 juin 2020 13:10:09,540 DEBUG [NioProcessor-2]
>> quickfix.mina.message.FIXMessageDecoder - body length = 76:
>> pos=0,lim=98,rem=98,offset=15,state=3
>>
>>
>>
>> The full content of the cfg file :
>> [DEFAULT]
>> ConnectionType=initiator
>> FileStorePath=init/store
>> FileLogPath=init/log
>> StartTime=00:00:00
>> EndTime=00:00:00
>> ResetOnLogon=Y
>> HeartBtInt=30
>> ReconnectInterval=2
>> MaxReconnectAttempts=5
>> MaxWaitSeconds=300
>>
>> #Oracle Config
>> ## Oracle config
>> JdbcDriver=oracle.jdbc.driver.OracleDriver
>> JdbcURL=jdbc:oracle:thin:@xxxxxx:1521:XE
>> JdbcSessionIdDefaultPropertyValue=n
>> JdbcStoreSessionsTableName=sessions
>> JdbcStoreMessagesTableName=messages
>> JdbcUser=xxxxx
>> JdbcPassword=xxxxx
>> SLF4JLogEventCategory=${senderCompID}.${targetCompID}.events
>> SLF4JLogIncomingMessageCategory=${senderCompID}.${targetCompID}.incoming
>> SLF4JLogOutgoingMessageCategory=${senderCompID}.${targetCompID}.outgoing
>>
>>
>> [SESSION]
>> BeginString=FIX.4.2
>> SenderCompID=CLIENT1
>> TargetCompID=EXECUTOR
>> SocketConnectPort=5001
>> SocketConnectHost=localhost
>>
>>
>> I also removed the primary key from the tables and removed the NULL
>> clauses but no netter results
>>
>> Thanks !
>>
>>
>>
>>>
>>
> --
> 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] QuickFix/J and oracle

[Alexandre G. <aga...@sa...>]

As I'm starting from the very beginning, I'm still using banzai (and 
executor) to fully understand the engine.

The main class has :

         OrderTableModel orderTableModel = new OrderTableModel();
         ExecutionTableModel executionTableModel = new 
ExecutionTableModel();
         BanzaiApplication application = new 
BanzaiApplication(orderTableModel, executionTableModel);
        /* this one ??? ==> */  MessageStoreFactory messageStoreFactory 
= new FileStoreFactory(settings);
         LogFactory logFactory = new ScreenLogFactory(true, true, true, 
logHeartbeats);
         MessageFactory messageFactory = new DefaultMessageFactory();


Le 20/06/2020 à 02:40, Christoph John a écrit :
> Good point. This made me think that Alexandre might have used a 
> FileStoreFactory all along.
> Alexandre, could you double check that you are using a 
> JdbcStoreFactory in your application code? The behaviour you are 
> describing (no error messages, no data in tables) sure sound a little 
> like you are actually using a FileStore or MemoryStore.
>
> Cheers,
> Chris.
>
> On 19.06.20 15:51, Grant Birchmeier wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> What is the symptom of the failure?  You say it's not working -- did 
>> it throw an exception?  Did you see any messages received on the 
>> other side?  What malfunction do you actually see?
>>
>> Got a message log?  Do you see any logon messages being sent out?
>>
>> And just for our sanity: Does it work when you use a 
>> FileStoreFactory? e.g. does it connect when you don't use the DB at all?
>>
>>
>>
>> On Fri, Jun 19, 2020 at 8:43 AM Alexandre Galmiche 
>> <aga...@sa... 
>> <mailto:aga...@sa...>> wrote:
>>
>>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>     QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J>
>>     Support: http://www.quickfixj.org/support/
>>
>>
>>     Here is my log file :
>>     19 juin 2020 13:10:08,342 INFO [main]
>>     quickfix.DefaultSessionSchedule - [FIX.4.2:CLIENT1->EXECUTOR]
>>     daily, 00:00:00-UTC - 00:00:00-UTC
>>     19 juin 2020 13:10:08,377 INFO [main]
>>     quickfix.mina.NetworkingOptions - Socket option:
>>     SocketTcpNoDelay=true
>>     19 juin 2020 13:10:08,377 INFO [main]
>>     quickfix.mina.NetworkingOptions - Socket option:
>>     SocketSynchronousWrites=false
>>     19 juin 2020 13:10:08,378 INFO [main]
>>     quickfix.mina.NetworkingOptions - Socket option:
>>     SocketSynchronousWriteTimeout=30000
>>     19 juin 2020 13:10:08,406 INFO [main] quickfix.SocketInitiator -
>>     SessionTimer started
>>     19 juin 2020 13:10:08,409 INFO [QFJ Message Processor]
>>     quickfix.SocketInitiator - Started QFJ Message Processor
>>     19 juin 2020 13:10:09,538 DEBUG [NioProcessor-2]
>>     org.apache.mina.filter.codec.ProtocolCodecFilter - Processing a
>>     MESSAGE_RECEIVED for session 1
>>     19 juin 2020 13:10:09,540 DEBUG [NioProcessor-2]
>>     quickfix.mina.message.FIXMessageDecoder - detected header:
>>     pos=0,lim=98,rem=98,offset=0,state=1
>>     19 juin 2020 13:10:09,540 DEBUG [NioProcessor-2]
>>     quickfix.mina.message.FIXMessageDecoder - body length = 76:
>>     pos=0,lim=98,rem=98,offset=15,state=3
>>
>>
>>
>>     The full content of the cfg file :
>>
>>     [DEFAULT]
>>     ConnectionType=initiator
>>     FileStorePath=init/store
>>     FileLogPath=init/log
>>     StartTime=00:00:00
>>     EndTime=00:00:00
>>     ResetOnLogon=Y
>>     HeartBtInt=30
>>     ReconnectInterval=2
>>     MaxReconnectAttempts=5
>>     MaxWaitSeconds=300
>>
>>     #Oracle Config
>>     ## Oracle config
>>     JdbcDriver=oracle.jdbc.driver.OracleDriver
>>     JdbcURL=jdbc:oracle:thin:@xxxxxx:1521:XE
>>     JdbcSessionIdDefaultPropertyValue=n
>>     JdbcStoreSessionsTableName=sessions
>>     JdbcStoreMessagesTableName=messages
>>     JdbcUser=xxxxx
>>     JdbcPassword=xxxxx
>>     SLF4JLogEventCategory=${senderCompID}.${targetCompID}.events
>>     SLF4JLogIncomingMessageCategory=${senderCompID}.${targetCompID}.incoming
>>     SLF4JLogOutgoingMessageCategory=${senderCompID}.${targetCompID}.outgoing
>>
>>
>>     [SESSION]
>>     BeginString=FIX.4.2
>>     SenderCompID=CLIENT1
>>     TargetCompID=EXECUTOR
>>     SocketConnectPort=5001
>>     SocketConnectHost=localhost
>>
>>
>>     I also removed the primary key from the tables and removed the
>>     NULL clauses but no netter results
>>
>>     Thanks !
>>
>>
>
> -- 
> 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] Quickfixj client disconnecting immediately after sending logout instead of waiting for logout response?

[Ajay P. <ap...@en...>]

No Ari
You are right, I have reported this before. We are still using 1.6 and we
have this problem where we ended up missing an execution report sent a ms
after our logout was sent. The workaround suggested at the time was to
adjust your session end time to slightly later so that you rather rely on
the other side to send the logout from your side (ie if you are talking
about a timed logout)
I was not able to open a jira at the time, but I dont think there is any
configuration you can change on your end other than the timing workaround.

Ajay Patwardhan


On Mon, Jun 22, 2020 at 4:20 PM Aaron (Ari) Engel <ar...@pi...> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Hi, I am seeing that my quickfixj client disconnects immediately after
> sending a logout request (35=5) to the server, but I believe FIX protocol
> states that it should wait for the logout response (35=5) from the server
> before disconnecting. Is that correct? Should it be waiting? Is there
> something wrong with my setup that is causing this? Note I am using an old
> version of quickfixj (1.3.X) but I dont know if that impacts this. Any
> guidance? Thanks!
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Quickfixj client disconnecting immediately after sending logout instead of waiting for logout response?

[Grant B. <gbi...@co...>]

Answers in order:
* Yes, you are correct.
* Yes, your app should wait.
* Don't know if there's something wrong with your setup, because we don't
know anything about your setup.
* Upgrading might help, if this is due to some old bug that was fixed long
ago.  In fact, I'd say that's a strong possibility, because 1.3 is not just
old, it's *very* old.  It's 12 years old!

Or there's an outside chance that your counterparty is misbehaving.  Is it
possible that they're killing the connection as soon as they receive your
logout instead of sending a logout back?  I'm not saying this is likely
(though I have seen some counterparties do dumb stuff), but it's not
impossible.

-Grant



On Mon, Jun 22, 2020 at 4:20 PM Aaron (Ari) Engel <ar...@pi...> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Hi, I am seeing that my quickfixj client disconnects immediately after
> sending a logout request (35=5) to the server, but I believe FIX protocol
> states that it should wait for the logout response (35=5) from the server
> before disconnecting. Is that correct? Should it be waiting? Is there
> something wrong with my setup that is causing this? Note I am using an old
> version of quickfixj (1.3.X) but I dont know if that impacts this. Any
> guidance? Thanks!
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com

-- 
This email, along with any attachments, is confidential. If you believe you 
received this message in error, please contact the sender immediately and 
delete all copies of the message. Thank you from Connamara Systems, LLC.

[Quickfixj-users] Quickfixj client disconnecting immediately after sending logout instead of waiting for logout response?

[Aaron (A. E. <ar...@pi...>]

Hi, I am seeing that my quickfixj client disconnects immediately after
sending a logout request (35=5) to the server, but I believe FIX protocol
states that it should wait for the logout response (35=5) from the server
before disconnecting. Is that correct? Should it be waiting? Is there
something wrong with my setup that is causing this? Note I am using an old
version of quickfixj (1.3.X) but I dont know if that impacts this. Any
guidance? Thanks!