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

Re: [Quickfixj-users] Start/Stop session on different time on different days

[Nik G. <nik...@gm...>]

Gaurav,

This is very similar to the question that you asked on September 16...

Hi
> I am trying to setup daily sessions such as
> session starts on Monday 9:30  , ends on Tuesday 9:28
> Starts on Tuesday 9:30 , ends on Wednesday 9:28
> starts on Wed 10:10 and ends on thursday 10:08
> can you please tell how to configure sessions like the above.
> --
> Regards
> Gaurav



which was answered by Philip Whitehouse...

You will need to implement your own SessionSchedule in place of
> DefaultSessionSchedule if you want it to start at different times on
> different days as the current configuration does not support this.
> I’m surprised that it’s a useful feature - most counter parties have
> predictable sessions to cover predictable trading hours.
> Best,
> Philip Whitehouse



The answer is very unlikely to be any different now!


  Nik



On Tue, 6 Oct 2020 at 10:46, Gaurav Kumar <kum...@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/
>
>
> Apologies, I have hit the sent button before completing the email.
>
> I am using quickfixj 2.2.0 along with Camel, one of our
> upstream starts/stop  the session at 21:55/21:53 UTC Mon-Friday, but on Sat
> it stops the session on 23:00 UTC.
> I am using daily session with the configuration like as below
> StartTime=21:55
> StopTime=21:53
> Weekdays= Mon,Tue,Wed,Thur,Fri,Sat.
>
> Now the issue is how do I keep running my session for an extended period
> on Sat, i.e on Sat my session should end on 23:00 instead of 21:53.
>
> Regards
> Gaurav
>
> On Tue, 6 Oct 2020 at 15:07, Gaurav Kumar <kum...@gm...> wrote:
>
>> Hi
>>
>> I am using quickfixj 2.2.0 along with camel, one of our upstrea
>>
>> --
>> Regards
>> Gaurav
>>
>
>
> --
> Regards
> Gaurav
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Start/Stop session on different time on different days

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

QuickFIXJ doesn’t support this out of the box. You’ll have to write your own SessionSchedule implementation.

Best,

Philip Whitehouse

> On 6 Oct 2020, at 10:45, Gaurav Kumar <kum...@gm...> wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> Apologies, I have hit the sent button before completing the email.
> 
> I am using quickfixj 2.2.0 along with Camel, one of our upstream starts/stop  the session at 21:55/21:53 UTC Mon-Friday, but on Sat it stops the session on 23:00 UTC.
> I am using daily session with the configuration like as below
> StartTime=21:55
> StopTime=21:53
> Weekdays= Mon,Tue,Wed,Thur,Fri,Sat.
> 
> Now the issue is how do I keep running my session for an extended period on Sat, i.e on Sat my session should end on 23:00 instead of 21:53.
> 
> Regards
> Gaurav
> 
>> On Tue, 6 Oct 2020 at 15:07, Gaurav Kumar <kum...@gm...> wrote:
>> Hi
>> 
>> I am using quickfixj 2.2.0 along with camel, one of our upstrea
>> 
>> -- 
>> Regards
>> Gaurav
> 
> 
> -- 
> Regards
> Gaurav
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Start/Stop session on different time on different days

[Gaurav K. <kum...@gm...>]

Apologies, I have hit the sent button before completing the email.

I am using quickfixj 2.2.0 along with Camel, one of our
upstream starts/stop  the session at 21:55/21:53 UTC Mon-Friday, but on Sat
it stops the session on 23:00 UTC.
I am using daily session with the configuration like as below
StartTime=21:55
StopTime=21:53
Weekdays= Mon,Tue,Wed,Thur,Fri,Sat.

Now the issue is how do I keep running my session for an extended period on
Sat, i.e on Sat my session should end on 23:00 instead of 21:53.

Regards
Gaurav

On Tue, 6 Oct 2020 at 15:07, Gaurav Kumar <kum...@gm...> wrote:

> Hi
>
> I am using quickfixj 2.2.0 along with camel, one of our upstrea
>
> --
> Regards
> Gaurav
>


-- 
Regards
Gaurav

[Quickfixj-users] Start/Stop session on different time on different days

[Gaurav K. <kum...@gm...>]

Hi

I am using quickfixj 2.2.0 along with camel, one of our upstrea

-- 
Regards
Gaurav

[Quickfixj-users] quickfixj_2.2.0 osgi bundle

[Merly A. T. <mer...@gm...>]

Hi,

Good day!

I'm trying to update the quickfixj library to this new version.
1.  I added the jar file in my osgi bundle, in my bnd file
"import-package", i can see the manifest that quickfix-all_2.2.0 jar was
there, However it seems there are some missing jar "net.sf.saxon" when i
try to run the program.
2. I tried to add the jar (Saxon-HE-9.8.0-4.jar) in my bnd as well and in
my bundle folder. Still missing requirements.

*Log:*
-> ERROR: Bundle org.quickfixj.all [12] Error starting
file:{path}/bundle/quickfixj-all-2.0.0.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
org.quickfixj.all [12]: Unable to resolve 12.0: missing requirement [12.0]
osgi.wiring.package; (osgi.wiring.package=net.sf.saxon))

 Appreciate your help on this matter.

Regards,

Re: [Quickfixj-users] Additional tags in Logon message

[Gaurav K. <kum...@gm...>]

Thanks Chris

I am able to pass tag 96 in logon message without making any changes for
the data type.

Regards
Gaurav

On Thu, 1 Oct 2020 at 14:48, Christoph John <chr...@ma...> wrote:

> Hi,
>
> starting with version 2.2.0 you can indeed set Logon tags per
> configuration using the setting LogonTag.
>
> https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html
> (search for LogonTag)
>
> However, tag 96 is of the "data" type so you need to test if you can pass
> that in as a string through the settings. Depends on how your "data" looks
> like.
>
> Cheers,
> Chris.
>
>
>
>
> On 01.10.20 10:17, Gaurav Kumar wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi
> I am using quickfix 2.2.0 with Camel, and I need to send additional tags
> (95 and 96) in logon message. These are required for one of our upstream
> system.
>
> Is there anyway to include these tags in logon messages using
> configuration.
>
> Regards
> Gaurav
>
>
> --
> Regards
> Gaurav
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

-- 
Regards
Gaurav

Re: [Quickfixj-users] Additional tags in Logon message

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

Hi,

starting with version 2.2.0 you can indeed set Logon tags per configuration using the setting LogonTag.
https://rawgit.com/quickfix-j/quickfixj/master/quickfixj-core/src/main/doc/usermanual/usage/configuration.html 
(search for LogonTag)

However, tag 96 is of the "data" type so you need to test if you can pass that in as a string 
through the settings. Depends on how your "data" looks like.

Cheers,
Chris.




On 01.10.20 10:17, Gaurav Kumar wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi
> I am using quickfix 2.2.0 with Camel, and I need to send additional tags (95 and 96) in logon 
> message. These are required for one of our upstream system.
>
> Is there anyway to include these tags in logon messages using configuration.
>
> Regards
> Gaurav
>
>
> -- 
> Regards
> Gaurav
>
>
> _______________________________________________
> 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] Additional tags in Logon message

[Gaurav K. <kum...@gm...>]

Hi
I am using quickfix 2.2.0 with Camel, and I need to send additional tags
(95 and 96) in logon message. These are required for one of our upstream
system.

Is there anyway to include these tags in logon messages using configuration.

Regards
Gaurav


-- 
Regards
Gaurav

Re: [Quickfixj-users] unsubscribe me

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

Follow the link at the bottom of this email.

On Thu, Sep 24, 2020 at 12:18 PM Vamsi Pinnamaneni <
vam...@we...> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
>
>
> --
> Regards,
> Vamsi Krishna Pinnamaneni
>
> The information contained in this message may be confidential and is
> intended for the addressee only. If you don't think this email is meant for
> you, please let us know. Do not copy or forward the information it
> contains, and delete this email from your system. Any personal views or
> opinions are those of the author and do not necessarily represent those of
> Wealth Objects Limited. This email does not create or vary any contractual
> obligations between Wealth Objects Limited and the addressee.
> _______________________________________________
> 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] unsubscribe me

[Vamsi P. <vam...@we...>]

-- 
Regards,
Vamsi Krishna Pinnamaneni

The information contained in this message may be confidential and is
intended for the addressee only. If you don't think this email is meant for
you, please let us know. Do not copy or forward the information it
contains, and delete this email from your system. Any personal views or
opinions are those of the author and do not necessarily represent those of
Wealth Objects Limited. This email does not create or vary any contractual
obligations between Wealth Objects Limited and the addressee.

Re: [Quickfixj-users] UtcTimestampConverter question

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

I meant it has no native support for the TZ* fields and you will need to parse them as Strings and 
do the conversion yourself.
Of course QFJ has support for the UTC* fields and will convert them for you.

Cheers,
Chris.


On 24.09.20 09:55, Andrew Marlow wrote:
> Hello Christoph,
>
> Many thanks for your quick reply. I am bit confused though. You say that QFJ has no tentative 
> support for these types but it is QFJ that is throwing the exception in the converter. So I am not 
> sure what you mean.
>
> On Thu, 24 Sep 2020 at 00:26, Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi Andrew,
>
>     please be aware that there are fields in FIX which follow the ISO 8601 date convention. The
>     type in that case is either TZTimestamp or TZDateOnly.
>     https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP258/fix_datatypes.html
>     But there are only few fields with these data types. One of them is 1132/TZTransactTime, but I
>     assume that you are talking about tag 60/TransactTime, so yes, that one should be without a
>     "Z" in it.
>
>     QFJ has no native support for these fields but will treat them as String fields.
>
>     Cheers,
>     Chris.
>
>
>     On 23.09.20 19:27, Andrew Marlow wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hello everyone,
>>
>>     I am working on a feed program that connects to an ECN that speaks FIX, so I am using
>>     quickfixj. The protocol is 5.0sp2. I am using the latest version of quickfixj, version 2.2.0.
>>     I am seeing something very strange in the data that comes over. One of the messages has a
>>     transaction time that is supposed to be in UTC. However the data that comes over the wire has
>>     a trailing "Z" after the number of seconds. I presume that "Z" stands for Zulu time,
>>     basically an alias for UTC. That seems wrong to me. If the value is supposed to be in UTC
>>     then there is no need for any characters at the end to denote the timezone even if that
>>     timezone is UTC. quickfix agrees. We are getting a IncorrectDateFormat exception which seems
>>     to be thrown from UtcTimestampConverter.convert. I presumed that the ECN side would be using
>>     quickfixj to assemble the messages that we see and using the same data dictionary that they
>>     have given us, so how on earth can this happen? Any thoughts/ideas will be gratefully received.
>>
>>     -- 
>>     Regards,
>>
>>     Andrew Marlow
>>     http://www.andrewpetermarlow.co.uk
>>
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>

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

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

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

Re: [Quickfixj-users] UtcTimestampConverter question

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

Hello Christoph,

Many thanks for your quick reply. I am bit confused though. You say that
QFJ has no tentative support for these types but it is QFJ that is throwing
the exception in the converter. So I am not sure what you mean.

On Thu, 24 Sep 2020 at 00:26, Christoph John <chr...@ma...>
wrote:

> Hi Andrew,
>
> please be aware that there are fields in FIX which follow the ISO 8601
> date convention. The type in that case is either TZTimestamp or TZDateOnly.
> https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP258/fix_datatypes.html
> But there are only few fields with these data types. One of them is
> 1132/TZTransactTime, but I assume that you are talking about tag
> 60/TransactTime, so yes, that one should be without a "Z" in it.
>
> QFJ has no native support for these fields but will treat them as String
> fields.
>
> Cheers,
> Chris.
>
>
> On 23.09.20 19:27, Andrew Marlow wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hello everyone,
>
> I am working on a feed program that connects to an ECN that speaks FIX, so
> I am using quickfixj. The protocol is 5.0sp2. I am using the latest version
> of quickfixj, version 2.2.0. I am seeing something very strange in the data
> that comes over. One of the messages has a transaction time that is
> supposed to be in UTC. However the data that comes over the wire has a
> trailing "Z" after the number of seconds. I presume that "Z" stands for
> Zulu time, basically an alias for UTC. That seems wrong to me. If the value
> is supposed to be in UTC then there is no need for any characters at the
> end to denote the timezone even if that timezone is UTC. quickfix agrees.
> We are getting a IncorrectDateFormat exception which seems to be thrown
> from UtcTimestampConverter.convert. I presumed that the ECN side would be
> using quickfixj to assemble the messages that we see and using the same
> data dictionary that they have given us, so how on earth can this happen?
> Any thoughts/ideas will be gratefully received.
>
> --
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

-- 
Regards,

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

Re: [Quickfixj-users] UtcTimestampConverter question

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

Hi Andrew,

please be aware that there are fields in FIX which follow the ISO 8601 date convention. The type in 
that case is either TZTimestamp or TZDateOnly.
https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP258/fix_datatypes.html
But there are only few fields with these data types. One of them is 1132/TZTransactTime, but I 
assume that you are talking about tag 60/TransactTime, so yes, that one should be without a "Z" in it.

QFJ has no native support for these fields but will treat them as String fields.

Cheers,
Chris.


On 23.09.20 19:27, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello everyone,
>
> I am working on a feed program that connects to an ECN that speaks FIX, so I am using quickfixj. 
> The protocol is 5.0sp2. I am using the latest version of quickfixj, version 2.2.0. I am seeing 
> something very strange in the data that comes over. One of the messages has a transaction time 
> that is supposed to be in UTC. However the data that comes over the wire has a trailing "Z" after 
> the number of seconds. I presume that "Z" stands for Zulu time, basically an alias for UTC. That 
> seems wrong to me. If the value is supposed to be in UTC then there is no need for any characters 
> at the end to denote the timezone even if that timezone is UTC. quickfix agrees. We are getting a 
> IncorrectDateFormat exception which seems to be thrown from UtcTimestampConverter.convert. I 
> presumed that the ECN side would be using quickfixj to assemble the messages that we see and using 
> the same data dictionary that they have given us, so how on earth can this happen? Any 
> thoughts/ideas will be gratefully received.
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

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

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

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

Re: [Quickfixj-users] Losing time between fromApp calls

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

We rolled a combo DB-backed and in-memory store.

Use MemoryStore as a mix-in in your DB-backed store. It's not 100% 
guaranteed in case of unplanned downtime, but, FIX supports re-sync of 
the session.

This gives you the best of both worlds in 99% of the use-cases.

On 9/23/20 12:43 AM, Florian Leu wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Thanks Chris, the "putting into a queue part" I already had before, 
> the thing was that the time was lost between two consecutive "putting 
> into the queue" calls (which is the only thing I do directly in the 
> fromApp method), which was due to the standard JdbcStore class making 
> an update to the session store table for every sequence number 
> increase, which kind of defeats the purpose of batching together n 
> messages for writing into the DB, when Quickfix/j itself does a DB 
> write after every received message.
>
> However, since a MemoryStore was not a real option for me, because we 
> need to be able to pick up where we left off after a downtime and a 
> secondary server needs to be able to "jump in" if the primary server 
> goes down, my solution in the end was to copy the JdbcStore (and 
> JdbcStoreFactory) classes and adapt them slightly by changing the 
> method storeSequenceNumbers() in a way that it only executes it every 
> n-th time (which I currently set to 25). With that I got a performance 
> increase from about 40msg/s to about 500msg/s throughput. The drawback 
> is obviously that after a crash, the sequence numbers might be off by 
> at most n, but Quickfix/j is able to recover automatically from that 
> via the standard FIX protocol means.
>
> Maybe there's a better way to make the provided JdbcStore perform 
> quick enough, but I didn't find it...
>
>
> On 16.09.2020 23:53, Christoph John wrote:
>> BTW, you could also put the received messages into a queue with a 
>> worker thread.
>> That way the processing is completely decoupled and the subsequent 
>> message can be processed by QFJ immediately.
>>
>> Cheers,
>> Chris.
>>
>>
>> On 10.09.20 23:06, Florian Leu wrote:
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> Thanks a lot for the hint, it turns out the JdbcStoreFactory was the 
>>> "culprit". With a MemoryStoreFactory instead, the performance 
>>> skyrocketed. Now I just need to figure out a way to store the 
>>> sequence numbers elsewhere to protect against a possible downtime...
>>>
>>> On 10.09.2020 19:01, Colin DuPlantis wrote:
>>>> The recommendation is the same, though, attach a profiler to see 
>>>> where the time is being taken.
>>>>
>>>> On 9/10/20 10:00 AM, Florian Leu wrote:
>>>>> Thanks for the reply. Actually the messages arrive very quickly 
>>>>> (thousands inside one second) which I can see because the 
>>>>> Slf4jLogger logs them immediately to my console. It's just the 
>>>>> fromApp() method calls that seem to be delayed with this 20ms gap. 
>>>>> And btw. it's not always exactly 20ms, it varies between 15-30ms, 
>>>>> I just picked a nice example with consistent spacing between the 
>>>>> method calls. So I don't really know what's happening in between 
>>>>> since I don't know what code is running in this gap and therefore 
>>>>> I can't add log statements there.
>>>>>
>>>>> On 10.09.2020 18:05, Colin DuPlantis wrote:
>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>
>>>>>>
>>>>>> We regularly process over 1000 messages/s, so I don't think this 
>>>>>> is some integral limitation to qfj.
>>>>>>
>>>>>> If it were me, I would use a profiling tool like Oracle JMC or 
>>>>>> the like to see what's taking the most cycles.
>>>>>>
>>>>>> At a guess, I would be suspicious of whatever it is that's 
>>>>>> sending the messages. It's such a regular interval that I wonder 
>>>>>> if your source isn't sending messages fast enough.
>>>>>>
>>>>>> In my experience, the network side of qfj takes microseconds to 
>>>>>> handle a message.
>>>>>>
>>>>>> On 9/10/20 1:33 AM, Florian Leu wrote:
>>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>>
>>>>>>>
>>>>>>> Hi everyone
>>>>>>>
>>>>>>> I'm a new user of Quickfix/j and so far the implementation is 
>>>>>>> going well, but now that I started performance testing I 
>>>>>>> realized that it isn't my code in the fromApp calls that is 
>>>>>>> losing time, but it's actually that between every fromApp call 
>>>>>>> I'm losing around 20ms, which limits my throughput to under 
>>>>>>> 50msg/s. I see this by logging at the beginning and at the end 
>>>>>>> of every fromApp call, which shows clearly that the time is lost 
>>>>>>> between the calls and not during the method execution. Can 
>>>>>>> anyone tell me what I might be doing wrong or how I can get 
>>>>>>> Quickfix/j not to pause for 20ms between consecutive fromApp 
>>>>>>> calls, but follow one fromApp call immediately after the last 
>>>>>>> has terminated? Or is there any way to parallelize the fromApp 
>>>>>>> calls (even though the messages all arrive via the same session)?
>>>>>>>
>>>>>>> 2020-09-10 09:00:33.210  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : startFromApp
>>>>>>> 2020-09-10 09:00:33.210  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : endFromApp
>>>>>>> 2020-09-10 09:00:33.230  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : startFromApp
>>>>>>> 2020-09-10 09:00:33.230  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : endFromApp
>>>>>>> 2020-09-10 09:00:33.250  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : startFromApp
>>>>>>> 2020-09-10 09:00:33.250  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : endFromApp
>>>>>>> 2020-09-10 09:00:33.270  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : startFromApp
>>>>>>> 2020-09-10 09:00:33.270  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : endFromApp
>>>>>>> 2020-09-10 09:00:33.290  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : startFromApp
>>>>>>> 2020-09-10 09:00:33.290  INFO 12184 --- [QFJ Message Processor] 
>>>>>>> MyApp    : endFromApp
>>>>>>>
>>>>>>> Thanks for your help and best regards,
>>>>>>> Florian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Quickfixj-users mailing list
>>>>>>> Qui...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>>
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

Re: [Quickfixj-users] UtcTimestampConverter question

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

Yes, my reading of the FIX spec for timestamps suggests including 'Z' 
(which does, indeed, stand for UTC) is incorrect:

Time/date combination represented in UTC (Universal Time Coordinated, 
also known as "GMT") in either YYYYMMDD-HH:MM:SS (whole seconds) or 
YYYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period 
required.

Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 
00-59, SS = 00-5960 (60 only if UTC leap second) (without milliseconds). 
YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 
00-5960 (60 only if UTC leap second), sss=000-999 (indicating milliseconds).

You can certainly tell the counter that they're sending incorrectly 
formatted data. In my experience, that rarely accomplishes much, but, 
it's worth a try. In the meantime, you can retrieve the data as a string 
from the message and perform surgery on it before converting.


On 9/23/20 10:27 AM, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello everyone,
>
> I am working on a feed program that connects to an ECN that speaks 
> FIX, so I am using quickfixj. The protocol is 5.0sp2. I am using the 
> latest version of quickfixj, version 2.2.0. I am seeing something very 
> strange in the data that comes over. One of the messages has a 
> transaction time that is supposed to be in UTC. However the data that 
> comes over the wire has a trailing "Z" after the number of seconds. I 
> presume that "Z" stands for Zulu time, basically an alias for UTC. 
> That seems wrong to me. If the value is supposed to be in UTC then 
> there is no need for any characters at the end to denote the timezone 
> even if that timezone is UTC. quickfix agrees. We are getting a 
> IncorrectDateFormat exception which seems to be thrown from 
> UtcTimestampConverter.convert. I presumed that the ECN side would be 
> using quickfixj to assemble the messages that we see and using the 
> same data dictionary that they have given us, so how on earth can this 
> happen? Any thoughts/ideas will be gratefully received.
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

[Quickfixj-users] UtcTimestampConverter question

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

Hello everyone,

I am working on a feed program that connects to an ECN that speaks FIX, so
I am using quickfixj. The protocol is 5.0sp2. I am using the latest version
of quickfixj, version 2.2.0. I am seeing something very strange in the data
that comes over. One of the messages has a transaction time that is
supposed to be in UTC. However the data that comes over the wire has a
trailing "Z" after the number of seconds. I presume that "Z" stands for
Zulu time, basically an alias for UTC. That seems wrong to me. If the value
is supposed to be in UTC then there is no need for any characters at the
end to denote the timezone even if that timezone is UTC. quickfix agrees.
We are getting a IncorrectDateFormat exception which seems to be thrown
from UtcTimestampConverter.convert. I presumed that the ECN side would be
using quickfixj to assemble the messages that we see and using the same
data dictionary that they have given us, so how on earth can this happen?
Any thoughts/ideas will be gratefully received.

-- 
Regards,

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

Re: [Quickfixj-users] Losing time between fromApp calls

[Florian L. <fl...@un...>]

Thanks Chris, the "putting into a queue part" I already had before, the 
thing was that the time was lost between two consecutive "putting into 
the queue" calls (which is the only thing I do directly in the fromApp 
method), which was due to the standard JdbcStore class making an update 
to the session store table for every sequence number increase, which 
kind of defeats the purpose of batching together n messages for writing 
into the DB, when Quickfix/j itself does a DB write after every received 
message.

However, since a MemoryStore was not a real option for me, because we 
need to be able to pick up where we left off after a downtime and a 
secondary server needs to be able to "jump in" if the primary server 
goes down, my solution in the end was to copy the JdbcStore (and 
JdbcStoreFactory) classes and adapt them slightly by changing the method 
storeSequenceNumbers() in a way that it only executes it every n-th time 
(which I currently set to 25). With that I got a performance increase 
from about 40msg/s to about 500msg/s throughput. The drawback is 
obviously that after a crash, the sequence numbers might be off by at 
most n, but Quickfix/j is able to recover automatically from that via 
the standard FIX protocol means.

Maybe there's a better way to make the provided JdbcStore perform quick 
enough, but I didn't find it...


On 16.09.2020 23:53, Christoph John wrote:
> BTW, you could also put the received messages into a queue with a 
> worker thread.
> That way the processing is completely decoupled and the subsequent 
> message can be processed by QFJ immediately.
>
> Cheers,
> Chris.
>
>
> On 10.09.20 23:06, Florian Leu wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Thanks a lot for the hint, it turns out the JdbcStoreFactory was the 
>> "culprit". With a MemoryStoreFactory instead, the performance 
>> skyrocketed. Now I just need to figure out a way to store the 
>> sequence numbers elsewhere to protect against a possible downtime...
>>
>> On 10.09.2020 19:01, Colin DuPlantis wrote:
>>> The recommendation is the same, though, attach a profiler to see 
>>> where the time is being taken.
>>>
>>> On 9/10/20 10:00 AM, Florian Leu wrote:
>>>> Thanks for the reply. Actually the messages arrive very quickly 
>>>> (thousands inside one second) which I can see because the 
>>>> Slf4jLogger logs them immediately to my console. It's just the 
>>>> fromApp() method calls that seem to be delayed with this 20ms gap. 
>>>> And btw. it's not always exactly 20ms, it varies between 15-30ms, I 
>>>> just picked a nice example with consistent spacing between the 
>>>> method calls. So I don't really know what's happening in between 
>>>> since I don't know what code is running in this gap and therefore I 
>>>> can't add log statements there.
>>>>
>>>> On 10.09.2020 18:05, Colin DuPlantis wrote:
>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>> We regularly process over 1000 messages/s, so I don't think this 
>>>>> is some integral limitation to qfj.
>>>>>
>>>>> If it were me, I would use a profiling tool like Oracle JMC or the 
>>>>> like to see what's taking the most cycles.
>>>>>
>>>>> At a guess, I would be suspicious of whatever it is that's sending 
>>>>> the messages. It's such a regular interval that I wonder if your 
>>>>> source isn't sending messages fast enough.
>>>>>
>>>>> In my experience, the network side of qfj takes microseconds to 
>>>>> handle a message.
>>>>>
>>>>> On 9/10/20 1:33 AM, Florian Leu wrote:
>>>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>>>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>>>>
>>>>>>
>>>>>> Hi everyone
>>>>>>
>>>>>> I'm a new user of Quickfix/j and so far the implementation is 
>>>>>> going well, but now that I started performance testing I realized 
>>>>>> that it isn't my code in the fromApp calls that is losing time, 
>>>>>> but it's actually that between every fromApp call I'm losing 
>>>>>> around 20ms, which limits my throughput to under 50msg/s. I see 
>>>>>> this by logging at the beginning and at the end of every fromApp 
>>>>>> call, which shows clearly that the time is lost between the calls 
>>>>>> and not during the method execution. Can anyone tell me what I 
>>>>>> might be doing wrong or how I can get Quickfix/j not to pause for 
>>>>>> 20ms between consecutive fromApp calls, but follow one fromApp 
>>>>>> call immediately after the last has terminated? Or is there any 
>>>>>> way to parallelize the fromApp calls (even though the messages 
>>>>>> all arrive via the same session)?
>>>>>>
>>>>>> 2020-09-10 09:00:33.210  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : startFromApp
>>>>>> 2020-09-10 09:00:33.210  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : endFromApp
>>>>>> 2020-09-10 09:00:33.230  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : startFromApp
>>>>>> 2020-09-10 09:00:33.230  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : endFromApp
>>>>>> 2020-09-10 09:00:33.250  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : startFromApp
>>>>>> 2020-09-10 09:00:33.250  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : endFromApp
>>>>>> 2020-09-10 09:00:33.270  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : startFromApp
>>>>>> 2020-09-10 09:00:33.270  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : endFromApp
>>>>>> 2020-09-10 09:00:33.290  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : startFromApp
>>>>>> 2020-09-10 09:00:33.290  INFO 12184 --- [QFJ Message Processor] 
>>>>>> MyApp    : endFromApp
>>>>>>
>>>>>> Thanks for your help and best regards,
>>>>>> Florian
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Quickfixj-users mailing list
>>>>>> Qui...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>>>>
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

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

When I compare the description in the bug ticket to your description it looks like the same issue to 
me, especially considering the following:
* Logon from counterparty has higher seqnum than expected and is queued
* the order of resend requests (first your side, then theirs)
* In the bug ticket the resend request from the counterparty has seqnum 7 which later incorrectly is 
the expected seqnum although it should be 8. Hence all incoming messages are queued. This matches 
your statement of "at the end they have began sending messages with a 34 that’s 1 more than the 34 
they used with their resend request earlier.".

But eventually a message log would probably be best to check if it is the same issue.

What do you think?

Cheers,
Chris.


On 22.09.20 03:05, Robert Nicholson wrote:
> In my example I’m not the one satisfying the resend request. I’m the initiator.
>
> I’m the one who sent it because of the detected gap.
>
> Do you still think that bug is related to my scenario?
>
>> On Sep 21, 2020, at 6:04 PM, Christoph John <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>> Hi,
>>
>> sounds like this bug to me: https://www.quickfixj.org/jira/browse/QFJ-673
>> This is fixed in 1.6.0.
>>
>> Cheers,
>> Chris.
>>
>> On 21.09.20 19:30, Robert Nicholson wrote:
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>> So it seems that Quickfixj is suppose to consider the resend request satisfied when it processes a message that’s higher than the end range (16=0 but it’s recorded the range)  of the resend request.
>>>
>>> On this occasion it did that but didn’t consider the resend request satisfied.
>>>
>>>> On Sep 21, 2020, at 9:00 AM, Robert Nicholson<rob...@gm...>  wrote:
>>>>
>>>> I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.
>>>>
>>>> This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.
>>>>
>>>> In the latest episode I have an example where
>>>>
>>>> I logon
>>>>
>>>> their logon was queued because it was received out of order after a disconnect.
>>>>
>>>> our end has sent a resend request
>>>>
>>>> their end has sent a resend request
>>>>
>>>> then they begin to satisfy the resend request I made with all those message that have posdup = Y
>>>>
>>>> at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.
>>>>
>>>> There is no sequence reset from them at all.
>>>>
>>>> At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.
>>>>
>>>> The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.
>>>>
>>>> Q. What does quickfixj generally expect to see before it considers a resend request satisfied?
>>> _______________________________________________
>>> 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
>

-- 
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 enqueuing logon and not sure when a resend request is satisfied.

[Robert N. <rob...@gm...>]

That much I get but it keeps track of the requested range and considers the resend request satisfied once it sees a message larger than the range
and then should stop enqueuing the messages.

In this case it received such  message but for some reason it never satisfied the resend request and continued to enqueue everything that was sent
as “current” after the resend request had resent everything in the requested range.

> On Sep 21, 2020, at 10:13 AM, philip <ph...@wh...> wrote:
> 
> In short, it simply expects the next message and stores anything higher. It should tell you what sequence number it's expecting and not been sent:
> 
> https://github.com/quickfix-j/quickfixj/blob/QFJ_RELEASE_1_5_2/core/src/main/java/quickfix/Session.java#L2114
> 
> I do recommend you consider upgrading - there's a couple of resend request bugs fixed - e.g: https://github.com/quickfix-j/quickfixj/pull/48
> 
> Best regards,
> 
> Philip Whitehouse.
> 
> On 2020-09-21 15:00, Robert Nicholson wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> I have an older quickfixj  application that seems to repeatedly have
>> more issues with one vendors traffic than another.
>> This vendor has a custom implementation of their FIX engine and I’m
>> wondering if the problems that result from that are due to quickfixj
>> or their implementation.
>> In the latest episode I have an example where
>> I logon
>> their logon was queued because it was received out of order after a disconnect.
>> our end has sent a resend request
>> their end has sent a resend request
>> then they begin to satisfy the resend request I made with all those
>> message that have posdup = Y
>> at the end they have began sending messages with a 34 that’s 1 more
>> than the 34 they used with their resend request earlier.
>> There is no sequence reset from them at all.
>> At the point quickfixj still doesn’t consider the resend request
>> satisfied and is continuing to enqueue every subsequent message.
>> The version used is older 1.52 with custom patches including the
>> recursive resend request handling to avoid stack overflow.
>> Q. What does quickfixj generally expect to see before it considers a
>> resend request satisfied?
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

[Robert N. <rob...@gm...>]

In my example I’m not the one satisfying the resend request. I’m the initiator.

I’m the one who sent it because of the detected gap.

Do you still think that bug is related to my scenario?

> On Sep 21, 2020, at 6:04 PM, Christoph John <chr...@ma...> wrote:
> 
> Hi,
> 
> sounds like this bug to me: https://www.quickfixj.org/jira/browse/QFJ-673 <https://www.quickfixj.org/jira/browse/QFJ-673>
> This is fixed in 1.6.0.
> 
> Cheers,
> Chris.
> 
> On 21.09.20 19:30, Robert Nicholson wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/>
>> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>> 
>> 
>> So it seems that Quickfixj is suppose to consider the resend request satisfied when it processes a message that’s higher than the end range (16=0 but it’s recorded the range)  of the resend request.
>> 
>> On this occasion it did that but didn’t consider the resend request satisfied.
>> 
>>> On Sep 21, 2020, at 9:00 AM, Robert Nicholson <rob...@gm...> <mailto:rob...@gm...> wrote:
>>> 
>>> I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.
>>> 
>>> This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.
>>> 
>>> In the latest episode I have an example where
>>> 
>>> I logon
>>> 
>>> their logon was queued because it was received out of order after a disconnect.
>>> 
>>> our end has sent a resend request
>>> 
>>> their end has sent a resend request
>>> 
>>> then they begin to satisfy the resend request I made with all those message that have posdup = Y 
>>> 
>>> at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.
>>> 
>>> There is no sequence reset from them at all.
>>> 
>>> At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.
>>> 
>>> The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.
>>> 
>>> Q. What does quickfixj generally expect to see before it considers a resend request satisfied?
>> 
>> 
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li... <mailto:Qui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
> 
> -- 
> Christoph John
> Software Engineering
> T +49 241 557080-28
> chr...@ma... <mailto:chr...@ma...>
> 
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com <http://www.macd.com/>
> 
> Amtsgericht Aachen: HRB 8151 
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

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

Hi,

sounds like this bug to me: https://www.quickfixj.org/jira/browse/QFJ-673
This is fixed in 1.6.0.

Cheers,
Chris.

On 21.09.20 19:30, Robert Nicholson wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> So it seems that Quickfixj is suppose to consider the resend request satisfied when it processes a message that’s higher than the end range (16=0 but it’s recorded the range)  of the resend request.
>
> On this occasion it did that but didn’t consider the resend request satisfied.
>
>> On Sep 21, 2020, at 9:00 AM, Robert Nicholson <rob...@gm...> wrote:
>>
>> I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.
>>
>> This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.
>>
>> In the latest episode I have an example where
>>
>> I logon
>>
>> their logon was queued because it was received out of order after a disconnect.
>>
>> our end has sent a resend request
>>
>> their end has sent a resend request
>>
>> then they begin to satisfy the resend request I made with all those message that have posdup = Y
>>
>> at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.
>>
>> There is no sequence reset from them at all.
>>
>> At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.
>>
>> The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.
>>
>> Q. What does quickfixj generally expect to see before it considers a resend request satisfied?
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

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

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

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

Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

[Robert N. <rob...@gm...>]

So it seems that Quickfixj is suppose to consider the resend request satisfied when it processes a message that’s higher than the end range (16=0 but it’s recorded the range)  of the resend request.

On this occasion it did that but didn’t consider the resend request satisfied.

> On Sep 21, 2020, at 9:00 AM, Robert Nicholson <rob...@gm...> wrote:
> 
> I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.
> 
> This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.
> 
> In the latest episode I have an example where
> 
> I logon
> 
> their logon was queued because it was received out of order after a disconnect.
> 
> our end has sent a resend request
> 
> their end has sent a resend request
> 
> then they begin to satisfy the resend request I made with all those message that have posdup = Y 
> 
> at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.
> 
> There is no sequence reset from them at all.
> 
> At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.
> 
> The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.
> 
> Q. What does quickfixj generally expect to see before it considers a resend request satisfied?

Re: [Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

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

In short, it simply expects the next message and stores anything higher. 
It should tell you what sequence number it's expecting and not been 
sent:

https://github.com/quickfix-j/quickfixj/blob/QFJ_RELEASE_1_5_2/core/src/main/java/quickfix/Session.java#L2114

I do recommend you consider upgrading - there's a couple of resend 
request bugs fixed - e.g: 
https://github.com/quickfix-j/quickfixj/pull/48

Best regards,

Philip Whitehouse.

On 2020-09-21 15:00, Robert Nicholson wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> I have an older quickfixj  application that seems to repeatedly have
> more issues with one vendors traffic than another.
> 
> This vendor has a custom implementation of their FIX engine and I’m
> wondering if the problems that result from that are due to quickfixj
> or their implementation.
> 
> In the latest episode I have an example where
> 
> I logon
> 
> their logon was queued because it was received out of order after a 
> disconnect.
> 
> our end has sent a resend request
> 
> their end has sent a resend request
> 
> then they begin to satisfy the resend request I made with all those
> message that have posdup = Y
> 
> at the end they have began sending messages with a 34 that’s 1 more
> than the 34 they used with their resend request earlier.
> 
> There is no sequence reset from them at all.
> 
> At the point quickfixj still doesn’t consider the resend request
> satisfied and is continuing to enqueue every subsequent message.
> 
> The version used is older 1.52 with custom patches including the
> recursive resend request handling to avoid stack overflow.
> 
> Q. What does quickfixj generally expect to see before it considers a
> resend request satisfied?
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

[Quickfixj-users] Quickfixj enqueuing logon and not sure when a resend request is satisfied.

[Robert N. <rob...@gm...>]

I have an older quickfixj  application that seems to repeatedly have more issues with one vendors traffic than another.

This vendor has a custom implementation of their FIX engine and I’m wondering if the problems that result from that are due to quickfixj or their implementation.

In the latest episode I have an example where

I logon

their logon was queued because it was received out of order after a disconnect.

our end has sent a resend request

their end has sent a resend request

then they begin to satisfy the resend request I made with all those message that have posdup = Y 

at the end they have began sending messages with a 34 that’s 1 more than the 34 they used with their resend request earlier.

There is no sequence reset from them at all.

At the point quickfixj still doesn’t consider the resend request satisfied and is continuing to enqueue every subsequent message.

The version used is older 1.52 with custom patches including the recursive resend request handling to avoid stack overflow.

Q. What does quickfixj generally expect to see before it considers a resend request satisfied?

Re: [Quickfixj-users] Sequence reset time

[Gaurav K. <kum...@gm...>]

Thanks Philip for your help.

On Thu, 17 Sep 2020 at 19:47, philip <ph...@wh...> wrote:

> At 9:25 a logout will be sent. Between 9:25 and 9:30 no messages will be
> sent. Then at 9:30 a logon will be sent with 34=1.
> This is how FIX is expected to work. Sending sequence resets mid-session
> is not expected behaviour.
>
> You're expected to agree the session window with your counter-party.
> This is a key part of the onboarding process.
>
> Weekly sessions are no different - except because it's a weekly session
> the sequence number resets once a week when the session window ends.
>
> ResetOnLogon mostly exists to deal with a scenario where you don't care
> about missed messages. Again this is agreed with the counter-party. It's
> common in sending live pricing data (rather than say order flow, where a
> missed order/allocation obviously should be re-sent).
>
> On 2020-09-17 15:08, Gaurav Kumar wrote:
> > Also I have weekly session (Sunday -Sat), will it work for daily
> > sessions only?
> >
> > On Thu, 17 Sep 2020 at 19:35, Gaurav Kumar <kum...@gm...>
> > wrote:
> >
> >> I haven't seen reset message generate between start and end time, i
> >> am using quickfix version 1.6.4.
> >> but let say start time is 9:30 and end time is 9:25 , are you saying
> >> that reset sequence can be sent anytime between 9:25 and 9:30?
> >>
> >> On Thu, 17 Sep 2020 at 19:08, philip <ph...@wh...> wrote:
> >>
> >>> With a StartTime and EndTime defined, the session *will* reset
> >>> between
> >>> the EndTime and StartTime.
> >>>
> >>> Is this behaviour not doing what you need it to?
> >>>
> >>> On 2020-09-17 14:29, Gaurav Kumar wrote:
> >>>> QuickFIX/J Documentation:
> >>> http://www.quickfixj.org/documentation/
> >>>> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>>>
> >>>>
> >>>>
> >>>> Hi
> >>>>
> >>>> Is there any way in configuration to define the time of sequence
> >>> reset
> >>>> I know sequence can be rest during logon or logout but  i am
> >>> looking
> >>>> at the configuration like below.
> >>>>
> >>>> Start time : 9:30
> >>>> End time : 9:25
> >>>> Sequence reset : 9:27
> >>>>
> >>>> i don't want to reset the sequence at logon/session start as
> >>> in
> >>>> case application goes down intraday and comes up again then it
> >>> will
> >>>> send logon and ask for sequence reset.
> >>>>
> >>>> Regards
> >>>> Gaurav
> >>>>
> >>>> --
> >>>> Regards
> >>>> Gaurav
> >>>> _______________________________________________
> >>>> Quickfixj-users mailing list
> >>>> Qui...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >>
> >> --
> >> Regards
> >> Gaurav
> >
> > --
> > Regards
> > Gaurav
>


-- 
Regards
Gaurav