Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bartłomiej K. <bar...@gm...> - 2018-01-27 13:00:15
|
Phillip: I could implement some logic to block sending the message out od the session time but this would be vunerable to some race condtions (e.g. I check the session time and if session is logged in and I’m about to sens the message but in the meantime the session was logged out) so I really think it should be done on protocol-handling level. Colin: thank you for good hints, I think I’ll go with implementing custom message store, it’s the closest to the thing I wanted to achieve. Best regards Bartłomiej Kruczyk > Wiadomość napisana przez Colin DuPlantis <co...@ma...> w dniu 26.01.2018, o godz. 18:36: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > You could code your own message store that wraps an existing one and temp persists messages sent out-of-session. You could trigger the messages to be resent on session logon. > >> On 01/26/2018 05:59 AM, Philip Whitehouse wrote: >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> >> >> If you want messages to be sent after a reset you'll have to manage this in your application code. >> >> From: Bartłomiej Kruczyk <bar...@gm...> >> Sent: 26 January 2018 13:47:30 >> To: qui...@li... >> Subject: [Quickfixj-users] Queuing messages between the sessions >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> >> _______________________________________________ >> 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 +1.541.306.6556 > http://www.marketcetera.org > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Colin D. <co...@ma...> - 2018-01-26 17:36:31
|
You could code your own message store that wraps an existing one and temp persists messages sent out-of-session. You could trigger the messages to be resent on session logon. On 01/26/2018 05:59 AM, Philip Whitehouse wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > If you want messages to be sent after a reset you'll have to manage > this in your application code. > > ------------------------------------------------------------------------ > *From:* Bartłomiej Kruczyk <bar...@gm...> > *Sent:* 26 January 2018 13:47:30 > *To:* qui...@li... > *Subject:* [Quickfixj-users] Queuing messages between the sessions > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > <http://www.quickfixj.org/documentation/> > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > 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 +1.541.306.6556 http://www.marketcetera.org |
|
From: Philip W. <Phi...@fl...> - 2018-01-26 17:32:46
|
If you want messages to be sent after a reset you'll have to manage this in your application code. ________________________________ From: Bartłomiej Kruczyk <bar...@gm...> Sent: 26 January 2018 13:47:30 To: qui...@li... Subject: [Quickfixj-users] Queuing messages between the sessions QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: Colin D. <co...@ma...> - 2018-01-26 15:47:31
|
I don't think it's possible to distinguish between "actually sent" and "queued" except indirectly. In both cases, sendMessage will return true. In the case of "actually sent", you should get some kind of reply back from the counter. For example, a new order should return an ER of Pending New status, though this is optional and not all counters will do it. What we do is set a timer and track whether we got some kind of response for an outgoing message. It's not completely deterministic, but it can at least give you a hint. On 01/26/2018 07:26 AM, Bartłomiej Kruczyk wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Thanks for response! > > I have a problem with this approach though, how can I check if message > has been actually sent or that it is queued? > > PS. I think this issue should be stated more clearly in quickfix/j > javadoc. > > z poważaniem > Bartłomiej Kruczyk > > 2018-01-26 15:23 GMT+01:00 Christoph John <chr...@ma... > <mailto:chr...@ma...>>: > > Hi, > > this cannot be done in QFJ itself. Unless you never reset the > sequence numbers automatically. > > Usually this can be achieved by having a sequencing in your stored > data as well. When you send out messages you store the sent > internal sequence "number" (e.g. date plus increasing number). > When the session comes up the next time, you subscribe only the > data that has a higher sequence number than the one that you > already sent out. > > A more brute-force approach could be to have your application > check if there are still messages in the store, waiting to be > sent. If yes, store these messages (memory or disk), reset the > sequence numbers and re-insert these messages into the store. > > I'm sure there are also other ways to tackle this. > > Regards, > Chris. > > > On 26/01/18 14:47, Bartłomiej Kruczyk 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! >> >> I know that quickfix is queueing messages in message store and >> sends them when other party is logged into the session. My >> problem is that when new session starts, the sequence number is >> resetted to 1 and thus messages queued after session end time >> (but before star time) are never being sent to counterparty. Is >> there a way for a quickfix to ensure that the message will always >> been sent, preferably at the begging of the new session? >> >> Best regards >> Bartłomiej Kruczyk >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org!http://sdm.link/slashdot >> >> >> _______________________________________________ >> 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 > Development & Support > T+49 241 557080-28 <tel:+49%20241%2055708028> > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachen > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE813021663 <tel:81%20302%2016%2063> > Geschäftsführer: George Macdonald > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > 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 +1.541.306.6556 http://www.marketcetera.org |
|
From: Bartłomiej K. <bar...@gm...> - 2018-01-26 15:26:41
|
Thanks for response! I have a problem with this approach though, how can I check if message has been actually sent or that it is queued? PS. I think this issue should be stated more clearly in quickfix/j javadoc. z poważaniem Bartłomiej Kruczyk 2018-01-26 15:23 GMT+01:00 Christoph John <chr...@ma...>: > Hi, > > this cannot be done in QFJ itself. Unless you never reset the sequence > numbers automatically. > > Usually this can be achieved by having a sequencing in your stored data > as well. When you send out messages you store the sent internal sequence > "number" (e.g. date plus increasing number). > When the session comes up the next time, you subscribe only the data that has > a higher sequence number than the one that you already sent out. > > A more brute-force approach could be to have your application check if > there are still messages in the store, waiting to be sent. If yes, store > these messages (memory or disk), reset the sequence numbers and re-insert > these messages into the store. > > I'm sure there are also other ways to tackle this. > > Regards, > Chris. > > > On 26/01/18 14:47, Bartłomiej Kruczyk wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hello! > > I know that quickfix is queueing messages in message store and sends them > when other party is logged into the session. My problem is that when new > session starts, the sequence number is resetted to 1 and thus messages > queued after session end time (but before star time) are never being sent > to counterparty. Is there a way for a quickfix to ensure that the message > will always been sent, preferably at the begging of the new session? > > Best regards > Bartłomiej Kruczyk > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > _______________________________________________ > Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > -- > Christoph John > Development & Support > T +49 241 557080-28 <+49%20241%2055708028>chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachenwww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 <81%20302%2016%2063> > Geschäftsführer: George Macdonald > > |
|
From: Christoph J. <chr...@ma...> - 2018-01-26 14:24:09
|
Hi, this cannot be done in QFJ itself. Unless you never reset the sequence numbers automatically. Usually this can be achieved by having a sequencing in your stored data as well. When you send out messages you store the sent internal sequence "number" (e.g. date plus increasing number). When the session comes up the next time, you subscribe only the data that has a higher sequence number than the one that you already sent out. A more brute-force approach could be to have your application check if there are still messages in the store, waiting to be sent. If yes, store these messages (memory or disk), reset the sequence numbers and re-insert these messages into the store. I'm sure there are also other ways to tackle this. Regards, Chris. On 26/01/18 14:47, Bartłomiej Kruczyk wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hello! > > I know that quickfix is queueing messages in message store and sends them when other party is > logged into the session. My problem is that when new session starts, the sequence number is > resetted to 1 and thus messages queued after session end time (but before star time) are never > being sent to counterparty. Is there a way for a quickfix to ensure that the message will always > been sent, preferably at the begging of the new session? > > Best regards > Bartłomiej Kruczyk > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Bartłomiej K. <bar...@gm...> - 2018-01-26 13:47:57
|
Hello! I know that quickfix is queueing messages in message store and sends them when other party is logged into the session. My problem is that when new session starts, the sequence number is resetted to 1 and thus messages queued after session end time (but before star time) are never being sent to counterparty. Is there a way for a quickfix to ensure that the message will always been sent, preferably at the begging of the new session? Best regards Bartłomiej Kruczyk |
|
From: Colin D. <co...@ma...> - 2018-01-23 14:04:37
|
It should be 'StartDay' and 'EndDay' instead of 'StartDate' and 'EndDate', I believe. Your session may be resetting because your local engine thinks it's using daily sessions. On 01/23/2018 04:26 AM, Николай Симонов wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hello! > Hello! > I have next settings: > [DEFAULT] > ConnectionType=initiator > ReconnectInterval=5 > FileStorePath=store > FileLogPath=log > StartDate=sun > EndDate=fri > ResetOnLogout=N > ResetOnLogon=N > ResetOnDisconnect=N > ResetOnError=N > RefreshOnLogon=Y > ... > > [SESSION] > StartTime=21:05:00 > EndTime=20:55:00 > BeginString=FIX.4.3 > HeartBtInt=30 > ... > > On the Sunday it has reset sequence at 21:05. It's ok. > By the server side a sequence number also reseting every Sunday at 21:05. > > But. > I have reset sequience on the monday at 21:05. > I see next: > 20180122-21:05:01.219 : Connecting to 0.0.0.0 on port 21003 > 20180122-21:05:01.221 : Initiated logon request > 20180122-21:05:01.355 : Socket Error: Соединение сброшено другой стороной > 20180122-21:05:01.355 : Disconnecting > 20180122-21:05:06.042 : Connecting to 0.0.0.0 on port 21003 > 20180122-21:05:06.043 : Initiated logon request > 20180122-21:05:06.172 : Socket Error: Соединение сброшено другой стороной > 20180122-21:05:06.172 : Disconnecting > ... > 20180122-22:08:11.768 : MsgSeqNum too high, expecting 748 but received > 3502 > 20180122-22:08:11.769 : Sent ResendRequest FROM: 748 TO: 0 > 20180122-22:08:11.769 : Received ResendRequest FROM: 2251 TO: 0 > 20180122-22:08:11.770 : Sent SequenceReset TO: 2255 > 20180122-22:08:11.813 : Received SequenceReset FROM: 748 TO: 1129 > 20180122-22:08:11.989 : Received SequenceReset FROM: 1131 TO: 1331 > ... > > in messages.current.log > 20180122-21:05:01.221 : > 8=FIX.4.39=8135=A34=149=OME02_00_STP52=20180122-21:05:01.22156=NTPRO98=0108=301408=1.310=116 > > 20180122-21:05:06.043 : > 8=FIX.4.39=8135=A34=249=OME02_00_STP52=20180122-21:05:06.04256=NTPRO98=0108=301408=1.310=123 > > .... > 8=FIX.4.39=011635=549=XXX56=YYYY34=275552=20180122-21:06:09.04758=Incoming > SeqNum = 12 is less than expected = 225110=081 > > > And then previous messages is getting again. > Why? How I can disable reset sequence on the initiator side? > I want to see 3502 seq number or less, but not less then it was before > previous disconnect. > > С уважением, > Николай Симонов > > logo-for-mailservice > > > > andagar.ru <http://andagar.ru/> | Коммерческий директор > tel: +7 (495) 104-30-04 > cell: +7 (926) 625-84-55 > 141078, г. Королев, проспект Королева, 5В, офис 215 > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > 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 +1.541.306.6556 http://www.marketcetera.org |
|
From: Николай С. <nsi...@an...> - 2018-01-23 12:41:42
|
Hello! Hello! I have next settings: [DEFAULT] ConnectionType=initiator ReconnectInterval=5 FileStorePath=store FileLogPath=log StartDate=sun EndDate=fri ResetOnLogout=N ResetOnLogon=N ResetOnDisconnect=N ResetOnError=N RefreshOnLogon=Y ... [SESSION] StartTime=21:05:00 EndTime=20:55:00 BeginString=FIX.4.3 HeartBtInt=30 ... On the Sunday it has reset sequence at 21:05. It's ok. By the server side a sequence number also reseting every Sunday at 21:05. But. I have reset sequience on the monday at 21:05. I see next: 20180122-21:05:01.219 : Connecting to 0.0.0.0 on port 21003 20180122-21:05:01.221 : Initiated logon request 20180122-21:05:01.355 : Socket Error: Соединение сброшено другой стороной 20180122-21:05:01.355 : Disconnecting 20180122-21:05:06.042 : Connecting to 0.0.0.0 on port 21003 20180122-21:05:06.043 : Initiated logon request 20180122-21:05:06.172 : Socket Error: Соединение сброшено другой стороной 20180122-21:05:06.172 : Disconnecting ... 20180122-22:08:11.768 : MsgSeqNum too high, expecting 748 but received 3502 20180122-22:08:11.769 : Sent ResendRequest FROM: 748 TO: 0 20180122-22:08:11.769 : Received ResendRequest FROM: 2251 TO: 0 20180122-22:08:11.770 : Sent SequenceReset TO: 2255 20180122-22:08:11.813 : Received SequenceReset FROM: 748 TO: 1129 20180122-22:08:11.989 : Received SequenceReset FROM: 1131 TO: 1331 ... in messages.current.log 20180122-21:05:01.221 : 8=FIX.4.39=8135=A34=149=OME02_00_STP52=20180122-21:05:01.22156=NTPRO98=0108=301408=1.310=116 20180122-21:05:06.043 : 8=FIX.4.39=8135=A34=249=OME02_00_STP52=20180122-21:05:06.04256=NTPRO98=0108=301408=1.310=123 .... 8=FIX.4.39=011635=549=XXX56=YYYY34=275552=20180122-21:06:09.04758=Incoming SeqNum = 12 is less than expected = 225110=081 And then previous messages is getting again. Why? How I can disable reset sequence on the initiator side? I want to see 3502 seq number or less, but not less then it was before previous disconnect. С уважением, Николай Симонов [logo-for-mailservice] andagar.ru [http://andagar.ru/] | Коммерческий директор tel: +7 (495) 104-30-04 cell: +7 (926) 625-84-55 141078, г. Королев, проспект Королева, 5В, офис 215 |
|
From: Chris B. <cbl...@gm...> - 2018-01-17 19:56:42
|
Ah, you are correct. I had to let the onLogout complete before the isLoggedOn would show false. That's good to know, thanks. On Tue, Jan 16, 2018 at 3:21 PM, Philip Whitehouse < Phi...@fl...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > isLoggedOn should definitely be returning false, although maybe it's not > set false until after the callback returns. > > Have you tried scheduling a task to run, say 10 seconds later and checking > the return value there? > > Philip Whitehouse > > > > From: Chris Blessing > Sent: Tuesday 16 January, 22:59 > Subject: [Quickfixj-users] Detect if a session has been logged out for too > long > To: qui...@li... > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > |
|
From: Philip W. <Phi...@fl...> - 2018-01-17 02:55:15
|
isLoggedOn should definitely be returning false, although maybe it's not set false until after the callback returns. Have you tried scheduling a task to run, say 10 seconds later and checking the return value there? Philip Whitehouse From: Chris Blessing Sent: Tuesday 16 January, 22:59 Subject: [Quickfixj-users] Detect if a session has been logged out for too long To: qui...@li... QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: Chris B. <cbl...@gm...> - 2018-01-16 22:59:14
|
I'm looking for a way to detect when my initiator app loses its connection to the acceptor for an extended period of time without being able to reconnect. I can see the disconnect happen in the onLogout callback, but that happens immediately and I want to give quickfix a chance to reconnect before I start automatically creating trouble tickets. I can start a thread when onLogout happens and wait for a while, but when I check the session's status with isLoggedOn it always returns "true". I even checked it immediately after entering onLogout, but it's still "true". Is there some other way to check the logon status of a session? |
|
From: Vipin C. <vip...@gm...> - 2018-01-11 11:08:43
|
looks this is same scenario reported recently as well. I think you can watch pull request https://github.com/quickfix-j/ quickfixj/pull/152 Thanks Vipin On Thu, Jan 11, 2018 at 3:09 PM, Muhammadh Aadhil <mua...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi All, > > First of all, I'm very new to this forum, if anyone helps me i'll be very > grateful to you guys. > > In an Initiator Session, we do have 2 different SocketConnectHost for Fail > over scenario. With this configuration, we are connected to the sending a > manual Logout request to the session and sending a Logon request. When we > try this scenario, Application tries to logon to the Secondary > Ip(SocketConnectHost1). Our expectation is to continue the Primary > IP(SocketConnectHost). > > [session] > SessionIdentifier=TDWL > ConnectionType=initiator > SenderCompID=SLGM0 > TargetCompID=TDWL > SessionQualifier=TDWL > SocketConnectHost=127.0.0.1 > SocketConnectPort=7000 > SocketConnectHost1=192.168.13.40 > SocketConnectPort1=7000 > HeartBtInt=20 > StartTime=09:20:00 > EndTime=23:15:00 > > > > -- > Sent from: http://quickfix-j.364392.n2.nabble.com/ > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Muhammadh A. <mua...@gm...> - 2018-01-11 09:39:26
|
Hi All, First of all, I'm very new to this forum, if anyone helps me i'll be very grateful to you guys. In an Initiator Session, we do have 2 different SocketConnectHost for Fail over scenario. With this configuration, we are connected to the sending a manual Logout request to the session and sending a Logon request. When we try this scenario, Application tries to logon to the Secondary Ip(SocketConnectHost1). Our expectation is to continue the Primary IP(SocketConnectHost). [session] SessionIdentifier=TDWL ConnectionType=initiator SenderCompID=SLGM0 TargetCompID=TDWL SessionQualifier=TDWL SocketConnectHost=127.0.0.1 SocketConnectPort=7000 SocketConnectHost1=192.168.13.40 SocketConnectPort1=7000 HeartBtInt=20 StartTime=09:20:00 EndTime=23:15:00 -- Sent from: http://quickfix-j.364392.n2.nabble.com/ |
|
From: Philip W. <ph...@wh...> - 2018-01-10 00:59:58
|
<div dir='auto'><div>Java 8.<br><div class="gmail_extra"><br><div class="gmail_quote">On 10 Jan 2018 00:43, Peeyush Sharma <pee...@gm...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What is the minimum java version supported by <span style="font-size:16px">QuickFIX/J 2.0 ?</span><div><br></div><div>Thanks</div><div>Peeyush</div><div><br><div class="elided-text">On Tue, Jan 9, 2018 at 8:38 AM, Guido Medina <span dir="ltr"><<a href="mailto:ox...@gm...">ox...@gm...</a>></span> wrote:<br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/%0d%0aQuickFIX/J">http://www.quickfixj.org/<wbr>documentation/<br> QuickFIX/J</a> Support: <a href="http://www.quickfixj.org/support/">http://www.quickfixj.org/<wbr>support/</a><br> <br> <br> </div></div><br><div dir="ltr"><div style="font-size:small">Runs fine, but I "was" only using FIX 4.4, I had our main application running for weeks with Java 9.</div></div><div><br><div class="elided-text">On 9 January 2018 at 16:02, Qing Guo <span dir="ltr"><<a href="mailto:Qi...@cr...">Qi...@cr...</a>></span> wrote:<br><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/QuickFIX/J">http://www.quickfixj.org/docum<wbr>entation/<br> QuickFIX/J</a> Support: <a href="http://www.quickfixj.org/support/">http://www.quickfixj.org/suppo<wbr>rt/</a><br> <br> <br> <br> <div> <div> <p>Hi,<u></u><u></u></p> <p><u></u> <u></u></p> <p>Is there anybody run QuickFIX/J 2.0 on Java 9 Runtime ? Experience or comments are appreciated .<u></u><u></u></p> <p><u></u> <u></u></p> <p>Thanks,<u></u><u></u></p> <p>Qing<u></u><u></u></p> <p><u></u> <u></u></p> </div> </div> <br>------------------------------<wbr>------------------------------<wbr>------------------<br> Check out the vibrant tech community on one of the world's most<br> engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>______________________________<wbr>_________________<br> Quickfixj-users mailing list<br> <a href="mailto:Qui...@li...">Qui...@li...<wbr>rge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/quickfixj-users">https://lists.sourceforge.net/<wbr>lists/listinfo/quickfixj-users</a><br> <br></blockquote></div><br></div> <br>------------------------------<wbr>------------------------------<wbr>------------------<br> Check out the vibrant tech community on one of the world's most<br> engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot">http://sdm.link/slashdot</a><br>______________________________<wbr>_________________<br> Quickfixj-users mailing list<br> <a href="mailto:Qui...@li...">Quickfixj-users@lists.<wbr>sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/quickfixj-users">https://lists.sourceforge.net/<wbr>lists/listinfo/quickfixj-users</a><br> <br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div>Peeyush</div></div> </div></div> </blockquote></div><br></div></div></div> |
|
From: Peeyush S. <pee...@gm...> - 2018-01-10 00:43:29
|
What is the minimum java version supported by QuickFIX/J 2.0 ? Thanks Peeyush On Tue, Jan 9, 2018 at 8:38 AM, Guido Medina <ox...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Runs fine, but I "was" only using FIX 4.4, I had our main application > running for weeks with Java 9. > > On 9 January 2018 at 16:02, Qing Guo <Qi...@cr...> 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, >> >> >> >> Is there anybody run QuickFIX/J 2.0 on Java 9 Runtime ? Experience or >> comments are appreciated . >> >> >> >> Thanks, >> >> Qing >> >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- Peeyush |
|
From: Guido M. <ox...@gm...> - 2018-01-09 16:38:59
|
Runs fine, but I "was" only using FIX 4.4, I had our main application running for weeks with Java 9. On 9 January 2018 at 16:02, Qing Guo <Qi...@cr...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > > > Is there anybody run QuickFIX/J 2.0 on Java 9 Runtime ? Experience or > comments are appreciated . > > > > Thanks, > > Qing > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > |
|
From: Qing G. <Qi...@cr...> - 2018-01-09 16:17:29
|
Hi, Is there anybody run QuickFIX/J 2.0 on Java 9 Runtime ? Experience or comments are appreciated . Thanks, Qing |
|
From: Robert M. <rm...@ne...> - 2018-01-09 15:16:51
|
John
Thanks for the responses: the reordering of the fields in the repeating group addressed the problem, apparently the message processor in production has more logic to handle the variation in party groups than my current test implementation.
Thanks again
Rob MacKay
From: Christoph John [mailto:chr...@ma...]
Sent: Tuesday, January 9, 2018 7:51 AM
To: Robert MacKay <rm...@ne...>; qui...@li...; Freedman, Jon <Jon...@br...>
Subject: Re: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton
That clearly says that 448/PartyID should come before 447/PartyIDSource. So the error is justified.
Try swapping these fields.
On 09/01/18 15:48, Robert MacKay wrote:
Yes sorry about that, this is the corresponding group definition
<message name="MarketDataRequest" msgtype="V" msgcat="app">
<field name="MDReqID" required="Y" />
<group name="NoPartyIDs" required="N">
<field name="PartyID" required="Y" />
<field name="PartyIDSource" required="Y" />
<field name="PartyRole" required="Y" />
</group>
<field name="Symbol" required="Y" />
<field name="SubscriptionRequestType" required="Y" />
<field name="MarketDepth" required="N" />
<field name="MDUpdateType" required="N" />
<group name="NoRequestedSize" required="N">
<field name="RequestedSize" required="N" />
</group>
<field name="OrdType" required="N"/>
</message>
From: Christoph John [mailto:chr...@ma...]
Sent: Tuesday, January 9, 2018 7:46 AM
To: qui...@li...<mailto:qui...@li...>; Robert MacKay <rm...@ne...><mailto:rm...@ne...>; Freedman, Jon <Jon...@br...><mailto:Jon...@br...>
Subject: Re: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton
Oh yeah, you are listing the part where the fields are defined. But you really should look it up in the component Parties.
On 09/01/18 15:45, Christoph John wrote:
But I think that section from the data dictionary makes no sense. The count tag NoPartyIDs is listed as last item in the component??
Chris.
On 09/01/18 15:42, Christoph John via Quickfixj-users wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Sorry, I misread it. ;)
IIRC you need to regenerate the message code when you want to validate repeating groups with a non-standard order.
On 09/01/18 15:40, Christoph John wrote:
There you have it. The repeating group should start with 448 but starts with 447.
Chris.
On 09/01/18 15:38, Robert MacKay wrote:
This is the corresponding data dictionary section
<field number="447" name="PartyIDSource" type="CHAR">
<value enum="D" description="PROPRIETARY_CUSTOM_CODE" />
</field>
<field number="448" name="PartyID" type="STRING" />
<field number="452" name="PartyRole" type="INT">
<value enum="1" description="EXECUTING_FIRM" />
<value enum="3" description="CLIENT_ID" />
<value enum="35" description="PROVIDER" />
</field>
<field number="453" name="NoPartyIDs" type="NUMINGROUP" />
After upgrading QF/J to 2.0.0 it is failing in a new way
453=1|447=D|448=XX|452=35|
(Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447)
But still failing around repeating party groups.
Thanks
Rob MacKay
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com<http://www.macd.com>
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com<http://www.macd.com>
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com<http://www.macd.com>
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
|
|
From: Christoph J. <chr...@ma...> - 2018-01-09 14:50:56
|
That clearly says that 448/PartyID should come before 447/PartyIDSource. So the error is justified. Try swapping these fields. On 09/01/18 15:48, Robert MacKay wrote: > > Yes sorry about that, this is the corresponding group definition > > <message name="MarketDataRequest" msgtype="V" msgcat="app"> > > <field name="MDReqID" required="Y" /> > > <group name="NoPartyIDs" required="N"> > > <field name="PartyID" required="Y" /> > > <field name="PartyIDSource" required="Y" /> > > <field name="PartyRole" required="Y" /> > > </group> > > <field name="Symbol" required="Y" /> > > <field name="SubscriptionRequestType" required="Y" /> > > <field name="MarketDepth" required="N" /> > > <field name="MDUpdateType" required="N" /> > > <group name="NoRequestedSize" required="N"> > > <field name="RequestedSize" required="N" /> > > </group> > > <field name="OrdType" required="N"/> > > </message> > > *From:*Christoph John [mailto:chr...@ma...] > *Sent:* Tuesday, January 9, 2018 7:46 AM > *To:* qui...@li...; Robert MacKay <rm...@ne...>; Freedman, Jon > <Jon...@br...> > *Subject:* Re: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton > > Oh yeah, you are listing the part where the fields are defined. But you really should look it up > in the component Parties. > > > On 09/01/18 15:45, Christoph John wrote: > > But I think that section from the data dictionary makes no sense. The count tag NoPartyIDs is > listed as last item in the component?? > > Chris. > > On 09/01/18 15:42, Christoph John via Quickfixj-users wrote: > > QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ > > QuickFIX/J Support:http://www.quickfixj.org/support/ > > > > Sorry, I misread it. ;) > IIRC you need to regenerate the message code when you want to validate repeating groups > with a non-standard order. > > On 09/01/18 15:40, Christoph John wrote: > > There you have it. The repeating group should start with 448 but starts with 447. > > Chris. > > On 09/01/18 15:38, Robert MacKay wrote: > > This is the corresponding data dictionary section > > <field number="447" name="PartyIDSource" type="CHAR"> > > <value enum="D" description="PROPRIETARY_CUSTOM_CODE" /> > > </field> > > <field number="448" name="PartyID" type="STRING" /> > > <field number="452" name="PartyRole" type="INT"> > > <value enum="1" description="EXECUTING_FIRM" /> > > <value enum="3" description="CLIENT_ID" /> > > <value enum="35" description="PROVIDER" /> > > </field> > > <field number="453" name="NoPartyIDs" type="NUMINGROUP" /> > > After upgrading QF/J to 2.0.0 it is failing in a new way > > 453=1|447=D|448=XX|452=35| > > (Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447) > > But still failing around repeating party groups. > > > > Thanks > > Rob MacKay > > > > -- > > Christoph John > > Development & Support > > T +49 241 557080-28 > > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > > Oppenhoffallee 103 > > D-52066 Aachen > > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > > Ust.-Id: DE 813021663 > > Geschäftsführer: George Macdonald > > > > -- > Christoph John > Development & Support > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachen > www.macd.com <http://www.macd.com> > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Robert M. <rm...@ne...> - 2018-01-09 14:48:43
|
Yes sorry about that, this is the corresponding group definition
<message name="MarketDataRequest" msgtype="V" msgcat="app">
<field name="MDReqID" required="Y" />
<group name="NoPartyIDs" required="N">
<field name="PartyID" required="Y" />
<field name="PartyIDSource" required="Y" />
<field name="PartyRole" required="Y" />
</group>
<field name="Symbol" required="Y" />
<field name="SubscriptionRequestType" required="Y" />
<field name="MarketDepth" required="N" />
<field name="MDUpdateType" required="N" />
<group name="NoRequestedSize" required="N">
<field name="RequestedSize" required="N" />
</group>
<field name="OrdType" required="N"/>
</message>
From: Christoph John [mailto:chr...@ma...]
Sent: Tuesday, January 9, 2018 7:46 AM
To: qui...@li...; Robert MacKay <rm...@ne...>; Freedman, Jon <Jon...@br...>
Subject: Re: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton
Oh yeah, you are listing the part where the fields are defined. But you really should look it up in the component Parties.
On 09/01/18 15:45, Christoph John wrote:
But I think that section from the data dictionary makes no sense. The count tag NoPartyIDs is listed as last item in the component??
Chris.
On 09/01/18 15:42, Christoph John via Quickfixj-users wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Sorry, I misread it. ;)
IIRC you need to regenerate the message code when you want to validate repeating groups with a non-standard order.
On 09/01/18 15:40, Christoph John wrote:
There you have it. The repeating group should start with 448 but starts with 447.
Chris.
On 09/01/18 15:38, Robert MacKay wrote:
This is the corresponding data dictionary section
<field number="447" name="PartyIDSource" type="CHAR">
<value enum="D" description="PROPRIETARY_CUSTOM_CODE" />
</field>
<field number="448" name="PartyID" type="STRING" />
<field number="452" name="PartyRole" type="INT">
<value enum="1" description="EXECUTING_FIRM" />
<value enum="3" description="CLIENT_ID" />
<value enum="35" description="PROVIDER" />
</field>
<field number="453" name="NoPartyIDs" type="NUMINGROUP" />
After upgrading QF/J to 2.0.0 it is failing in a new way
453=1|447=D|448=XX|452=35|
(Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447)
But still failing around repeating party groups.
Thanks
Rob MacKay
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com<http://www.macd.com>
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com<http://www.macd.com>
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
|
|
From: Christoph J. <chr...@ma...> - 2018-01-09 14:46:18
|
Oh yeah, you are listing the part where the fields are defined. But you really should look it up in the component Parties. On 09/01/18 15:45, Christoph John wrote: > But I think that section from the data dictionary makes no sense. The count tag NoPartyIDs > islisted as last item in the component?? > > Chris. > > > On 09/01/18 15:42, Christoph John via Quickfixj-users wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> >> Sorry, I misread it. ;) >> IIRC you need to regenerate the message code when you want to validate repeating groups with a >> non-standard order. >> >> >> On 09/01/18 15:40, Christoph John wrote: >>> There you have it. The repeating group should start with 448 but starts with 447. >>> >>> Chris. >>> >>> On 09/01/18 15:38, Robert MacKay wrote: >>>> This is the corresponding data dictionary section >>>> <field number="447" name="PartyIDSource" type="CHAR"> >>>> <value enum="D" description="PROPRIETARY_CUSTOM_CODE" /> >>>> </field> >>>> <field number="448" name="PartyID" type="STRING" /> >>>> <field number="452" name="PartyRole" type="INT"> >>>> <value enum="1" description="EXECUTING_FIRM" /> >>>> <value enum="3" description="CLIENT_ID" /> >>>> <value enum="35" description="PROVIDER" /> >>>> </field> >>>> <field number="453" name="NoPartyIDs" type="NUMINGROUP" /> >>>> >>>> >>>> After upgrading QF/J to 2.0.0 it is failing in a new way >>>> 453=1|447=D|448=XX|452=35| >>>> (Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447) >>>> >>>> But still failing around repeating party groups. >>>> >>>> Thanks >>>> Rob MacKay >>>> >>>> > > -- > Christoph John > Development & Support > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachen > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-01-09 14:45:31
|
But I think that section from the data dictionary makes no sense. The count tag NoPartyIDs islisted as last item in the component?? Chris. On 09/01/18 15:42, Christoph John via Quickfixj-users wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Sorry, I misread it. ;) > IIRC you need to regenerate the message code when you want to validate repeating groups with a > non-standard order. > > > On 09/01/18 15:40, Christoph John wrote: >> There you have it. The repeating group should start with 448 but starts with 447. >> >> Chris. >> >> On 09/01/18 15:38, Robert MacKay wrote: >>> This is the corresponding data dictionary section >>> <field number="447" name="PartyIDSource" type="CHAR"> >>> <value enum="D" description="PROPRIETARY_CUSTOM_CODE" /> >>> </field> >>> <field number="448" name="PartyID" type="STRING" /> >>> <field number="452" name="PartyRole" type="INT"> >>> <value enum="1" description="EXECUTING_FIRM" /> >>> <value enum="3" description="CLIENT_ID" /> >>> <value enum="35" description="PROVIDER" /> >>> </field> >>> <field number="453" name="NoPartyIDs" type="NUMINGROUP" /> >>> >>> >>> After upgrading QF/J to 2.0.0 it is failing in a new way >>> 453=1|447=D|448=XX|452=35| >>> (Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447) >>> >>> But still failing around repeating party groups. >>> >>> Thanks >>> Rob MacKay >>> >>> -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-01-09 14:42:53
|
Sorry, I misread it. ;) IIRC you need to regenerate the message code when you want to validate repeating groups with a non-standard order. On 09/01/18 15:40, Christoph John wrote: > There you have it. The repeating group should start with 448 but starts with 447. > > Chris. > > On 09/01/18 15:38, Robert MacKay wrote: >> This is the corresponding data dictionary section >> <field number="447" name="PartyIDSource" type="CHAR"> >> <value enum="D" description="PROPRIETARY_CUSTOM_CODE" /> >> </field> >> <field number="448" name="PartyID" type="STRING" /> >> <field number="452" name="PartyRole" type="INT"> >> <value enum="1" description="EXECUTING_FIRM" /> >> <value enum="3" description="CLIENT_ID" /> >> <value enum="35" description="PROVIDER" /> >> </field> >> <field number="453" name="NoPartyIDs" type="NUMINGROUP" /> >> >> >> After upgrading QF/J to 2.0.0 it is failing in a new way >> 453=1|447=D|448=XX|452=35| >> (Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447) >> >> But still failing around repeating party groups. >> >> Thanks >> Rob MacKay >> >> -----Original Message----- >> From: Robert MacKay >> Sent: Tuesday, January 9, 2018 7:12 AM >> To: 'Freedman, Jon'<Jon...@br...>; 'qui...@li...'<qui...@li...> >> Subject: RE: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton >> >> The repeating group is coming from a production implementation (this work is for a test server), I have the repeating fields group working in an initiator implementation, in building this acceptor the same datadictionary file is not being read or applied by the acceptor. The repeating groups do not match the 4.4 spec specifically because they are customized and defined in the custom datadictionary. The entire problem is that incoming messages are not being evaluated by the custom dictionary. >> >> Thanks >> Rob MacKay >> >> -----Original Message----- >> From: Freedman, Jon [mailto:Jon...@br...] >> Sent: Tuesday, January 9, 2018 12:54 AM >> To: 'qui...@li...'<qui...@li...> >> Cc: Robert MacKay<rm...@ne...> >> Subject: RE: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton >> >> Can you anonymise the data around field 447 and include the Parties repeating groups? I'm sure your FIX counterpart definitely didn't screw up their MiFID II changes... :) >> >> -----Original Message----- >> From: Robert MacKay via Quickfixj-users [mailto:qui...@li...] >> Sent: 08 January 2018 21:34 >> To:qui...@li... >> Cc: Robert MacKay >> Subject: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton >> >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> [default] >> FileStorePath=target/data/executor >> ConnectionType=acceptor >> StartTime=00:00:00 >> EndTime=00:00:00 >> HeartBtInt=30 >> SenderCompID=SNDCOMPID >> TargetCompID=TRGCOMPID >> UseDataDictionary=Y >> DataDictionary=CUST_FIX44.xml >> >> [session] >> SenderCompID=SNDCOMPID >> TargetCompID=TRGCOMPID >> BeginString=FIX.4.4 >> SocketAcceptPort=9001 >> UseDataDictionary=Y >> DataDictionary=CUST_FIX44.xml >> >> Throws this error on incoming custom FIX message: >> >> error> (Rejecting invalid message: quickfix.FieldException: >> Out of order repeating group members, field=447: 8=FIX.4.49=16535=V... >> >> The CUST_FIX44.xml file contains definitions for the repeating groups. >> >> The Custom DataDictionary is not being applied to message validation even though loaded and recognized. When I put in an invalid path before the xml file it throws the not found error at start, the name appears in the SessionSettings object during Application init but is not applied to validation. >> >> Thanks >> Rob MacKay >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!http://sdm.link/slashdot _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> >> >> This email, the information therein and any attached materials (collectively the "Email") are intended only for the addressee(s) and may contain confidential, proprietary, copyrighted and/or privileged material. If you have received this Email in error please delete it and notify the sender immediately. This Email remains the property of Brevan Howard, which reserves the right to require its return (together with any copies or extracts thereof) at any time upon request. Any unauthorised review, retransmission, dissemination, forwarding, printing, copying or other use of this Email is prohibited. Brevan Howard may be legally required to review and retain outgoing and incoming email and produce it to regulatory authorities and others with legal rights to the information. Internet communications cannot be guaranteed to be secure or error free as information could be intercepted, changed corrupted, lost, arrive late or contain viruses. Brevan Howard accepts no liability for any errors or omissions in this Email which arise as a result of internet transmission. This Email is not an official confirmation of any transaction. Any comments or statements made herein do not necessarily reflect the views of Brevan Howard. >> This Email is not an offer to sell or solicitation of an offer to buy any security or investment. It does not constitute or contain any investment advice and is being made without regard to the recipients investment objectives, financial situation or means. Past Performance is not an indicator of future results and Brevan Howard provides no assurance that future results will be consistent with any information provided herein or attached hereto. Brevan Howard and the sender make no warranties regarding the accuracy or completeness of the information in this Email and it should not be relied upon and is subject to change without notice. Brevan Howard and its representatives, officers and employees accept no responsibility for any losses suffered as a result of reliance on the information in this Email or the reliability, accuracy, or completeness thereof. >> In this Email, "Brevan Howard" means Brevan Howard Asset Management LLP ("BHAM"), Brevan Howard Inc., Brevan Howard (Israel) Ltd and their respective affiliates. BHAM is a limited liability partnership authorised and regulated by the Financial Conduct Authority of the United Kingdom and registered in England & Wales (reg. no. OC302636). >> > > -- > Christoph John > Development & Support > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachen > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-01-09 14:40:44
|
There you have it. The repeating group should start with 448 but starts with 447. Chris. On 09/01/18 15:38, Robert MacKay wrote: > This is the corresponding data dictionary section > <field number="447" name="PartyIDSource" type="CHAR"> > <value enum="D" description="PROPRIETARY_CUSTOM_CODE" /> > </field> > <field number="448" name="PartyID" type="STRING" /> > <field number="452" name="PartyRole" type="INT"> > <value enum="1" description="EXECUTING_FIRM" /> > <value enum="3" description="CLIENT_ID" /> > <value enum="35" description="PROVIDER" /> > </field> > <field number="453" name="NoPartyIDs" type="NUMINGROUP" /> > > > After upgrading QF/J to 2.0.0 it is failing in a new way > 453=1|447=D|448=XX|452=35| > (Rejecting invalid message: quickfix.FieldException: The group 453 must set the delimiter field 448:447) > > But still failing around repeating party groups. > > Thanks > Rob MacKay > > -----Original Message----- > From: Robert MacKay > Sent: Tuesday, January 9, 2018 7:12 AM > To: 'Freedman, Jon' <Jon...@br...>; 'qui...@li...' <qui...@li...> > Subject: RE: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton > > The repeating group is coming from a production implementation (this work is for a test server), I have the repeating fields group working in an initiator implementation, in building this acceptor the same datadictionary file is not being read or applied by the acceptor. The repeating groups do not match the 4.4 spec specifically because they are customized and defined in the custom datadictionary. The entire problem is that incoming messages are not being evaluated by the custom dictionary. > > Thanks > Rob MacKay > > -----Original Message----- > From: Freedman, Jon [mailto:Jon...@br...] > Sent: Tuesday, January 9, 2018 12:54 AM > To: 'qui...@li...' <qui...@li...> > Cc: Robert MacKay <rm...@ne...> > Subject: RE: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton > > Can you anonymise the data around field 447 and include the Parties repeating groups? I'm sure your FIX counterpart definitely didn't screw up their MiFID II changes... :) > > -----Original Message----- > From: Robert MacKay via Quickfixj-users [mailto:qui...@li...] > Sent: 08 January 2018 21:34 > To: qui...@li... > Cc: Robert MacKay > Subject: [Quickfixj-users] custom data dictionary not being used on inbound message validaiton > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > [default] > FileStorePath=target/data/executor > ConnectionType=acceptor > StartTime=00:00:00 > EndTime=00:00:00 > HeartBtInt=30 > SenderCompID=SNDCOMPID > TargetCompID=TRGCOMPID > UseDataDictionary=Y > DataDictionary=CUST_FIX44.xml > > [session] > SenderCompID=SNDCOMPID > TargetCompID=TRGCOMPID > BeginString=FIX.4.4 > SocketAcceptPort=9001 > UseDataDictionary=Y > DataDictionary=CUST_FIX44.xml > > Throws this error on incoming custom FIX message: > > error> (Rejecting invalid message: quickfix.FieldException: > Out of order repeating group members, field=447: 8=FIX.4.49=16535=V... > > The CUST_FIX44.xml file contains definitions for the repeating groups. > > The Custom DataDictionary is not being applied to message validation even though loaded and recognized. When I put in an invalid path before the xml file it throws the not found error at start, the name appears in the SessionSettings object during Application init but is not applied to validation. > > Thanks > Rob MacKay > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > > This email, the information therein and any attached materials (collectively the "Email") are intended only for the addressee(s) and may contain confidential, proprietary, copyrighted and/or privileged material. If you have received this Email in error please delete it and notify the sender immediately. This Email remains the property of Brevan Howard, which reserves the right to require its return (together with any copies or extracts thereof) at any time upon request. Any unauthorised review, retransmission, dissemination, forwarding, printing, copying or other use of this Email is prohibited. Brevan Howard may be legally required to review and retain outgoing and incoming email and produce it to regulatory authorities and others with legal rights to the information. Internet communications cannot be guaranteed to be secure or error free as information could be intercepted, changed corrupted, lost, arrive late or contain viruses. Brevan Howard accepts no liability for any errors or omissions in this Email which arise as a result of internet transmission. This Email is not an official confirmation of any transaction. Any comments or statements made herein do not necessarily reflect the views of Brevan Howard. > This Email is not an offer to sell or solicitation of an offer to buy any security or investment. It does not constitute or contain any investment advice and is being made without regard to the recipients investment objectives, financial situation or means. Past Performance is not an indicator of future results and Brevan Howard provides no assurance that future results will be consistent with any information provided herein or attached hereto. Brevan Howard and the sender make no warranties regarding the accuracy or completeness of the information in this Email and it should not be relied upon and is subject to change without notice. Brevan Howard and its representatives, officers and employees accept no responsibility for any losses suffered as a result of reliance on the information in this Email or the reliability, accuracy, or completeness thereof. > In this Email, "Brevan Howard" means Brevan Howard Asset Management LLP ("BHAM"), Brevan Howard Inc., Brevan Howard (Israel) Ltd and their respective affiliates. BHAM is a limited liability partnership authorised and regulated by the Financial Conduct Authority of the United Kingdom and registered in England & Wales (reg. no. OC302636). > -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
103 messages has been excluded from this view by a project administrator.
