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: Егор М. <eg...@gm...> - 2019-10-03 10:40:59
|
John, Oh, You are right about NewOrderSingle. Sorry for this. Mistake in specification from client side. We are not going use real client-server communication flow. Just receive several messages. And we have some different validation rules for the different messages. Thanks a lot for help! чт, 3 окт. 2019 г. в 13:14, Christoph John <chr...@ma...>: > > Hi, > > no that is not possible to be specified in the dictionary. You will need to do such validations in your application code. > But do you have a real-life example for this? Because the OrdStatus is a bad example since it does not occur on a NewOrderSingle. And besides, quite often fields from the order are echoed back on the ExecutionReport so I cannot think of a use-case for this right now. But maybe there is. Please elaborate. > > Cheers, > Chris. > > > On 03.10.19 12:08, Егор Мороз wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > Please help me with this. > > Is it possible to validate different values for the same field for the different messages using dictionary xml file. > > For example i have two message NewOrderSingle and ExecutionReport and field OrdStatus. > > For NewOrderSingle the valid values are : Accepted, PartiallyFilled, Filled, DoneForDay > > For ExecutionReport : Accepted, PartiallyFilled. > > I tried different variants but I can set OrdStatus values only for all messages globally. > > Thanks for help! > > > _______________________________________________ > 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: Christoph J. <chr...@ma...> - 2019-10-03 10:15:17
|
Hi, no that is not possible to be specified in the dictionary. You will need to do such validations in your application code. But do you have a real-life example for this? Because the OrdStatus is a bad example since it does not occur on a NewOrderSingle. And besides, quite often fields from the order are echoed back on the ExecutionReport so I cannot think of a use-case for this right now. But maybe there is. Please elaborate. Cheers, Chris. On 03.10.19 12:08, Егор Мороз wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > Please help me with this. > > Is it possible to validate different values for the same field for the different messages using > dictionary xml file. > > For example i have two message NewOrderSingle and ExecutionReport and field OrdStatus. > > For NewOrderSingle the valid values are : Accepted, PartiallyFilled, Filled, DoneForDay > > For ExecutionReport : Accepted, PartiallyFilled. > > I tried different variants but I can set OrdStatus values only for all messages globally. > > Thanks for help! > > > _______________________________________________ > 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: Егор М. <eg...@gm...> - 2019-10-03 10:09:05
|
Hi, Please help me with this. Is it possible to validate different values for the same field for the different messages using dictionary xml file. For example i have two message NewOrderSingle and ExecutionReport and field OrdStatus. For NewOrderSingle the valid values are : Accepted, PartiallyFilled, Filled, DoneForDay For ExecutionReport : Accepted, PartiallyFilled. I tried different variants but I can set OrdStatus values only for all messages globally. Thanks for help! |
|
From: Tom <eg...@gm...> - 2019-10-03 10:04:34
|
Hi, Please help me with this. Is it possible to validate different values for the same field for the different messages using dictionary xml file. For example i have two message NewOrderSingle and ExecutionReport and field OrdStatus. For NewOrderSingle the valid values are : Accepted, PartiallyFilled, Filled, DoneForDay For ExecutionReport : Accepted, PartiallyFilled. I tried different variants but I can set OrdStatus values only for all messages globally. Thanks for help! -- Sent from: http://quickfix-j.364392.n2.nabble.com/ |
|
From: Christoph J. <chr...@ma...> - 2019-10-02 21:23:49
|
Hi Pavel, maybe you were hitting "reply" instead of "reply to all". But nevermind, maybe our mails crossed. Now to your problem. I think Colin is right in saying that you probably send your orders with a different SessionID. Or you try to send it when the connection is down. Then they should be stored in the message store and sent on next Logon. But this will not work in your case since you send the ResetSeqNumFlag 141=Y on the Logon message. That means the message store will be reset and with it all messages that are contained. The log from LMAX and your events do not match. The LMAX log is from 2019-09-27, your log and events from today. So it is a little hard to put that in relation. Cheers, Chris. On 02.10.19 16:23, Pavel Tashev wrote: > QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ > QuickFIX/J Support:http://www.quickfixj.org/support/ > > > > I receive the messages in my mail box. To reply to your message I hit "Reply". > > Here is the log from LMAX server (they provided it to me): > > 2019-09-27 UTC 12:54:10.925655 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=114|35=A|34=1|49=MY_USERNAME|52=20190927-12:54:10.837|56=LMXBL|98=0|108=5|141=Y|553=MY_USERNAME|554=###############|10=108| > 2019-09-27 UTC 12:54:11.074854 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=77|35=A|49=LMXBL|56=MY_USERNAME|34=1|52=20190927-12:54:11.074|98=0|108=5|141=Y|10=033| > 2019-09-27 UTC 12:54:15.830025 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=60|35=0|34=2|49=MY_USERNAME|52=20190927-12:54:15.828|56=LMXBL|10=252| > 2019-09-27 UTC 12:54:16.075524 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=2|52=20190927-12:54:16.075|10=247| > 2019-09-27 UTC 12:54:20.830474 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=60|35=0|34=3|49=MY_USERNAME|52=20190927-12:54:20.828|56=LMXBL|10=249| > 2019-09-27 UTC 12:54:21.075640 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=3|52=20190927-12:54:21.075|10=244| > 2019-09-27 UTC 12:54:25.830495 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=60|35=0|34=4|49=MY_USERNAME|52=20190927-12:54:25.828|56=LMXBL|10=255| > 2019-09-27 UTC 12:54:26.076542 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=4|52=20190927-12:54:26.076|10=251| > 2019-09-27 UTC 12:54:30.829822 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=60|35=0|34=5|49=MY_USERNAME|52=20190927-12:54:30.828|56=LMXBL|10=252| > 2019-09-27 UTC 12:54:31.076209 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=5|52=20190927-12:54:31.076|10=248| > 2019-09-27 UTC 12:54:35.829791 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=60|35=0|34=6|49=MY_USERNAME|52=20190927-12:54:35.828|56=LMXBL|10=002| > 2019-09-27 UTC 12:54:36.076360 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=6|52=20190927-12:54:36.076|10=254| > 2019-09-27 UTC 12:54:38.829332 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123 > 8=FIX.4.4|9=69|35=1|34=7|49=MY_USERNAME|52=20190927-12:54:38.828|56=LMXBL|112=TEST|10=034| > 2019-09-27 UTC 12:54:38.829466 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007 > 8=FIX.4.4|9=69|35=0|49=LMXBL|56=MY_USERNAME|34=7|52=20190927-12:54:38.829|112=TEST|10=034| > 2019-09-27 UTC 12:54:39.830189 MY_IP_ADDRESS:46788 > LMAX_IP_ADDRESS:20113 8=TCP|35=FIN > 2019-09-27 UTC 12:54:39.830275 LMAX_IP_ADDRESS:20113 > MY_IP_ADDRESS:46788 8=TCP|35=FIN > > On my side Quickfix generates the following events: > > 8=FIX.4.49=11435=A34=149=tomgranger1152=20191002-12:56:56.63956=LMXBL98=0108=5141=Y553=tomgranger11554=L7qxd6LhnEB9PRD10=105 > 8=FIX.4.49=7735=A49=LMXBL56=tomgranger1134=152=20191002-12:56:56.86498=0108=5141=Y10=036 > 8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=252=20191002-12:57:01.86410=235 > 8=FIX.4.49=6035=034=249=tomgranger1152=20191002-12:57:01.87256=LMXBL10=234 > 8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=352=20191002-12:57:06.86510=242 > 8=FIX.4.49=6035=034=349=tomgranger1152=20191002-12:57:06.86956=LMXBL10=246 > 8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=452=20191002-12:57:11.86610=240 > 8=FIX.4.49=6035=034=449=tomgranger1152=20191002-12:57:12.62256=LMXBL10=231 > 8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=552=20191002-12:57:16.86610=246 > 8=FIX.4.49=6035=034=549=tomgranger1152=20191002-12:57:17.62256=LMXBL10=237 > 8=FIX.4.49=6935=134=649=tomgranger1152=20191002-12:57:19.62256=LMXBL112=TEST10=012 > 8=FIX.4.49=6935=049=LMXBL56=tomgranger1134=652=20191002-12:57:19.625112=TEST10=014 > > and here are the events: > > 20191002-12:56:55: Session FIX.4.4:tomgranger11->LMXBL schedule is daily, 00:00:00-UTC - 21:30:00-UTC > 20191002-12:56:55: Created session: FIX.4.4:tomgranger11->LMXBL > 20191002-12:56:55: Configured socket addresses for session: > [fix-order.london-demo.lmax.com/91.215.166.65:443 > <http://fix-order.london-demo.lmax.com/91.215.166.65:443>] > 20191002-12:56:55: MINA session created: local=/167.71.142.68:41860 <http://167.71.142.68:41860>, > class org.apache.mina.transport.socket.nio.NioSocketSession, > remote=fix-order.london-demo.lmax.com/91.215.166.65:443 > <http://fix-order.london-demo.lmax.com/91.215.166.65:443> > 20191002-12:56:56: Initiated logon request > 20191002-12:56:56: Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1 > 20191002-12:56:56: Received logon > 20191002-12:57:19: Sent test request TEST > > The confusing thing is that I don't see log indicating that I send a request for openning a new order. > > Regards, > Pavel > > -- 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...> - 2019-10-02 15:24:25
|
Does Session.sendToTarget return true or false? You may be setting the wrong sender/target comp ids and the message is never sent. <snip> -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |
|
From: Pavel T. <pav...@wh...> - 2019-10-02 14:23:58
|
I receive the messages in my mail box. To reply to your message I hit
"Reply".
Here is the log from LMAX server (they provided it to me):
2019-09-27 UTC 12:54:10.925655 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=114|35=A|34=1|49=MY_USERNAME|52=20190927-12:54:10.837|56=LMXBL|98=0|108=5|141=Y|553=MY_USERNAME|554=###############|10=108|
2019-09-27 UTC 12:54:11.074854 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=77|35=A|49=LMXBL|56=MY_USERNAME|34=1|52=20190927-12:54:11.074|98=0|108=5|141=Y|10=033|
2019-09-27 UTC 12:54:15.830025 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=60|35=0|34=2|49=MY_USERNAME|52=20190927-12:54:15.828|56=LMXBL|10=252|
2019-09-27 UTC 12:54:16.075524 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=2|52=20190927-12:54:16.075|10=247|
2019-09-27 UTC 12:54:20.830474 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=60|35=0|34=3|49=MY_USERNAME|52=20190927-12:54:20.828|56=LMXBL|10=249|
2019-09-27 UTC 12:54:21.075640 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=3|52=20190927-12:54:21.075|10=244|
2019-09-27 UTC 12:54:25.830495 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=60|35=0|34=4|49=MY_USERNAME|52=20190927-12:54:25.828|56=LMXBL|10=255|
2019-09-27 UTC 12:54:26.076542 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=4|52=20190927-12:54:26.076|10=251|
2019-09-27 UTC 12:54:30.829822 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=60|35=0|34=5|49=MY_USERNAME|52=20190927-12:54:30.828|56=LMXBL|10=252|
2019-09-27 UTC 12:54:31.076209 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=5|52=20190927-12:54:31.076|10=248|
2019-09-27 UTC 12:54:35.829791 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=60|35=0|34=6|49=MY_USERNAME|52=20190927-12:54:35.828|56=LMXBL|10=002|
2019-09-27 UTC 12:54:36.076360 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=60|35=0|49=LMXBL|56=MY_USERNAME|34=6|52=20190927-12:54:36.076|10=254|
2019-09-27 UTC 12:54:38.829332 MY_IP_ADDRESS:45007 > LMAX_IP_ADDRESS:20123
8=FIX.4.4|9=69|35=1|34=7|49=MY_USERNAME|52=20190927-12:54:38.828|56=LMXBL|112=TEST|10=034|
2019-09-27 UTC 12:54:38.829466 LMAX_IP_ADDRESS:20123 > MY_IP_ADDRESS:45007
8=FIX.4.4|9=69|35=0|49=LMXBL|56=MY_USERNAME|34=7|52=20190927-12:54:38.829|112=TEST|10=034|
2019-09-27 UTC 12:54:39.830189 MY_IP_ADDRESS:46788 > LMAX_IP_ADDRESS:20113
8=TCP|35=FIN
2019-09-27 UTC 12:54:39.830275 LMAX_IP_ADDRESS:20113 > MY_IP_ADDRESS:46788
8=TCP|35=FIN
On my side Quickfix generates the following events:
8=FIX.4.49=11435=A34=149=tomgranger1152=20191002-12:56:56.63956=LMXBL98=0108=5141=Y553=tomgranger11554=L7qxd6LhnEB9PRD10=105
8=FIX.4.49=7735=A49=LMXBL56=tomgranger1134=152=20191002-12:56:56.86498=0108=5141=Y10=036
8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=252=20191002-12:57:01.86410=235
8=FIX.4.49=6035=034=249=tomgranger1152=20191002-12:57:01.87256=LMXBL10=234
8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=352=20191002-12:57:06.86510=242
8=FIX.4.49=6035=034=349=tomgranger1152=20191002-12:57:06.86956=LMXBL10=246
8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=452=20191002-12:57:11.86610=240
8=FIX.4.49=6035=034=449=tomgranger1152=20191002-12:57:12.62256=LMXBL10=231
8=FIX.4.49=6035=049=LMXBL56=tomgranger1134=552=20191002-12:57:16.86610=246
8=FIX.4.49=6035=034=549=tomgranger1152=20191002-12:57:17.62256=LMXBL10=237
8=FIX.4.49=6935=134=649=tomgranger1152=20191002-12:57:19.62256=LMXBL112=TEST10=012
8=FIX.4.49=6935=049=LMXBL56=tomgranger1134=652=20191002-12:57:19.625112=TEST10=014
and here are the events:
20191002-12:56:55: Session FIX.4.4:tomgranger11->LMXBL schedule is daily,
00:00:00-UTC - 21:30:00-UTC
20191002-12:56:55: Created session: FIX.4.4:tomgranger11->LMXBL
20191002-12:56:55: Configured socket addresses for session: [
fix-order.london-demo.lmax.com/91.215.166.65:443]
20191002-12:56:55: MINA session created: local=/167.71.142.68:41860, class
org.apache.mina.transport.socket.nio.NioSocketSession, remote=
fix-order.london-demo.lmax.com/91.215.166.65:443
20191002-12:56:56: Initiated logon request
20191002-12:56:56: Logon contains ResetSeqNumFlag=Y, resetting sequence
numbers to 1
20191002-12:56:56: Received logon
20191002-12:57:19: Sent test request TEST
The confusing thing is that I don't see log indicating that I send a
request for openning a new order.
Regards,
Pavel
On Wed, Oct 2, 2019 at 1:20 PM Christoph John <chr...@ma...>
wrote:
> Hi,
>
> did you see my other mail on the list? Here again:
>
> ------
> Hi Pavel,
>
> but I take it your session to LMAX could be established correctly and is
> exchanging heartbeats? Can you maybe post your message and event log of the
> relevant points in time? (please do not forget to remove passwords from FIX
> messages if there are any)
>
> Cheers,
> Chris.
>
> ----------
>
> On 02.10.19 09:03, Pavel Tashev wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> I use Quickfix/J to send requests to LMAX. Right after openning a new
> order LMAX disconnects me. According to their support, my server sends TCP
> FIN. Here is a log from their server:
>
> 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS
> 8=TCP|35=FIN
>
> Why Quickfix/J (installed on my machine) sends a message of type FIN? Here
> is how I open a new order:
> public void sendNewOrderSingle(String p, char SideValue, char OrdTypeValue
> , double price, double OrderQty) throws SessionNotFound
> {
> System.out.println("\nNewOrderSingle");
> // Prepare
> String ClOrdID = generateRandomString(20);
> LocalDateTime now = LocalDateTime.now();
> // Save data in Strategy
> StrategySwitcher.setClOrdID(p, ClOrdID);
> // Build and send request
> quickfix.fix44.NewOrderSingle message = new quickfix.fix44.
> NewOrderSingle();
>
> message.setField(new ClOrdID(ClOrdID)); //11
> message.setField(new SecurityID("4001")); //48
> message.setField(new SecurityIDSource("8")); //22
> message.setField(new Symbol(p)); //55 Ticker symbol
> message.setField(new Side(SideValue));
> //54 Side. 1 = Buy, 2 = Sell
> message.setField(new ExecInst("H"));
> //18 H = Reinstate on System Failure (Do not cancel on disconnect); Q = Cancel on System Failure (Cancel on disconnect)
> message.setField(new TransactTime(now));
> //60 Time this order request was initiated/released by the trader, trading system, or intermediary. Ignored by LMAX.
> message.setField(new OrderQty(OrderQty));
> //38 The number of contracts that an order is for.
> message.setField(new OrdType(OrdTypeValue));
> //40 Order type. 1 = Market, 2 = Limit, 3 = Stop, 4 = Stop Limit
> switch (String.valueOf(OrdTypeValue)) {
> case "2": // LIMIT
> message.setField(new Price(price));
> // 44 Price. Required for limit OrdTypes.
> break;
> case "3": // STOP
> message.setField(new StopPx(price));
> // 99 StopPx. Required for stop OrdTypes.
> break;
> }
> message.setField(new TimeInForce(TimeInForceMap.get(
> "GOOD_TILL_CANCEL")));
> // 59 Specifies how long the order remains in effect. 0 = Day (trading session), 1 = Good Till Cancel (GTC), 3 = Immediate or Cancel (IOC), 4 = Fill or Kill (FOK)
> Session.sendToTarget(message, senderCompID, tradeTargetCompID);
> }
>
> In my case:
> SideValue => SELL which is 2
> OrdTypeValue => LIMIT which is 2
>
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
|
|
From: Colin D. <co...@ma...> - 2019-10-02 14:11:02
|
FIN is a TCP-level message. You're looking at too low a level. There are 1 to several TCP messages that make up a single QFJ message. On 10/2/19 12:03 AM, Pavel Tashev wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I use Quickfix/J to send requests to LMAX. Right after openning a new > order LMAX disconnects me. According to their support, my server sends > TCP FIN. Here is a log from their server: > > 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS > 8=TCP|35=FIN > > Why Quickfix/J (installed on my machine) sends a message of type FIN? > Here is how I open a new order: > publicvoidsendNewOrderSingle(Stringp, charSideValue, charOrdTypeValue, > doubleprice, doubleOrderQty) throwsSessionNotFound { > System.out.println("\nNewOrderSingle"); > // Prepare > StringClOrdID=generateRandomString(20); > LocalDateTimenow=LocalDateTime.now(); > // Save data in Strategy > StrategySwitcher.setClOrdID(p, ClOrdID); > // Build and send request > quickfix.fix44.NewOrderSinglemessage=new quickfix.fix44.NewOrderSingle(); > message.setField(newClOrdID(ClOrdID)); //11 > message.setField(newSecurityID("4001")); //48 > message.setField(newSecurityIDSource("8")); //22 > message.setField(newSymbol(p)); //55 Ticker symbol > message.setField(newSide(SideValue)); //54 Side. 1 = Buy, 2 = Sell > message.setField(newExecInst("H")); > //18 H = Reinstate on System Failure (Do not cancel on disconnect); Q = Cancel on System Failure (Cancel on disconnect) > message.setField(newTransactTime(now)); > //60 Time this order request was initiated/released by the trader, trading system, or intermediary. Ignored by LMAX. > message.setField(newOrderQty(OrderQty)); > //38 The number of contracts that an order is for. > message.setField(newOrdType(OrdTypeValue)); > //40 Order type. 1 = Market, 2 = Limit, 3 = Stop, 4 = Stop Limit > switch (String.valueOf(OrdTypeValue)) { > case"2":// LIMIT > message.setField(newPrice(price)); > // 44 Price. Required for limit OrdTypes. > break; > case"3":// STOP > message.setField(newStopPx(price)); > // 99 StopPx. Required for stop OrdTypes. > break; > } > message.setField(newTimeInForce(TimeInForceMap.get("GOOD_TILL_CANCEL"))); > // 59 Specifies how long the order remains in effect. 0 = Day (trading session), 1 = Good Till Cancel (GTC), 3 = Immediate or Cancel (IOC), 4 = Fill or Kill (FOK) > Session.sendToTarget(message, senderCompID, tradeTargetCompID); > } > > In my case: > SideValue => SELL which is 2 > OrdTypeValue => LIMIT which is 2 > > > > _______________________________________________ > 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: Christoph J. <chr...@ma...> - 2019-10-02 10:21:15
|
Hi, did you see my other mail on the list? Here again: ------ Hi Pavel, but I take it your session to LMAX could be established correctly and is exchanging heartbeats? Can you maybe post your message and event log of the relevant points in time? (please do not forget to remove passwords from FIX messages if there are any) Cheers, Chris. ---------- On 02.10.19 09:03, Pavel Tashev wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I use Quickfix/J to send requests to LMAX. Right after openning a new order LMAX disconnects me. > According to their support, my server sends TCP FIN. Here is a log from their server: > > 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS 8=TCP|35=FIN > > Why Quickfix/J (installed on my machine) sends a message of type FIN? Here is how I open a new order: > publicvoidsendNewOrderSingle(Stringp, charSideValue, charOrdTypeValue, doubleprice, > doubleOrderQty) throwsSessionNotFound { > System.out.println("\nNewOrderSingle"); > // Prepare > StringClOrdID=generateRandomString(20); > LocalDateTimenow=LocalDateTime.now(); > // Save data in Strategy > StrategySwitcher.setClOrdID(p, ClOrdID); > // Build and send request > quickfix.fix44.NewOrderSinglemessage=new quickfix.fix44.NewOrderSingle(); > message.setField(newClOrdID(ClOrdID)); //11 > message.setField(newSecurityID("4001")); //48 > message.setField(newSecurityIDSource("8")); //22 > message.setField(newSymbol(p)); //55 Ticker symbol > message.setField(newSide(SideValue)); //54 Side. 1 = Buy, 2 = Sell > message.setField(newExecInst("H")); > //18 H = Reinstate on System Failure (Do not cancel on disconnect); Q = Cancel on System Failure (Cancel on disconnect) > message.setField(newTransactTime(now)); > //60 Time this order request was initiated/released by the trader, trading system, or intermediary. Ignored by LMAX. > message.setField(newOrderQty(OrderQty)); //38 The number of contracts that an order is for. > message.setField(newOrdType(OrdTypeValue)); > //40 Order type. 1 = Market, 2 = Limit, 3 = Stop, 4 = Stop Limit > switch (String.valueOf(OrdTypeValue)) { > case"2":// LIMIT > message.setField(newPrice(price)); // 44 Price. Required for limit OrdTypes. > break; > case"3":// STOP > message.setField(newStopPx(price)); // 99 StopPx. Required for stop OrdTypes. > break; > } > message.setField(newTimeInForce(TimeInForceMap.get("GOOD_TILL_CANCEL"))); > // 59 Specifies how long the order remains in effect. 0 = Day (trading session), 1 = Good Till Cancel (GTC), 3 = Immediate or Cancel (IOC), 4 = Fill or Kill (FOK) > Session.sendToTarget(message, senderCompID, tradeTargetCompID); > } > > In my case: > SideValue => SELL which is 2 > OrdTypeValue => LIMIT which is 2 > > > > _______________________________________________ > 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: Pavel T. <pav...@wh...> - 2019-10-02 07:03:28
|
Hi,
I use Quickfix/J to send requests to LMAX. Right after openning a new order
LMAX disconnects me. According to their support, my server sends TCP FIN.
Here is a log from their server:
2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS
8=TCP|35=FIN
Why Quickfix/J (installed on my machine) sends a message of type FIN? Here
is how I open a new order:
public void sendNewOrderSingle(String p, char SideValue, char OrdTypeValue,
double price, double OrderQty) throws SessionNotFound
{
System.out.println("\nNewOrderSingle");
// Prepare
String ClOrdID = generateRandomString(20);
LocalDateTime now = LocalDateTime.now();
// Save data in Strategy
StrategySwitcher.setClOrdID(p, ClOrdID);
// Build and send request
quickfix.fix44.NewOrderSingle message = new quickfix.fix44.
NewOrderSingle();
message.setField(new ClOrdID(ClOrdID)); //11
message.setField(new SecurityID("4001")); //48
message.setField(new SecurityIDSource("8")); //22
message.setField(new Symbol(p)); //55 Ticker symbol
message.setField(new Side(SideValue)); //54 Side. 1 = Buy, 2 = Sell
message.setField(new ExecInst("H"));
//18 H = Reinstate on System Failure (Do not cancel on disconnect); Q
= Cancel on System Failure (Cancel on disconnect)
message.setField(new TransactTime(now));
//60 Time this order request was initiated/released by the trader,
trading system, or intermediary. Ignored by LMAX.
message.setField(new OrderQty(OrderQty));
//38 The number of contracts that an order is for.
message.setField(new OrdType(OrdTypeValue));
//40 Order type. 1 = Market, 2 = Limit, 3 = Stop, 4 = Stop Limit
switch (String.valueOf(OrdTypeValue)) {
case "2": // LIMIT
message.setField(new Price(price));
// 44 Price. Required for limit OrdTypes.
break;
case "3": // STOP
message.setField(new StopPx(price));
// 99 StopPx. Required for stop OrdTypes.
break;
}
message.setField(new TimeInForce(TimeInForceMap.get(
"GOOD_TILL_CANCEL")));
// 59 Specifies how long the order remains in effect. 0 = Day (trading
session), 1 = Good Till Cancel (GTC), 3 = Immediate or Cancel (IOC),
4 = Fill or Kill (FOK)
Session.sendToTarget(message, senderCompID, tradeTargetCompID);
}
In my case:
SideValue => SELL which is 2
OrdTypeValue => LIMIT which is 2
|
|
From: Christoph J. <chr...@ma...> - 2019-10-01 20:39:14
|
Hi Pavel, but I take it your session to LMAX could be established correctly and is exchanging heartbeats? Can you maybe post your message and event log of the relevant points in time? (please do not forget to remove passwords from FIX messages if there are any) Cheers, Chris. On 01.10.19 15:54, Colin DuPlantis wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > TCP FIN is not a QFJ message, it's a socket-level message. It indicates the end of a particular > transmission. > > Their logs are too detailed, at least from the point-of-view of QFJ. You need to know the contents > of the whole TCP message, not a single packet. > > Ask if they can send you the FIX message that causes the disconnection, if there is one. > > On 10/1/19 1:45 AM, Pavel Tashev wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi, >> >> I use Quickfix/J to send requests to LMAX. Right after openning a new order LMAX disconnects me. >> According to their support, my server sends TCP FIN. Here is a log from their server: >> >> 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS 8=TCP|35=FIN >> >> Why Quickfix/J (installed on my machine) sends a message of type FIN? >> >> Regards, >> Pavel >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- > Colin DuPlantis > Chief Architect, Marketcetera > Download, Run, Trade > 888.868.4884 > https://www.marketcetera.com > > > _______________________________________________ > Quickfixj-users 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...> - 2019-10-01 13:54:21
|
TCP FIN is not a QFJ message, it's a socket-level message. It indicates the end of a particular transmission. Their logs are too detailed, at least from the point-of-view of QFJ. You need to know the contents of the whole TCP message, not a single packet. Ask if they can send you the FIX message that causes the disconnection, if there is one. On 10/1/19 1:45 AM, Pavel Tashev wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I use Quickfix/J to send requests to LMAX. Right after openning a new > order LMAX disconnects me. According to their support, my server sends > TCP FIN. Here is a log from their server: > > 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS > 8=TCP|35=FIN > > Why Quickfix/J (installed on my machine) sends a message of type FIN? > > Regards, > Pavel > > > _______________________________________________ > 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: Christoph J. <chr...@ma...> - 2019-10-01 09:30:05
|
Hi, looking at that log output it looks like an application problem. Usually FIX messages start with 8=FIX. I don't know where 8=TCP is coming from but am pretty sure that QFJ itself is not sending this. How do you send your order? Which method are you calling? Cheers, Chris. On 01.10.19 10:45, Pavel Tashev wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I use Quickfix/J to send requests to LMAX. Right after openning a new order LMAX disconnects me. > According to their support, my server sends TCP FIN. Here is a log from their server: > > 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS 8=TCP|35=FIN > > Why Quickfix/J (installed on my machine) sends a message of type FIN? > > Regards, > Pavel > > > _______________________________________________ > 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: Pavel T. <pav...@wh...> - 2019-10-01 08:46:10
|
Hi, I use Quickfix/J to send requests to LMAX. Right after openning a new order LMAX disconnects me. According to their support, my server sends TCP FIN. Here is a log from their server: 2019-09-27 UTC 12:54:39.830189 MY_IP ADDRESS > THEIR_IP_ADDRESS 8=TCP|35=FIN Why Quickfix/J (installed on my machine) sends a message of type FIN? Regards, Pavel |
|
From: Christoph J. <chr...@ma...> - 2019-09-30 19:55:33
|
Hi Vlad, I think it would be sensible to create the PR with the necessary changes. If there is the need, developers can comment/review there. Thanks in advance and best regards, Chris. On 25.09.19 11:39, Christoph John wrote: > Hi Vlad, > > thanks for your effort! > I prefer solution 1 (Generate a quickfixj-fields jar to be used as dependency by the other > messages jars. This way the jar can be imported only once and split package issue is avoided. > Advantage: avoid code duplication, avoid split package issue). > It is also going to introduce the least hassle I think. Users then need to add just one additional > dependency which should be fine. > > BTW quickfixj-core also would need the quickfixj-fields.jar as dependency. Maybe this is also a > problem. I don't know whether there may be circular dependencies between the core and fields > module. IIRC with some field converters but maybe I am confusing something. > > Cheers, > Chris. > > > On 24.09.19 08:41, vlad manuel wrote: >> Hi all, >> >> I have created the following Jira Ticket to keep track of the agreed solution before creating the >> PR to fix split packages issue: [QFJ-987] JPMS: Change field classes generation to resolve split >> package issue - QuickFIX/J Jira <https://www.quickfixj.org/jira/browse/QFJ-987> >> >> I have added there a comment with 2 possible solutions I'm considering. I'm looking forward for >> your feedback! >> >> Thanks, >> Vlad >> >> >> Le jeudi 12 septembre 2019 à 11:13:21 UTC+3, Christoph John <chr...@ma...> a écrit : >> >> >> Hi Vlad, >> >> oh well, yes. This is one of the things that were done to get the dependencies in Maven right >> IIRC. But I could be wrong, it was some years ago when this was done. >> However, please feel free the open a PR for this, very much appreciated. >> https://github.com/quickfix-j/quickfixj/pulls >> >> I think all users appreciate if QFJ could be used with a recent Java version without issues. >> >> Thanks in advance and best regards >> Chris. >> >> On 12.09.19 09:55, vlad manuel via Quickfixj-users wrote: >>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>> >>> >>> >> Hi all, >> >> I'm trying to use quickfixj in a Java11 environment with the new java modules. >> However, I'm facing some split package issues. >> E.g., each version of quickfix messages contain the same "quickfix.fiels" package. >> So if I'm using two versions of messages in my module, I'm facing a split package issue which is >> no longer tolerated by the jvm. >> >> I would like to create a PR for this. Looking forward to hearing your opinion on this topic. >> >> Thanks, >> Vlad Muresan >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> -- >> Christoph John >> Software Engineering >> T +49 241 557080-28 >> chr...@ma... <mailto:chr...@ma...> >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germany >> www.macd.com <http://www.macd.com> >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2019-09-30 09:32:13
|
Hi Philip, I think it might be sensible to extend the validation by this. It could keep user's application code cleaner. However, I think this validation should be made configurable via a configuration option, e.g. ValidateDatatypes or similar. Of course one could still turn off complete validation but in my opinion a finer grained control of the various validation options is better. Cheers, Chris. On 27.09.19 17:53, Philip Whitehouse wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi all, > > The FIX spec for Qty states: > > float field capable of storing either a whole number (no decimal places) of "shares" (securities > denominated in whole units) or a decimal value containing decimal places for non-share quantity > asset classes (securities denominated in fractional units). > > > > There’s no mention of negative values (whereas there is for price). > > But we parse it as a double and it’s left to applications to validate that it’s positive. > > A DAYOFMONTH field is parsed as a string (even though it should be 1-31) > > Similar stuff can be said for lots of other fields. > > Should we move towards tighter validation of field values here: > https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/main/java/quickfix/DataDictionary.java#L706 > > Thoughts and comments appreciated, > > Best regards, > > Philip Whitehouse > > > > _______________________________________________ > 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: Philip W. <Phi...@fl...> - 2019-09-27 16:28:37
|
Hi all, The FIX spec for Qty states: float field capable of storing either a whole number (no decimal places) of "shares" (securities denominated in whole units) or a decimal value containing decimal places for non-share quantity asset classes (securities denominated in fractional units). There's no mention of negative values (whereas there is for price). But we parse it as a double and it's left to applications to validate that it's positive. A DAYOFMONTH field is parsed as a string (even though it should be 1-31) Similar stuff can be said for lots of other fields. Should we move towards tighter validation of field values here: https://github.com/quickfix-j/quickfixj/blob/master/quickfixj-core/src/main/java/quickfix/DataDictionary.java#L706 Thoughts and comments appreciated, Best regards, Philip Whitehouse |
|
From: Christoph J. <chr...@ma...> - 2019-09-25 09:39:42
|
Hi Vlad, thanks for your effort! I prefer solution 1 (Generate a quickfixj-fields jar to be used as dependency by the other messages jars. This way the jar can be imported only once and split package issue is avoided. Advantage: avoid code duplication, avoid split package issue). It is also going to introduce the least hassle I think. Users then need to add just one additional dependency which should be fine. BTW quickfixj-core also would need the quickfixj-fields.jar as dependency. Maybe this is also a problem. I don't know whether there may be circular dependencies between the core and fields module. IIRC with some field converters but maybe I am confusing something. Cheers, Chris. On 24.09.19 08:41, vlad manuel wrote: > Hi all, > > I have created the following Jira Ticket to keep track of the agreed solution before creating the > PR to fix split packages issue: [QFJ-987] JPMS: Change field classes generation to resolve split > package issue - QuickFIX/J Jira <https://www.quickfixj.org/jira/browse/QFJ-987> > > I have added there a comment with 2 possible solutions I'm considering. I'm looking forward for > your feedback! > > Thanks, > Vlad > > > Le jeudi 12 septembre 2019 à 11:13:21 UTC+3, Christoph John <chr...@ma...> a écrit : > > > Hi Vlad, > > oh well, yes. This is one of the things that were done to get the dependencies in Maven right > IIRC. But I could be wrong, it was some years ago when this was done. > However, please feel free the open a PR for this, very much appreciated. > https://github.com/quickfix-j/quickfixj/pulls > > I think all users appreciate if QFJ could be used with a recent Java version without issues. > > Thanks in advance and best regards > Chris. > > On 12.09.19 09:55, vlad manuel via Quickfixj-users wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> > Hi all, > > I'm trying to use quickfixj in a Java11 environment with the new java modules. > However, I'm facing some split package issues. > E.g., each version of quickfix messages contain the same "quickfix.fiels" package. > So if I'm using two versions of messages in my module, I'm facing a split package issue which is > no longer tolerated by the jvm. > > I would like to create a PR for this. Looking forward to hearing your opinion on this topic. > > Thanks, > Vlad Muresan > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... <mailto:Qui...@li...> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Philip W. <ph...@wh...> - 2019-09-25 09:21:33
|
It’s currently being looked at on this list - there’s a modules issue that reportedly needs resolving: https://www.quickfixj.org/jira/browse/QFJ-987 Best, Philip Whitehouse > On 25 Sep 2019, at 07:13, Vipin Chaudhary <vip...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi Everyone, > > I am using latest quickfixj 2.1.1. Currently we are using jdk 8 but we are planning to migrate to jdk 11 soon. > > Is quickfixj 2.1.1 compatible with jdk 11 ? If not, Is there any plan to add jdk11 compatibility in near future? > > Thanks > Vipin > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: vlad m. <vla...@ya...> - 2019-09-25 09:05:33
|
Hi Vipin,
While the library can run on JDK 11, it is not yet compatible with the Java Platform Module System (JPMS).
If you plan to use quickfixj in a java module based application, you can have a look at the related discussions here and follow the status on this Jira Ticket.
Cheers,Vlad
Le mercredi 25 septembre 2019 à 09:12:51 UTC+3, Vipin Chaudhary <vip...@gm...> a écrit :
Hi Everyone,
I am using latest quickfixj 2.1.1. Currently we are using jdk 8 but we are planning to migrate to jdk 11 soon.
Is quickfixj 2.1.1 compatible with jdk 11 ? If not, Is there any plan to add jdk11 compatibility in near future?
ThanksVipin
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
|
|
From: Vipin C. <vip...@gm...> - 2019-09-25 06:12:36
|
Hi Everyone, I am using latest quickfixj 2.1.1. Currently we are using jdk 8 but we are planning to migrate to jdk 11 soon. Is quickfixj 2.1.1 compatible with jdk 11 ? If not, Is there any plan to add jdk11 compatibility in near future? Thanks Vipin |
|
From: vlad m. <vla...@ya...> - 2019-09-24 06:41:28
|
Hi all,
I have created the following Jira Ticket to keep track of the agreed solution before creating the PR to fix split packages issue: [QFJ-987] JPMS: Change field classes generation to resolve split package issue - QuickFIX/J Jira
I have added there a comment with 2 possible solutions I'm considering. I'm looking forward for your feedback!
Thanks,Vlad
Le jeudi 12 septembre 2019 à 11:13:21 UTC+3, Christoph John <chr...@ma...> a écrit :
Hi Vlad,
oh well, yes. This is one of the things that were done to get the dependencies in Maven right IIRC. But I could be wrong, it was some years ago when this was done.
However, please feel free the open a PR for this, very much appreciated. https://github.com/quickfix-j/quickfixj/pulls
I think all users appreciate if QFJ could be used with a recent Java version without issues.
Thanks in advance and best regards
Chris.
On 12.09.19 09:55, vlad manuel via Quickfixj-users wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hi all,
I'm trying to use quickfixj in a Java11 environment with the new java modules. However, I'm facing some split package issues. E.g., each version of quickfix messages contain the same "quickfix.fiels" package. So if I'm using two versions of messages in my module, I'm facing a split package issue which is no longer tolerated by the jvm.
I would like to create a PR for this. Looking forward to hearing your opinion on this topic.
Thanks, Vlad Muresan
_______________________________________________
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: Christoph J. <chr...@ma...> - 2019-09-21 20:36:48
|
Hi, I assume this has more or less historic reasons. It is done the same way in the C++ implementation. The C# implementation also does not validate seqnums on reception of a Logout message. Another way to ensure that the seqnums are in sync is to send a TestRequest before Logout. That will trigger a Resend if seqnums are not in sync. Of course, this does only work when your side initiates the Logout. Cheers, Chris. On 19.09.19 18:20, Oleg Smirnov wrote: > QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ > QuickFIX/J Support:http://www.quickfixj.org/support/ > > > > Hello, > > Could you please answer the question: > */Why the QuickFIX/J library doesn't validate MsgSeqNum when it receives a Logout message?/* > > It's very strange because according to *Page 13* of the FIX Transport protocol specification > <https://www.fixtrading.org/standards/fixt/> > > Sequence number checking is a vital part of FIX session management. However, a discrepancy in > the sequence number stream is handled differently for certain classes of FIX messages. > > In *ALL* cases except the Sequence Reset - Reset message, the FIX session should be terminated > if the incoming sequence number is less than expected and the PossDupFlag is not set. > A Logout message with some descriptive text should be sent to the other side before closing > the session. > > > Also, it says: > > *Sequence number mismatch in case of Logout message:* > If a message gap was detected, issue a ResendRequest to retrieve all missing messages followed > by a Logout message which serves as a confirmation of the logout request. DO NOT terminate > the session. The initiator of the Logout sequence has responsibility to terminate the > session. This allows the Logout initiator to respond to any ResendRequest message. > If this side was the initiator of the Logout sequence, then this is a Logout confirmation and > the session should be immediately terminated upon receipt. > The only exception to the “do not terminate the session” rule is for an invalid Logon > attempt. The session acceptor has the right to send a Logout message and terminate the > session immediately. This minimizes the threat of unauthorized connection attempts. > > > -- > Regards, > > Oleg > > > _______________________________________________ > 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: Oleg S. <ole...@ex...> - 2019-09-19 16:51:23
|
Hello, Could you please answer the question: *Why the QuickFIX/J library doesn't validate MsgSeqNum when it receives a Logout message?* It's very strange because according to *Page 13* of the FIX Transport protocol specification <https://www.fixtrading.org/standards/fixt/> > Sequence number checking is a vital part of FIX session management. > However, a discrepancy in the sequence number stream is handled differently > for certain classes of FIX messages. > > In *ALL* cases except the Sequence Reset - Reset message, the FIX session > should be terminated if the incoming sequence number is less than expected > and the PossDupFlag is not set. > A Logout message with some descriptive text should be sent to the other > side before closing the session. Also, it says: *Sequence number mismatch in case of Logout message:* > If a message gap was detected, issue a ResendRequest to retrieve all > missing messages followed by a Logout message which serves as a > confirmation of the logout request. DO NOT terminate the session. The > initiator of the Logout sequence has responsibility to terminate the > session. This allows the Logout initiator to respond to any ResendRequest > message. > If this side was the initiator of the Logout sequence, then this is a > Logout confirmation and the session should be immediately terminated upon > receipt. > The only exception to the “do not terminate the session” rule is for an > invalid Logon attempt. The session acceptor has the right to send a Logout > message and terminate the session immediately. This minimizes the threat > of unauthorized connection attempts. -- Regards, Oleg |
|
From: Colin D. <co...@ma...> - 2019-09-12 12:47:28
|
Yeah, agree with Chris, here. We use multiple SocketInitiators to make it easier to dynamically add and remove sessions without restarting. If you don't need to dynamically remove sessions without restarting, no reason to use multiple SIs, but, you probably do want to use ThreadedSocketInitiator, as Chris suggests. On 9/12/19 3:21 AM, Christoph John via Quickfixj-users wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > you can safely use one SocketInitiator for multiple sessions. The > default SocketInitiator has one thread for all sessions. > You might want to use a ThreadedSocketInitiator then (has one thread > per session) but it is not required. > > If you used one SocketInitiator per connection it is IMHO easier to > start/stop dedicated sessions. You could then simply stop the whole > SocketInitiator. > I don't know how many sessions you want to handle. > > Cheers, > Chris. > > > > On 12.09.19 11:51, Kodippili Arachchige, Asanka wrote: >> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >> QuickFIX/J Support:http://www.quickfixj.org/support/ >> >> >> >> Hi, >> >> What is the correct usage of SocketInitiator ? Is it recommended to >> create a separate session initiator object for each connection? I >> came across some code that follows this approach. Can’t we safely >> use the same SocketInitiator for multiple connections in a >> multi-threaded application ? The documentation suggests that this is >> possible. I wanted to check if there is might be any reason to use >> the one SocketInitiator per connection approach instead. >> >> Thanks, >> >> Asanka >> >> ------------------------------------------------------------------------------------------------------------ >> >> Please read these warnings and restrictions: >> >> This e-mail transmission is strictly confidential and intended solely >> for the ordinary user of the e-mail address to which it was >> addressed. It may contain legally privileged and/or CONFIDENTIAL >> information. >> >> The unauthorised use, disclosure, distribution and/or copying of this >> e-mail or any information it contains is prohibited and could, in >> certain circumstances, constitute a criminal offence. >> >> If you have received this e-mail in error or are not an intended >> recipient please inform London Stock Exchange Group (“LSEG”) >> immediately by return e-mail or telephone 020 7797 1000. >> >> LSEG may collect, process and retain your personal information for >> its business purposes. For more information please see our Privacy >> Policy <https://www.lseg.com/privacy-and-cookie-policy>. >> >> We advise that in keeping with good computing practice the recipient >> of this e-mail should ensure that it is virus free. We do not accept >> responsibility for any virus that may be transferred by way of this >> e-mail. >> >> E-mail may be susceptible to data corruption, interception and >> unauthorised amendment, and we do not accept liability for any such >> corruption, interception or amendment or any consequences thereof. >> >> Calls to London Stock Exchange Group may be recorded to enable LSEG >> to carry out its regulatory responsibilities. >> >> London Stock Exchange Group plc >> >> 10 Paternoster Square >> London >> EC4M 7LS >> >> Registered in England and Wales No 05369106 >> >> ------------------------------------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 https://www.marketcetera.com |
103 messages has been excluded from this view by a project administrator.
