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: Grant B. <gbi...@co...> - 2021-06-02 13:23:26
|
Are you writing code for the acceptor side or for the initiator side? My advice is: If on initiator side: Follow your counterparty's instructions. Use this field only as much as you have to. If on acceptor side: Don't use it. On Wed, Jun 2, 2021 at 5:49 AM Ajit Gautam <aji...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Hi, > > As per the quickfix manual, the SenderSubID field can be set in session > configuration. > This means, one user per session can take login and send the request from > quickfix initiator. > > But in case of multiple users per session, how will this setting work or > any different setting is required? > > Any help will be appreciated. > > Regards > Ajit Gautam > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com -- This email, along with any attachments, is confidential. If you believe you received this message in error, please contact the sender immediately and delete all copies of the message. Thank you from Connamara Systems, LLC. |
From: Grant B. <gbi...@co...> - 2021-06-02 13:21:08
|
Ultimately, it depends on how your counterparty is using them. Don't look for logic, just look at their spec and obey it. SenderSubId is usually used for session identification, and not trade party identification. (but some counterparties do weird things...) On Wed, Jun 2, 2021 at 2:48 AM Ajit Gautam <aji...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > Hi, > > I am using a quickfix acceptor in an exchange. > I was stuck with a few fields of FIX. > In a Quote Request message, I have two fields, one SenderSubID in header > and PartyID in message structure. > Both have the same values. > > I was wondering if both fields are the same, then what is the point of > having two different fields. > Maybe I am missing something on this. > > Any help would be appreciated. > > > Regards > Ajit Gautam > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com -- This email, along with any attachments, is confidential. If you believe you received this message in error, please contact the sender immediately and delete all copies of the message. Thank you from Connamara Systems, LLC. |
From: Ajit G. <aji...@gm...> - 2021-06-02 10:48:39
|
Hi, As per the quickfix manual, the SenderSubID field can be set in session configuration. This means, one user per session can take login and send the request from quickfix initiator. But in case of multiple users per session, how will this setting work or any different setting is required? Any help will be appreciated. Regards Ajit Gautam |
From: Ajit G. <aji...@gm...> - 2021-06-02 07:48:01
|
Hi, I am using a quickfix acceptor in an exchange. I was stuck with a few fields of FIX. In a Quote Request message, I have two fields, one SenderSubID in header and PartyID in message structure. Both have the same values. I was wondering if both fields are the same, then what is the point of having two different fields. Maybe I am missing something on this. Any help would be appreciated. Regards Ajit Gautam |
From: Taysay S. <tay...@gm...> - 2021-06-01 17:39:03
|
Thank you so much, Please, is there any forum you can suggest? Terseer (taysay)Shaguy Coding & Digitalization Enthusiast Email: tay...@ya... Phone(s): +2348036533888 <https://www.twitter.com/taysay> <https://www.linkedin.com/terseer-shaguy> <https://www.apple.com/tay> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> On Tue, Jun 1, 2021 at 5:22 PM Philip Whitehouse <ph...@wh...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > I agree that I’d expect a response to an order status request. > > This is something you need to discuss with your counter-party after > reviewing your agreement with them. > > It may, for example, be that they don’t provide an order status service > and expect you to maintain your own state and will just send you updates > when the state changes. > > In that scenario I would hope for a reject but there’s no protocol > guarantee. > > For detailed discussions about FIX as a protocol, rather than technical > concerns with QFJ you might benefit from asking on the FIX Trading > Community forums. > > Best, > > Philip Whitehouse > > On 1 Jun 2021, at 16:08, Taysay Shaguy <tay...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello, > > I understand, but wouldn't it better to at least respond and indicate > there is no data found or something. > > I am looking in the context of a self service app. So I send a Single > order Message D, and I get an execution report or a trade report. > > I may just need to get the status of the my request, so not getting a > feedback on a status call is worrisome to me. > > And thus my question, is this a norm in FIX, and if yes, why so? > > Thank you > > On Tue, Jun 1, 2021, 3:51 PM Christoph John <chr...@ma...> > wrote: > >> Hi >> I daresay that there is no feedback because the counterparty does not >> send any?! Did you check with them? >> Cheers >> Chris. >> >> Am 1. Juni 2021 15:19:37 MESZ schrieb Taysay Shaguy < >> tay...@gm...>: >>> >>> Dear Chris, >>> >>> Thank you for your feedback. >>> >>> Please see sample order status request H, no error message nor feedback. >>> >>> >>> >>> 8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 >>> >>> >>> >>> Terseer (taysay)Shaguy >>> >>> Coding & Digitalization Enthusiast >>> >>> Email: tay...@ya... >>> >>> Phone(s): +2348036533888 >>> >>> <https://www.twitter.com/taysay> >>> <https://www.linkedin.com/terseer-shaguy> >>> <https://www.apple.com/tay> >>> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> >>> >>> >>> On Tue, Jun 1, 2021 at 12:09 PM Christoph John <chr...@ma...> >>> wrote: >>> >>>> Hi, >>>> >>>> for the same problematic tags there should always be the same error. An >>>> example and log file (with both working and not working case) would be >>>> helpful. >>>> >>>> Cheers, >>>> Chris. >>>> >>>> On 01.06.21 12:23, Taysay Shaguy wrote: >>>> >>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>>> >>>> >>>> Dear Team, >>>> >>>> I am sure you all are staying safe. >>>> >>>> Please I am new to FIX, and while I acknowledge it's not a request and >>>> response system. >>>> >>>> I am integrating to a FIX engine, from a REST interface where I have >>>> requests come in via a REST interface, then wrap the requests as FIX >>>> messages and push. >>>> >>>> I get to validate the feed so, that I can give instant feedback on >>>> errors based on defined request parameters. >>>> >>>> My issue is when I send a request to the engine without a required tag, >>>> say a request which requires tag 541, it bounces back errors. >>>> >>>> However, sometimes It just goes quiet without any feedback. Please is >>>> this a norm? >>>> >>>> Apologies for the looong chat. >>>> >>>> >>>> Terseer (taysay)Shaguy >>>> >>>> Coding & Digitalization Enthusiast >>>> >>>> Email: tay...@ya... >>>> >>>> Phone(s): +2348036533888 >>>> >>>> <https://www.twitter.com/taysay> >>>> <https://www.linkedin.com/terseer-shaguy> >>>> <https://www.apple.com/tay> >>>> >>>> >>>> _______________________________________________ >>>> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>>> >>>> >>>> -- >>>> Christoph John >>>> Software Engineering >>>> T +49 241 557...@ma... >>>> >>>> MACD GmbH >>>> Oppenhoffallee 103 >>>> 52066 Aachen, Germanywww.macd.com >>>> >>>> Amtsgericht Aachen: HRB 8151 >>>> Ust.-Id: DE 813021663 >>>> Geschäftsführer: George Macdonald >>>> >>>> _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
From: Philip W. <ph...@wh...> - 2021-06-01 16:21:19
|
I agree that I’d expect a response to an order status request. This is something you need to discuss with your counter-party after reviewing your agreement with them. It may, for example, be that they don’t provide an order status service and expect you to maintain your own state and will just send you updates when the state changes. In that scenario I would hope for a reject but there’s no protocol guarantee. For detailed discussions about FIX as a protocol, rather than technical concerns with QFJ you might benefit from asking on the FIX Trading Community forums. Best, Philip Whitehouse > On 1 Jun 2021, at 16:08, Taysay Shaguy <tay...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello, > > I understand, but wouldn't it better to at least respond and indicate there is no data found or something. > > I am looking in the context of a self service app. So I send a Single order Message D, and I get an execution report or a trade report. > > I may just need to get the status of the my request, so not getting a feedback on a status call is worrisome to me. > > And thus my question, is this a norm in FIX, and if yes, why so? > > Thank you > >> On Tue, Jun 1, 2021, 3:51 PM Christoph John <chr...@ma...> wrote: >> Hi >> I daresay that there is no feedback because the counterparty does not send any?! Did you check with them? >> Cheers >> Chris. >> >> Am 1. Juni 2021 15:19:37 MESZ schrieb Taysay Shaguy <tay...@gm...>: >>> >>> Dear Chris, >>> >>> Thank you for your feedback. >>> >>> Please see sample order status request H, no error message nor feedback. >>> >>> >>> 8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 >>> >>> >>> >>> Terseer (taysay)Shaguy >>> Coding & Digitalization Enthusiast >>> >>> Email: tay...@ya... >>> Phone(s): +2348036533888 >>> >>> >>> >>> >>> >>> >>>> On Tue, Jun 1, 2021 at 12:09 PM Christoph John <chr...@ma...> wrote: >>>> Hi, >>>> >>>> for the same problematic tags there should always be the same error. An example and log file (with both working and not working case) would be helpful. >>>> >>>> Cheers, >>>> Chris. >>>> >>>>> On 01.06.21 12:23, Taysay Shaguy wrote: >>>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>>>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>>>> >>>>> >>>>> >>>>> >>>>> Dear Team, >>>>> >>>>> I am sure you all are staying safe. >>>>> >>>>> Please I am new to FIX, and while I acknowledge it's not a request and response system. >>>>> >>>>> I am integrating to a FIX engine, from a REST interface where I have requests come in via a REST interface, then wrap the requests as FIX messages and push. >>>>> >>>>> I get to validate the feed so, that I can give instant feedback on errors based on defined request parameters. >>>>> >>>>> My issue is when I send a request to the engine without a required tag, say a request which requires tag 541, it bounces back errors. >>>>> >>>>> However, sometimes It just goes quiet without any feedback. Please is this a norm? >>>>> >>>>> Apologies for the looong chat. >>>>> >>>>> >>>>> >>>>> Terseer (taysay)Shaguy >>>>> Coding & Digitalization Enthusiast >>>>> >>>>> Email: tay...@ya... >>>>> Phone(s): +2348036533888 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 |
From: Taysay S. <tay...@gm...> - 2021-06-01 15:06:59
|
Hello, I understand, but wouldn't it better to at least respond and indicate there is no data found or something. I am looking in the context of a self service app. So I send a Single order Message D, and I get an execution report or a trade report. I may just need to get the status of the my request, so not getting a feedback on a status call is worrisome to me. And thus my question, is this a norm in FIX, and if yes, why so? Thank you On Tue, Jun 1, 2021, 3:51 PM Christoph John <chr...@ma...> wrote: > Hi > I daresay that there is no feedback because the counterparty does not send > any?! Did you check with them? > Cheers > Chris. > > Am 1. Juni 2021 15:19:37 MESZ schrieb Taysay Shaguy < > tay...@gm...>: >> >> Dear Chris, >> >> Thank you for your feedback. >> >> Please see sample order status request H, no error message nor feedback. >> >> >> >> 8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 >> >> >> >> Terseer (taysay)Shaguy >> >> Coding & Digitalization Enthusiast >> >> Email: tay...@ya... >> >> Phone(s): +2348036533888 >> >> <https://www.twitter.com/taysay> >> <https://www.linkedin.com/terseer-shaguy> >> <https://www.apple.com/tay> >> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> >> >> >> On Tue, Jun 1, 2021 at 12:09 PM Christoph John <chr...@ma...> >> wrote: >> >>> Hi, >>> >>> for the same problematic tags there should always be the same error. An >>> example and log file (with both working and not working case) would be >>> helpful. >>> >>> Cheers, >>> Chris. >>> >>> On 01.06.21 12:23, Taysay Shaguy wrote: >>> >>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support: http://www.quickfixj.org/support/ >>> >>> >>> Dear Team, >>> >>> I am sure you all are staying safe. >>> >>> Please I am new to FIX, and while I acknowledge it's not a request and >>> response system. >>> >>> I am integrating to a FIX engine, from a REST interface where I have >>> requests come in via a REST interface, then wrap the requests as FIX >>> messages and push. >>> >>> I get to validate the feed so, that I can give instant feedback on >>> errors based on defined request parameters. >>> >>> My issue is when I send a request to the engine without a required tag, >>> say a request which requires tag 541, it bounces back errors. >>> >>> However, sometimes It just goes quiet without any feedback. Please is >>> this a norm? >>> >>> Apologies for the looong chat. >>> >>> >>> Terseer (taysay)Shaguy >>> >>> Coding & Digitalization Enthusiast >>> >>> Email: tay...@ya... >>> >>> Phone(s): +2348036533888 >>> >>> <https://www.twitter.com/taysay> >>> <https://www.linkedin.com/terseer-shaguy> >>> <https://www.apple.com/tay> >>> >>> >>> _______________________________________________ >>> Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users >>> >>> >>> -- >>> Christoph John >>> Software Engineering >>> T +49 241 557...@ma... >>> >>> MACD GmbH >>> Oppenhoffallee 103 >>> 52066 Aachen, Germanywww.macd.com >>> >>> Amtsgericht Aachen: HRB 8151 >>> Ust.-Id: DE 813021663 >>> Geschäftsführer: George Macdonald >>> >>> |
From: Christoph J. <chr...@ma...> - 2021-06-01 14:51:35
|
Hi I daresay that there is no feedback because the counterparty does not send any?! Did you check with them? Cheers Chris. Am 1. Juni 2021 15:19:37 MESZ schrieb Taysay Shaguy <tay...@gm...>: >Dear Chris, > >Thank you for your feedback. > >Please see sample order status request H, no error message nor >feedback. > > >8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 > > > >Terseer (taysay)Shaguy > >Coding & Digitalization Enthusiast > >Email: tay...@ya... > >Phone(s): +2348036533888 > ><https://www.twitter.com/taysay> ><https://www.linkedin.com/terseer-shaguy> ><https://www.apple.com/tay> ><https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> > > >On Tue, Jun 1, 2021 at 12:09 PM Christoph John ><chr...@ma...> >wrote: > >> Hi, >> >> for the same problematic tags there should always be the same error. >An >> example and log file (with both working and not working case) would >be >> helpful. >> >> Cheers, >> Chris. >> >> On 01.06.21 12:23, Taysay Shaguy wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Dear Team, >> >> I am sure you all are staying safe. >> >> Please I am new to FIX, and while I acknowledge it's not a request >and >> response system. >> >> I am integrating to a FIX engine, from a REST interface where I have >> requests come in via a REST interface, then wrap the requests as FIX >> messages and push. >> >> I get to validate the feed so, that I can give instant feedback on >errors >> based on defined request parameters. >> >> My issue is when I send a request to the engine without a required >tag, >> say a request which requires tag 541, it bounces back errors. >> >> However, sometimes It just goes quiet without any feedback. Please is >this >> a norm? >> >> Apologies for the looong chat. >> >> >> Terseer (taysay)Shaguy >> >> Coding & Digitalization Enthusiast >> >> Email: tay...@ya... >> >> Phone(s): +2348036533888 >> >> <https://www.twitter.com/taysay> >> <https://www.linkedin.com/terseer-shaguy> >> <https://www.apple.com/tay> >> >> >> _______________________________________________ >> Quickfixj-users mailing >lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> >> -- >> Christoph John >> Software Engineering >> T +49 241 557...@ma... >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germanywww.macd.com >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> >> |
From: Taysay S. <tay...@gm...> - 2021-06-01 13:19:55
|
Dear Chris, Thank you for your feedback. Please see sample order status request H, no error message nor feedback. 8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 Terseer (taysay)Shaguy Coding & Digitalization Enthusiast Email: tay...@ya... Phone(s): +2348036533888 <https://www.twitter.com/taysay> <https://www.linkedin.com/terseer-shaguy> <https://www.apple.com/tay> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> On Tue, Jun 1, 2021 at 12:09 PM Christoph John <chr...@ma...> wrote: > Hi, > > for the same problematic tags there should always be the same error. An > example and log file (with both working and not working case) would be > helpful. > > Cheers, > Chris. > > On 01.06.21 12:23, Taysay Shaguy wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Dear Team, > > I am sure you all are staying safe. > > Please I am new to FIX, and while I acknowledge it's not a request and > response system. > > I am integrating to a FIX engine, from a REST interface where I have > requests come in via a REST interface, then wrap the requests as FIX > messages and push. > > I get to validate the feed so, that I can give instant feedback on errors > based on defined request parameters. > > My issue is when I send a request to the engine without a required tag, > say a request which requires tag 541, it bounces back errors. > > However, sometimes It just goes quiet without any feedback. Please is this > a norm? > > Apologies for the looong chat. > > > Terseer (taysay)Shaguy > > Coding & Digitalization Enthusiast > > Email: tay...@ya... > > Phone(s): +2348036533888 > > <https://www.twitter.com/taysay> > <https://www.linkedin.com/terseer-shaguy> > <https://www.apple.com/tay> > > > _______________________________________________ > Quickfixj-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Taysay S. <tay...@gm...> - 2021-06-01 13:18:37
|
Dear Philip, Thank you for the feedback. Yes, the translation over Rest is just to ease of use/ access, in the event the partner has no knowledge of FIX. So I send the Order status request. 8=FIXT.1.19=10535=H34=649=SUNTSHA52=20210601-13:14:3056=STT37=01114131148=BONF54=155=XAHE167=CORP541=2021060310=008 There is no error and no response, however, when I omit some tags, it screams. Terseer (taysay)Shaguy Coding & Digitalization Enthusiast Email: tay...@ya... Phone(s): +2348036533888 <https://www.twitter.com/taysay> <https://www.linkedin.com/terseer-shaguy> <https://www.apple.com/tay> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> On Tue, Jun 1, 2021 at 12:25 PM Philip Whitehouse <ph...@wh...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > On a more general level than Chris’s feedback. > > There is no protocol defined “response time requirement” in FIX for an > order to be acknowledged or cancelled or filled except those specified in > the order itself (eg “Good Till Close”). > > In general counter parties tend to agree (implicitly or otherwise) > reasonable execution behaviour and complain if an order is not acked within > a reasonable time period. > > But that can be well beyond a reasonable web request response timeout. > > If you never get a response from a counter-party you should probably > engage them - a session level reject/cancel/business level reject/DK > (depending on the direction you’re working in) would generally be expected > if it’s incorrect (or an ack if it’ll be filled). > > Translating the FIX order state model to a REST API is non-trivial as a > result of this. > > Best, > > Philip Whitehouse > > On 1 Jun 2021, at 11:24, Taysay Shaguy <tay...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Dear Team, > > I am sure you all are staying safe. > > Please I am new to FIX, and while I acknowledge it's not a request and > response system. > > I am integrating to a FIX engine, from a REST interface where I have > requests come in via a REST interface, then wrap the requests as FIX > messages and push. > > I get to validate the feed so, that I can give instant feedback on errors > based on defined request parameters. > > My issue is when I send a request to the engine without a required tag, > say a request which requires tag 541, it bounces back errors. > > However, sometimes It just goes quiet without any feedback. Please is this > a norm? > > Apologies for the looong chat. > > > Terseer (taysay)Shaguy > > Coding & Digitalization Enthusiast > > Email: tay...@ya... > > Phone(s): +2348036533888 > > <https://www.twitter.com/taysay> > <https://www.linkedin.com/terseer-shaguy> > <https://www.apple.com/tay> > <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
From: Ajit G. <aji...@gm...> - 2021-06-01 11:45:34
|
Hi, Is setting the field ValidateUnorderedGroupFields = N is a recommended approach for the production environment? I have built a quickfix acceptor and the test client is sending me the request in an unordered way. Thus, the acceptor rejects the message with "Out of order group members". I am not aware whether setting ValidateUnorderedGroupFields = N will cause any problems or not. Any help would be appreciated. Regards Ajit Gautam |
From: Philip W. <ph...@wh...> - 2021-06-01 11:24:34
|
On a more general level than Chris’s feedback. There is no protocol defined “response time requirement” in FIX for an order to be acknowledged or cancelled or filled except those specified in the order itself (eg “Good Till Close”). In general counter parties tend to agree (implicitly or otherwise) reasonable execution behaviour and complain if an order is not acked within a reasonable time period. But that can be well beyond a reasonable web request response timeout. If you never get a response from a counter-party you should probably engage them - a session level reject/cancel/business level reject/DK (depending on the direction you’re working in) would generally be expected if it’s incorrect (or an ack if it’ll be filled). Translating the FIX order state model to a REST API is non-trivial as a result of this. Best, Philip Whitehouse > On 1 Jun 2021, at 11:24, Taysay Shaguy <tay...@gm...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Dear Team, > > I am sure you all are staying safe. > > Please I am new to FIX, and while I acknowledge it's not a request and response system. > > I am integrating to a FIX engine, from a REST interface where I have requests come in via a REST interface, then wrap the requests as FIX messages and push. > > I get to validate the feed so, that I can give instant feedback on errors based on defined request parameters. > > My issue is when I send a request to the engine without a required tag, say a request which requires tag 541, it bounces back errors. > > However, sometimes It just goes quiet without any feedback. Please is this a norm? > > Apologies for the looong chat. > > > > Terseer (taysay)Shaguy > Coding & Digitalization Enthusiast > > Email: tay...@ya... > Phone(s): +2348036533888 > > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
From: Christoph J. <chr...@ma...> - 2021-06-01 11:10:13
|
Hi, for the same problematic tags there should always be the same error. An example and log file (with both working and not working case) would be helpful. Cheers, Chris. On 01.06.21 12:23, Taysay Shaguy wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Dear Team, > > I am sure you all are staying safe. > > Please I am new to FIX, and while I acknowledge it's not a request and response system. > > I am integrating to a FIX engine, from a REST interface where I have requests come in via a REST > interface, then wrap the requests as FIX messages and push. > > I get to validate the feed so, that I can give instant feedback on errors based on defined request > parameters. > > My issue is when I send a request to the engine without a required tag, say a request which > requires tag 541, it bounces back errors. > > However, sometimes It just goes quiet without any feedback. Please is this a norm? > > Apologies for the looong chat. > > > > > Terseer (taysay)Shaguy > > Coding & Digitalization Enthusiast > > Email: tay...@ya... <mailto:tay...@ya...> > > Phone(s): +2348036533888 <tel:+2348036533888> > > <https://www.twitter.com/taysay> > > > <https://www.linkedin.com/terseer-shaguy> > > > > > <https://www.apple.com/tay> > > > > _______________________________________________ > 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: Taysay S. <tay...@gm...> - 2021-06-01 10:23:44
|
Dear Team, I am sure you all are staying safe. Please I am new to FIX, and while I acknowledge it's not a request and response system. I am integrating to a FIX engine, from a REST interface where I have requests come in via a REST interface, then wrap the requests as FIX messages and push. I get to validate the feed so, that I can give instant feedback on errors based on defined request parameters. My issue is when I send a request to the engine without a required tag, say a request which requires tag 541, it bounces back errors. However, sometimes It just goes quiet without any feedback. Please is this a norm? Apologies for the looong chat. Terseer (taysay)Shaguy Coding & Digitalization Enthusiast Email: tay...@ya... Phone(s): +2348036533888 <https://www.twitter.com/taysay> <https://www.linkedin.com/terseer-shaguy> <https://www.apple.com/tay> <https://signature.disha.ng/?utm_source=disha&utm_medium=email_signature> |
From: Ajit G. <aji...@gm...> - 2021-06-01 04:50:10
|
Thanks Chris. That's really helpful. Regards Ajit Gautam On Tue, Jun 1, 2021, 03:45 Christoph John <chr...@ma...> wrote: > Hi Ajit, > > On 31.05.21 15:37, Ajit Gautam wrote: > > Thanks chris. It was a configuration problem. But, mostly I see in FIX > manuals, institutions follow one port per session. > Is this option available only with Quickfix/J? > > I am pretty sure that more FIX engines than QFJ offer this option. > Probably it is more convenient to have clients separated per port, e.g. > for a tcp dump or to create a specific allow-rule in a firewall. > > > Apart from heavy traffic on a single port, I cannot see any problem. > Does this approach of one port for all sessions have any disadvantages? > > See above. Moreover, most of the time one port means one process. I.e. > when you only have one process listening on that port and that process goes > down, all clients have a problem. > > > Also, I was curious to know how quickfix handles all sessions on one port. > I will appreciate it if you elaborate on the concept behind it. > > I mean the concept is not new. Every server component handles clients on > the same port... ;) > If you mean how QFJ can tell the different sessions apart: it simply looks > at the SessionID of the FIX message and forwards the message to that > Session instance. > The relevant code is here: > https://github.com/quickfix-j/quickfixj/blob/7e3a07104cd8bfaf7e704896dd668b767c9aa13b/quickfixj-core/src/main/java/quickfix/mina/acceptor/AcceptorIoHandler.java#L62 > > > Adding to the same approach, can we create a setting which can > differentiate identical sessions(Same sender ID, TargetID and port). > > You could use a SessionQualifier, but that is only available for > initiators. I would also not recommend to use it. At the beginning of this > document there are a few words about it: > https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html > The SessionID should be unique, so there shouldn't be any identical > sessions. You could add e.g. a SenderSubID to tell different sessions apart. > > Cheers, > Chris. > > > > Regards > Ajit Gautam > > On Mon, May 31, 2021 at 5:16 PM Christoph John <chr...@ma...> > wrote: > >> Hi, >> >> we are doing something similar and run almost 100 sessions all via the >> same acceptor port. So if something is "blocking" on your side it most >> likely is a configuration or application problem. >> >> Cheers, >> Chris. >> >> >> On 31.05.21 13:10, Ajit Gautam wrote: >> >> Hi Chris, >> >> Thanks for acknowledging. >> I will share the log soon. >> >> Just to confirm you, I am running one FIX acceptor with multiple >> sessions. Each session is established by a Unique SenderID and XYZ Target >> ID (Target ID is the same for all sessions) and a dedicated port for each >> session. >> >> I ran a FIX acceptor with multiple sessions configured on the *same port >> *with a unique Sender ID of each session and Target ID XYZ same for all >> sessions. >> >> Regards >> Ajit Gautam >> >> On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma...> >> wrote: >> >>> Are you maybe starting multiple Acceptors? I definitely works when using >>> one Acceptor with multiple configured sessions. >>> What do you mean by "gets blocked"? A log file would be helpful. >>> >>> Cheers, >>> Chris. >>> >>> On 31.05.21 11:44, Ajit Gautam wrote: >>> >>> Hi, >>> >>> I have a FIX Acceptor trading session with each port assigned to one >>> member. This results in opening multiple ports at the firewall which >>> doesn't look a viable option. >>> I tried keeping the same port for a few members(different sender ID >>> connecting to the same port), but the session I start second gets blocked >>> by the first. >>> >>> Any help would be appreciated. >>> >>> Regards >>> Ajit Gautam >>> >>> On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma...> >>> wrote: >>> >>>> What keeps you from configuring the same SocketAcceptPort for all >>>> sessions in your acceptor config file? >>>> >>>> Chris >>>> >>>> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam < >>>> aji...@gm...>: >>>>> >>>>> Hi, >>>>> >>>>> I have a FIX acceptor which connects with Client FIX initiators with a >>>>> separate port for each session assigned to each client. >>>>> I was thinking of modifying the approach of having a separate port for >>>>> each session to one port for all the members. >>>>> >>>>> Is there an implementation available in Quickfix/J for such a setup >>>>> which assigns single port and IP to all the Client FIX initiators? >>>>> >>>>> >>>>> Regards >>>>> Ajit Gautam >>>>> >>>> >>> -- >>> Christoph John >>> Software Engineering >>> T +49 241 557...@ma... >>> >>> MACD GmbH >>> Oppenhoffallee 103 >>> 52066 Aachen, Germanywww.macd.com >>> >>> Amtsgericht Aachen: HRB 8151 >>> Ust.-Id: DE 813021663 >>> Geschäftsführer: George Macdonald >>> >>> >> -- >> Christoph John >> Software Engineering >> T +49 241 557...@ma... >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germanywww.macd.com >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> >> > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-05-31 22:16:05
|
Hi Ajit, On 31.05.21 15:37, Ajit Gautam wrote: > Thanks chris. It was a configuration problem. But, mostly I see in FIX manuals, institutions > follow one port per session. > Is this option available only with Quickfix/J? I am pretty sure that more FIX engines than QFJ offer this option. Probably it is more convenient to have clients separated per port, e.g. for a tcp dump or to create a specific allow-rule in a firewall. > > Apart from heavy traffic on a single port, I cannot see any problem. > Does this approach of one port for all sessions have any disadvantages? See above. Moreover, most of the time one port means one process. I.e. when you only have one process listening on that port and that process goes down, all clients have a problem. > > Also, I was curious to know how quickfix handles all sessions on one port. I will appreciate it if > you elaborate on the concept behind it. I mean the concept is not new. Every server component handles clients on the same port... ;) If you mean how QFJ can tell the different sessions apart: it simply looks at the SessionID of the FIX message and forwards the message to that Session instance. The relevant code is here: https://github.com/quickfix-j/quickfixj/blob/7e3a07104cd8bfaf7e704896dd668b767c9aa13b/quickfixj-core/src/main/java/quickfix/mina/acceptor/AcceptorIoHandler.java#L62 > > Adding to the same approach, can we create a setting which can differentiate identical > sessions(Same sender ID, TargetID and port). You could use a SessionQualifier, but that is only available for initiators. I would also not recommend to use it. At the beginning of this document there are a few words about it: https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html The SessionID should be unique, so there shouldn't be any identical sessions. You could add e.g. a SenderSubID to tell different sessions apart. Cheers, Chris. > > > Regards > Ajit Gautam > > On Mon, May 31, 2021 at 5:16 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi, > > we are doing something similar and run almost 100 sessions all via the same acceptor port. So > if something is "blocking" on your side it most likely is a configuration or application problem. > > Cheers, > Chris. > > > On 31.05.21 13:10, Ajit Gautam wrote: >> Hi Chris, >> >> Thanks for acknowledging. >> I will share the log soon. >> >> Just to confirm you, I am running one FIX acceptor with multiple sessions. Each session is >> established by a Unique SenderID and XYZ Target ID (Target ID is the same for all sessions) >> and a dedicated port for each session. >> >> I ran a FIX acceptor with multiple sessions configured on the *same port *with a unique >> Sender ID of each session and Target ID XYZ same for all sessions. >> >> Regards >> Ajit Gautam >> >> On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma... >> <mailto:chr...@ma...>> wrote: >> >> Are you maybe starting multiple Acceptors? I definitely works when using one Acceptor >> with multiple configured sessions. >> What do you mean by "gets blocked"? A log file would be helpful. >> >> Cheers, >> Chris. >> >> On 31.05.21 11:44, Ajit Gautam wrote: >>> Hi, >>> >>> I have a FIX Acceptor trading session with each port assigned to one member. This >>> results in opening multiple ports at the firewall which doesn't look a viable option. >>> I tried keeping the same port for a few members(different sender ID connecting to the >>> same port), but the session I start second gets blocked by the first. >>> >>> Any help would be appreciated. >>> >>> Regards >>> Ajit Gautam >>> >>> On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma... >>> <mailto:chr...@ma...>> wrote: >>> >>> What keeps you from configuring the same SocketAcceptPort for all sessions in your >>> acceptor config file? >>> >>> Chris >>> >>> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <aji...@gm... >>> <mailto:aji...@gm...>>: >>> >>> Hi, >>> >>> I have a FIX acceptor which connects with Client FIX initiators with a separate >>> port for each session assigned to each client. >>> I was thinking of modifying the approach of having a separate port for each >>> session to one port for all the members. >>> >>> Is there an implementation available in Quickfix/J for such a setup which >>> assigns single port and IP to all the Client FIX initiators? >>> >>> >>> Regards >>> Ajit Gautam >>> >> >> -- >> Christoph John >> Software Engineering >> T +49 241 557080-28 >> chr...@ma... <mailto:chr...@ma...> >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germany >> www.macd.com <http://www.macd.com> >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> > > -- > 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: Ajit G. <aji...@gm...> - 2021-05-31 13:38:01
|
Thanks chris. It was a configuration problem. But, mostly I see in FIX manuals, institutions follow one port per session. Is this option available only with Quickfix/J? Apart from heavy traffic on a single port, I cannot see any problem. Does this approach of one port for all sessions have any disadvantages? Also, I was curious to know how quickfix handles all sessions on one port. I will appreciate it if you elaborate on the concept behind it. Adding to the same approach, can we create a setting which can differentiate identical sessions(Same sender ID, TargetID and port). Regards Ajit Gautam On Mon, May 31, 2021 at 5:16 PM Christoph John <chr...@ma...> wrote: > Hi, > > we are doing something similar and run almost 100 sessions all via the > same acceptor port. So if something is "blocking" on your side it most > likely is a configuration or application problem. > > Cheers, > Chris. > > > On 31.05.21 13:10, Ajit Gautam wrote: > > Hi Chris, > > Thanks for acknowledging. > I will share the log soon. > > Just to confirm you, I am running one FIX acceptor with multiple sessions. > Each session is established by a Unique SenderID and XYZ Target ID (Target > ID is the same for all sessions) and a dedicated port for each session. > > I ran a FIX acceptor with multiple sessions configured on the *same port *with > a unique Sender ID of each session and Target ID XYZ same for all sessions. > > Regards > Ajit Gautam > > On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma...> > wrote: > >> Are you maybe starting multiple Acceptors? I definitely works when using >> one Acceptor with multiple configured sessions. >> What do you mean by "gets blocked"? A log file would be helpful. >> >> Cheers, >> Chris. >> >> On 31.05.21 11:44, Ajit Gautam wrote: >> >> Hi, >> >> I have a FIX Acceptor trading session with each port assigned to one >> member. This results in opening multiple ports at the firewall which >> doesn't look a viable option. >> I tried keeping the same port for a few members(different sender ID >> connecting to the same port), but the session I start second gets blocked >> by the first. >> >> Any help would be appreciated. >> >> Regards >> Ajit Gautam >> >> On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma...> >> wrote: >> >>> What keeps you from configuring the same SocketAcceptPort for all >>> sessions in your acceptor config file? >>> >>> Chris >>> >>> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam < >>> aji...@gm...>: >>>> >>>> Hi, >>>> >>>> I have a FIX acceptor which connects with Client FIX initiators with a >>>> separate port for each session assigned to each client. >>>> I was thinking of modifying the approach of having a separate port for >>>> each session to one port for all the members. >>>> >>>> Is there an implementation available in Quickfix/J for such a setup >>>> which assigns single port and IP to all the Client FIX initiators? >>>> >>>> >>>> Regards >>>> Ajit Gautam >>>> >>> >> -- >> Christoph John >> Software Engineering >> T +49 241 557...@ma... >> >> MACD GmbH >> Oppenhoffallee 103 >> 52066 Aachen, Germanywww.macd.com >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> >> > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-05-31 11:46:49
|
Hi, we are doing something similar and run almost 100 sessions all via the same acceptor port. So if something is "blocking" on your side it most likely is a configuration or application problem. Cheers, Chris. On 31.05.21 13:10, Ajit Gautam wrote: > Hi Chris, > > Thanks for acknowledging. > I will share the log soon. > > Just to confirm you, I am running one FIX acceptor with multiple sessions. Each session is > established by a Unique SenderID and XYZ Target ID (Target ID is the same for all sessions) and a > dedicated port for each session. > > I ran a FIX acceptor with multiple sessions configured on the *same port *with a unique Sender ID > of each session and Target ID XYZ same for all sessions. > > Regards > Ajit Gautam > > On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Are you maybe starting multiple Acceptors? I definitely works when using one Acceptor with > multiple configured sessions. > What do you mean by "gets blocked"? A log file would be helpful. > > Cheers, > Chris. > > On 31.05.21 11:44, Ajit Gautam wrote: >> Hi, >> >> I have a FIX Acceptor trading session with each port assigned to one member. This results in >> opening multiple ports at the firewall which doesn't look a viable option. >> I tried keeping the same port for a few members(different sender ID connecting to the >> same port), but the session I start second gets blocked by the first. >> >> Any help would be appreciated. >> >> Regards >> Ajit Gautam >> >> On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma... >> <mailto:chr...@ma...>> wrote: >> >> What keeps you from configuring the same SocketAcceptPort for all sessions in your >> acceptor config file? >> >> Chris >> >> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <aji...@gm... >> <mailto:aji...@gm...>>: >> >> Hi, >> >> I have a FIX acceptor which connects with Client FIX initiators with a separate port >> for each session assigned to each client. >> I was thinking of modifying the approach of having a separate port for each session >> to one port for all the members. >> >> Is there an implementation available in Quickfix/J for such a setup which assigns >> single port and IP to all the Client FIX initiators? >> >> >> Regards >> Ajit Gautam >> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Ajit G. <aji...@gm...> - 2021-05-31 11:11:20
|
Hi Chris, Thanks for acknowledging. I will share the log soon. Just to confirm you, I am running one FIX acceptor with multiple sessions. Each session is established by a Unique SenderID and XYZ Target ID (Target ID is the same for all sessions) and a dedicated port for each session. I ran a FIX acceptor with multiple sessions configured on the *same port *with a unique Sender ID of each session and Target ID XYZ same for all sessions. Regards Ajit Gautam On Mon, May 31, 2021 at 3:17 PM Christoph John <chr...@ma...> wrote: > Are you maybe starting multiple Acceptors? I definitely works when using > one Acceptor with multiple configured sessions. > What do you mean by "gets blocked"? A log file would be helpful. > > Cheers, > Chris. > > On 31.05.21 11:44, Ajit Gautam wrote: > > Hi, > > I have a FIX Acceptor trading session with each port assigned to one > member. This results in opening multiple ports at the firewall which > doesn't look a viable option. > I tried keeping the same port for a few members(different sender ID > connecting to the same port), but the session I start second gets blocked > by the first. > > Any help would be appreciated. > > Regards > Ajit Gautam > > On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma...> > wrote: > >> What keeps you from configuring the same SocketAcceptPort for all >> sessions in your acceptor config file? >> >> Chris >> >> Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam < >> aji...@gm...>: >>> >>> Hi, >>> >>> I have a FIX acceptor which connects with Client FIX initiators with a >>> separate port for each session assigned to each client. >>> I was thinking of modifying the approach of having a separate port for >>> each session to one port for all the members. >>> >>> Is there an implementation available in Quickfix/J for such a setup >>> which assigns single port and IP to all the Client FIX initiators? >>> >>> >>> Regards >>> Ajit Gautam >>> >> > -- > Christoph John > Software Engineering > T +49 241 557...@ma... > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germanywww.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > |
From: Christoph J. <chr...@ma...> - 2021-05-31 09:47:33
|
Are you maybe starting multiple Acceptors? I definitely works when using one Acceptor with multiple configured sessions. What do you mean by "gets blocked"? A log file would be helpful. Cheers, Chris. On 31.05.21 11:44, Ajit Gautam wrote: > Hi, > > I have a FIX Acceptor trading session with each port assigned to one member. This results in > opening multiple ports at the firewall which doesn't look a viable option. > I tried keeping the same port for a few members(different sender ID connecting to the same port), > but the session I start second gets blocked by the first. > > Any help would be appreciated. > > Regards > Ajit Gautam > > On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > What keeps you from configuring the same SocketAcceptPort for all sessions in your acceptor > config file? > > Chris > > Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <aji...@gm... > <mailto:aji...@gm...>>: > > Hi, > > I have a FIX acceptor which connects with Client FIX initiators with a separate port for > each session assigned to each client. > I was thinking of modifying the approach of having a separate port for each session to one > port for all the members. > > Is there an implementation available in Quickfix/J for such a setup which assigns single > port and IP to all the Client FIX initiators? > > > Regards > Ajit Gautam > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
From: Ajit G. <aji...@gm...> - 2021-05-31 09:45:15
|
Hi, I have a FIX Acceptor trading session with each port assigned to one member. This results in opening multiple ports at the firewall which doesn't look a viable option. I tried keeping the same port for a few members(different sender ID connecting to the same port), but the session I start second gets blocked by the first. Any help would be appreciated. Regards Ajit Gautam On Thu, May 27, 2021 at 10:15 PM Christoph John <chr...@ma...> wrote: > What keeps you from configuring the same SocketAcceptPort for all sessions > in your acceptor config file? > > Chris > > Am 27. Mai 2021 17:50:22 MESZ schrieb Ajit Gautam <aji...@gm... > >: >> >> Hi, >> >> I have a FIX acceptor which connects with Client FIX initiators with a >> separate port for each session assigned to each client. >> I was thinking of modifying the approach of having a separate port for >> each session to one port for all the members. >> >> Is there an implementation available in Quickfix/J for such a setup which >> assigns single port and IP to all the Client FIX initiators? >> >> >> Regards >> Ajit Gautam >> > |
From: Christoph J. <chr...@ma...> - 2021-05-28 21:23:34
|
You could implement your own quickfix.Log and obfuscate the unwanted tags in the onIncoming/onOutgoing callbacks. Chris. On 28.05.21 13:38, Ajit Gautam wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Hi, > > I have a Quickfix acceptor and a custom message for user logon and response. > I am using Quickfix libraries and logging the messages. In the quickfix message log, user name and > password are getting logged. But, I don't want to log the password field > Is there a way or work around that avoids logging only the password field on a user logon request > message? > > > > Regards > Ajit Gautam > > > _______________________________________________ > 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: Grant B. <gbi...@co...> - 2021-05-28 15:50:38
|
Unsubscribe yourself! Click the link at the bottom. On Fri, May 28, 2021 at 10:02 AM Vamsi Pinnamaneni < vam...@we...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ > > > > > -- > Regards, > Vamsi Krishna Pinnamaneni > > The information contained in this message may be confidential and is > intended for the addressee only. If you don't think this email is meant for > you, please let us know. Do not copy or forward the information it > contains, and delete this email from your system. Any personal views or > opinions are those of the author and do not necessarily represent those of > Wealth Objects Limited. This email does not create or vary any contractual > obligations between Wealth Objects Limited and the addressee. > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com -- This email, along with any attachments, is confidential. If you believe you received this message in error, please contact the sender immediately and delete all copies of the message. Thank you from Connamara Systems, LLC. |
From: Vamsi P. <vam...@we...> - 2021-05-28 15:02:20
|
-- Regards, Vamsi Krishna Pinnamaneni The information contained in this message may be confidential and is intended for the addressee only. If you don't think this email is meant for you, please let us know. Do not copy or forward the information it contains, and delete this email from your system. Any personal views or opinions are those of the author and do not necessarily represent those of Wealth Objects Limited. This email does not create or vary any contractual obligations between Wealth Objects Limited and the addressee. |
From: Philip W. <ph...@wh...> - 2021-05-28 12:40:13
|
See https://github.com/quickfix-j/quickfixj/issues/330 Best, Philip Whitehouse > On 28 May 2021, at 12:39, Ajit Gautam <aji...@gm...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > I have a Quickfix acceptor and a custom message for user logon and response. > I am using Quickfix libraries and logging the messages. In the quickfix message log, user name and password are getting logged. But, I don't want to log the password field > Is there a way or work around that avoids logging only the password field on a user logon request message? > > > > Regards > Ajit Gautam > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |