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: Sean L. <sea...@ic...> - 2018-04-18 16:43:03
|
Actually, that seems to have answered my question. I added all of these as config: AllowUnknownMsgFields ='Y' ValidateUserDefinedFields ='N' ValidateFieldsOutOfOrder='N' ValidateUnorderedGroupFields ='N' ValidateIncomingMessage ='N' And now I get the entire message. Thank you! On 4/17/18 11:32 AM, Colin DuPlantis wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > FieldsOutOfOrder ? > > Can you give us a sample message (redacted as necessary)? > > > On 04/17/2018 10:15 AM, Sean LeBlanc wrote: >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hello, >> >> >> With Quickfix 1.6.3, as the initiator, I'm trying accept sent >> messages that violate the given data dictionary. I've tried a few >> things: >> >> 1. Setting UseDataDictionary to 'N'. This seems to work to get a >> corresponding message, but the application doesn't seem to get the >> entire message. The app gets a message, but it looks like it has >> fewer fields than the message logged in QuickFix/J's message log. >> >> 2. Setting AllowUnknownMsgFields to 'Y' and ValidateUserDefinedFields >> to 'N'. This seems to have no effect? QuickFix/J still seems to >> reject the message beforehand. >> >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Christoph J. <chr...@ma...> - 2018-04-18 07:01:35
|
Hi, I would try with ValidateIncomingMessage=N and UseDataDictionary=Y (since it is needed for parsing repeating groups correctly). But as Philip already said I'd advise to upgrade to 2.0.0 since there were some fixes around message validation. Cheers, Chris. On 17/04/18 19:15, Sean LeBlanc wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello, > > > With Quickfix 1.6.3, as the initiator, I'm trying accept sent messages that violate the given data > dictionary. I've tried a few things: > > 1. Setting UseDataDictionary to 'N'. This seems to work to get a corresponding message, but the > application doesn't seem to get the entire message. The app gets a message, but it looks like it > has fewer fields than the message logged in QuickFix/J's message log. > > 2. Setting AllowUnknownMsgFields to 'Y' and ValidateUserDefinedFields to 'N'. This seems to have > no effect? QuickFix/J still seems to reject the message beforehand. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Colin D. <co...@ma...> - 2018-04-17 18:00:55
|
FieldsOutOfOrder ? Can you give us a sample message (redacted as necessary)? On 04/17/2018 10:15 AM, Sean LeBlanc wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hello, > > > With Quickfix 1.6.3, as the initiator, I'm trying accept sent messages > that violate the given data dictionary. I've tried a few things: > > 1. Setting UseDataDictionary to 'N'. This seems to work to get a > corresponding message, but the application doesn't seem to get the > entire message. The app gets a message, but it looks like it has fewer > fields than the message logged in QuickFix/J's message log. > > 2. Setting AllowUnknownMsgFields to 'Y' and ValidateUserDefinedFields > to 'N'. This seems to have no effect? QuickFix/J still seems to reject > the message beforehand. > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 +1.541.306.6556 http://www.marketcetera.org |
|
From: Philip W. <ph...@wh...> - 2018-04-17 17:34:32
|
There's a known bug in QFJ 1.6 where Validate User-defined fields doesn't work properly. On 17 April 2018 18:15:53 BST, Sean LeBlanc <sea...@ic...> wrote: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ > > >Hello, > > >With Quickfix 1.6.3, as the initiator, I'm trying accept sent messages >that violate the given data dictionary. I've tried a few things: > >1. Setting UseDataDictionary to 'N'. This seems to work to get a >corresponding message, but the application doesn't seem to get the >entire message. The app gets a message, but it looks like it has fewer >fields than the message logged in QuickFix/J's message log. > >2. Setting AllowUnknownMsgFields to 'Y' and ValidateUserDefinedFields >to >'N'. This seems to have no effect? QuickFix/J still seems to reject the > >message beforehand. > > >------------------------------------------------------------------------------ >Check out the vibrant tech community on one of the world's most >engaging tech sites, Slashdot.org! http://sdm.link/slashdot >_______________________________________________ >Quickfixj-users mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
From: Sean L. <sea...@ic...> - 2018-04-17 17:31:26
|
Hello, With Quickfix 1.6.3, as the initiator, I'm trying accept sent messages that violate the given data dictionary. I've tried a few things: 1. Setting UseDataDictionary to 'N'. This seems to work to get a corresponding message, but the application doesn't seem to get the entire message. The app gets a message, but it looks like it has fewer fields than the message logged in QuickFix/J's message log. 2. Setting AllowUnknownMsgFields to 'Y' and ValidateUserDefinedFields to 'N'. This seems to have no effect? QuickFix/J still seems to reject the message beforehand. |
|
From: Christoph J. <chr...@ma...> - 2018-04-17 07:46:04
|
Hi, the classes are generated from the DD "FIX44.modified.xml". This modified version has some minor corrections which do not result in uncompilable code. So please do your changes in FIX44.modified.xmland try again. Cheers, Chris. On 17/04/18 04:31, Lakshmi wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi Team, > > Am trying to rebuild Quickfixj 2.0.0 using Maven.I ahve updated/Added new > message in Datadictionary > in location > *quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.xml* > shown below. > <message name="CustomSecurityDefinition" msgtype="UDS" msgcat="app"> > <field name="SecurityReqID" required="Y"/> > <field name="SecurityResponseID" required="Y"/> > <field name="SecurityResponseType" required="Y" /> > <field name="Symbol" required="Y"/> > <field name="SecurityID" required="N"/> > <field name="SecurityIDSource" required="N"/> > <field name="SecurityExchange" required="N"/> > <field name="StrategySecurityID" required="N"/> > <field name="UnderlyingStrategySymbol" required="N"/> > --- > </messages> > After making these changes in the FIX44.xml file i have executed below > command > mvn clean install -Dmaven.test.skip=true. > After rebuilding it generated quickfixj-messages-fix44-2.0.0.jar file > inside target folder of quickfixj-messages\quickfixj-messages-fix44\. > > But when i look into the contents/classes of this generated jat file i could > see any new class with name CustomSecurityDefinition.Last time i have > rebuild quickfixj-1.4.0 using ant , at that time i could see that a new > class is genarted with name CustomSecurityDefinition. > So can someone help in sorting my issue. > > > > > -- > Sent from: http://quickfix-j.364392.n2.nabble.com/ > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Lakshmi <Lak...@uk...> - 2018-04-17 02:48:56
|
Hi Team,
Am trying to rebuild Quickfixj 2.0.0 using Maven.I ahve updated/Added new
message in Datadictionary
in location
*quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.xml*
shown below.
<message name="CustomSecurityDefinition" msgtype="UDS" msgcat="app">
<field name="SecurityReqID" required="Y"/>
<field name="SecurityResponseID" required="Y"/>
<field name="SecurityResponseType" required="Y" />
<field name="Symbol" required="Y"/>
<field name="SecurityID" required="N"/>
<field name="SecurityIDSource" required="N"/>
<field name="SecurityExchange" required="N"/>
<field name="StrategySecurityID" required="N"/>
<field name="UnderlyingStrategySymbol" required="N"/>
---
</messages>
After making these changes in the FIX44.xml file i have executed below
command
mvn clean install -Dmaven.test.skip=true.
After rebuilding it generated quickfixj-messages-fix44-2.0.0.jar file
inside target folder of quickfixj-messages\quickfixj-messages-fix44\.
But when i look into the contents/classes of this generated jat file i could
see any new class with name CustomSecurityDefinition.Last time i have
rebuild quickfixj-1.4.0 using ant , at that time i could see that a new
class is genarted with name CustomSecurityDefinition.
So can someone help in sorting my issue.
--
Sent from: http://quickfix-j.364392.n2.nabble.com/
|
|
From: Philip W. <ph...@wh...> - 2018-04-16 12:32:54
|
<div dir='auto'><div>Yes you will need to modify QFJ. Yes this allowed. </div><div dir="auto"><br></div><div dir="auto">There are some conditions associated with redistribution which you should be following regardless. The license is pretty short so it's worth a read!</div><div dir="auto"><br></div><div dir="auto">Consider also submitting your changes in a PR so that everyone can benefit - that's how the library improves :)<br></div><div dir="auto"><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 16 Apr 2018 12:50, Ravi Nemala <rav...@gm...> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi,<br><br></div>I am using the QuickFix library to parse the FIX messages in FIX4.0 - FIX4.4 versions. Consider a record that has multiple errors: like one missing mandatory field and one field of wrong type.<br></div>The parser just throws an error on encountering the first error(Missing mandatory field in the above case) and returns. <br></div>I want to capture all the errors present in each record. Do I have to modify the QuickFIX code for this or any mechanism already exists already?<br></div>If I have to modify the code, are the modifications allowed as part of QuickFIX license agreement?<br><br></div>Regards,<br></div>Ravi<br></div> </blockquote></div><br></div></div></div> |
|
From: Ravi N. <rav...@gm...> - 2018-04-16 11:51:04
|
Hi, I am using the QuickFix library to parse the FIX messages in FIX4.0 - FIX4.4 versions. Consider a record that has multiple errors: like one missing mandatory field and one field of wrong type. The parser just throws an error on encountering the first error(Missing mandatory field in the above case) and returns. I want to capture all the errors present in each record. Do I have to modify the QuickFIX code for this or any mechanism already exists already? If I have to modify the code, are the modifications allowed as part of QuickFIX license agreement? Regards, Ravi |
|
From: Christoph J. <chr...@ma...> - 2018-04-10 07:38:29
|
Unfortunately I'm not familiar with XSL either.
But e.g. the group TradeCaptureReport.NoLegs.NoNestedPartyIDs.NoNestedPartySubIDs is also nested in
a component inside another component, isn't it? And that group works.
However, it seems that NestedPartyIDs component has a repeating group as start of the component,
whereas the problematic components UnderlyingLegInstrument and InstrumentLeg have the repeating
group further down in the list.
One thing you could try is to move e.g. the LegSecAltIDGrp directly to the start of the
InstrumentLeg component and recompile QFJ. If the generated code then has the
NoLegs.NoLegSecurityAltID group we only need to find out how to fix the XSL. ;)
Chris.
On 09/04/18 21:06, eri...@th... wrote:
> I’m not very experienced with XSL, but is it because the group is nested in a component inside
> another component?
>
> Does this:
>
> <xsl:template mode="group-factories" match="component"><xsl:param name="fullPath"/><xsl:variable
> name="name" select="@name"/><xsl:apply-templates mode="group-factories"
> select="/fix/components/component[@name=$name]/group"><xsl:with-param name="fullPath"
> select='$fullPath'/></xsl:apply-templates></xsl:template>
> Need a way to look for components another level deeper in the path? I don’t know how to do that.
>
> -------------------------
> Eric Goebelbecker
> eri...@th... <mailto:eri...@th...>
>
>
>
>> On Apr 6, 2018, at 17:33, Christoph John via Quickfixj-users
>> <qui...@li... <mailto:qui...@li...>> wrote:
>>
>>
>> Hi,
>>
>> strange, the generated code is indeed missing that group (along with group 1334
>> NoUnderlyingLegSecurityAltID). All other groups of the NoLegs group seem to be there:
>>
>> case quickfix.field.NoLegs.FIELD:
>> return new quickfix.fix50sp2.TradeCaptureReport.NoLegs();
>>
>> case quickfix.field.NoLegStipulations.FIELD:
>> return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoLegStipulations();
>>
>> case quickfix.field.NoNestedPartyIDs.FIELD:
>> return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoNestedPartyIDs();
>>
>> case quickfix.field.NoNestedPartySubIDs.FIELD:
>> return new
>> quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoNestedPartyIDs.NoNestedPartySubIDs();
>>
>> case quickfix.field.NoOfLegUnderlyings.FIELD:
>> return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoOfLegUnderlyings();
>>
>> Groups NoUnderlyingLegSecurityAltID and NoLegSecurityAltID are missing.
>> Seems to be an error with the code generation but at first glance I cannot tell why some
>> groupsare working and others not.
>>
>> Chris.
>>
>>
>> On 06/04/18 22:36,eri...@th...
>> <mailto:eri...@th...>wrote:
>>>
>>> Here it is, somewhat distilled:
>>>
>>>
>>> @Test
>>> public void yesItisMissing() {
>>>
>>> MessageFactory factory = new quickfix.fix50sp2.MessageFactory();
>>>
>>> Group goodGroup = factory.create(FixVersions.FIX50SP2, "AE", 1120);
>>>
>>> assertNotNull(goodGroup);
>>>
>>> Group badGroup = factory.create(FixVersions.FIX50SP2, "AE", 604);
>>>
>>> assertNull(badGroup);
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Apr 6, 2018, at 15:12, Colin DuPlantis <co...@ma...
>>>> <mailto:co...@ma...><mailto:co...@ma...>> wrote:
>>>>
>>>>
>>>> Can you give us a code snippet?
>>>>
--
Christoph John
Development & Support
T +49 241 557080-28
chr...@ma...
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
www.macd.com
Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald
|
|
From: Christoph J. <chr...@ma...> - 2018-04-06 22:00:51
|
Hi, strange, the generated code is indeed missing that group (along with group 1334 NoUnderlyingLegSecurityAltID). All other groups of the NoLegs group seem to be there: case quickfix.field.NoLegs.FIELD: return new quickfix.fix50sp2.TradeCaptureReport.NoLegs(); case quickfix.field.NoLegStipulations.FIELD: return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoLegStipulations(); case quickfix.field.NoNestedPartyIDs.FIELD: return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoNestedPartyIDs(); case quickfix.field.NoNestedPartySubIDs.FIELD: return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoNestedPartyIDs.NoNestedPartySubIDs(); case quickfix.field.NoOfLegUnderlyings.FIELD: return new quickfix.fix50sp2.TradeCaptureReport.NoLegs.NoOfLegUnderlyings(); Groups NoUnderlyingLegSecurityAltID and NoLegSecurityAltID are missing. Seems to be an error with the code generation but at first glance I cannot tell why some groupsare working and others not. Chris. On 06/04/18 22:36, eri...@th... wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Here it is, somewhat distilled: > > > @Test > public void yesItisMissing() { > > MessageFactory factory = new quickfix.fix50sp2.MessageFactory(); > > Group goodGroup = factory.create(FixVersions.FIX50SP2, "AE", 1120); > > assertNotNull(goodGroup); > > Group badGroup = factory.create(FixVersions.FIX50SP2, "AE", 604); > > assertNull(badGroup); > > } > > > > > > >> On Apr 6, 2018, at 15:12, Colin DuPlantis <co...@ma... >> <mailto:co...@ma...>> wrote: >> >> QuickFIX/J Documentation: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=arxbs1eiCyw_yg7yfUMPGVP3ZNKnFenCEMeytWvqIIM&e= >> QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http- >> <https://urldefense.proofpoint.com/v2/url?u=http->3A__www.quickfixj.org_support_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=EqFUknfI6RI5HTV4qrrbCNiLBxBsYMsHt9HO5qWw1xg&e= >> >> >> Can you give us a code snippet? >> >> >> On 04/06/2018 09:09 AM, eri...@th... >> <mailto:eri...@th...> wrote: >>> QuickFIX/J Documentation: >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=arxbs1eiCyw_yg7yfUMPGVP3ZNKnFenCEMeytWvqIIM&e= >>> QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http- >>> <https://urldefense.proofpoint.com/v2/url?u=http->3A__www.quickfixj.org_support_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=EqFUknfI6RI5HTV4qrrbCNiLBxBsYMsHt9HO5qWw1xg&e= >>> >>> >>> I am trying to process a TradeCaptureReport (AE) message in FIX 5.0SP2 >>> >>> Based on the spec, one of the optional components is TrdInstrmtLegGrp. >>> >>> Looking the dictionary In see it there in the message definition: >>> >>> (It’s huge, so I am not including the entire message.) >>> >>> <component name="TrdInstrmtLegGrp" required="N”/> >>> >>> The component is defined with an InstrumentLeg: >>> >>> <component name="InstrumentLeg" required="N”/> <- I’m interested in this guy >>> >>> Which has a LegSecAltIDGrp: >>> >>> <component name="LegSecAltIDGrp" required="N"/> >>> >>> Which is this: >>> >>> <component name="LegSecAltIDGrp"> >>> <group name="NoLegSecurityAltID" required="N"> >>> <field name="LegSecurityAltID" required="N"/> >>> <field name="LegSecurityAltIDSource" required="N"/> >>> </group> >>> </component> >>> >>> With these fields: >>> >>> <field number="604" name="NoLegSecurityAltID" type="NUMINGROUP"/> >>> <field number="605" name="LegSecurityAltID" type="STRING"/> >>> <field number="606" name="LegSecurityAltIDSource" type="STRING"/> >>> >>> All of this agrees with the spec, of course. >>> >>> But when I try to create a NoLegSecurityAltID group, MessageFactory returns a null. >>> >>> When I ran my code in the debugger, LegSecAltIDGrp does not seem to be defined anywhere. >>> >>> Am I missing something? -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: <eri...@th...> - 2018-04-06 20:36:42
|
Here it is, somewhat distilled:
@Test
public void yesItisMissing() {
MessageFactory factory = new quickfix.fix50sp2.MessageFactory();
Group goodGroup = factory.create(FixVersions.FIX50SP2, "AE", 1120);
assertNotNull(goodGroup);
Group badGroup = factory.create(FixVersions.FIX50SP2, "AE", 604);
assertNull(badGroup);
}
On Apr 6, 2018, at 15:12, Colin DuPlantis <co...@ma...<mailto:co...@ma...>> wrote:
QuickFIX/J Documentation: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=arxbs1eiCyw_yg7yfUMPGVP3ZNKnFenCEMeytWvqIIM&e= QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=EqFUknfI6RI5HTV4qrrbCNiLBxBsYMsHt9HO5qWw1xg&e=
Can you give us a code snippet?
On 04/06/2018 09:09 AM, eri...@th...<mailto:eri...@th...> wrote:
QuickFIX/J Documentation: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=arxbs1eiCyw_yg7yfUMPGVP3ZNKnFenCEMeytWvqIIM&e= QuickFIX/J Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=EqFUknfI6RI5HTV4qrrbCNiLBxBsYMsHt9HO5qWw1xg&e=
I am trying to process a TradeCaptureReport (AE) message in FIX 5.0SP2
Based on the spec, one of the optional components is TrdInstrmtLegGrp.
Looking the dictionary In see it there in the message definition:
(It’s huge, so I am not including the entire message.)
<component name="TrdInstrmtLegGrp" required="N”/>
The component is defined with an InstrumentLeg:
<component name="InstrumentLeg" required="N”/> <- I’m interested in this guy
Which has a LegSecAltIDGrp:
<component name="LegSecAltIDGrp" required="N"/>
Which is this:
<component name="LegSecAltIDGrp">
<group name="NoLegSecurityAltID" required="N">
<field name="LegSecurityAltID" required="N"/>
<field name="LegSecurityAltIDSource" required="N"/>
</group>
</component>
With these fields:
<field number="604" name="NoLegSecurityAltID" type="NUMINGROUP"/>
<field number="605" name="LegSecurityAltID" type="STRING"/>
<field number="606" name="LegSecurityAltIDSource" type="STRING"/>
All of this agrees with the spec, of course.
But when I try to create a NoLegSecurityAltID group, MessageFactory returns a null.
When I ran my code in the debugger, LegSecAltIDGrp does not seem to be defined anywhere.
Am I missing something?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=OWayvgdXT1pbdk7l-Qq2N5tdAQrOjfpEhacQXDpUmyI&e= _______________________________________________
Quickfixj-users mailing list
Qui...@li...<mailto:Qui...@li...>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=TDELiyOML8_ptQM_klvYY87PZ5XVUdcYP7Ycw9aQ-Bs&e=
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org<http://Slashdot.org>! https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=OWayvgdXT1pbdk7l-Qq2N5tdAQrOjfpEhacQXDpUmyI&e= _______________________________________________
Quickfixj-users mailing list
Qui...@li...<mailto:Qui...@li...>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwIGaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=ihmYxWMI9R8y4xNQHKZ2zdacr6LNJA7uZ1N5xMiyzOA&s=TDELiyOML8_ptQM_klvYY87PZ5XVUdcYP7Ycw9aQ-Bs&e=
|
|
From: Colin D. <co...@ma...> - 2018-04-06 19:38:03
|
Can you give us a code snippet? On 04/06/2018 09:09 AM, eri...@th... wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I am trying to process a TradeCaptureReport (AE) message in FIX 5.0SP2 > > Based on the spec, one of the optional components is TrdInstrmtLegGrp. > > Looking the dictionary In see it there in the message definition: > > (It’s huge, so I am not including the entire message.) > > <component name="TrdInstrmtLegGrp" required="N”/> > > The component is defined with an InstrumentLeg: > > <component name="InstrumentLeg" required="N”/> <- I’m interested in this guy > > Which has a LegSecAltIDGrp: > > <component name="LegSecAltIDGrp" required="N"/> > > Which is this: > > <component name="LegSecAltIDGrp"> > <group name="NoLegSecurityAltID" required="N"> > <field name="LegSecurityAltID" required="N"/> > <field name="LegSecurityAltIDSource" required="N"/> > </group> > </component> > > With these fields: > > <field number="604" name="NoLegSecurityAltID" type="NUMINGROUP"/> > <field number="605" name="LegSecurityAltID" type="STRING"/> > <field number="606" name="LegSecurityAltIDSource" type="STRING"/> > > All of this agrees with the spec, of course. > > But when I try to create a NoLegSecurityAltID group, MessageFactory returns a null. > > When I ran my code in the debugger, LegSecAltIDGrp does not seem to be defined anywhere. > > Am I missing something? > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: <eri...@th...> - 2018-04-06 16:28:18
|
I am trying to process a TradeCaptureReport (AE) message in FIX 5.0SP2
Based on the spec, one of the optional components is TrdInstrmtLegGrp.
Looking the dictionary In see it there in the message definition:
(It’s huge, so I am not including the entire message.)
<component name="TrdInstrmtLegGrp" required="N”/>
The component is defined with an InstrumentLeg:
<component name="InstrumentLeg" required="N”/> <- I’m interested in this guy
Which has a LegSecAltIDGrp:
<component name="LegSecAltIDGrp" required="N"/>
Which is this:
<component name="LegSecAltIDGrp">
<group name="NoLegSecurityAltID" required="N">
<field name="LegSecurityAltID" required="N"/>
<field name="LegSecurityAltIDSource" required="N"/>
</group>
</component>
With these fields:
<field number="604" name="NoLegSecurityAltID" type="NUMINGROUP"/>
<field number="605" name="LegSecurityAltID" type="STRING"/>
<field number="606" name="LegSecurityAltIDSource" type="STRING"/>
All of this agrees with the spec, of course.
But when I try to create a NoLegSecurityAltID group, MessageFactory returns a null.
When I ran my code in the debugger, LegSecAltIDGrp does not seem to be defined anywhere.
Am I missing something? |
|
From: Christoph J. <chr...@ma...> - 2018-03-28 12:38:39
|
Hi, what is the error message you are getting? Do you maybe needto fill other parameters like ProxyUser or ProxyPassword? According to this comment https://github.com/quickfix-j/quickfixj/pull/92#issuecomment-282728355 http proxy without SSL should work. Cheers, Chris. On 27/03/18 16:19, Riddhi Agarwal wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > I am trying to connect using quickfixj using an HTTP proxy. As told that quickfixj 200 has some > limitation for the support, I manually upgraded mina-core version to 2.0.17 and run the program > again. But each time it is not establishing the connection. Has anyone tried to create an HTTP > proxy connection? > > mkv.fix.session.ProxyType=http > mkv.fix.session.ProxyVersion=1.1 > mkv.fix.session.ProxyHost=X.X.X.X > mkv.fix.session.ProxyPort=nnnn > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-03-28 07:25:25
|
That last message with the workflow that you quoted below did not make it through to the list. At least I didn't receive it. If you want to prevent sending a Logon from an Initiator then you should implement the canLogon() method from the ApplicationExtended interface. If you then return false from that method, the Initiator will not try to logon. Which version of QFJ are you using? There was a change to the behaviour of the used socket addresses with https://github.com/quickfix-j/quickfixj/pull/152 which will be part of QFJ 2.0.1. Maybe that iteration behaviour will fit better to your situation. Chris. On 28/03/18 08:33, Rekha Hindlekar wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hello All, > > Any leads.. > > On Tue, Mar 27, 2018 at 11:16 AM, Rekha Hindlekar <rek...@or... > <mailto:rek...@or...>> wrote: > > Hello All, > > I have attached the work flow. If its round robin then how can we prevent sending login > request to both hosts from initiator. > Since initiator and acceptor both are developed by us using quickfix/j > > On Mon, Mar 26, 2018 at 7:30 PM, Øyvind Matheson Wergeland <oyv...@om... > <mailto:oyv...@om...>> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: > http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> > > > > The QF/J initiator will try to connect to the configured endpoints round robin. I guess > this is the behavior you see. > > -Øyvind > > 26. mar. 2018 kl. 12:21 skrev Christoph John via Quickfixj-users > <qui...@li... <mailto:qui...@li...>>: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> Hi, >> >> sorry, I still don't get the problem. >> So you have ONE initiator. And this initiator connects alternatively to "host" and >> "host1". I assume this happens on a connection disruption. It should not connect to >> "host1" as long as there is a connection to "host" established. >> Or are you telling me that the initiator sends a Logon to "host" and "host1" at the same >> time? >> >> Chris. >> >> >> On 26/03/18 11:22, Rekha Hindlekar wrote: >>>> Hello Christoph, >>>> >>>> I am planning to implement Failover, >>>> >>>> I run two instances of my FIX Acceptor application on two hosts viz.,*Host*and*Host_1*. >>>> >>>> I did configuration in Initiator Session by specifying **/*SocketConnectHost=Host */and >>>> /*SocketConnectHost1=Host_1*(and specified corresponding ports)./// >>>> >>>> I ran all the applications i.e. Initiator and Acceptor on both hosts, initially >>>> Initiator got connected to Acceptor running on/*Host.*/ >>>> /Now when I shut the Acceptor running on /*Host*//, sessions were established with >>>> /Acceptor running on*Host_1*./// >>>> /// >>>> /// >>>> ///When I restarted the Acceptor running on/*Host*, then Logon request from the >>>> Initiator was alternately sent to both the Acceptors running*Host*/and /*Host1*.////// >>> >>> >>> On Mon, Mar 26, 2018 at 2:05 PM, Christoph John <chr...@ma... >>> <mailto:chr...@ma...>> wrote: >>> >>> Hi, >>> >>> >>>> This observation is not according to that noted in the documentation URL. >>> >>> Which documented behaviour do you mean? The documentation you mentioned is about >>> Acceptors and does not talk about any behaviour regarding Initiators. >>> >>> What is the exact problem that you're having? >>> >>> Chris. >>> >>> >> -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Rekha H. <rek...@or...> - 2018-03-28 06:58:18
|
Hello All, Any leads.. On Tue, Mar 27, 2018 at 11:16 AM, Rekha Hindlekar < rek...@or...> wrote: > Hello All, > > I have attached the work flow. If its round robin then how can we prevent > sending login request to both hosts from initiator. > Since initiator and acceptor both are developed by us using quickfix/j > > On Mon, Mar 26, 2018 at 7:30 PM, Øyvind Matheson Wergeland < > oyv...@om...> wrote: > >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support: >> http://www.quickfixj.org/support/ >> >> >> >> The QF/J initiator will try to connect to the configured endpoints round >> robin. I guess this is the behavior you see. >> >> -Øyvind >> >> 26. mar. 2018 kl. 12:21 skrev Christoph John via Quickfixj-users < >> qui...@li...>: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> Hi, >> >> sorry, I still don't get the problem. >> So you have ONE initiator. And this initiator connects alternatively to "host" >> and "host1". I assume this happens on a connection disruption. It should >> not connect to "host1" as long as there is a connection to "host" >> established. >> Or are you telling me that the initiator sends a Logon to "host" and >> "host1" at the same time? >> >> Chris. >> >> >> On 26/03/18 11:22, Rekha Hindlekar wrote: >> >> Hello Christoph, >> >> I am planning to implement Failover, >> >> I run two instances of my FIX Acceptor application on two hosts viz., >> *Host *and *Host_1*. >> >> I did configuration in Initiator Session by specifying *SocketConnectHost=Host and SocketConnectHost1=Host_1 (and >> specified corresponding ports).* >> >> I ran all the applications i.e. Initiator and Acceptor on both hosts, >> initially Initiator got connected to Acceptor running on *Host.* >> *Now when I shut the Acceptor running on Host, sessions were established >> with Acceptor running on Host_1.* >> >> *When I restarted the Acceptor running on Host, then Logon request from >> the Initiator was alternately sent to both the Acceptors >> running Host and Host1.* >> >> >> >> On Mon, Mar 26, 2018 at 2:05 PM, Christoph John <chr...@ma...> >> wrote: >> >>> Hi, >>> >>> >>> This observation is not according to that noted in the documentation URL. >>> >>> >>> Which documented behaviour do you mean? The documentation you mentioned >>> is about Acceptors and does not talk about any behaviour regarding >>> Initiators. >>> >>> What is the exact problem that you're having? >>> >>> Chris. >>> >>> >>> >> -- >> Christoph John >> Development & Support >> T +49 241 557...@ma... >> >> MACD GmbH >> Oppenhoffallee 103 >> D-52066 Aachenwww.macd.com >> >> Amtsgericht Aachen: HRB 8151 >> Ust.-Id: DE 813021663 >> Geschäftsführer: George Macdonald >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> > > > -- > Regards > > Rekha Hindlekar | Sr. Technical Lead | OroSoft Solutions Pvt. Ltd. > rek...@or... | www.orosoftsolutions.com > <http://www.orosoftsolutions.com> > > DISCLAIMER: > > "This e-mail message including any of its attachments is intended solely > for the addressee(s) and may contain privileged information. If you are not > the addressee or you have received this email message in error, please > notify the sender who will remove your details from its database. You are > not authorized to read, copy, disseminate, distribute or use this e-mail > message or any attachment to it in any manner and must delete the email and > destroy any hard copies of it. > > This e-mail message does not contain financial instructions or commitments > of any kind. Any views expressed in this message are those of the > individual sender and do not necessarily reflect the views of OroSoft > Solutions Pvt. Ltd., or any other related subsidiaries, entities or > persons." > -- Regards Rekha Hindlekar | Sr. Technical Lead | OroSoft Solutions Pvt. Ltd. rek...@or... | www.orosoftsolutions.com <http://www.orosoftsolutions.com> DISCLAIMER: "This e-mail message including any of its attachments is intended solely for the addressee(s) and may contain privileged information. If you are not the addressee or you have received this email message in error, please notify the sender who will remove your details from its database. You are not authorized to read, copy, disseminate, distribute or use this e-mail message or any attachment to it in any manner and must delete the email and destroy any hard copies of it. This e-mail message does not contain financial instructions or commitments of any kind. Any views expressed in this message are those of the individual sender and do not necessarily reflect the views of OroSoft Solutions Pvt. Ltd., or any other related subsidiaries, entities or persons." |
|
From: Riddhi A. <inf...@gm...> - 2018-03-27 14:19:17
|
I am trying to connect using quickfixj using an HTTP proxy. As told that quickfixj 200 has some limitation for the support, I manually upgraded mina-core version to 2.0.17 and run the program again. But each time it is not establishing the connection. Has anyone tried to create an HTTP proxy connection? mkv.fix.session.ProxyType=http mkv.fix.session.ProxyVersion=1.1 mkv.fix.session.ProxyHost=X.X.X.X mkv.fix.session.ProxyPort=nnnn |
|
From: Christoph J. <chr...@ma...> - 2018-03-27 05:52:27
|
I don't know if FIX spec knows about the session time concept or if this is something QF specific. But I also saw counterparties that handle the reset the same way, i.e. expecting a new Logon with 141=Y. But this was only possible intra day for recovery reasons. At the end of the session it was perfectly legal to send Logout. Maybe you can recheck the session times with your counterparty. Chris Am 26. März 2018 23:35:51 MESZ schrieb Robert Nicholson <rob...@gm...>: >QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >QuickFIX/J Support: http://www.quickfixj.org/support/ |
|
From: Colin D. <co...@ma...> - 2018-03-26 21:40:43
|
In my experience, this is not typical. I think sequence numbers are expected automatically to reset at the end/beginning of the session. On 03/26/2018 02:35 PM, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Daily session. > > So I’m not currently sending 141=Y on Logon but they only reset if I > do and will complain if I have already reset based on schedule alone > but didn’t tell them on Logon that I had <http://had.ie>. if I send > the sequence number 1 when they expected last+1 they get upset even > though we’ve > both passed the reset schedule window. > > Is that typical? > > also they are also expecting me not to send them a Logout at the end > of the session and just want me to logon again which > I also suspect isn’t standard either. > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 +1.541.306.6556 http://www.marketcetera.org |
|
From: Robert N. <rob...@gm...> - 2018-03-26 21:36:02
|
Daily session. So I’m not currently sending 141=Y on Logon but they only reset if I do and will complain if I have already reset based on schedule alone but didn’t tell them on Logon that I had <http://had.ie/>. if I send the sequence number 1 when they expected last+1 they get upset even though we’ve both passed the reset schedule window. Is that typical? also they are also expecting me not to send them a Logout at the end of the session and just want me to logon again which I also suspect isn’t standard either. |
|
From: Øyvind M. W. <oyv...@om...> - 2018-03-26 14:01:03
|
The QF/J initiator will try to connect to the configured endpoints round robin. I guess this is the behavior you see. -Øyvind > 26. mar. 2018 kl. 12:21 skrev Christoph John via Quickfixj-users <qui...@li...>: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > Hi, > > sorry, I still don't get the problem. > So you have ONE initiator. And this initiator connects alternatively to "host" and "host1". I assume this happens on a connection disruption. It should not connect to "host1" as long as there is a connection to "host" established. > Or are you telling me that the initiator sends a Logon to "host" and "host1" at the same time? > > Chris. > > >> On 26/03/18 11:22, Rekha Hindlekar wrote: >>> Hello Christoph, >>> >>> I am planning to implement Failover, >>> >>> I run two instances of my FIX Acceptor application on two hosts viz., Host and Host_1. >>> >>> I did configuration in Initiator Session by specifying SocketConnectHost=Host and SocketConnectHost1=Host_1 (and specified corresponding ports). >>> >>> I ran all the applications i.e. Initiator and Acceptor on both hosts, initially Initiator got connected to Acceptor running on Host. >>> Now when I shut the Acceptor running on Host, sessions were established with Acceptor running on Host_1. >>> >>> When I restarted the Acceptor running on Host, then Logon request from the Initiator was alternately sent to both the Acceptors running Host and Host1. >> >> >>> On Mon, Mar 26, 2018 at 2:05 PM, Christoph John <chr...@ma...> wrote: >>> Hi, >>> >>> >>>> This observation is not according to that noted in the documentation URL. >>> >>> Which documented behaviour do you mean? The documentation you mentioned is about Acceptors and does not talk about any behaviour regarding Initiators. >>> >>> What is the exact problem that you're having? >>> >>> Chris. >>> >>> > > -- > Christoph John > Development & Support > T +49 241 557080-28 > chr...@ma... > > MACD GmbH > Oppenhoffallee 103 > D-52066 Aachen > www.macd.com > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Christoph J. <chr...@ma...> - 2018-03-26 10:21:43
|
Hi, sorry, I still don't get the problem. So you have ONE initiator. And this initiator connects alternatively to "host" and "host1". I assume this happens on a connection disruption. It should not connect to "host1" as long as there is a connection to "host" established. Or are you telling me that the initiator sends a Logon to "host" and "host1" at the same time? Chris. On 26/03/18 11:22, Rekha Hindlekar wrote: >> Hello Christoph, >> >> I am planning to implement Failover, >> >> I run two instances of my FIX Acceptor application on two hosts viz.,*Host*and*Host_1*. >> >> I did configuration in Initiator Session by specifying **/*SocketConnectHost=Host */and >> /*SocketConnectHost1=Host_1*(and specified corresponding ports)./// >> >> I ran all the applications i.e. Initiator and Acceptor on both hosts, initially Initiator got >> connected to Acceptor running on/*Host.*/ >> /Now when I shut the Acceptor running on /*Host*//, sessions were established with /Acceptor >> running on*Host_1*./// >> /// >> /// >> ///When I restarted the Acceptor running on/*Host*, then Logon request from the Initiator was >> alternately sent to both the Acceptors running*Host*/and /*Host1*.////// > > > On Mon, Mar 26, 2018 at 2:05 PM, Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi, > > >> This observation is not according to that noted in the documentation URL. > > Which documented behaviour do you mean? The documentation you mentioned is about Acceptors and > does not talk about any behaviour regarding Initiators. > > What is the exact problem that you're having? > > Chris. > > -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-03-26 08:42:21
|
From my experience old seqnums are used. The old message is sent with 122/OrigSendingTime and 43/PossDup=Y. I did not see acounterparty that did otherwise. How do they specify that it is a resend then? Using 97/PossResend? Somehow the FIX engine needs to know that the ResendRequest has been satisfied. How should it know when only new seqnums are used? I guess the counterparty sends a SequenceReset before sending the other messagesthen? Cheers, Chris. On 24/03/18 14:56, Robert Nicholson wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > One version the FIX spec I read said that a resend request must be satisfied with using original sequence numbers and not new ones when sending business messages. > > Is that still the case? > > I’ve seen at least one mainstream vendor who uses new sequence numbers when satisfying a resend request. > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
|
From: Christoph J. <chr...@ma...> - 2018-03-26 08:35:53
|
Hi, > This observation is not according to that noted in the documentation URL. Which documented behaviour do you mean? The documentation you mentioned is about Acceptors and does not talk about any behaviour regarding Initiators. What is the exact problem that you're having? Chris. On 26/03/18 08:54, Rekha Hindlekar wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Hi, > > I have used QuickFIX/J in my FIX Acceptor application. > > I am now planning to implement Failover, > I found QuickFIX/J documentation here > https://www.quickfixj.org/usermanual/1.6.3/usage/acceptor_failover.html > <https://www.quickfixj.org/usermanual/1.6.3/usage/acceptor_failover.html> > > I did configuration in Initiator Session by specifying /SocketConnectHost, /SocketConnectPort and > /SocketConnectHost1, /SocketConnectPort1.//// > > Now when I run the application all Initiators got connected to /SocketConnectHost and then when I > shut the Acceptor running on /SocketConnectHost, sessions were established with > /SocketConnectHost1./// > /// > /// > ///But when I restarted the Acceptor running on /SocketConnectHost, then logon request from an > Initiator was sent to /SocketConnectHost and /SocketConnectHost1 alternately.////// > //////This observation is not according to that noted in the documentation URL.////// > > > > > -- > Regards > > Rekha Hindlekar | Sr. Technical Lead | OroSoft Solutions Pvt. Ltd. > rek...@or... <mailto:rek...@or...> > |www.orosoftsolutions.com <http://www.orosoftsolutions.com> > > DISCLAIMER: > > "This e-mail message including any of its attachments is intended solely for the addressee(s) and > may contain privileged information. If you are not the addressee or you have received this email > message in error, please notify the sender who will remove your details from its database. You are > not authorized to read, copy, disseminate, distribute or use this e-mail message or any attachment > to it in any manner and must delete the email and destroy any hard copies of it. > > This e-mail message does not contain financial instructions or commitments of any kind. Any views > expressed in this message are those of the individual sender and do not necessarily reflect the > views of OroSoft Solutions Pvt. Ltd., or any other related subsidiaries, entities or persons." > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Christoph John Development & Support T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 D-52066 Aachen www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |