You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph J. <chr...@ma...> - 2021-11-12 12:11:37
|
Hi, these releases include a bug fix for an issue which could render your application unusable on reception of a malformed message. Please consider upgrading especially when your application is publicly accessible. Release notes can be found here: https://github.com/quickfix-j/quickfixj/wiki/QFJ-2.2.1-and-2.3.1-release-notes Release can be downloaded from here: https://github.com/quickfix-j/quickfixj/releases/download/QFJ_RELEASE_2_3_1/org.quickfixj-2.3.1-bin.zip or https://github.com/quickfix-j/quickfixj/releases/download/QFJ_RELEASE_2_2_1/org.quickfixj-2.2.1-bin.zip Cheers, Chris. -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Felipe W. <fel...@gm...> - 2021-10-12 14:17:28
|
Colin, Thanks for your advice. Regards, Felipe Windmoller Em ter, 12 de out de 2021 10:41, Colin DuPlantis <co...@ma...> escreveu: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Just to add, don’t put too much effort into duplicating what QFJ already > does. It’s fine to make sure your app processed all the messages without > error, but, QFJ already makes sure that all messages have been sent by the > counter, so, put your “we read the message” check after your business > processes the message, not just after QFJ receives the message. > > On Oct 12, 2021, at 5:30 AM, Felipe Windmoller <fel...@gm...> > wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello Chris, > > Thanks a lot for your advices! > > I'll store the last read seqnum as you suggested. > > Regards, > Felipe > > Em ter, 12 de out de 2021 09:06, Christoph John <chr...@ma...> > escreveu: > >> Hi Felipe, >> >> IMHO if the one minute schedule is sufficient I'd avoid introducing more >> complexity and go for the data base solution. >> Maybe store the last read seqnum in your app so that you do not read the >> whole table over and over every minute. >> >> Cheers, >> Chris. >> >> >> On 12.10.21 13:28, Felipe Windmoller wrote: >> >> Hello John! >> >> The initial idea was that the application would run after the market was >> closed and then would read all messages of the day using the QFJ LOG table. >> >> But later the business team decided that they wanted the information >> during the day. >> >> Your advice is excellent. It will make things much more simple. >> >> I think I'll configure one schedule, like every 1 minute, to run a task >> that will read the QFJ LOG table and then update our business tables. >> >> Regards, >> Felipe Windmoller >> >> >> >> >> Em ter., 12 de out. de 2021 às 05:40, Christoph John < >> chr...@ma...> escreveu: >> >>> Hi, >>> >>> just one thing that I am asking myself: why doesn't the other >>> application read all messages from the table? ;) >>> Please excuse if this is a dumb question, just was asking myself while >>> reading this. >>> >>> Cheers, >>> Chris. >>> >>> >>> On 11.10.21 23:52, Felipe Windmoller wrote: >>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>> >>> >>> Hello everyone! >>> >>> I'll be happy if any of you could give me some advice about one idea! >>> >>> I have one drop copy session and I must interpret the FIX messages and >>> translate them to business tables. >>> >>> We got a bit worried about doing this in the same application that does >>> the FIX communication with QFJ help. >>> >>> Our worry is that this processing could overhead the application and >>> even crash it in case of some error. >>> >>> The other application would be listening to the Kafka topic, checking >>> the sequence number, and processing the messages. If this application >>> identifies that one message is missing, it would read the FIX LOG table to >>> fill the gap. >>> >>> So, what is your opinion? Is this a reasonable idea or perhaps there are >>> problems here that I wasn't able to see. >>> >>> Thanks a lot, >>> Felipe Henrique Gross Windmoller >>> >>> >>> _______________________________________________ >>> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> >>> >>> -- >>> Christoph John >>> Software Engineering >>> T +49 241 557...@ma... >>> >>> MACD GmbH >>> Oppenhoffallee 103 >>> 52066 Aachen, Germanywww.macd.com >>> >>> Amtsgericht Aachen: HRB 8151 >>> Ust.-Id: DE 813021663 >>> Geschäftsführer: George Macdonald >>> >>> >> -- >> 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 > > > Colin DuPlantis > Chief Architect, Marketcetera > Download, Run, Trade > https://www.marketcetera.com > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
From: Colin D. <co...@ma...> - 2021-10-12 13:40:01
|
Just to add, don’t put too much effort into duplicating what QFJ already does. It’s fine to make sure your app processed all the messages without error, but, QFJ already makes sure that all messages have been sent by the counter, so, put your “we read the message” check after your business processes the message, not just after QFJ receives the message. > On Oct 12, 2021, at 5:30 AM, Felipe Windmoller <fel...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello Chris, > > Thanks a lot for your advices! > > I'll store the last read seqnum as you suggested. > > Regards, > Felipe > > Em ter, 12 de out de 2021 09:06, Christoph John <chr...@ma... <mailto:chr...@ma...>> escreveu: > Hi Felipe, > > IMHO if the one minute schedule is sufficient I'd avoid introducing more complexity and go for the data base solution. > Maybe store the last read seqnum in your app so that you do not read the whole table over and over every minute. > > Cheers, > Chris. > > > On 12.10.21 13:28, Felipe Windmoller wrote: >> Hello John! >> >> The initial idea was that the application would run after the market was closed and then would read all messages of the day using the QFJ LOG table. >> >> But later the business team decided that they wanted the information during the day. >> >> Your advice is excellent. It will make things much more simple. >> >> I think I'll configure one schedule, like every 1 minute, to run a task that will read the QFJ LOG table and then update our business tables. >> >> Regards, >> Felipe Windmoller >> >> >> >> >> Em ter., 12 de out. de 2021 às 05:40, Christoph John <chr...@ma... <mailto:chr...@ma...>> escreveu: >> Hi, >> >> just one thing that I am asking myself: why doesn't the other application read all messages from the table? ;) >> Please excuse if this is a dumb question, just was asking myself while reading this. >> >> Cheers, >> Chris. >> >> >> On 11.10.21 23:52, Felipe Windmoller wrote: >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/> >>> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >>> >>> >>> >>> >>> Hello everyone! >>> >>> I'll be happy if any of you could give me some advice about one idea! >>> >>> I have one drop copy session and I must interpret the FIX messages and translate them to business tables. >>> >>> We got a bit worried about doing this in the same application that does the FIX communication with QFJ help. >>> >>> Our worry is that this processing could overhead the application and even crash it in case of some error. >>> >>> The other application would be listening to the Kafka topic, checking the sequence number, and processing the messages. If this application identifies that one message is missing, it would read the FIX LOG table to fill the gap. >>> >>> So, what is your opinion? Is this a reasonable idea or perhaps there are problems here that I wasn't able to see. >>> >>> Thanks a lot, >>> Felipe Henrique Gross Windmoller >>> >>> >>> >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... <mailto:Qui...@li...> >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> >> >> -- >> Christoph John >> Software Engineering >> T +49 241 557080-28 >> chr...@ma... <mailto:chr...@ma...> >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germany >> www.macd.com <http://www.macd.com/> >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com/> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade https://www.marketcetera.com |
From: Felipe W. <fel...@gm...> - 2021-10-12 12:32:32
|
Hello Chris, Thanks a lot for your advices! I'll store the last read seqnum as you suggested. Regards, Felipe Em ter, 12 de out de 2021 09:06, Christoph John <chr...@ma...> escreveu: > Hi Felipe, > > IMHO if the one minute schedule is sufficient I'd avoid introducing more > complexity and go for the data base solution. > Maybe store the last read seqnum in your app so that you do not read the > whole table over and over every minute. > > Cheers, > Chris. > > > On 12.10.21 13:28, Felipe Windmoller wrote: > > Hello John! > > The initial idea was that the application would run after the market was > closed and then would read all messages of the day using the QFJ LOG table. > > But later the business team decided that they wanted the information > during the day. > > Your advice is excellent. It will make things much more simple. > > I think I'll configure one schedule, like every 1 minute, to run a task > that will read the QFJ LOG table and then update our business tables. > > Regards, > Felipe Windmoller > > > > > Em ter., 12 de out. de 2021 às 05:40, Christoph John < > chr...@ma...> escreveu: > >> Hi, >> >> just one thing that I am asking myself: why doesn't the other application >> read all messages from the table? ;) >> Please excuse if this is a dumb question, just was asking myself while >> reading this. >> >> Cheers, >> Chris. >> >> >> On 11.10.21 23:52, Felipe Windmoller wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hello everyone! >> >> I'll be happy if any of you could give me some advice about one idea! >> >> I have one drop copy session and I must interpret the FIX messages and >> translate them to business tables. >> >> We got a bit worried about doing this in the same application that does >> the FIX communication with QFJ help. >> >> Our worry is that this processing could overhead the application and even >> crash it in case of some error. >> >> The other application would be listening to the Kafka topic, checking the >> sequence number, and processing the messages. If this application >> identifies that one message is missing, it would read the FIX LOG table to >> fill the gap. >> >> So, what is your opinion? Is this a reasonable idea or perhaps there are >> problems here that I wasn't able to see. >> >> Thanks a lot, >> Felipe Henrique Gross Windmoller >> >> >> _______________________________________________ >> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> >> -- >> Christoph John >> Software Engineering >> T +49 241 557...@ma... >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germanywww.macd.com >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> >> > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-10-12 12:06:34
|
Hi Felipe, IMHO if the one minute schedule is sufficient I'd avoid introducing more complexity and go for the data base solution. Maybe store the last read seqnum in your app so that you do not read the whole table over and over every minute. Cheers, Chris. On 12.10.21 13:28, Felipe Windmoller wrote: > Hello John! > > The initial idea was that the application would run after the market was closed and then would > read all messages of the day using the QFJ LOG table. > > But later the business team decided that they wanted the information during the day. > > Your advice is excellent. It will make things much more simple. > > I think I'll configure one schedule, like every 1 minute, to run a task that will read the QFJ LOG > table and then update our business tables. > > Regards, > Felipe Windmoller > > > > > Em ter., 12 de out. de 2021 às 05:40, Christoph John <chr...@ma... > <mailto:chr...@ma...>> escreveu: > > Hi, > > just one thing that I am asking myself: why doesn't the other application read all messages > from the table? ;) > Please excuse if this is a dumb question, just was asking myself while reading this. > > Cheers, > Chris. > > > On 11.10.21 23:52, Felipe Windmoller wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support:http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> >> Hello everyone! >> >> I'll be happy if any of you could give me some advice about one idea! >> >> I have one drop copy session and I must interpret the FIX messages and translate them to >> business tables. >> >> We got a bit worried about doing this in the same application that does the FIX communication >> with QFJ help. >> >> Our worry is that this processing could overhead the application and even crash it in case of >> some error. >> >> The other application would be listening to the Kafka topic, checking the sequence number, >> and processing the messages. If this application identifies that one message is missing, it >> would read the FIX LOG table to fill the gap. >> >> So, what is your opinion? Is this a reasonable idea or perhaps there are problems here that I >> wasn't able to see. >> >> Thanks a lot, >> Felipe Henrique Gross Windmoller >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Felipe W. <fel...@gm...> - 2021-10-12 11:28:45
|
Hello John! The initial idea was that the application would run after the market was closed and then would read all messages of the day using the QFJ LOG table. But later the business team decided that they wanted the information during the day. Your advice is excellent. It will make things much more simple. I think I'll configure one schedule, like every 1 minute, to run a task that will read the QFJ LOG table and then update our business tables. Regards, Felipe Windmoller Em ter., 12 de out. de 2021 às 05:40, Christoph John < chr...@ma...> escreveu: > Hi, > > just one thing that I am asking myself: why doesn't the other application > read all messages from the table? ;) > Please excuse if this is a dumb question, just was asking myself while > reading this. > > Cheers, > Chris. > > > On 11.10.21 23:52, Felipe Windmoller wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello everyone! > > I'll be happy if any of you could give me some advice about one idea! > > I have one drop copy session and I must interpret the FIX messages and > translate them to business tables. > > We got a bit worried about doing this in the same application that does > the FIX communication with QFJ help. > > Our worry is that this processing could overhead the application and even > crash it in case of some error. > > The other application would be listening to the Kafka topic, checking the > sequence number, and processing the messages. If this application > identifies that one message is missing, it would read the FIX LOG table to > fill the gap. > > So, what is your opinion? Is this a reasonable idea or perhaps there are > problems here that I wasn't able to see. > > Thanks a lot, > Felipe Henrique Gross Windmoller > > > _______________________________________________ > Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-10-12 08:58:30
|
Hi, just one thing that I am asking myself: why doesn't the other application read all messages from the table? ;) Please excuse if this is a dumb question, just was asking myself while reading this. Cheers, Chris. On 11.10.21 23:52, Felipe Windmoller wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello everyone! > > I'll be happy if any of you could give me some advice about one idea! > > I have one drop copy session and I must interpret the FIX messages and translate them to business > tables. > > We got a bit worried about doing this in the same application that does the FIX communication with > QFJ help. > > Our worry is that this processing could overhead the application and even crash it in case of some > error. > > The other application would be listening to the Kafka topic, checking the sequence number, and > processing the messages. If this application identifies that one message is missing, it would read > the FIX LOG table to fill the gap. > > So, what is your opinion? Is this a reasonable idea or perhaps there are problems here that I > wasn't able to see. > > Thanks a lot, > Felipe Henrique Gross Windmoller > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Felipe W. <fel...@gm...> - 2021-10-11 21:53:23
|
Hello everyone! I'll be happy if any of you could give me some advice about one idea! I have one drop copy session and I must interpret the FIX messages and translate them to business tables. We got a bit worried about doing this in the same application that does the FIX communication with QFJ help. Our worry is that this processing could overhead the application and even crash it in case of some error. The other application would be listening to the Kafka topic, checking the sequence number, and processing the messages. If this application identifies that one message is missing, it would read the FIX LOG table to fill the gap. So, what is your opinion? Is this a reasonable idea or perhaps there are problems here that I wasn't able to see. Thanks a lot, Felipe Henrique Gross Windmoller |
From: Christoph J. <chr...@ma...> - 2021-08-28 22:18:15
|
Hi Vipin, sorry, did not notice that the method is not public. Then I guess your best bet is to use reflection to get access to the IoSession in the Responder. Cheers, Chris. On 26.08.21 08:42, Vipin Chaudhary wrote: > HI Christoph, > > getIoSession() method is not public and has a default access identifier. So I am not able to > access this method from my own class. > > Can we get access to IOSession in any other way? or I need to make this method public and need to > compile the code again(which is less preferred). > > What's your thoughts? > > Thanks > Vipin > > > On Sun, Aug 1, 2021 at 3:42 AM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi Vipin, > > you can track the number of scheduled write requests by getting the Responder of a Session via > Session.getResponder(). Then you can do: > ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() > > In theory you could monitor that and throttle something in your application. I've never tried > it but it could work. > > W.r.t. point 3: two minutes sounds like a long timeout to me. However, the sending should be > decoupled from the receiving side. Do you have a log where you can see heartbeats coming in > and get a timeout anyway? > > Cheers, > Chris. > > > On 30.07.21 10:27, Vipin Chaudhary wrote: >> Hi Team, >> >> I have three specific questions regarding throttling QuickFIxj. >> >> 1. Is there a way so that if we use the "MaxScheduledWriteRequests" option and if that value >> is reached then instead of disconnecting, Quickfixj will wait for clearing the Queue. >> 2. Is there any hook where we can track the size of WriteRequestQueue ? >> 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and 2 minute timeout, >> Lets say my writing thread is waiting for write to complete. So during write time would I >> will be able to receive heartbeat/message from my counter party ? I have seen >> "Disconnecting: Timed out waiting for heartbeat " . Is is because my thread is waiting >> for write to complete and not able to receive heartbeat message ? >> >> >> Thanks >> Vipin >> >> On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users >> <qui...@li... <mailto:qui...@li...>> wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> Hi, >> >> please always reply to the group. Other users might have the same problem/question now or >> in the future. >> >> For incoming messages you can pass a high and a low watermark queue limit when >> constructing your >> connector. >> If the high limit is reached the reads from the socket will be suspended and if the low >> limit is >> reached, reads from the socket will be resumed. Of course if the socket buffer will >> overflow the >> connection could be terminated. >> >> Example: >> ThreadedSocketAcceptor.newBuilder() >> .withApplication( acceptorApplication ) >> .withMessageStoreFactory( messageStoreFactory ) >> .withSettings( settings ) >> .withLogFactory( fileLog ) >> .withMessageFactory( messageFactory ) >> .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK ).build(); >> >> For outgoing messages there is the setting MaxScheduledWriteRequests. >> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html >> <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html> >> If there are more than the configured write requests, the session is disconnected. So >> this is no >> real throttling per se but does the trick in most cases. >> >> Cheers, >> Chris. >> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Vipin C. <vip...@gm...> - 2021-08-26 06:43:09
|
HI Christoph, getIoSession() method is not public and has a default access identifier. So I am not able to access this method from my own class. Can we get access to IOSession in any other way? or I need to make this method public and need to compile the code again(which is less preferred). What's your thoughts? Thanks Vipin On Sun, Aug 1, 2021 at 3:42 AM Christoph John <chr...@ma...> wrote: > Hi Vipin, > > you can track the number of scheduled write requests by getting the > Responder of a Session via Session.getResponder(). Then you can do: > ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() > > In theory you could monitor that and throttle something in your > application. I've never tried it but it could work. > > W.r.t. point 3: two minutes sounds like a long timeout to me. However, the > sending should be decoupled from the receiving side. Do you have a log > where you can see heartbeats coming in and get a timeout anyway? > > Cheers, > Chris. > > > On 30.07.21 10:27, Vipin Chaudhary wrote: > > Hi Team, > > I have three specific questions regarding throttling QuickFIxj. > > > 1. Is there a way so that if we use the "MaxScheduledWriteRequests" > option and if that value is reached then instead of disconnecting, > Quickfixj will wait for clearing the Queue. > 2. Is there any hook where we can track the size of WriteRequestQueue ? > 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and > 2 minute timeout, Lets say my writing thread is waiting for write to > complete. So during write time would I will be able to receive > heartbeat/message from my counter party ? I have seen "Disconnecting: > Timed out waiting for heartbeat " . Is is because my thread is waiting > for write to complete and not able to receive heartbeat message ? > > > Thanks > Vipin > > On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users < > qui...@li...> wrote: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ >> >> >> Hi, >> >> please always reply to the group. Other users might have the same >> problem/question now or in the future. >> >> For incoming messages you can pass a high and a low watermark queue limit >> when constructing your >> connector. >> If the high limit is reached the reads from the socket will be suspended >> and if the low limit is >> reached, reads from the socket will be resumed. Of course if the socket >> buffer will overflow the >> connection could be terminated. >> >> Example: >> ThreadedSocketAcceptor.newBuilder() >> .withApplication( >> acceptorApplication ) >> .withMessageStoreFactory( >> messageStoreFactory ) >> .withSettings( settings ) >> .withLogFactory( fileLog ) >> .withMessageFactory( messageFactory >> ) >> .withQueueWatermarks( >> LOW_WATERMARK, HIGH_WATERMARK ).build(); >> >> For outgoing messages there is the setting MaxScheduledWriteRequests. >> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html >> If there are more than the configured write requests, the session is >> disconnected. So this is no >> real throttling per se but does the trick in most cases. >> >> Cheers, >> Chris. >> > > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Grant B. <gbi...@co...> - 2021-08-23 23:28:35
|
UserDefinedStrategy is not a standard FIX message in any version. UserDefinedStrategy is a custom message that ICE invented. If you have it in FIX44, it's probably because someone in your firm manually added it to your FIX44 dictionary (and maybe even regenerated/rebuilt your QF/j engine source). You're talking about receiving one of ICE's custom message types from Nodal.. but that's never going to happen. If Nodal supports strategies, they probably do it differently than ICE does, and will use different messaging structures to do it. Every counterparty has their own set of message/field definitions and a different way of using them. Don't expect anything that works on ICE to work on Nodal. Get ahold of the Nodal FIX connection's documentation and review it thoroughly. -Grant On Mon, Aug 23, 2021 at 5:35 PM Prince Elangiyil <pri...@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/ > > > Hi All, > > I've a QuickFIXJ client which is built on FIX4.4 using QuickFIXJ ver > 1.7.0.5 and it supports "UserDefinedStrategy" messages for ICE. > > But we have a new customer, which wants to use Nodal Exchange and Nodal > only supports FIX5.0 SP2. When I started using FIX50SP2, I realized the > jars have no support for "UserDefinedStrategy" messages. This is causing > my code to break. > Why is that ? Is there no backward compatibility ? > > -- > Prince K. Elangiyil > _______________________________________________ > 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. |
From: Colin D. <co...@ma...> - 2021-08-23 23:22:09
|
I don’t see UserDefinedStrategy as a defined field for FIX4.4. What tag number is it? Could you have created a custom FIX dictionary (or someone else did)? If so, maybe just do the same for FIX50. > On Aug 23, 2021, at 3:34 PM, Prince Elangiyil <pri...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi All, > > I've a QuickFIXJ client which is built on FIX4.4 using QuickFIXJ ver 1.7.0.5 and it supports "UserDefinedStrategy" messages for ICE. > > But we have a new customer, which wants to use Nodal Exchange and Nodal only supports FIX5.0 SP2. When I started using FIX50SP2, I realized the jars have no support for "UserDefinedStrategy" messages. This is causing my code to break. > Why is that ? Is there no backward compatibility ? > > -- > Prince K. Elangiyil > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
From: Prince E. <pri...@gm...> - 2021-08-23 22:35:24
|
Hi All, I've a QuickFIXJ client which is built on FIX4.4 using QuickFIXJ ver 1.7.0.5 and it supports "UserDefinedStrategy" messages for ICE. But we have a new customer, which wants to use Nodal Exchange and Nodal only supports FIX5.0 SP2. When I started using FIX50SP2, I realized the jars have no support for "UserDefinedStrategy" messages. This is causing my code to break. Why is that ? Is there no backward compatibility ? -- Prince K. Elangiyil |
From: Christoph J. <chr...@ma...> - 2021-08-13 14:35:12
|
Hi this will not be done automatically by QFJ. You need to validate that by yourself. Cheers Chris Am 13. August 2021 15:40:30 MESZ schrieb Ajit Gautam <aji...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ |
From: Ajit G. <aji...@gm...> - 2021-08-13 13:40:55
|
Hi, Any idea anyone has related to below query. Regards Ajit Gautam On Thu, Aug 12, 2021, 12:39 Ajit Gautam <aji...@gm...> wrote: > Hi, > > I am using TestMessageIndicator field in my Quickfix/J acceptor for > checking production or test environment. > > I tried below method to check - > Placed TestMessageIndicator value as 'N' in acceptor config. > Passed 'Y' value from initiator. > But, session logon was accepted. > > Is this correct? > > Is there any way to authenticate TestMessageIndicator while session logon > through configuration setting. > > I will appreciate if anyone can give a quick response on this. > > > Regards > Ajit Gautam > |
From: Ajit G. <aji...@gm...> - 2021-08-12 07:09:56
|
Hi, I am using TestMessageIndicator field in my Quickfix/J acceptor for checking production or test environment. I tried below method to check - Placed TestMessageIndicator value as 'N' in acceptor config. Passed 'Y' value from initiator. But, session logon was accepted. Is this correct? Is there any way to authenticate TestMessageIndicator while session logon through configuration setting. I will appreciate if anyone can give a quick response on this. Regards Ajit Gautam |
From: Christoph J. <chr...@ma...> - 2021-08-02 12:08:27
|
Hi Vipin, messages are sent on the thread that calls Session.sendToTarget() or sendRaw() respectively, i.e. this will probably be a thread from your application. Received messages are pushed by the EventHandlingStrategy (either single threaded or thread-per-Session) into a queue where it is either picked up by a single thread or a thread per Session. So I cannot see where incoming Heartbeats should be affected by outgoing messages. But you even said that you could not see Heartbeats in the log when the timeout occured. So the most probable reason is that there really were no Heartbeats received. Probably the underlying connection timed out. Cheers, Chris. On 01.08.21 10:13, Vipin Chaudhary wrote: > Hi Christoph, > > We don't see any heartbeat in incoming log. > My confusion is, do the same thread read and write the messages? Like if the same thread is used > for reading and writing messages then how quickfixj behaves when the thread is waiting for writing. > > Thanks > Vipin > > On Sun, Aug 1, 2021 at 3:42 AM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi Vipin, > > you can track the number of scheduled write requests by getting the Responder of a Session via > Session.getResponder(). Then you can do: > ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() > > In theory you could monitor that and throttle something in your application. I've never tried > it but it could work. > > W.r.t. point 3: two minutes sounds like a long timeout to me. However, the sending should be > decoupled from the receiving side. Do you have a log where you can see heartbeats coming in > and get a timeout anyway? > > Cheers, > Chris. > > > On 30.07.21 10:27, Vipin Chaudhary wrote: >> Hi Team, >> >> I have three specific questions regarding throttling QuickFIxj. >> >> 1. Is there a way so that if we use the "MaxScheduledWriteRequests" option and if that value >> is reached then instead of disconnecting, Quickfixj will wait for clearing the Queue. >> 2. Is there any hook where we can track the size of WriteRequestQueue ? >> 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and 2 minute timeout, >> Lets say my writing thread is waiting for write to complete. So during write time would I >> will be able to receive heartbeat/message from my counter party ? I have seen >> "Disconnecting: Timed out waiting for heartbeat " . Is is because my thread is waiting >> for write to complete and not able to receive heartbeat message ? >> >> >> Thanks >> Vipin >> >> On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users >> <qui...@li... <mailto:qui...@li...>> wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> Hi, >> >> please always reply to the group. Other users might have the same problem/question now or >> in the future. >> >> For incoming messages you can pass a high and a low watermark queue limit when >> constructing your >> connector. >> If the high limit is reached the reads from the socket will be suspended and if the low >> limit is >> reached, reads from the socket will be resumed. Of course if the socket buffer will >> overflow the >> connection could be terminated. >> >> Example: >> ThreadedSocketAcceptor.newBuilder() >> .withApplication( acceptorApplication ) >> .withMessageStoreFactory( messageStoreFactory ) >> .withSettings( settings ) >> .withLogFactory( fileLog ) >> .withMessageFactory( messageFactory ) >> .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK ).build(); >> >> For outgoing messages there is the setting MaxScheduledWriteRequests. >> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html >> <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html> >> If there are more than the configured write requests, the session is disconnected. So >> this is no >> real throttling per se but does the trick in most cases. >> >> Cheers, >> Chris. >> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Vipin C. <vip...@gm...> - 2021-08-01 08:13:24
|
Hi Christoph, We don't see any heartbeat in incoming log. My confusion is, do the same thread read and write the messages? Like if the same thread is used for reading and writing messages then how quickfixj behaves when the thread is waiting for writing. Thanks Vipin On Sun, Aug 1, 2021 at 3:42 AM Christoph John <chr...@ma...> wrote: > Hi Vipin, > > you can track the number of scheduled write requests by getting the > Responder of a Session via Session.getResponder(). Then you can do: > ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() > > In theory you could monitor that and throttle something in your > application. I've never tried it but it could work. > > W.r.t. point 3: two minutes sounds like a long timeout to me. However, the > sending should be decoupled from the receiving side. Do you have a log > where you can see heartbeats coming in and get a timeout anyway? > > Cheers, > Chris. > > > On 30.07.21 10:27, Vipin Chaudhary wrote: > > Hi Team, > > I have three specific questions regarding throttling QuickFIxj. > > > 1. Is there a way so that if we use the "MaxScheduledWriteRequests" > option and if that value is reached then instead of disconnecting, > Quickfixj will wait for clearing the Queue. > 2. Is there any hook where we can track the size of WriteRequestQueue ? > 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and > 2 minute timeout, Lets say my writing thread is waiting for write to > complete. So during write time would I will be able to receive > heartbeat/message from my counter party ? I have seen "Disconnecting: > Timed out waiting for heartbeat " . Is is because my thread is waiting > for write to complete and not able to receive heartbeat message ? > > > Thanks > Vipin > > On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users < > qui...@li...> wrote: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ >> >> >> Hi, >> >> please always reply to the group. Other users might have the same >> problem/question now or in the future. >> >> For incoming messages you can pass a high and a low watermark queue limit >> when constructing your >> connector. >> If the high limit is reached the reads from the socket will be suspended >> and if the low limit is >> reached, reads from the socket will be resumed. Of course if the socket >> buffer will overflow the >> connection could be terminated. >> >> Example: >> ThreadedSocketAcceptor.newBuilder() >> .withApplication( >> acceptorApplication ) >> .withMessageStoreFactory( >> messageStoreFactory ) >> .withSettings( settings ) >> .withLogFactory( fileLog ) >> .withMessageFactory( messageFactory >> ) >> .withQueueWatermarks( >> LOW_WATERMARK, HIGH_WATERMARK ).build(); >> >> For outgoing messages there is the setting MaxScheduledWriteRequests. >> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html >> If there are more than the configured write requests, the session is >> disconnected. So this is no >> real throttling per se but does the trick in most cases. >> >> Cheers, >> Chris. >> > > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-07-31 22:12:54
|
Hi Vipin, you can track the number of scheduled write requests by getting the Responder of a Session via Session.getResponder(). Then you can do: ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() In theory you could monitor that and throttle something in your application. I've never tried it but it could work. W.r.t. point 3: two minutes sounds like a long timeout to me. However, the sending should be decoupled from the receiving side. Do you have a log where you can see heartbeats coming in and get a timeout anyway? Cheers, Chris. On 30.07.21 10:27, Vipin Chaudhary wrote: > Hi Team, > > I have three specific questions regarding throttling QuickFIxj. > > 1. Is there a way so that if we use the "MaxScheduledWriteRequests" option and if that value is > reached then instead of disconnecting, Quickfixj will wait for clearing the Queue. > 2. Is there any hook where we can track the size of WriteRequestQueue ? > 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and 2 minute timeout, Lets say > my writing thread is waiting for write to complete. So during write time would I will be able > to receive heartbeat/message from my counter party ? I have seen "Disconnecting: Timed out > waiting for heartbeat " . Is is because my thread is waiting for write to complete and not > able to receive heartbeat message ? > > > Thanks > Vipin > > On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users > <qui...@li... <mailto:qui...@li...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> > > > Hi, > > please always reply to the group. Other users might have the same problem/question now or in > the future. > > For incoming messages you can pass a high and a low watermark queue limit when constructing your > connector. > If the high limit is reached the reads from the socket will be suspended and if the low limit is > reached, reads from the socket will be resumed. Of course if the socket buffer will overflow the > connection could be terminated. > > Example: > ThreadedSocketAcceptor.newBuilder() > .withApplication( acceptorApplication ) > .withMessageStoreFactory( messageStoreFactory ) > .withSettings( settings ) > .withLogFactory( fileLog ) > .withMessageFactory( messageFactory ) > .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK > ).build(); > > For outgoing messages there is the setting MaxScheduledWriteRequests. > https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html > <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html> > If there are more than the configured write requests, the session is disconnected. So this is no > real throttling per se but does the trick in most cases. > > Cheers, > Chris. > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Vipin C. <vip...@gm...> - 2021-07-30 08:27:59
|
Hi Team, I have three specific questions regarding throttling QuickFIxj. 1. Is there a way so that if we use the "MaxScheduledWriteRequests" option and if that value is reached then instead of disconnecting, Quickfixj will wait for clearing the Queue. 2. Is there any hook where we can track the size of WriteRequestQueue ? 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and 2 minute timeout, Lets say my writing thread is waiting for write to complete. So during write time would I will be able to receive heartbeat/message from my counter party ? I have seen "Disconnecting: Timed out waiting for heartbeat " . Is is because my thread is waiting for write to complete and not able to receive heartbeat message ? Thanks Vipin On Tue, Jul 27, 2021 at 4:20 AM Christoph John via Quickfixj-users < qui...@li...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Hi, > > please always reply to the group. Other users might have the same > problem/question now or in the future. > > For incoming messages you can pass a high and a low watermark queue limit > when constructing your > connector. > If the high limit is reached the reads from the socket will be suspended > and if the low limit is > reached, reads from the socket will be resumed. Of course if the socket > buffer will overflow the > connection could be terminated. > > Example: > ThreadedSocketAcceptor.newBuilder() > .withApplication( > acceptorApplication ) > .withMessageStoreFactory( > messageStoreFactory ) > .withSettings( settings ) > .withLogFactory( fileLog ) > .withMessageFactory( messageFactory ) > .withQueueWatermarks( LOW_WATERMARK, > HIGH_WATERMARK ).build(); > > For outgoing messages there is the setting MaxScheduledWriteRequests. > https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html > If there are more than the configured write requests, the session is > disconnected. So this is no > real throttling per se but does the trick in most cases. > > Cheers, > Chris. > > > > On 26.07.21 16:36, Ajit Gautam wrote: > > Hi Chris, > > > > I want limit for incoming message. > > > > It would be good to know if outgoing stream also has some configuration > throttle limit. > > > > > > Regards > > Ajit Gautam > > > > On Mon, Jul 26, 2021, 16:44 Christoph John <chr...@ma... > > <mailto:chr...@ma...>> wrote: > > > > Hi, > > > > for incoming or outgoing messages?? > > > > Cheers, > > Chris. > > > > On 26.07.21 13:11, Ajit Gautam wrote: > >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ < > http://www.quickfixj.org/documentation/> > >> QuickFIX/J Support:http://www.quickfixj.org/support/ < > http://www.quickfixj.org/support/> > >> > >> > >> > >> Hi, > >> > >> Is there any configuration available for setting the throttle limit > in Quickfix Java? > >> > >> Also, is there any max throttle limit in Quickfix Java. > >> > >> Regards > >> Ajit Gautam > > > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
From: Christoph J. <chr...@ma...> - 2021-07-28 23:20:58
|
Hi, there is nothing unusual about it. Application messages (and Rejects) are getting resent. All other messages are skipped either with a gap fill message or there is a SequenceReset message that sets the sequence number to the next expected one. You can read more about it here: https://www.fixtrading.org/standards/fix-session-layer-online/#message-recovery Hope that helps. Cheers, Chris. On 28.07.21 19:54, Ajit Gautam wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I observed a scenario in quickfix in which resend request is followed by sequence reset. > > I don't get the point of sending sequence reset when missed messages are already delivered in > resend request. > > I may be having some understanding gap. > I will appreciate if anyone can help on understanding. > > Regards > Ajit G > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Colin D. <co...@ma...> - 2021-07-28 18:43:28
|
What is the config setting for the session for the following: - ResetOnLogon - ResetOnLogout - ResetOnDisconnect - ResetOnError Also, please include a sample logon message from the session. On 7/28/21 10:54 AM, Ajit Gautam wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I observed a scenario in quickfix in which resend request is followed > by sequence reset. > > I don't get the point of sending sequence reset when missed messages > are already delivered in resend request. > > I may be having some understanding gap. > I will appreciate if anyone can help on understanding. > > Regards > Ajit G > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |
From: Ajit G. <aji...@gm...> - 2021-07-28 17:54:52
|
Hi, I observed a scenario in quickfix in which resend request is followed by sequence reset. I don't get the point of sending sequence reset when missed messages are already delivered in resend request. I may be having some understanding gap. I will appreciate if anyone can help on understanding. Regards Ajit G |
From: Christoph J. <chr...@ma...> - 2021-07-27 09:14:11
|
Hi, there is no default limit. It has to be configured either in the code (watermark queue) or config (MaxScheduledWriteRequests). Cheers, Chris. On 27.07.21 05:51, Ajit Gautam wrote: > Hi Chris, > > Thanks for your reply. > Is there any default limit available in Quickfix/J for incoming or outgoing messages. > > I am planning to use Quickfix/J libraries and packages to build my own camel project. So, wanted > to know about default throttle limit. > > > Regards > Ajit Gautam > > On Tue, Jul 27, 2021, 04:20 Christoph John via Quickfixj-users > <qui...@li... <mailto:qui...@li...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> > > > Hi, > > please always reply to the group. Other users might have the same problem/question now or in > the future. > > For incoming messages you can pass a high and a low watermark queue limit when constructing your > connector. > If the high limit is reached the reads from the socket will be suspended and if the low limit is > reached, reads from the socket will be resumed. Of course if the socket buffer will overflow the > connection could be terminated. > > Example: > ThreadedSocketAcceptor.newBuilder() > .withApplication( acceptorApplication ) > .withMessageStoreFactory( messageStoreFactory ) > .withSettings( settings ) > .withLogFactory( fileLog ) > .withMessageFactory( messageFactory ) > .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK > ).build(); > > For outgoing messages there is the setting MaxScheduledWriteRequests. > https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html > <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html> > If there are more than the configured write requests, the session is disconnected. So this is no > real throttling per se but does the trick in most cases. > > Cheers, > Chris. > > > > On 26.07.21 16:36, Ajit Gautam wrote: > > Hi Chris, > > > > I want limit for incoming message. > > > > It would be good to know if outgoing stream also has some configuration throttle limit. > > > > > > Regards > > Ajit Gautam > > > > On Mon, Jul 26, 2021, 16:44 Christoph John <chr...@ma... > <mailto:chr...@ma...> > > <mailto:chr...@ma... <mailto:chr...@ma...>>> wrote: > > > > Hi, > > > > for incoming or outgoing messages?? > > > > Cheers, > > Chris. > > > > On 26.07.21 13:11, Ajit Gautam wrote: > >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ > <http://www.quickfixj.org/documentation/> <http://www.quickfixj.org/documentation/ > <http://www.quickfixj.org/documentation/>> > >> QuickFIX/J Support:http://www.quickfixj.org/support/ > <http://www.quickfixj.org/support/> <http://www.quickfixj.org/support/ > <http://www.quickfixj.org/support/>> > >> > >> > >> > >> Hi, > >> > >> Is there any configuration available for setting the throttle limit in Quickfix Java? > >> > >> Also, is there any max throttle limit in Quickfix Java. > >> > >> Regards > >> Ajit Gautam > > > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... <mailto:Qui...@li...> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Ajit G. <aji...@gm...> - 2021-07-27 03:51:34
|
Hi Chris, Thanks for your reply. Is there any default limit available in Quickfix/J for incoming or outgoing messages. I am planning to use Quickfix/J libraries and packages to build my own camel project. So, wanted to know about default throttle limit. Regards Ajit Gautam On Tue, Jul 27, 2021, 04:20 Christoph John via Quickfixj-users < qui...@li...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Hi, > > please always reply to the group. Other users might have the same > problem/question now or in the future. > > For incoming messages you can pass a high and a low watermark queue limit > when constructing your > connector. > If the high limit is reached the reads from the socket will be suspended > and if the low limit is > reached, reads from the socket will be resumed. Of course if the socket > buffer will overflow the > connection could be terminated. > > Example: > ThreadedSocketAcceptor.newBuilder() > .withApplication( > acceptorApplication ) > .withMessageStoreFactory( > messageStoreFactory ) > .withSettings( settings ) > .withLogFactory( fileLog ) > .withMessageFactory( messageFactory ) > .withQueueWatermarks( LOW_WATERMARK, > HIGH_WATERMARK ).build(); > > For outgoing messages there is the setting MaxScheduledWriteRequests. > https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html > If there are more than the configured write requests, the session is > disconnected. So this is no > real throttling per se but does the trick in most cases. > > Cheers, > Chris. > > > > On 26.07.21 16:36, Ajit Gautam wrote: > > Hi Chris, > > > > I want limit for incoming message. > > > > It would be good to know if outgoing stream also has some configuration > throttle limit. > > > > > > Regards > > Ajit Gautam > > > > On Mon, Jul 26, 2021, 16:44 Christoph John <chr...@ma... > > <mailto:chr...@ma...>> wrote: > > > > Hi, > > > > for incoming or outgoing messages?? > > > > Cheers, > > Chris. > > > > On 26.07.21 13:11, Ajit Gautam wrote: > >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ < > http://www.quickfixj.org/documentation/> > >> QuickFIX/J Support:http://www.quickfixj.org/support/ < > http://www.quickfixj.org/support/> > >> > >> > >> > >> Hi, > >> > >> Is there any configuration available for setting the throttle limit > in Quickfix Java? > >> > >> Also, is there any max throttle limit in Quickfix Java. > >> > >> Regards > >> Ajit Gautam > > > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |