quickfixj-users — General mailing list for QuickFIX/J topics.

Re: [Quickfixj-users] Support for UI64 data type

[Christoph J. <chr...@ma...>]

Does not really help but: maybe using plain FIX protocol for such a high number of messages is not a good idea? But I guess this is out of control of the original poster? Is this a system propagating market data? 
I cannot imagine that it is desired to get thousands or even more messages in a resend scenario. 
Maybe turning off sequence number validation  (or complete validation) will help? Cannot look at the code at the moment. 
Cheers 
Chris 

Am 7. August 2019 10:36:41 MESZ schrieb Philip Whitehouse <ph...@wh...>:
>You can reset sequence numbers mid-session to avoid this. Maybe QFJ
>should natively do this automatically when it gets close (say at 2
>billion as a nice round number).
>
>Of course resetting means being unable to re-request the previous
>sessions messages which might be a problem..
>
>If this therefore isn’t an option and you’re reallly exceeding 2
>billion for the MsgSeqNum (an average of >3,300 messages per second for
>a week) you have a problem.
>
>The FIX spec mandates it is an integer so it’s unlikely we’d want to
>merge a code change to make it as a default. It’d be a breaking change
>obviously too.
>
>You’ll also have to change more than just that field. Certainly the
>related fields in Reject, Logon, ResendRequest and SequenceReset will
>also have to change.
>
>It feels like this is something that should be part of a FIXT2 spec if
>it’s a practical concern.
>
>If you have a code change for this that you want to submit we can
>discuss how to limit the API breakage in more detail.
>
>What does QFJ do right now when this happens?
>
>Best,
>
>Philip Whitehouse
>
>> On 7 Aug 2019, at 06:44, Kodippili Arachchige, Asanka
><as...@ls...> wrote:
>> 
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>> 
>> 
>> Thanks for your responses. To clarify my requirement further, I need
>to send a ui64 value for the MsgSeqNum field. ( This is due to a system
>running for several days continuously and the sequence number reaches
>ui64 values ) . Currently quickfix expects the MsgSeqNum field to be an
>int. If I send it as a string, an IncorectDataException is thrown. The
>methods provided by Session class related to sequence number such as
>getExpectedTargetNum()  and setNextSenderMsgSeqNum also expect the
>MsgSeqNum field to be an int.
>>  
>> Could quickfix/J be changed to handle the MsgSeqNum as a long value ?
>>  
>>  
>>  
>> Thanks,
>> AsankaK
>>  
>> From: Christoph John [mailto:chr...@ma...] 
>> Sent: Monday, August 05, 2019 5:29 PM
>> To: qui...@li...; Kodippili Arachchige,
>Asanka <as...@ls...>; Qui...@li...
>> Subject: Re: [Quickfixj-users] Support for UI64 data type
>>  
>> *** THIS EMAIL ORIGINATED FROM OUTSIDE OF THE ORGANISATION ***
>> 
>> Use String field? There you can send almost anything. 
>> Cheers 
>> Chris
>> 
>> Am 5. August 2019 13:18:19 MESZ schrieb "Kodippili Arachchige,
>Asanka" <as...@ls...>:
>> Does quickfix/J support unsigned long (UI64) values ? Is there any
>workaround I could use for this with existing FIeldTypes ?
>>  
>> Thanks,
>> Kodippili Arachchige Asanka
>> Associate Tech Lead, MillenniumIT
>> LSEG Technology
>> Telephone +94 11 241 6000 Ext 26717
>> Mobile +94 77 9627002 
>> as...@ls...
>> MillenniumIT, No 01, Millennium Drive, Malabe
>> www.lseg.com
>> 
>> 
>> 
>> Please consider the environment before printing this email. 
>>  
>>
>------------------------------------------------------------------------------------------------------------
>> 
>> Please read these warnings and restrictions:
>> 
>> This e-mail transmission is strictly confidential and intended solely
>for the ordinary user of the e-mail address to which it was addressed.
>It may contain legally privileged and/or CONFIDENTIAL information.
>> 
>> The unauthorised use, disclosure, distribution and/or copying of this
>e-mail or any information it contains is prohibited and could, in
>certain circumstances, constitute a criminal offence.
>> 
>> If you have received this e-mail in error or are not an intended
>recipient please inform London Stock Exchange Group (“LSEG”)
>immediately by return e-mail or telephone 020 7797 1000.
>> 
>> LSEG may collect, process and retain your personal information for
>its business purposes. For more information please see our Privacy
>Policy.
>> 
>> We advise that in keeping with good computing practice the recipient
>of this e-mail should ensure that it is virus free. We do not accept
>responsibility for any virus that may be transferred by way of this
>e-mail.
>> 
>> E-mail may be susceptible to data corruption, interception and
>unauthorised amendment, and we do not accept liability for any such
>corruption, interception or amendment or any consequences thereof.
>> 
>> Calls to London Stock Exchange Group may be recorded to enable LSEG
>to carry out its regulatory responsibilities.
>> 
>> London Stock Exchange Group plc
>> 
>> 10 Paternoster Square
>> London 
>> EC4M 7LS
>> 
>> Registered in England and Wales No 05369106
>> 
>>
>------------------------------------------------------------------------------------------------------------
>> 
>>  
>>  
>> 
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Support for UI64 data type

[Philip W. <ph...@wh...>]

You can reset sequence numbers mid-session to avoid this. Maybe QFJ should natively do this automatically when it gets close (say at 2 billion as a nice round number).

Of course resetting means being unable to re-request the previous sessions messages which might be a problem..

If this therefore isn’t an option and you’re reallly exceeding 2 billion for the MsgSeqNum (an average of >3,300 messages per second for a week) you have a problem.

The FIX spec mandates it is an integer so it’s unlikely we’d want to merge a code change to make it as a default. It’d be a breaking change obviously too.

You’ll also have to change more than just that field. Certainly the related fields in Reject, Logon, ResendRequest and SequenceReset will also have to change.

It feels like this is something that should be part of a FIXT2 spec if it’s a practical concern.

If you have a code change for this that you want to submit we can discuss how to limit the API breakage in more detail.

What does QFJ do right now when this happens?

Best,

Philip Whitehouse

> On 7 Aug 2019, at 06:44, Kodippili Arachchige, Asanka <as...@ls...> wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> Thanks for your responses. To clarify my requirement further, I need to send a ui64 value for the MsgSeqNum field. ( This is due to a system running for several days continuously and the sequence number reaches ui64 values ) . Currently quickfix expects the MsgSeqNum field to be an int. If I send it as a string, an IncorectDataException is thrown. The methods provided by Session class related to sequence number such as getExpectedTargetNum()  and setNextSenderMsgSeqNum also expect the MsgSeqNum field to be an int.
>  
> Could quickfix/J be changed to handle the MsgSeqNum as a long value ?
>  
>  
>  
> Thanks,
> AsankaK
>  
> From: Christoph John [mailto:chr...@ma...] 
> Sent: Monday, August 05, 2019 5:29 PM
> To: qui...@li...; Kodippili Arachchige, Asanka <as...@ls...>; Qui...@li...
> Subject: Re: [Quickfixj-users] Support for UI64 data type
>  
> *** THIS EMAIL ORIGINATED FROM OUTSIDE OF THE ORGANISATION ***
> 
> Use String field? There you can send almost anything. 
> Cheers 
> Chris
> 
> Am 5. August 2019 13:18:19 MESZ schrieb "Kodippili Arachchige, Asanka" <as...@ls...>:
> Does quickfix/J support unsigned long (UI64) values ? Is there any workaround I could use for this with existing FIeldTypes ?
>  
> Thanks,
> Kodippili Arachchige Asanka
> Associate Tech Lead, MillenniumIT
> LSEG Technology
> Telephone +94 11 241 6000 Ext 26717
> Mobile +94 77 9627002 
> as...@ls...
> MillenniumIT, No 01, Millennium Drive, Malabe
> www.lseg.com
> 
> 
> 
> Please consider the environment before printing this email. 
>  
> ------------------------------------------------------------------------------------------------------------
> 
> Please read these warnings and restrictions:
> 
> This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information.
> 
> The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.
> 
> If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000.
> 
> LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy.
> 
> We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail.
> 
> E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof.
> 
> Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities.
> 
> London Stock Exchange Group plc
> 
> 10 Paternoster Square
> London 
> EC4M 7LS
> 
> Registered in England and Wales No 05369106
> 
> ------------------------------------------------------------------------------------------------------------
> 
>  
>  
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Support for UI64 data type

[Kodippili A. A. <as...@ls...>]

Thanks for your responses. To clarify my requirement further, I need to send a ui64 value for the MsgSeqNum field. ( This is due to a system running for several days continuously and the sequence number reaches ui64 values ) . Currently quickfix expects the MsgSeqNum field to be an int. If I send it as a string, an IncorectDataException is thrown. The methods provided by Session class related to sequence number such as getExpectedTargetNum()  and setNextSenderMsgSeqNum also expect the MsgSeqNum field to be an int.

Could quickfix/J be changed to handle the MsgSeqNum as a long value ?



Thanks,
AsankaK

From: Christoph John [mailto:chr...@ma...]
Sent: Monday, August 05, 2019 5:29 PM
To: qui...@li...; Kodippili Arachchige, Asanka <as...@ls...>; Qui...@li...
Subject: Re: [Quickfixj-users] Support for UI64 data type

*** THIS EMAIL ORIGINATED FROM OUTSIDE OF THE ORGANISATION ***

Use String field? There you can send almost anything.
Cheers
Chris
Am 5. August 2019 13:18:19 MESZ schrieb "Kodippili Arachchige, Asanka" <as...@ls...<mailto:as...@ls...>>:
Does quickfix/J support unsigned long (UI64) values ? Is there any workaround I could use for this with existing FIeldTypes ?

Thanks,
Kodippili Arachchige Asanka
Associate Tech Lead, MillenniumIT
LSEG Technology
Telephone +94 11 241 6000 Ext 26717
Mobile +94 77 9627002
as...@ls...<mailto:as...@ls...>
MillenniumIT, No 01, Millennium Drive, Malabe
www.lseg.com<http://www.lseg.com/>
[Description: cid:image001.png@01D37A69.7DB53A20]
[Description: cid:image002.png@01D37A69.7DB53A20]
Please consider the environment before printing this email.


------------------------------------------------------------------------------------------------------------

Please read these warnings and restrictions:

This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information.

The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.

If you have received this e-mail in error or are not an intended recipient please inform London Stock Exchange Group (“LSEG”) immediately by return e-mail or telephone 020 7797 1000.

LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy<https://www.lseg.com/privacy-and-cookie-policy>.

We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail.

E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof.

Calls to London Stock Exchange Group may be recorded to enable LSEG to carry out its regulatory responsibilities.

London Stock Exchange Group plc

10 Paternoster Square
London
EC4M 7LS

Registered in England and Wales No 05369106

------------------------------------------------------------------------------------------------------------

Re: [Quickfixj-users] Support for UI64 data type

[Colin D. <co...@ma...>]

The strict answer is, no, because there is no primitive unsigned 64-bit 
integer type in Java.

However, you can use the version of QFJ that uses BigDecimals instead of 
longs. There is no size limit to BigDecimal types, though they aren't 
primitives in Java, so, there are some differences, particularly with 
operators.

On 8/5/19 4:18 AM, Kodippili Arachchige, Asanka wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Does quickfix/J support unsigned long (UI64) values ? Is there any 
> workaround I could use for this with existing FIeldTypes ?
>
> Thanks,
>
> Kodippili Arachchige Asanka
> Associate Tech Lead, MillenniumIT
> *LSEG Technology*
>
> Telephone +94 11 241 6000 Ext _26717_
> Mobile +94 77 9627002
> as...@ls... <mailto:as...@ls...>
>
> MillenniumIT, No 01, Millennium Drive, Malabe
>
> *www.lseg.com* <http://www.lseg.com/>
>
> Description: cid:image001.png@01D37A69.7DB53A20
>
> Description: cid:image002.png@01D37A69.7DB53A20
>
> Please consider the environment before printing this email.
>
> ------------------------------------------------------------------------------------------------------------
>
> Please read these warnings and restrictions:
>
> This e-mail transmission is strictly confidential and intended solely 
> for the ordinary user of the e-mail address to which it was addressed. 
> It may contain legally privileged and/or CONFIDENTIAL information.
>
> The unauthorised use, disclosure, distribution and/or copying of this 
> e-mail or any information it contains is prohibited and could, in 
> certain circumstances, constitute a criminal offence.
>
> If you have received this e-mail in error or are not an intended 
> recipient please inform London Stock Exchange Group (“LSEG”) 
> immediately by return e-mail or telephone 020 7797 1000.
>
> LSEG may collect, process and retain your personal information for its 
> business purposes. For more information please see our Privacy Policy 
> <https://www.lseg.com/privacy-and-cookie-policy>.
>
> We advise that in keeping with good computing practice the recipient 
> of this e-mail should ensure that it is virus free. We do not accept 
> responsibility for any virus that may be transferred by way of this 
> e-mail.
>
> E-mail may be susceptible to data corruption, interception and 
> unauthorised amendment, and we do not accept liability for any such 
> corruption, interception or amendment or any consequences thereof.
>
> Calls to London Stock Exchange Group may be recorded to enable LSEG to 
> carry out its regulatory responsibilities.
>
> London Stock Exchange Group plc
>
> 10 Paternoster Square
> London
> EC4M 7LS
>
> Registered in England and Wales No 05369106
>
> ------------------------------------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com

Re: [Quickfixj-users] Support for UI64 data type

[Christoph J. <chr...@ma...>]

Use String field? There you can send almost anything. 
Cheers 
Chris

Am 5. August 2019 13:18:19 MESZ schrieb "Kodippili Arachchige, Asanka" <as...@ls...>:
>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>QuickFIX/J Support: http://www.quickfixj.org/support/

[Quickfixj-users] Support for UI64 data type

[Kodippili A. A. <as...@ls...>]

Does quickfix/J support unsigned long (UI64) values ? Is there any workaround I could use for this with existing FIeldTypes ?

Thanks,
Kodippili Arachchige Asanka
Associate Tech Lead, MillenniumIT
LSEG Technology
Telephone +94 11 241 6000 Ext 26717
Mobile +94 77 9627002
as...@ls...<mailto:as...@ls...>
MillenniumIT, No 01, Millennium Drive, Malabe
www.lseg.com<http://www.lseg.com/>
[Description: cid:image001.png@01D37A69.7DB53A20]
[Description: cid:image002.png@01D37A69.7DB53A20]
Please consider the environment before printing this email.


------------------------------------------------------------------------------------------------------------
 
Please read these warnings and restrictions:

This e-mail transmission is strictly confidential and intended solely for the ordinary user of the e-mail address to which it was addressed. It may contain legally privileged and/or CONFIDENTIAL information. 

The unauthorised use, disclosure, distribution and/or copying of this e-mail or any information it contains is prohibited and could, in certain circumstances, constitute a criminal offence.

If you have received this e-mail in error or are not an intended recipient please inform the London Stock Exchange immediately by return e-mail or telephone 020 7797 1000.

LSEG may collect, process and retain your personal information for its business purposes. For more information please see our Privacy Policy. 

We advise that in keeping with good computing practice the recipient of this e-mail should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this e-mail. 

E-mail may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any such corruption, interception or amendment or any consequences thereof. 

Calls to the London Stock Exchange may be recorded to enable the Exchange to carry out its regulatory responsibilities.

London Stock Exchange plc
10 Paternoster Square
London 
EC4M 7LS
Registered in England and Wales No 2075721 
 
------------------------------------------------------------------------------------------------------------

Re: [Quickfixj-users] Stop sending resend requests (MsgType 2)

[Christoph J. <chr...@ma...>]

Hi,

you could set ValidateSequenceNumbers=N to achieve this.

Cheers,
Chris.
/

/
On 31.07.19 10:36, Jalal Kharsa wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi All,
>
> I would like to know how I can configure/manipulate quickfixj to stop sending resend requests 
> (MsgType=2),
>
> Regards
>
> The information contained in this e-mail, along with any attachments, may be confidential or 
> legally privileged. It is intended only for the named person(s), who is/are the only authorised 
> recipients. If you are not the intended recipient of this e-mail, the use or any disclosure, 
> copying or distribution is prohibited and may be unlawful. If you received this in error, please 
> contact the sender immediately and delete this message from your system. Thank you for your help. 
> The views or opinions expressed in this e-mail are solely those of the author and do not 
> necessarily represent those of Inforalgo Information Technology Limited. Replies to this e-mail 
> may be monitored by Inforalgo Information Technology Limited for operational or business reasons. 
> Inforalgo Information Technology Ltd is a company registered in England and Wales, Company Number 
> 03471900. Registered office – 55 Baker Street, London. W1U 7EU
>
>
> _______________________________________________
> 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] Stop sending resend requests (MsgType 2)

[Jalal K. <jal...@in...>]

Hi All,

I would like to know how I can configure/manipulate quickfixj to stop sending resend requests (MsgType=2),

Regards
The information contained in this e-mail, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorised recipients. If you are not the intended recipient of this e-mail, the use or any disclosure, copying or distribution is prohibited and may be unlawful. If you received this in error, please contact the sender immediately and delete this message from your system. Thank you for your help. The views or opinions expressed in this e-mail are solely those of the author and do not necessarily represent those of Inforalgo Information Technology Limited. Replies to this e-mail may be monitored by Inforalgo Information Technology Limited for operational or business reasons. Inforalgo Information Technology Ltd is a company registered in England and Wales, Company Number 03471900. Registered office - 55 Baker Street, London. W1U 7EU

Re: [Quickfixj-users] Potential issue with failover connection logic and proxies

[DAVID H. V. <dav...@bb...>]

Hi, Chris.

>From what I've been able to see so far, I lean towards #2, but I have the
feeling that there's a more fundamental thing to consider here, which is
the fact that when connecting through a proxy, the IoSession object
actually exists, so I think the main if statement would probably need to be
changed and be made "proxy-aware" and not just rely on the existence of the
object. Not sure if IoSession will expose all the information we need but
I'll check. Otherwise, we would defeat the purpose of the pull request you
mentioned. On the other hand, creating strategies would need to bear this
in mind anyways... Does this make sense?

Another interesting thing I found (potentially related to this), is that if
you're connecting through a proxy, the Session.getRemoteAddress() method
gives you the proxy address instead of the final endpoint (which is what I
would expect).

Thanks and regards.

David.

El vie., 26 jul. 2019 a las 12:58, Christoph John (<chr...@ma...>)
escribió:

> Hi David,
>
> this was changed and discussed here:
> https://github.com/quickfix-j/quickfixj/pull/152
> There it is also said that "I don't think this connection establishment
> logic can satisfy everyone. It would be better to extract interface and
> have different implementations - round-robin for LB, etc. But it is a
> separate feature, not a quick change."
>
> So as I see it we have two possibilities now:
> 1. Implement different strategies
> 2. Make the reset of the nextSocketAddressIndex conditional depending on
> whether a proxy is used or not
>
> What do you think? Do you have another idea?
>
> Cheers,
> Chris.
>
>
>
> On 26.07.19 12:47, DAVID HERNANDO VIEITES wrote:
>
> Hi, Chris.
>
> Thanks for your reply.
>
> My first idea would be to remove the line that resets
> nextSocketAddressIndex within pollConnectFuture, but I'm not sure about the
> reason why it's there in the first place. Is there a reason behind it? I
> could compare with older versions and the line wasn't there but I couldn't
> track it down to a specific reason.
>
> Thanks again.
>
> David.
>
> El vie., 26 jul. 2019 a las 12:41, Christoph John (<
> chr...@ma...>) escribió:
>
>> Hi David,
>>
>> thanks for your problem description. I never used QFJ in a proxy scenario
>> but what you describe makes sense to me.
>> Please open a JIRA ticket for this or even better create a pull request
>> with a proposed fix. :) https://github.com/quickfix-j/quickfixj/pulls
>>
>> Many thanks in advance and best regards,
>> Chris.
>>
>> On 26.07.19 09:10, DAVID HERNANDO VIEITES via Quickfixj-users wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> Hi, everyone.
>>
>> We started using QFJ 2.1.1 recently and I think we found an issue with
>> the use of failover hosts through a proxy.
>>
>> We have a cfg file with this set up (just leaving the relevant pieces):
>>
>> ProxyType=http
>> ProxyVersion=1.0
>> ProxyHost=xyz
>> ProxyPort=8080
>> ProxyUser=usr
>> ProxyPassword=pwd
>>
>> [SESSION]
>> SocketConnectHost=a.b.c.d
>> SocketConnectPort=5013
>> # Alternative connection host
>> SocketConnectHost1=d.c.b.a
>> SocketConnectPort1=5013
>>
>>
>> If the connection to the first host in the list could not be established,
>> the library is supposed to move to the next one and try it on the next
>> reconnection attempt. However, that doesn't seem to be the case when a
>> proxy is defined, because what I see is that the address being used is
>> always the first one.
>>
>> I think the issue may be within the IoSessionInitiator class. In
>> particular in the pollConnectFuture() method. When connecting through a
>> proxy, the if statement is always not null (assuming you're successfully
>> connected to the proxy), so the nextSocketAddressIndex gets constantly
>> reset even if you couldn't reach the endpoint.
>>
>> private void pollConnectFuture() {
>>     try {
>>         this.connectFuture.awaitUninterruptibly(2000L);        if (this.connectFuture.getSession() != null) {
>>             this.ioSession = this.connectFuture.getSession();            this.connectionFailureCount = 0;            this.nextSocketAddressIndex = 0;            this.lastConnectTime = System.currentTimeMillis();            this.connectFuture = null;        } else {
>>             this.fixSession.getLog().onEvent("Pending connection not established after " + (System.currentTimeMillis() - this.lastReconnectAttemptTime) + " ms.");        }
>>     } catch (Throwable var2) {
>>         this.handleConnectException(var2);    }
>>
>> }
>>
>> I was going to open a Jira ticket, but wanted to comment over here first.
>>
>> Many thanks!
>>
>>
>>
>> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede
>> contener información privada y confidencial. No lo reenvíe, copie o
>> distribuya a terceros que no deban conocer su contenido. En caso de haberlo
>> recibido por error,  rogamos lo notifique al remitente y proceda a su
>> borrado, así como al de cualquier documento que pudiera adjuntarse.
>>
>>  Por favor tenga en cuenta que los correos enviados vía Internet no
>> permiten garantizar la confidencialidad de los mensajes ni su transmisión
>> de forma íntegra.
>>
>>  Las opiniones expresadas en el presente correo pertenecen únicamente al
>> remitente y no representan necesariamente la opinión del Grupo BBVA."
>>
>>  "This message is intended exclusively for the adressee and may contain
>> privileged and confidential information. Please, do not disseminate, copy
>> or distribute it to third parties who should not receive it. In case you
>> have received it by mistake, please inform the sender and delete the
>> message and attachments from your system.
>>
>>  Please keep in mind that e-mails sent by Internet do not allow to
>> guarantee neither the confidentiality or the integrity of the messages
>> sent."
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
>
> --
> [image: BBVA | Creando Oportunidades]
> *David Hernando Vieites*
> *Global Markets - eCommerce & FX IT*
> Tel: +34 670 47 53 62 - 225362
> dav...@bb...
> C/ Azul, 4 Planta 2, 28050 Madrid
>
>
> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede
> contener información privada y confidencial. No lo reenvíe, copie o
> distribuya a terceros que no deban conocer su contenido. En caso de haberlo
> recibido por error,  rogamos lo notifique al remitente y proceda a su
> borrado, así como al de cualquier documento que pudiera adjuntarse.
>
>  Por favor tenga en cuenta que los correos enviados vía Internet no
> permiten garantizar la confidencialidad de los mensajes ni su transmisión
> de forma íntegra.
>
>  Las opiniones expresadas en el presente correo pertenecen únicamente al
> remitente y no representan necesariamente la opinión del Grupo BBVA."
>
>  "This message is intended exclusively for the adressee and may contain
> privileged and confidential information. Please, do not disseminate, copy
> or distribute it to third parties who should not receive it. In case you
> have received it by mistake, please inform the sender and delete the
> message and attachments from your system.
>
>  Please keep in mind that e-mails sent by Internet do not allow to
> guarantee neither the confidentiality or the integrity of the messages
> sent."
>
>
> --
> 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
>
>

-- 
[image: BBVA | Creando Oportunidades]
*David Hernando Vieites*
*Global Markets - eCommerce & FX IT*
Tel: +34 670 47 53 62 - 225362
dav...@bb...
C/ Azul, 4 Planta 2, 28050 Madrid

-- 


"Este mensaje está
dirigido de manera exclusiva a su destinatario y puede 
contener información
privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no
deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos
lo notifique al remitente y proceda a su 
borrado, así como al de cualquier
documento que pudiera adjuntarse.



 Por 
favor tenga en cuenta que
los correos enviados vía Internet no permiten 
garantizar la confidencialidad de
los mensajes ni su transmisión de forma 
íntegra.



 Las opiniones expresadas en el
presente correo pertenecen 
únicamente al remitente y no representan
necesariamente la opinión del 
Grupo BBVA."



 "This
message is intended exclusively for the adressee and 
may contain privileged and
confidential information. Please, do not 
disseminate, copy or distribute it to
third parties who should not receive 
it. In case you have received it by
mistake, please inform the sender and 
delete the message and attachments from
your system.



 Please
keep in 
mind that e-mails sent by Internet do not allow to guarantee neither
the 
confidentiality or the integrity of the messages sent."

Re: [Quickfixj-users] Potential issue with failover connection logic and proxies

[DAVID H. V. <dav...@bb...>]

Hi, Chris.

Thanks for your reply.

My first idea would be to remove the line that resets
nextSocketAddressIndex within pollConnectFuture, but I'm not sure about the
reason why it's there in the first place. Is there a reason behind it? I
could compare with older versions and the line wasn't there but I couldn't
track it down to a specific reason.

Thanks again.

David.

El vie., 26 jul. 2019 a las 12:41, Christoph John (<chr...@ma...>)
escribió:

> Hi David,
>
> thanks for your problem description. I never used QFJ in a proxy scenario
> but what you describe makes sense to me.
> Please open a JIRA ticket for this or even better create a pull request
> with a proposed fix. :) https://github.com/quickfix-j/quickfixj/pulls
>
> Many thanks in advance and best regards,
> Chris.
>
> On 26.07.19 09:10, DAVID HERNANDO VIEITES via Quickfixj-users wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi, everyone.
>
> We started using QFJ 2.1.1 recently and I think we found an issue with the
> use of failover hosts through a proxy.
>
> We have a cfg file with this set up (just leaving the relevant pieces):
>
> ProxyType=http
> ProxyVersion=1.0
> ProxyHost=xyz
> ProxyPort=8080
> ProxyUser=usr
> ProxyPassword=pwd
>
> [SESSION]
> SocketConnectHost=a.b.c.d
> SocketConnectPort=5013
> # Alternative connection host
> SocketConnectHost1=d.c.b.a
> SocketConnectPort1=5013
>
>
> If the connection to the first host in the list could not be established,
> the library is supposed to move to the next one and try it on the next
> reconnection attempt. However, that doesn't seem to be the case when a
> proxy is defined, because what I see is that the address being used is
> always the first one.
>
> I think the issue may be within the IoSessionInitiator class. In
> particular in the pollConnectFuture() method. When connecting through a
> proxy, the if statement is always not null (assuming you're successfully
> connected to the proxy), so the nextSocketAddressIndex gets constantly
> reset even if you couldn't reach the endpoint.
>
> private void pollConnectFuture() {
>     try {
>         this.connectFuture.awaitUninterruptibly(2000L);        if (this.connectFuture.getSession() != null) {
>             this.ioSession = this.connectFuture.getSession();            this.connectionFailureCount = 0;            this.nextSocketAddressIndex = 0;            this.lastConnectTime = System.currentTimeMillis();            this.connectFuture = null;        } else {
>             this.fixSession.getLog().onEvent("Pending connection not established after " + (System.currentTimeMillis() - this.lastReconnectAttemptTime) + " ms.");        }
>     } catch (Throwable var2) {
>         this.handleConnectException(var2);    }
>
> }
>
> I was going to open a Jira ticket, but wanted to comment over here first.
>
> Many thanks!
>
>
>
> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede
> contener información privada y confidencial. No lo reenvíe, copie o
> distribuya a terceros que no deban conocer su contenido. En caso de haberlo
> recibido por error,  rogamos lo notifique al remitente y proceda a su
> borrado, así como al de cualquier documento que pudiera adjuntarse.
>
>  Por favor tenga en cuenta que los correos enviados vía Internet no
> permiten garantizar la confidencialidad de los mensajes ni su transmisión
> de forma íntegra.
>
>  Las opiniones expresadas en el presente correo pertenecen únicamente al
> remitente y no representan necesariamente la opinión del Grupo BBVA."
>
>  "This message is intended exclusively for the adressee and may contain
> privileged and confidential information. Please, do not disseminate, copy
> or distribute it to third parties who should not receive it. In case you
> have received it by mistake, please inform the sender and delete the
> message and attachments from your system.
>
>  Please keep in mind that e-mails sent by Internet do not allow to
> guarantee neither the confidentiality or the integrity of the messages
> sent."
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>

-- 
[image: BBVA | Creando Oportunidades]
*David Hernando Vieites*
*Global Markets - eCommerce & FX IT*
Tel: +34 670 47 53 62 - 225362
dav...@bb...
C/ Azul, 4 Planta 2, 28050 Madrid

-- 


"Este mensaje está
dirigido de manera exclusiva a su destinatario y puede 
contener información
privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no
deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos
lo notifique al remitente y proceda a su 
borrado, así como al de cualquier
documento que pudiera adjuntarse.



 Por 
favor tenga en cuenta que
los correos enviados vía Internet no permiten 
garantizar la confidencialidad de
los mensajes ni su transmisión de forma 
íntegra.



 Las opiniones expresadas en el
presente correo pertenecen 
únicamente al remitente y no representan
necesariamente la opinión del 
Grupo BBVA."



 "This
message is intended exclusively for the adressee and 
may contain privileged and
confidential information. Please, do not 
disseminate, copy or distribute it to
third parties who should not receive 
it. In case you have received it by
mistake, please inform the sender and 
delete the message and attachments from
your system.



 Please
keep in 
mind that e-mails sent by Internet do not allow to guarantee neither
the 
confidentiality or the integrity of the messages sent."

Re: [Quickfixj-users] Potential issue with failover connection logic and proxies

[Christoph J. <chr...@ma...>]

Hi David,

this was changed and discussed here: https://github.com/quickfix-j/quickfixj/pull/152
There it is also said that "I don't think this connection establishment logic can satisfy everyone. 
It would be better to extract interface and have different implementations - round-robin for LB, 
etc. But it is a separate feature, not a quick change."

So as I see it we have two possibilities now:
1. Implement different strategies
2. Make the reset of the nextSocketAddressIndex conditional depending on whether a proxy is used or not

What do you think? Do you have another idea?

Cheers,
Chris.



On 26.07.19 12:47, DAVID HERNANDO VIEITES wrote:
> Hi, Chris.
>
> Thanks for your reply.
>
> My first idea would be to remove the line that resets nextSocketAddressIndex within 
> pollConnectFuture, but I'm not sure about the reason why it's there in the first place. Is there a 
> reason behind it? I could compare with older versions and the line wasn't there but I couldn't 
> track it down to a specific reason.
>
> Thanks again.
>
> David.
>
> El vie., 26 jul. 2019 a las 12:41, Christoph John (<chr...@ma... 
> <mailto:chr...@ma...>>) escribió:
>
>     Hi David,
>
>     thanks for your problem description. I never used QFJ in a proxy scenario but what you
>     describe makes sense to me.
>     Please open a JIRA ticket for this or even better create a pull request with a proposed fix.
>     :) https://github.com/quickfix-j/quickfixj/pulls
>
>     Many thanks in advance and best regards,
>     Chris.
>
>     On 26.07.19 09:10, DAVID HERNANDO VIEITES via Quickfixj-users wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hi, everyone.
>>
>>     We started using QFJ 2.1.1 recently and I think we found an issue with the use of failover
>>     hosts through a proxy.
>>
>>     We have a cfg file with this set up (just leaving the relevant pieces):
>>     ProxyType=http
>>     ProxyVersion=1.0
>>     ProxyHost=xyz
>>     ProxyPort=8080
>>     ProxyUser=usr
>>     ProxyPassword=pwd
>>
>>     [SESSION]
>>     SocketConnectHost=a.b.c.d
>>     SocketConnectPort=5013
>>     # Alternative connection host
>>     SocketConnectHost1=d.c.b.a
>>     SocketConnectPort1=5013
>>
>>     If the connection to the first host in the list could not be established, the library is
>>     supposed to move to the next one and try it on the next reconnection attempt. However, that
>>     doesn't seem to be the case when a proxy is defined, because what I see is that the address
>>     being used is always the first one.
>>
>>     I think the issue may be within the IoSessionInitiator class. In particular in the
>>     pollConnectFuture() method. When connecting through a proxy, the if statement is always not
>>     null (assuming you're successfully connected to the proxy), so the nextSocketAddressIndex
>>     gets constantly reset even if you couldn't reach the endpoint.
>>     private void pollConnectFuture() {
>>          try {
>>              this.connectFuture.awaitUninterruptibly(2000L); if (this.connectFuture.getSession() !=null) {
>>                  this.ioSession =this.connectFuture.getSession(); this.connectionFailureCount =0; this.nextSocketAddressIndex =0; this.lastConnectTime = System.currentTimeMillis(); this.connectFuture =null; }else {
>>                  this.fixSession.getLog().onEvent("Pending connection not established after " + (System.currentTimeMillis() -this.lastReconnectAttemptTime) +" ms."); }
>>          }catch (Throwable var2) {
>>              this.handleConnectException(var2); }
>>
>>     }
>>     I was going to open a Jira ticket, but wanted to comment over here first.
>>
>>     Many thanks!
>>
>>
>>
>>     "Este mensaje está dirigido de manera exclusiva a su destinatario y puede contener
>>     información privada y confidencial. No lo reenvíe, copie o distribuya a terceros que no deban
>>     conocer su contenido. En caso de haberlo recibido por error,  rogamos lo notifique al
>>     remitente y proceda a su borrado, así como al de cualquier documento que pudiera adjuntarse.
>>
>>     Por favor tenga en cuenta que los correos enviados vía Internet no permiten garantizar la
>>     confidencialidad de los mensajes ni su transmisión de forma íntegra.
>>
>>     Las opiniones expresadas en el presente correo pertenecen únicamente al remitente y no
>>     representan necesariamente la opinión del Grupo BBVA."
>>
>>     "This message is intended exclusively for the adressee and may contain privileged and
>>     confidential information. Please, do not disseminate, copy or distribute it to third parties
>>     who should not receive it. In case you have received it by mistake, please inform the sender
>>     and delete the message and attachments from your system.
>>
>>     Please keep in mind that e-mails sent by Internet do not allow to guarantee neither the
>>     confidentiality or the integrity of the messages sent."
>>
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> -- 
> BBVA | Creando Oportunidades
> *David Hernando Vieites*
> *Global Markets - eCommerce & FX IT*
> Tel: +34 670 47 53 62 - 225362*
> *
> dav...@bb... <mailto:dav...@bb...>
> C/ Azul, 4 Planta 2, 28050 Madrid
>
>
> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede contener información 
> privada y confidencial. No lo reenvíe, copie o distribuya a terceros que no deban conocer su 
> contenido. En caso de haberlo recibido por error,  rogamos lo notifique al remitente y proceda a 
> su borrado, así como al de cualquier documento que pudiera adjuntarse.
>
> Por favor tenga en cuenta que los correos enviados vía Internet no permiten garantizar la 
> confidencialidad de los mensajes ni su transmisión de forma íntegra.
>
> Las opiniones expresadas en el presente correo pertenecen únicamente al remitente y no representan 
> necesariamente la opinión del Grupo BBVA."
>
> "This message is intended exclusively for the adressee and may contain privileged and confidential 
> information. Please, do not disseminate, copy or distribute it to third parties who should not 
> receive it. In case you have received it by mistake, please inform the sender and delete the 
> message and attachments from your system.
>
> Please keep in mind that e-mails sent by Internet do not allow to guarantee neither the 
> confidentiality or the integrity of the messages sent."
>

-- 
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

Re: [Quickfixj-users] Potential issue with failover connection logic and proxies

[Christoph J. <chr...@ma...>]

Hi David,

thanks for your problem description. I never used QFJ in a proxy scenario but what you describe 
makes sense to me.
Please open a JIRA ticket for this or even better create a pull request with a proposed fix. :) 
https://github.com/quickfix-j/quickfixj/pulls

Many thanks in advance and best regards,
Chris.

On 26.07.19 09:10, DAVID HERNANDO VIEITES via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi, everyone.
>
> We started using QFJ 2.1.1 recently and I think we found an issue with the use of failover hosts 
> through a proxy.
>
> We have a cfg file with this set up (just leaving the relevant pieces):
> ProxyType=http
> ProxyVersion=1.0
> ProxyHost=xyz
> ProxyPort=8080
> ProxyUser=usr
> ProxyPassword=pwd
>
> [SESSION]
> SocketConnectHost=a.b.c.d
> SocketConnectPort=5013
> # Alternative connection host
> SocketConnectHost1=d.c.b.a
> SocketConnectPort1=5013
>
> If the connection to the first host in the list could not be established, the library is supposed 
> to move to the next one and try it on the next reconnection attempt. However, that doesn't seem to 
> be the case when a proxy is defined, because what I see is that the address being used is always 
> the first one.
>
> I think the issue may be within the IoSessionInitiator class. In particular in the 
> pollConnectFuture() method. When connecting through a proxy, the if statement is always not null 
> (assuming you're successfully connected to the proxy), so the nextSocketAddressIndex gets 
> constantly reset even if you couldn't reach the endpoint.
> private void pollConnectFuture() {
>      try {
>          this.connectFuture.awaitUninterruptibly(2000L); if (this.connectFuture.getSession() !=null) {
>              this.ioSession =this.connectFuture.getSession(); this.connectionFailureCount =0; this.nextSocketAddressIndex =0; this.lastConnectTime = System.currentTimeMillis(); this.connectFuture =null; }else {
>              this.fixSession.getLog().onEvent("Pending connection not established after " + (System.currentTimeMillis() -this.lastReconnectAttemptTime) +" ms."); }
>      }catch (Throwable var2) {
>          this.handleConnectException(var2); }
>
> }
> I was going to open a Jira ticket, but wanted to comment over here first.
>
> Many thanks!
>
>
>
> "Este mensaje está dirigido de manera exclusiva a su destinatario y puede contener información 
> privada y confidencial. No lo reenvíe, copie o distribuya a terceros que no deban conocer su 
> contenido. En caso de haberlo recibido por error,  rogamos lo notifique al remitente y proceda a 
> su borrado, así como al de cualquier documento que pudiera adjuntarse.
>
> Por favor tenga en cuenta que los correos enviados vía Internet no permiten garantizar la 
> confidencialidad de los mensajes ni su transmisión de forma íntegra.
>
> Las opiniones expresadas en el presente correo pertenecen únicamente al remitente y no representan 
> necesariamente la opinión del Grupo BBVA."
>
> "This message is intended exclusively for the adressee and may contain privileged and confidential 
> information. Please, do not disseminate, copy or distribute it to third parties who should not 
> receive it. In case you have received it by mistake, please inform the sender and delete the 
> message and attachments from your system.
>
> Please keep in mind that e-mails sent by Internet do not allow to guarantee neither the 
> confidentiality or the integrity of the messages sent."
>
>
>
> _______________________________________________
> 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] Potential issue with failover connection logic and proxies

[DAVID H. V. <dav...@bb...>]

Hi, everyone.

We started using QFJ 2.1.1 recently and I think we found an issue with the
use of failover hosts through a proxy.

We have a cfg file with this set up (just leaving the relevant pieces):

ProxyType=http
ProxyVersion=1.0
ProxyHost=xyz
ProxyPort=8080
ProxyUser=usr
ProxyPassword=pwd

[SESSION]
SocketConnectHost=a.b.c.d
SocketConnectPort=5013
# Alternative connection host
SocketConnectHost1=d.c.b.a
SocketConnectPort1=5013

If the connection to the first host in the list could not be established,
the library is supposed to move to the next one and try it on the next
reconnection attempt. However, that doesn't seem to be the case when a
proxy is defined, because what I see is that the address being used is
always the first one.

I think the issue may be within the IoSessionInitiator class. In particular
in the pollConnectFuture() method. When connecting through a proxy, the if
statement is always not null (assuming you're successfully connected to the
proxy), so the nextSocketAddressIndex gets constantly reset even if you
couldn't reach the endpoint.

private void pollConnectFuture() {
    try {
        this.connectFuture.awaitUninterruptibly(2000L);
        if (this.connectFuture.getSession() != null) {
            this.ioSession = this.connectFuture.getSession();
            this.connectionFailureCount = 0;
            this.nextSocketAddressIndex = 0;
            this.lastConnectTime = System.currentTimeMillis();
            this.connectFuture = null;
        } else {
            this.fixSession.getLog().onEvent("Pending connection not
established after " + (System.currentTimeMillis() -
this.lastReconnectAttemptTime) + " ms.");
        }
    } catch (Throwable var2) {
        this.handleConnectException(var2);
    }

}

I was going to open a Jira ticket, but wanted to comment over here first.

Many thanks!

-- 


"Este mensaje está
dirigido de manera exclusiva a su destinatario y puede 
contener información
privada y confidencial. No lo reenvíe, copie o 
distribuya a terceros que no
deban conocer su contenido. En caso de haberlo 
recibido por error,  rogamos
lo notifique al remitente y proceda a su 
borrado, así como al de cualquier
documento que pudiera adjuntarse.



 Por 
favor tenga en cuenta que
los correos enviados vía Internet no permiten 
garantizar la confidencialidad de
los mensajes ni su transmisión de forma 
íntegra.



 Las opiniones expresadas en el
presente correo pertenecen 
únicamente al remitente y no representan
necesariamente la opinión del 
Grupo BBVA."



 "This
message is intended exclusively for the adressee and 
may contain privileged and
confidential information. Please, do not 
disseminate, copy or distribute it to
third parties who should not receive 
it. In case you have received it by
mistake, please inform the sender and 
delete the message and attachments from
your system.



 Please
keep in 
mind that e-mails sent by Internet do not allow to guarantee neither
the 
confidentiality or the integrity of the messages sent."

Re: [Quickfixj-users] Session validation settings have no effect for FIXT unless AppDataDictionary is set explicitly

[Christoph J. <chr...@ma...>]

I have created a JIRA issue for this and will fix it.
https://www.quickfixj.org/jira/browse/QFJ-981

Cheers,
Chris.

On 16.07.19 10:27, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi,
>
> I think I have found the problem in the code. When QFJ loads an app dictionary by default (i.e. 
> when it does not find it in the cache), the validation settings do not get applied. But need to 
> create a test case to be sure.
>
> Cheers,
> Chris.
>
>
> On 08/07/2019 18:08, Ilya Kurnosov wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Hi, there's a nuance, yes: if AppDataDictionary is not provided explicitly then "an attempt will 
>> be made to load a dictionary using the DefaultApplVerID for the session". The latter logic works 
>> fine resulting in proper dictionary being used, alas sessions validation settings, if any, get 
>> ignored.
>>
>> On Mon, Jul 8, 2019 at 2:05 PM Christoph John <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>>     Hi,
>>
>>     I did not check the code but how should QFJ validate if fields are out of order if no
>>     application data dictionary is specified?
>>     Or did I misunderstand your question?
>>
>>     Cheers,
>>     Chris.
>>
>>     On 21/03/2019 09:50, Ilya Kurnosov wrote:
>>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>
>>>     Hello! I ran into some interesting behavior with quickfixj 2 today. My question is if it's
>>>     intentionally designed this way? And, if yes, if someone could explain the reasoning behind it?
>>>
>>>     The behavior I see is that all the session validation settings:
>>>
>>>       * Session.SETTING_VALIDATE_FIELDS_HAVE_VALUES ("ValidateFieldsHaveValues")
>>>       * Session.SETTING_VALIDATE_FIELDS_OUT_OF_ORDER ("ValidateFieldsOutOfOrder")
>>>       * Session.SETTING_VALIDATE_UNORDERED_GROUP_FIELDS ("ValidateUnorderedGroupFields")
>>>       * Session.SETTING_VALIDATE_USER_DEFINED_FIELDS ("ValidateUserDefinedFields")
>>>       * Session.SETTING_ALLOW_UNKNOWN_MSG_FIELDS ("AllowUnknownMsgFields")
>>>
>>>     have exactly no effect on the validation of FIXT application messages unless one also
>>>     explicitly sets "AppDataDictionary" option (Session.SETTING_APP_DATA_DICTIONARY).
>>>     I observe this behavior in tests, but the code in
>>>     DefaultSessionFactory#processFixtDataDictionaries looks rather unambiguous too
>>>     (https://github.com/quickfix-j/quickfixj/blob/QFJ_RELEASE_2_1_1/quickfixj-core/src/main/java/quickfix/DefaultSessionFactory.java#L283).
>>>     It looks like DefaultSessionFactory#createDataDictionary (the only place using those
>>>     Validate* and AllowUnknownMsgFields settings) is called to create app dictionary IIF
>>>     AppDataDictionary is present.
>>>
>>>     Is this behavior intentional?
>>>

-- 
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

Re: [Quickfixj-users] Session validation settings have no effect for FIXT unless AppDataDictionary is set explicitly

[Christoph J. <chr...@ma...>]

Hi,

I think I have found the problem in the code. When QFJ loads an app dictionary by default (i.e. when 
it does not find it in the cache), the validation settings do not get applied. But need to create a 
test case to be sure.

Cheers,
Chris.


On 08/07/2019 18:08, Ilya Kurnosov wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi, there's a nuance, yes: if AppDataDictionary is not provided explicitly then "an attempt will 
> be made to load a dictionary using the DefaultApplVerID for the session". The latter logic works 
> fine resulting in proper dictionary being used, alas sessions validation settings, if any, get 
> ignored.
>
> On Mon, Jul 8, 2019 at 2:05 PM Christoph John <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hi,
>
>     I did not check the code but how should QFJ validate if fields are out of order if no
>     application data dictionary is specified?
>     Or did I misunderstand your question?
>
>     Cheers,
>     Chris.
>
>     On 21/03/2019 09:50, Ilya Kurnosov wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>     Hello! I ran into some interesting behavior with quickfixj 2 today. My question is if it's
>>     intentionally designed this way? And, if yes, if someone could explain the reasoning behind it?
>>
>>     The behavior I see is that all the session validation settings:
>>
>>       * Session.SETTING_VALIDATE_FIELDS_HAVE_VALUES ("ValidateFieldsHaveValues")
>>       * Session.SETTING_VALIDATE_FIELDS_OUT_OF_ORDER ("ValidateFieldsOutOfOrder")
>>       * Session.SETTING_VALIDATE_UNORDERED_GROUP_FIELDS ("ValidateUnorderedGroupFields")
>>       * Session.SETTING_VALIDATE_USER_DEFINED_FIELDS ("ValidateUserDefinedFields")
>>       * Session.SETTING_ALLOW_UNKNOWN_MSG_FIELDS ("AllowUnknownMsgFields")
>>
>>     have exactly no effect on the validation of FIXT application messages unless one also
>>     explicitly sets "AppDataDictionary" option (Session.SETTING_APP_DATA_DICTIONARY).
>>     I observe this behavior in tests, but the code in
>>     DefaultSessionFactory#processFixtDataDictionaries looks rather unambiguous too
>>     (https://github.com/quickfix-j/quickfixj/blob/QFJ_RELEASE_2_1_1/quickfixj-core/src/main/java/quickfix/DefaultSessionFactory.java#L283).
>>     It looks like DefaultSessionFactory#createDataDictionary (the only place using those
>>     Validate* and AllowUnknownMsgFields settings) is called to create app dictionary IIF
>>     AppDataDictionary is present.
>>
>>     Is this behavior intentional?
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li...  <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma...  <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com  <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>
>
>
> _______________________________________________
> 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

Re: [Quickfixj-users] Tag not defined for this message type, field=9610"

[Grant B. <gbi...@co...>]

"A possible additional clue is I also see this reject on ExecutionReports
  Rejecting invalid message: quickfix.FieldException: Tag appears more than
once, field=2669"

Oh, man, investigate that one first.  To me, this says that there is likely
an error in Bloomberg's DD regarding a repeating group.  The parser is
terminating the group early because it found a field that didn't belong in
it, and it screws up everything it parses after.

I think your only choice is to take that message and manually parse it
against your modified DD to find what's wrong.

By the way, this is normal.  Don't blindly trust counterparty-supplied
DDs.  Always suspect them of having errors.

On Thu, Jul 11, 2019 at 2:05 PM Andrew Munn <mun...@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/
>
>
> I have confirmed the user running the FIX initiator has read permission on
> the FIX44.modified.xml file
>
> Does FIX44.modified.xml completely replace FIX44.xml so I can delete
> FIX44.xml or is FIX44.modified.xml just overrideing FIX44.xml?
>
> I renamed a few fields in the DD and rebuild:
>
> <message name="ExecutionReport" msgtype="8"
> msgcat="SingleGeneralOrderHandling">
>    ...
>    <component name="NotesSpecial" required="N"/>
>   ...
> </message>
>
> <component name="NotesSpecial">
>   <group name="NoNotes2" required="N">
>      <field name="NoteType" required="N"/>
>      <field name="NoteLabel" required="N"/>
>      <field name="NoteText" required="N"/>
>   </group>
> </component>
>
> <field number="9610" name="NoNotes2" type="NUMINGROUP"/>
> <field number="9611" name="NoteType" type="STRING">
>   <value enum="C" description="CustomerNote"/>
>   <value enum="D" description="DealerNote"/>
>   <value enum="I" description="PrivateOrInternalNote"/>
> </field>
> <field number="9612" name="NoteLabel" type="STRING"/>
> <field number="9613" name="NoteText" type="STRING"/>
>
> I believe my FIX44.modified.xml DD was found in the expected location
> during compilation because when
> decompiling c:\java\qfj-2.1.1-bloomberg-map\quickfixj-core\target\classes\quickfix\fix44\ExecutionReport.class
> I see these methods:
>
>     import quickfix.fix44.component.NotesSpecial;
>     public void set(NotesSpecial component) {
>         this.setComponent(component);
>     }
>
>     public NotesSpecial get(NotesSpecial component) throws FieldNotFound {
>         this.getComponent(component);
>         return component;
>     }
>
>     public NotesSpecial getNotesSpecial() throws FieldNotFound {
>         return this.get(new NotesSpecial());
>     }
>
>     public void set(quickfix.field.NoNotes2 value) {
>         this.setField(value);
>     }
>
>     public quickfix.field.NoNotes2 get(quickfix.field.NoNotes2 value)
> throws FieldNotFound {
>         this.getField(value);
>         return value;
>     }
>
>     public quickfix.field.NoNotes2 getNoNotes2() throws FieldNotFound {
>         return this.get(new quickfix.field.NoNotes2());
>     }
>
>     public boolean isSet(quickfix.field.NoNotes2 field) {
>         return this.isSetField(field);
>     }
>
>     public boolean isSetNoNotes2() {
>         return this.isSetField(9610);
>     }
>
> And this class:
>
> public static class NoNotes2 extends Group {
>         static final long serialVersionUID = 20050617L;
>         private static final int[] ORDER = new int[]{9611, 9612, 9613, 0};
>
>         public NoNotes2() {
>             super(9610, 9611, ORDER);
>         }
>        ...
> }
>
> Does all that look correct?
>
> It feels like my initiator is not reading my DD but it must or I would not
> see the ConfigError exception when I remove the DD and restart, right?
>
> A possible additional clue is I also see this reject on ExecutionReports
>
>   Rejecting invalid message: quickfix.FieldException: Tag appears more
> than once, field=2669
>
> DD has:
>
> <message name="ExecutionReport" msgtype="8"
> msgcat="SingleGeneralOrderHandling">
>   ...
>   <component name="TrdRegPublicationGrp" required="N"/>
>   ...
> </message>
>
> <field number="2668" name="NoTrdRegPublications" type="NUMINGROUP"/>
> <field number="2669" name="TrdRegPublicationType" type="INT">
>   <value enum="0" description="PreTradeTransparencyWaiver"/>
>   <value enum="1" description="PostTradeDeferral"/>
>   <value enum="2" description="ExemptedFromPublication"/>
> </field>
>
> <component name="TrdRegPublicationGrp">
>   <group name="NoTrdRegPublications" required="N">
>     <field name="TrdRegPublicationType" required="N"/>
>     <field name="TrdRegPublicationReason" required="N"/>
>   </group>
> </component>
>
>
>
>
>
> On Thu, Jul 11, 2019 at 1:46 PM Andrew Munn <mun...@gm...> wrote:
>
>> The DD is the one being used.  If I rename it temporarily I get
>> Exception in thread "main" quickfix.ConfigError: Could not find data
>> dictionary: ./etc/FIX44.modified.xml
>>
>> tags are present:
>>
>> $ grep NoNotes2 FIX44.modified.xml
>>       <group name="NoNotes2" required="N">
>>     <field number="9610" name="NoNotes2" type="NUMINGROUP"/>
>>
>> I tried renaming the group to NoNotes2 in case there was some naming
>> collision.  Could this error be caused by some other field or group naming
>> collision elsewhere in the DD I was given?
>>
>> Everything looks ok but I must be overlooking something.
>>
>> Can I just in-line the Group into the ExecutionReport msg definition or
>> must Groups live in Components?
>>
>> On Thu, Jul 11, 2019 at 12:35 PM Grant Birchmeier <
>> gbi...@co...> wrote:
>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>>> http://www.quickfixj.org/support/
>>>
>>>
>>> Regarding your question about components, please read my SO answer here:
>>> https://stackoverflow.com/a/29774713/650475
>>> I think that will clarify the concept.
>>>
>>> I don't see anything obviously wrong in your message or DD definitions.
>>> 9610 is ok to appear in any top-level (not in another group) part of the
>>> message, and must be immediately followed by 9611 and then optionally
>>> 9612/13 (I'm sure you know all this already).
>>>
>>> My gut says your engine isn't reading the right config.  I mean, what
>>> you've posted all looks right.  Are you sure you copied the new DD to /etc/FIX44.modified.xml
>>> ?
>>>
>>>
>>> On Thu, Jul 11, 2019 at 10:22 AM Andrew Munn <mun...@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/
>>>>
>>>>
>>>> Adding subject
>>>>
>>>>
>>>> On Thu, Jul 11, 2019 at 11:05 AM Andrew Munn <mun...@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/
>>>>>
>>>>>
>>>>> I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and
>>>>> rejecting them with:
>>>>>
>>>>> "Rejecting invalid message: quickfix.FieldException: Tag not defined
>>>>> for this message type, field=9610"
>>>>>
>>>>> I'm using the DataDictionary Bloomberg provided.
>>>>>
>>>>> I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process
>>>>> to rebuild is:
>>>>> - delete all instances of FIX44.modified.xml in the QF directory tree
>>>>> - copy the provided DD to
>>>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
>>>>> - do not modify FIX44.xml
>>>>> - mvn clean package -Dmaven.javadoc.skip=true -DskipTests
>>>>> -PskipBundlePlugin -DskipAT=true
>>>>>
>>>>>  Directory of
>>>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
>>>>> 2019-07-11  09:16 AM           287,770 FIX44.modified.xml
>>>>> 2018-11-12  02:11 PM           336,023 FIX44.xml
>>>>>
>>>>> I get warnings like these.  In the past I was able to ignore then when
>>>>> building for other counterparties.
>>>>>
>>>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar
>>>>> define 7190 overlapping classes:
>>>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar
>>>>> define 5 overlapping classes:
>>>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
>>>>> overlapping classes:
>>>>> [WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar
>>>>> define 13 overlapping classes:
>>>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
>>>>> quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
>>>>> [WARNING] maven-shade-plugin has detected that some class files are
>>>>> [WARNING] present in two or more JARs. When this happens, only one
>>>>> [WARNING] single version of the class is copied to the uber jar.
>>>>> [WARNING] Usually this is not harmful and you can skip these warnings,
>>>>> [WARNING] otherwise try to manually exclude artifacts based on
>>>>> [WARNING] mvn dependency:tree -Ddetail=true and the above output.
>>>>> [WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
>>>>>
>>>>> FIX44.modified.xml has:
>>>>>
>>>>> <message name="ExecutionReport" msgtype="8"
>>>>> msgcat="SingleGeneralOrderHandling">
>>>>>   ...
>>>>>   <component name="Notes" required="N"/>
>>>>> </message>
>>>>>
>>>>> <component name="Notes">
>>>>>   <group name="NoNotes" required="N">
>>>>>     <field name="NoteType" required="N"/>
>>>>>     <field name="NoteLabel" required="N"/>
>>>>>     <field name="NoteText" required="N"/>
>>>>>   </group>
>>>>> </component>
>>>>>
>>>>> <field number="9610" name="NoNotes" type="NUMINGROUP"/>
>>>>> <field number="9611" name="NoteType" type="STRING">
>>>>>   <value enum="C" description="CustomerNote"/>
>>>>>   <value enum="D" description="DealerNote"/>
>>>>>   <value enum="I" description="PrivateOrInternalNote"/>
>>>>> </field>
>>>>> <field number="9612" name="NoteLabel" type="STRING"/>
>>>>> <field number="9613" name="NoteText" type="STRING"/>
>>>>>
>>>>> (cfg file)
>>>>> [DEFAULT]
>>>>> AllowUnknownMsgFields=Y
>>>>> UseDataDictionary=Y
>>>>> AppDataDictionary=./etc/FIX44.modified.xml
>>>>> ValidateFieldsOutOfOrder=Y
>>>>>
>>>>> I can successfully parse the ExecutionReport String they send to XML
>>>>> like this:
>>>>>
>>>>> void parseSingleBlbExec(String data) throws InvalidMessage,
>>>>> ConfigError {
>>>>>         DataDictionary sessionDictionary = new
>>>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>>>         appDictionary = new
>>>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>>>         appDictionary.setCheckFieldsOutOfOrder(true);
>>>>>         appDictionary.setAllowUnknownMessageFields(false);
>>>>>         appDictionary.setCheckUserDefinedFields(true);
>>>>>         appDictionary.setCheckUnorderedGroupFields(true);
>>>>>         quickfix.fix44.ExecutionReport message = new
>>>>> quickfix.fix44.ExecutionReport();
>>>>>         message.fromString(data, sessionDictionary, appDictionary,
>>>>> true);
>>>>>         System.out.println(message.toXML(appDictionary));
>>>>> }
>>>>>
>>>>> But when the message arrives on a live session I generate a reject.
>>>>>
>>>>> Messages are like this:
>>>>>
>>>>> 8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
>>>>> TREASURY
>>>>> N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
>>>>> XXXXX|803=9|523=NEW
>>>>> YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
>>>>> XX|803=9|523=NEW
>>>>> YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
>>>>> XXXX|803=9|523=NEW
>>>>> YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210
>>>>>
>>>>> 8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
>>>>> not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|
>>>>>
>>>>> Must <component> blocks in the dictionary's message definition appear
>>>>> in the same order that the repeating groups arrive in?
>>>>>
>>>>> What am I overlooking here?
>>>>>
>>>>> Thanks
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> --
>>> Grant Birchmeier
>>> *Connamara Systems, LLC*
>>> *Made-To-Measure Trading Solutions.*
>>> Exactly what you need. No more. No less.
>>> http://connamara.com
>>> _______________________________________________
>>> 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
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com

Re: [Quickfixj-users] Tag not defined for this message type, field=9610"

[Andrew M. <mun...@gm...>]

I have confirmed the user running the FIX initiator has read permission on
the FIX44.modified.xml file

Does FIX44.modified.xml completely replace FIX44.xml so I can delete
FIX44.xml or is FIX44.modified.xml just overrideing FIX44.xml?

I renamed a few fields in the DD and rebuild:

<message name="ExecutionReport" msgtype="8"
msgcat="SingleGeneralOrderHandling">
   ...
   <component name="NotesSpecial" required="N"/>
  ...
</message>

<component name="NotesSpecial">
  <group name="NoNotes2" required="N">
     <field name="NoteType" required="N"/>
     <field name="NoteLabel" required="N"/>
     <field name="NoteText" required="N"/>
  </group>
</component>

<field number="9610" name="NoNotes2" type="NUMINGROUP"/>
<field number="9611" name="NoteType" type="STRING">
  <value enum="C" description="CustomerNote"/>
  <value enum="D" description="DealerNote"/>
  <value enum="I" description="PrivateOrInternalNote"/>
</field>
<field number="9612" name="NoteLabel" type="STRING"/>
<field number="9613" name="NoteText" type="STRING"/>

I believe my FIX44.modified.xml DD was found in the expected location
during compilation because when
decompiling c:\java\qfj-2.1.1-bloomberg-map\quickfixj-core\target\classes\quickfix\fix44\ExecutionReport.class
I see these methods:

    import quickfix.fix44.component.NotesSpecial;
    public void set(NotesSpecial component) {
        this.setComponent(component);
    }

    public NotesSpecial get(NotesSpecial component) throws FieldNotFound {
        this.getComponent(component);
        return component;
    }

    public NotesSpecial getNotesSpecial() throws FieldNotFound {
        return this.get(new NotesSpecial());
    }

    public void set(quickfix.field.NoNotes2 value) {
        this.setField(value);
    }

    public quickfix.field.NoNotes2 get(quickfix.field.NoNotes2 value)
throws FieldNotFound {
        this.getField(value);
        return value;
    }

    public quickfix.field.NoNotes2 getNoNotes2() throws FieldNotFound {
        return this.get(new quickfix.field.NoNotes2());
    }

    public boolean isSet(quickfix.field.NoNotes2 field) {
        return this.isSetField(field);
    }

    public boolean isSetNoNotes2() {
        return this.isSetField(9610);
    }

And this class:

public static class NoNotes2 extends Group {
        static final long serialVersionUID = 20050617L;
        private static final int[] ORDER = new int[]{9611, 9612, 9613, 0};

        public NoNotes2() {
            super(9610, 9611, ORDER);
        }
       ...
}

Does all that look correct?

It feels like my initiator is not reading my DD but it must or I would not
see the ConfigError exception when I remove the DD and restart, right?

A possible additional clue is I also see this reject on ExecutionReports

  Rejecting invalid message: quickfix.FieldException: Tag appears more than
once, field=2669

DD has:

<message name="ExecutionReport" msgtype="8"
msgcat="SingleGeneralOrderHandling">
  ...
  <component name="TrdRegPublicationGrp" required="N"/>
  ...
</message>

<field number="2668" name="NoTrdRegPublications" type="NUMINGROUP"/>
<field number="2669" name="TrdRegPublicationType" type="INT">
  <value enum="0" description="PreTradeTransparencyWaiver"/>
  <value enum="1" description="PostTradeDeferral"/>
  <value enum="2" description="ExemptedFromPublication"/>
</field>

<component name="TrdRegPublicationGrp">
  <group name="NoTrdRegPublications" required="N">
    <field name="TrdRegPublicationType" required="N"/>
    <field name="TrdRegPublicationReason" required="N"/>
  </group>
</component>





On Thu, Jul 11, 2019 at 1:46 PM Andrew Munn <mun...@gm...> wrote:

> The DD is the one being used.  If I rename it temporarily I get
> Exception in thread "main" quickfix.ConfigError: Could not find data
> dictionary: ./etc/FIX44.modified.xml
>
> tags are present:
>
> $ grep NoNotes2 FIX44.modified.xml
>       <group name="NoNotes2" required="N">
>     <field number="9610" name="NoNotes2" type="NUMINGROUP"/>
>
> I tried renaming the group to NoNotes2 in case there was some naming
> collision.  Could this error be caused by some other field or group naming
> collision elsewhere in the DD I was given?
>
> Everything looks ok but I must be overlooking something.
>
> Can I just in-line the Group into the ExecutionReport msg definition or
> must Groups live in Components?
>
> On Thu, Jul 11, 2019 at 12:35 PM Grant Birchmeier <
> gbi...@co...> wrote:
>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
>> http://www.quickfixj.org/support/
>>
>>
>> Regarding your question about components, please read my SO answer here:
>> https://stackoverflow.com/a/29774713/650475
>> I think that will clarify the concept.
>>
>> I don't see anything obviously wrong in your message or DD definitions.
>> 9610 is ok to appear in any top-level (not in another group) part of the
>> message, and must be immediately followed by 9611 and then optionally
>> 9612/13 (I'm sure you know all this already).
>>
>> My gut says your engine isn't reading the right config.  I mean, what
>> you've posted all looks right.  Are you sure you copied the new DD to /etc/FIX44.modified.xml
>> ?
>>
>>
>> On Thu, Jul 11, 2019 at 10:22 AM Andrew Munn <mun...@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/
>>>
>>>
>>> Adding subject
>>>
>>>
>>> On Thu, Jul 11, 2019 at 11:05 AM Andrew Munn <mun...@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/
>>>>
>>>>
>>>> I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and rejecting
>>>> them with:
>>>>
>>>> "Rejecting invalid message: quickfix.FieldException: Tag not defined
>>>> for this message type, field=9610"
>>>>
>>>> I'm using the DataDictionary Bloomberg provided.
>>>>
>>>> I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process
>>>> to rebuild is:
>>>> - delete all instances of FIX44.modified.xml in the QF directory tree
>>>> - copy the provided DD to
>>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
>>>> - do not modify FIX44.xml
>>>> - mvn clean package -Dmaven.javadoc.skip=true -DskipTests
>>>> -PskipBundlePlugin -DskipAT=true
>>>>
>>>>  Directory of
>>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
>>>> 2019-07-11  09:16 AM           287,770 FIX44.modified.xml
>>>> 2018-11-12  02:11 PM           336,023 FIX44.xml
>>>>
>>>> I get warnings like these.  In the past I was able to ignore then when
>>>> building for other counterparties.
>>>>
>>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar
>>>> define 7190 overlapping classes:
>>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar
>>>> define 5 overlapping classes:
>>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
>>>> overlapping classes:
>>>> [WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar
>>>> define 13 overlapping classes:
>>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
>>>> quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
>>>> [WARNING] maven-shade-plugin has detected that some class files are
>>>> [WARNING] present in two or more JARs. When this happens, only one
>>>> [WARNING] single version of the class is copied to the uber jar.
>>>> [WARNING] Usually this is not harmful and you can skip these warnings,
>>>> [WARNING] otherwise try to manually exclude artifacts based on
>>>> [WARNING] mvn dependency:tree -Ddetail=true and the above output.
>>>> [WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
>>>>
>>>> FIX44.modified.xml has:
>>>>
>>>> <message name="ExecutionReport" msgtype="8"
>>>> msgcat="SingleGeneralOrderHandling">
>>>>   ...
>>>>   <component name="Notes" required="N"/>
>>>> </message>
>>>>
>>>> <component name="Notes">
>>>>   <group name="NoNotes" required="N">
>>>>     <field name="NoteType" required="N"/>
>>>>     <field name="NoteLabel" required="N"/>
>>>>     <field name="NoteText" required="N"/>
>>>>   </group>
>>>> </component>
>>>>
>>>> <field number="9610" name="NoNotes" type="NUMINGROUP"/>
>>>> <field number="9611" name="NoteType" type="STRING">
>>>>   <value enum="C" description="CustomerNote"/>
>>>>   <value enum="D" description="DealerNote"/>
>>>>   <value enum="I" description="PrivateOrInternalNote"/>
>>>> </field>
>>>> <field number="9612" name="NoteLabel" type="STRING"/>
>>>> <field number="9613" name="NoteText" type="STRING"/>
>>>>
>>>> (cfg file)
>>>> [DEFAULT]
>>>> AllowUnknownMsgFields=Y
>>>> UseDataDictionary=Y
>>>> AppDataDictionary=./etc/FIX44.modified.xml
>>>> ValidateFieldsOutOfOrder=Y
>>>>
>>>> I can successfully parse the ExecutionReport String they send to XML
>>>> like this:
>>>>
>>>> void parseSingleBlbExec(String data) throws InvalidMessage, ConfigError
>>>> {
>>>>         DataDictionary sessionDictionary = new
>>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>>         appDictionary = new
>>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>>         appDictionary.setCheckFieldsOutOfOrder(true);
>>>>         appDictionary.setAllowUnknownMessageFields(false);
>>>>         appDictionary.setCheckUserDefinedFields(true);
>>>>         appDictionary.setCheckUnorderedGroupFields(true);
>>>>         quickfix.fix44.ExecutionReport message = new
>>>> quickfix.fix44.ExecutionReport();
>>>>         message.fromString(data, sessionDictionary, appDictionary,
>>>> true);
>>>>         System.out.println(message.toXML(appDictionary));
>>>> }
>>>>
>>>> But when the message arrives on a live session I generate a reject.
>>>>
>>>> Messages are like this:
>>>>
>>>> 8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
>>>> TREASURY
>>>> N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
>>>> XXXXX|803=9|523=NEW
>>>> YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
>>>> XX|803=9|523=NEW
>>>> YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
>>>> XXXX|803=9|523=NEW
>>>> YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210
>>>>
>>>> 8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
>>>> not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|
>>>>
>>>> Must <component> blocks in the dictionary's message definition appear
>>>> in the same order that the repeating groups arrive in?
>>>>
>>>> What am I overlooking here?
>>>>
>>>> Thanks
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> --
>> Grant Birchmeier
>> *Connamara Systems, LLC*
>> *Made-To-Measure Trading Solutions.*
>> Exactly what you need. No more. No less.
>> http://connamara.com
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>

Re: [Quickfixj-users] Tag not defined for this message type, field=9610"

[Andrew M. <mun...@gm...>]

The DD is the one being used.  If I rename it temporarily I get
Exception in thread "main" quickfix.ConfigError: Could not find data
dictionary: ./etc/FIX44.modified.xml

tags are present:

$ grep NoNotes2 FIX44.modified.xml
      <group name="NoNotes2" required="N">
    <field number="9610" name="NoNotes2" type="NUMINGROUP"/>

I tried renaming the group to NoNotes2 in case there was some naming
collision.  Could this error be caused by some other field or group naming
collision elsewhere in the DD I was given?

Everything looks ok but I must be overlooking something.

Can I just in-line the Group into the ExecutionReport msg definition or
must Groups live in Components?

On Thu, Jul 11, 2019 at 12:35 PM Grant Birchmeier <gbi...@co...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Regarding your question about components, please read my SO answer here:
> https://stackoverflow.com/a/29774713/650475
> I think that will clarify the concept.
>
> I don't see anything obviously wrong in your message or DD definitions.
> 9610 is ok to appear in any top-level (not in another group) part of the
> message, and must be immediately followed by 9611 and then optionally
> 9612/13 (I'm sure you know all this already).
>
> My gut says your engine isn't reading the right config.  I mean, what
> you've posted all looks right.  Are you sure you copied the new DD to /etc/FIX44.modified.xml
> ?
>
>
> On Thu, Jul 11, 2019 at 10:22 AM Andrew Munn <mun...@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/
>>
>>
>> Adding subject
>>
>>
>> On Thu, Jul 11, 2019 at 11:05 AM Andrew Munn <mun...@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/
>>>
>>>
>>> I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and rejecting
>>> them with:
>>>
>>> "Rejecting invalid message: quickfix.FieldException: Tag not defined for
>>> this message type, field=9610"
>>>
>>> I'm using the DataDictionary Bloomberg provided.
>>>
>>> I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process to
>>> rebuild is:
>>> - delete all instances of FIX44.modified.xml in the QF directory tree
>>> - copy the provided DD to
>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
>>> - do not modify FIX44.xml
>>> - mvn clean package -Dmaven.javadoc.skip=true -DskipTests
>>> -PskipBundlePlugin -DskipAT=true
>>>
>>>  Directory of
>>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
>>> 2019-07-11  09:16 AM           287,770 FIX44.modified.xml
>>> 2018-11-12  02:11 PM           336,023 FIX44.xml
>>>
>>> I get warnings like these.  In the past I was able to ignore then when
>>> building for other counterparties.
>>>
>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar
>>> define 7190 overlapping classes:
>>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar
>>> define 5 overlapping classes:
>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
>>> overlapping classes:
>>> [WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar
>>> define 13 overlapping classes:
>>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
>>> quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
>>> [WARNING] maven-shade-plugin has detected that some class files are
>>> [WARNING] present in two or more JARs. When this happens, only one
>>> [WARNING] single version of the class is copied to the uber jar.
>>> [WARNING] Usually this is not harmful and you can skip these warnings,
>>> [WARNING] otherwise try to manually exclude artifacts based on
>>> [WARNING] mvn dependency:tree -Ddetail=true and the above output.
>>> [WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
>>>
>>> FIX44.modified.xml has:
>>>
>>> <message name="ExecutionReport" msgtype="8"
>>> msgcat="SingleGeneralOrderHandling">
>>>   ...
>>>   <component name="Notes" required="N"/>
>>> </message>
>>>
>>> <component name="Notes">
>>>   <group name="NoNotes" required="N">
>>>     <field name="NoteType" required="N"/>
>>>     <field name="NoteLabel" required="N"/>
>>>     <field name="NoteText" required="N"/>
>>>   </group>
>>> </component>
>>>
>>> <field number="9610" name="NoNotes" type="NUMINGROUP"/>
>>> <field number="9611" name="NoteType" type="STRING">
>>>   <value enum="C" description="CustomerNote"/>
>>>   <value enum="D" description="DealerNote"/>
>>>   <value enum="I" description="PrivateOrInternalNote"/>
>>> </field>
>>> <field number="9612" name="NoteLabel" type="STRING"/>
>>> <field number="9613" name="NoteText" type="STRING"/>
>>>
>>> (cfg file)
>>> [DEFAULT]
>>> AllowUnknownMsgFields=Y
>>> UseDataDictionary=Y
>>> AppDataDictionary=./etc/FIX44.modified.xml
>>> ValidateFieldsOutOfOrder=Y
>>>
>>> I can successfully parse the ExecutionReport String they send to XML
>>> like this:
>>>
>>> void parseSingleBlbExec(String data) throws InvalidMessage, ConfigError {
>>>         DataDictionary sessionDictionary = new
>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>         appDictionary = new
>>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>>         appDictionary.setCheckFieldsOutOfOrder(true);
>>>         appDictionary.setAllowUnknownMessageFields(false);
>>>         appDictionary.setCheckUserDefinedFields(true);
>>>         appDictionary.setCheckUnorderedGroupFields(true);
>>>         quickfix.fix44.ExecutionReport message = new
>>> quickfix.fix44.ExecutionReport();
>>>         message.fromString(data, sessionDictionary, appDictionary, true);
>>>         System.out.println(message.toXML(appDictionary));
>>> }
>>>
>>> But when the message arrives on a live session I generate a reject.
>>>
>>> Messages are like this:
>>>
>>> 8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
>>> TREASURY
>>> N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
>>> XXXXX|803=9|523=NEW
>>> YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
>>> XX|803=9|523=NEW
>>> YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
>>> XXXX|803=9|523=NEW
>>> YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210
>>>
>>> 8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
>>> not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|
>>>
>>> Must <component> blocks in the dictionary's message definition appear in
>>> the same order that the repeating groups arrive in?
>>>
>>> What am I overlooking here?
>>>
>>> Thanks
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.
> http://connamara.com
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Tag not defined for this message type, field=9610"

[Grant B. <gbi...@co...>]

Regarding your question about components, please read my SO answer here:
https://stackoverflow.com/a/29774713/650475
I think that will clarify the concept.

I don't see anything obviously wrong in your message or DD definitions.
9610 is ok to appear in any top-level (not in another group) part of the
message, and must be immediately followed by 9611 and then optionally
9612/13 (I'm sure you know all this already).

My gut says your engine isn't reading the right config.  I mean, what
you've posted all looks right.  Are you sure you copied the new DD to
/etc/FIX44.modified.xml
?


On Thu, Jul 11, 2019 at 10:22 AM Andrew Munn <mun...@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/
>
>
> Adding subject
>
>
> On Thu, Jul 11, 2019 at 11:05 AM Andrew Munn <mun...@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/
>>
>>
>> I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and rejecting
>> them with:
>>
>> "Rejecting invalid message: quickfix.FieldException: Tag not defined for
>> this message type, field=9610"
>>
>> I'm using the DataDictionary Bloomberg provided.
>>
>> I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process to
>> rebuild is:
>> - delete all instances of FIX44.modified.xml in the QF directory tree
>> - copy the provided DD to
>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
>> - do not modify FIX44.xml
>> - mvn clean package -Dmaven.javadoc.skip=true -DskipTests
>> -PskipBundlePlugin -DskipAT=true
>>
>>  Directory of
>> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
>> 2019-07-11  09:16 AM           287,770 FIX44.modified.xml
>> 2018-11-12  02:11 PM           336,023 FIX44.xml
>>
>> I get warnings like these.  In the past I was able to ignore then when
>> building for other counterparties.
>>
>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar
>> define 7190 overlapping classes:
>> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar
>> define 5 overlapping classes:
>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
>> overlapping classes:
>> [WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar
>> define 13 overlapping classes:
>> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
>> quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
>> [WARNING] maven-shade-plugin has detected that some class files are
>> [WARNING] present in two or more JARs. When this happens, only one
>> [WARNING] single version of the class is copied to the uber jar.
>> [WARNING] Usually this is not harmful and you can skip these warnings,
>> [WARNING] otherwise try to manually exclude artifacts based on
>> [WARNING] mvn dependency:tree -Ddetail=true and the above output.
>> [WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
>>
>> FIX44.modified.xml has:
>>
>> <message name="ExecutionReport" msgtype="8"
>> msgcat="SingleGeneralOrderHandling">
>>   ...
>>   <component name="Notes" required="N"/>
>> </message>
>>
>> <component name="Notes">
>>   <group name="NoNotes" required="N">
>>     <field name="NoteType" required="N"/>
>>     <field name="NoteLabel" required="N"/>
>>     <field name="NoteText" required="N"/>
>>   </group>
>> </component>
>>
>> <field number="9610" name="NoNotes" type="NUMINGROUP"/>
>> <field number="9611" name="NoteType" type="STRING">
>>   <value enum="C" description="CustomerNote"/>
>>   <value enum="D" description="DealerNote"/>
>>   <value enum="I" description="PrivateOrInternalNote"/>
>> </field>
>> <field number="9612" name="NoteLabel" type="STRING"/>
>> <field number="9613" name="NoteText" type="STRING"/>
>>
>> (cfg file)
>> [DEFAULT]
>> AllowUnknownMsgFields=Y
>> UseDataDictionary=Y
>> AppDataDictionary=./etc/FIX44.modified.xml
>> ValidateFieldsOutOfOrder=Y
>>
>> I can successfully parse the ExecutionReport String they send to XML like
>> this:
>>
>> void parseSingleBlbExec(String data) throws InvalidMessage, ConfigError {
>>         DataDictionary sessionDictionary = new
>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>         appDictionary = new
>> DataDictionary("c:\\temp\\FIX44.modified.xml");
>>         appDictionary.setCheckFieldsOutOfOrder(true);
>>         appDictionary.setAllowUnknownMessageFields(false);
>>         appDictionary.setCheckUserDefinedFields(true);
>>         appDictionary.setCheckUnorderedGroupFields(true);
>>         quickfix.fix44.ExecutionReport message = new
>> quickfix.fix44.ExecutionReport();
>>         message.fromString(data, sessionDictionary, appDictionary, true);
>>         System.out.println(message.toXML(appDictionary));
>> }
>>
>> But when the message arrives on a live session I generate a reject.
>>
>> Messages are like this:
>>
>> 8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
>> TREASURY
>> N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
>> XXXXX|803=9|523=NEW
>> YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
>> XX|803=9|523=NEW
>> YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
>> XXXX|803=9|523=NEW
>> YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210
>>
>> 8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
>> not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|
>>
>> Must <component> blocks in the dictionary's message definition appear in
>> the same order that the repeating groups arrive in?
>>
>> What am I overlooking here?
>>
>> Thanks
>> _______________________________________________
>> 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
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.
http://connamara.com

Re: [Quickfixj-users] Tag not defined for this message type, field=9610"

[Andrew M. <mun...@gm...>]

Adding subject


On Thu, Jul 11, 2019 at 11:05 AM Andrew Munn <mun...@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/
>
>
> I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and rejecting
> them with:
>
> "Rejecting invalid message: quickfix.FieldException: Tag not defined for
> this message type, field=9610"
>
> I'm using the DataDictionary Bloomberg provided.
>
> I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process to
> rebuild is:
> - delete all instances of FIX44.modified.xml in the QF directory tree
> - copy the provided DD to
> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
> - do not modify FIX44.xml
> - mvn clean package -Dmaven.javadoc.skip=true -DskipTests
> -PskipBundlePlugin -DskipAT=true
>
>  Directory of
> c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
> 2019-07-11  09:16 AM           287,770 FIX44.modified.xml
> 2018-11-12  02:11 PM           336,023 FIX44.xml
>
> I get warnings like these.  In the past I was able to ignore then when
> building for other counterparties.
>
> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar define
> 7190 overlapping classes:
> [WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar
> define 5 overlapping classes:
> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
> overlapping classes:
> [WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar
> define 13 overlapping classes:
> [WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
> quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
> [WARNING] maven-shade-plugin has detected that some class files are
> [WARNING] present in two or more JARs. When this happens, only one
> [WARNING] single version of the class is copied to the uber jar.
> [WARNING] Usually this is not harmful and you can skip these warnings,
> [WARNING] otherwise try to manually exclude artifacts based on
> [WARNING] mvn dependency:tree -Ddetail=true and the above output.
> [WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/
>
> FIX44.modified.xml has:
>
> <message name="ExecutionReport" msgtype="8"
> msgcat="SingleGeneralOrderHandling">
>   ...
>   <component name="Notes" required="N"/>
> </message>
>
> <component name="Notes">
>   <group name="NoNotes" required="N">
>     <field name="NoteType" required="N"/>
>     <field name="NoteLabel" required="N"/>
>     <field name="NoteText" required="N"/>
>   </group>
> </component>
>
> <field number="9610" name="NoNotes" type="NUMINGROUP"/>
> <field number="9611" name="NoteType" type="STRING">
>   <value enum="C" description="CustomerNote"/>
>   <value enum="D" description="DealerNote"/>
>   <value enum="I" description="PrivateOrInternalNote"/>
> </field>
> <field number="9612" name="NoteLabel" type="STRING"/>
> <field number="9613" name="NoteText" type="STRING"/>
>
> (cfg file)
> [DEFAULT]
> AllowUnknownMsgFields=Y
> UseDataDictionary=Y
> AppDataDictionary=./etc/FIX44.modified.xml
> ValidateFieldsOutOfOrder=Y
>
> I can successfully parse the ExecutionReport String they send to XML like
> this:
>
> void parseSingleBlbExec(String data) throws InvalidMessage, ConfigError {
>         DataDictionary sessionDictionary = new
> DataDictionary("c:\\temp\\FIX44.modified.xml");
>         appDictionary = new DataDictionary("c:\\temp\\FIX44.modified.xml");
>         appDictionary.setCheckFieldsOutOfOrder(true);
>         appDictionary.setAllowUnknownMessageFields(false);
>         appDictionary.setCheckUserDefinedFields(true);
>         appDictionary.setCheckUnorderedGroupFields(true);
>         quickfix.fix44.ExecutionReport message = new
> quickfix.fix44.ExecutionReport();
>         message.fromString(data, sessionDictionary, appDictionary, true);
>         System.out.println(message.toXML(appDictionary));
> }
>
> But when the message arrives on a live session I generate a reject.
>
> Messages are like this:
>
> 8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
> TREASURY
> N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
> XXXXX|803=9|523=NEW
> YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
> XX|803=9|523=NEW
> YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
> XXXX|803=9|523=NEW
> YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210
>
> 8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
> not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|
>
> Must <component> blocks in the dictionary's message definition appear in
> the same order that the repeating groups arrive in?
>
> What am I overlooking here?
>
> Thanks
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

[Quickfixj-users] (no subject)

[Andrew M. <mun...@gm...>]

I'm receiving FIX 4.4 ExecutionReport msgs from Bloomberg and rejecting
them with:

"Rejecting invalid message: quickfix.FieldException: Tag not defined for
this message type, field=9610"

I'm using the DataDictionary Bloomberg provided.

I've rebuilt QF/J 2.1.1 on Windows using the provided DD.  My process to
rebuild is:
- delete all instances of FIX44.modified.xml in the QF directory tree
- copy the provided DD to
c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources\FIX44.modified.xml
- do not modify FIX44.xml
- mvn clean package -Dmaven.javadoc.skip=true -DskipTests
-PskipBundlePlugin -DskipAT=true

 Directory of
c:\java\qfj-2.1.1-bloomberg-map\quickfixj-messages\quickfixj-messages-fix44\src\main\resources
2019-07-11  09:16 AM           287,770 FIX44.modified.xml
2018-11-12  02:11 PM           336,023 FIX44.xml

I get warnings like these.  In the past I was able to ignore then when
building for other counterparties.

[WARNING] quickfixj-all-2.1.1.jar, quickfixj-messages-all-2.1.1.jar define
7190 overlapping classes:
[WARNING] quickfixj-all-2.1.1.jar, quickfixj-codegenerator-2.1.1.jar define
5 overlapping classes:
[WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar define 238
overlapping classes:
[WARNING] quickfixj-dictgenerator-2.1.1.jar, quickfixj-all-2.1.1.jar define
13 overlapping classes:
[WARNING] quickfixj-core-2.1.1.jar, quickfixj-all-2.1.1.jar,
quickfixj-messages-all-2.1.1.jar define 2530 overlapping classes:
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/

FIX44.modified.xml has:

<message name="ExecutionReport" msgtype="8"
msgcat="SingleGeneralOrderHandling">
  ...
  <component name="Notes" required="N"/>
</message>

<component name="Notes">
  <group name="NoNotes" required="N">
    <field name="NoteType" required="N"/>
    <field name="NoteLabel" required="N"/>
    <field name="NoteText" required="N"/>
  </group>
</component>

<field number="9610" name="NoNotes" type="NUMINGROUP"/>
<field number="9611" name="NoteType" type="STRING">
  <value enum="C" description="CustomerNote"/>
  <value enum="D" description="DealerNote"/>
  <value enum="I" description="PrivateOrInternalNote"/>
</field>
<field number="9612" name="NoteLabel" type="STRING"/>
<field number="9613" name="NoteText" type="STRING"/>

(cfg file)
[DEFAULT]
AllowUnknownMsgFields=Y
UseDataDictionary=Y
AppDataDictionary=./etc/FIX44.modified.xml
ValidateFieldsOutOfOrder=Y

I can successfully parse the ExecutionReport String they send to XML like
this:

void parseSingleBlbExec(String data) throws InvalidMessage, ConfigError {
        DataDictionary sessionDictionary = new
DataDictionary("c:\\temp\\FIX44.modified.xml");
        appDictionary = new DataDictionary("c:\\temp\\FIX44.modified.xml");
        appDictionary.setCheckFieldsOutOfOrder(true);
        appDictionary.setAllowUnknownMessageFields(false);
        appDictionary.setCheckUserDefinedFields(true);
        appDictionary.setCheckUnorderedGroupFields(true);
        quickfix.fix44.ExecutionReport message = new
quickfix.fix44.ExecutionReport();
        message.fromString(data, sessionDictionary, appDictionary, true);
        System.out.println(message.toXML(appDictionary));
}

But when the message arrives on a live session I generate a reject.

Messages are like this:

8=FIX.4.4|9=1400|35=8|49=BLP_MAP_PROD3|56=XXX_PROD3|34=780|128=914171|347=UTF-8|142=Voice|144=FI|115=DCSVC_278_4|43=Y|122=20190711-11:18:25|52=20190711-14:10:12|30=XOFF|60=20190710-21:38:48.671|150=F|1950=8|31=123.456|151=0|541=20290515|32=99999|423=1|64=20190712|6=123.456|37=VCON:20190710:9999:9|157=58|38=99999|39=2|159=99999.99|669=123.456|460=6|223=0.123|14=999999|854=0|15=USD|75=20190710|106=US
TREASURY
N/B|17=VCON:20190710:xxxx:x:xx|167=XXXXXX|48=XXXXX86T2|198=3739:20190710:XXXXX:X|470=US|1430=V|381=123456.31|22=1|1913=0|54=2|7014=21|55=[N/A]|236=0.99|118=9999999.49|453=6|448=GS|447=D|452=1|802=2|523=3788|803=4014|523=N|803=4069|448=XXXXXXXXXXX:99999999|447=D|452=11|802=4|523=14|803=4|523=XXX
XXXXX|803=9|523=NEW
YORK|803=34|523=US|803=38|448=XXXXXXXXX:99999999|447=D|452=12|802=3|523=XXX
XX|803=9|523=NEW
YORK|803=34|523=US|803=38|448=XXXX|447=D|452=13|802=2|523=99999|803=9999|523=N|803=9999|448=BXT|447=D|452=16|448=XXXXXX:9999999|447=D|452=36|802=3|523=XXXX
XXXX|803=9|523=NEW
YORK|803=34|523=US|803=38|9610=3|9611=C|9612=Group|9613=XXX.XXX|9611=C|9612=Spread|9613=0|9611=C|9612=Prime|9613=XXX|454=4|455=USXXXXXXXXX|456=4|455=999999999|456=1|455=999999999|456=A|455=T|456=8|768=3|769=20190710-21:38:48.671|770=1|769=20190710-21:39:54.335|770=2|769=20190711-11:18:25.539|770=113|2529=1|2530=100|2531=9.9999999|10=210

8=FIX.4.4|9=195|35=3|34=4|49=XXX_PROD3|52=20190711-14:10:12.422|56=BLP_MAP_PROD3|115=914171|128=DCSVC_278_4|143=Voice|145=FI|45=780|58=Tag
not defined for this message type, field=9610|371=9610|372=8|373=2|10=237|

Must <component> blocks in the dictionary's message definition appear in
the same order that the repeating groups arrive in?

What am I overlooking here?

Thanks

Re: [Quickfixj-users] back...

[Christoph J. <chr...@ma...>]

Many thanks to all of you! :)

Cheers,
Chris.

On 09/07/2019 07:30, Rekha Hindlekar wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Congratulations Chris !!!
>
> On Mon, Jul 8, 2019 at 11:56 PM Philip Whitehouse <ph...@wh... <mailto: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/
>
>
>     Indeed, congratulations Chris!
>
>     Best,
>
>     Philip Whitehouse
>
>     > On 8 Jul 2019, at 17:17, Colin DuPlantis <co...@ma...
>     <mailto:co...@ma...>> wrote:
>     >
>     > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     > QuickFIX/J Support: http://www.quickfixj.org/support/
>     >
>     >
>     > Welcome back and congratulations on your fecundity!
>     >
>     >> On 7/8/19 4:14 AM, Christoph John via Quickfixj-users wrote:
>     >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     >> QuickFIX/J Support: http://www.quickfixj.org/support/
>     >>
>     >>
>     >> Hi,
>     >>
>     >> sorry if anyone did wait for a reply from me personally or on the QFJ project.
>     >> I am now back from a somewhat extended paternity leave. :)
>     >>
>     >> Cheers,
>     >> Chris.
>     >>
>     > --
>     > Colin DuPlantis
>     > Chief Architect, Marketcetera
>     > Download, Run, Trade
>     > 888.868.4884
>     > https://www.marketcetera.com
>     >
>     >
>     >
>     > _______________________________________________
>     > Quickfixj-users mailing list
>     > Qui...@li... <mailto:Qui...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] QuickFIX/J 2.1.1 - SLF4J Log Categories appear incorrect

[Christoph J. <chr...@ma...>]

Thinking further about this I believe that you do not need that setting when you already name your 
categories e.g. "${senderCompID}.${targetCompID}." So setting it to N should be OK.
The only problem I see now is that the sessionID seems to be appended and not prepended.

Chris.

On 11/07/2019 10:24, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi Tommy,
>
> sorry for the late reply.
> Just to understand: you were not specifying the setting SLF4JLogPrependSessionID=Y before? I mean 
> you shouldn't because its default seems to be Y.
> And when you now put SLF4JLogPrependSessionID=N then the behaviour is as before, i.e. with QFJ 1.6.3?
>
> Did the log filenames change or only the content of the files, i.e. the logger name?
>
> Cheers,
> Chris.
>
>
> On 26/04/2019 01:11, th...@ft... wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>> Has anybody with authority had a chance to look at this?  The change introduced has the presumed 
>> unintended consequences of breaking things for some of us using Log4J.
>>
>> Regards - Tommy
>>
>>> On Apr 10, 2019, at 10:26 PM, th...@ft... <mailto:th...@ft...> wrote:
>>>
>>> I recently downloaded QF/J 2.1.1 and am upgrading from QF/J 1.6.3.  Most of the work was 
>>> converting my application code to utilize the ‘java.time’ package.  I have everything running 
>>> and going thru some tests.  In the process, I noticed log messages in files they were not in 
>>> before.  We use Log4J and configure the following QF/J properties…
>>>
>>> SLF4JLogEventCategory=${senderCompID}.${targetCompID}.event
>>> SLF4JLogIncomingMessageCategory=${senderCompID}.${targetCompID}.msg.incoming
>>> SLF4JLogOutgoingMessageCategory=${senderCompID}.${targetCompID}.msg.outgoing
>>>
>>> ..and the recently discovered (not in the user manual)…
>>>
>>> SLF4JLogErrorEventCategory=${senderCompID}.${targetCompID}.errorEvent
>>>
>>> I have spent hours reviewing and comparing QF/J source code trying to determine what changed.
>>>
>>> It appears there is a configuration setting 'SLF4JLogPrependSessionID’ described as "Controls 
>>> whether session ID is prepended to log message.”
>>>
>>> The behavior of this setting has been completely changed by the following commit of source file 
>>> ‘SLF4JLog.java’...
>>>
>>> https://github.com/quickfix-j/quickfixj/commit/0eb3359059d3551dde588f3cff6c836119141cf6#diff-82a6b6a09255551e3683d8943e3e4263 
>>>
>>>
>>> It appears the intent of this change did not create the desired effect as my log “categories" 
>>> now all have the SessionID appended. (e.g. 'SENDER.TARGET.eventFIX.4.4:SENDER->TARGET: ')
>>>
>>> The current workaround is to configure... SLF4JLogPrependSessionID=N
>>>
>>> Would someone please elaborate on the intended use of configuration setting 
>>> ‘SLF4JLogPrependSessionID’.
>>>
>>> Regards - Tommy
>>
>>

-- 
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

Re: [Quickfixj-users] QuickFIX/J 2.1.1 - SLF4J Log Categories appear incorrect

[Christoph J. <chr...@ma...>]

Hi Tommy,

sorry for the late reply.
Just to understand: you were not specifying the setting SLF4JLogPrependSessionID=Y before? I mean 
you shouldn't because its default seems to be Y.
And when you now put SLF4JLogPrependSessionID=N then the behaviour is as before, i.e. with QFJ 1.6.3?

Did the log filenames change or only the content of the files, i.e. the logger name?

Cheers,
Chris.


On 26/04/2019 01:11, th...@ft... wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Has anybody with authority had a chance to look at this?  The change introduced has the presumed 
> unintended consequences of breaking things for some of us using Log4J.
>
> Regards - Tommy
>
>> On Apr 10, 2019, at 10:26 PM, th...@ft... <mailto:th...@ft...> wrote:
>>
>> I recently downloaded QF/J 2.1.1 and am upgrading from QF/J 1.6.3.  Most of the work was 
>> converting my application code to utilize the ‘java.time’ package.  I have everything running and 
>> going thru some tests.  In the process, I noticed log messages in files they were not in before. 
>>  We use Log4J and configure the following QF/J properties…
>>
>> SLF4JLogEventCategory=${senderCompID}.${targetCompID}.event
>> SLF4JLogIncomingMessageCategory=${senderCompID}.${targetCompID}.msg.incoming
>> SLF4JLogOutgoingMessageCategory=${senderCompID}.${targetCompID}.msg.outgoing
>>
>> ..and the recently discovered (not in the user manual)…
>>
>> SLF4JLogErrorEventCategory=${senderCompID}.${targetCompID}.errorEvent
>>
>> I have spent hours reviewing and comparing QF/J source code trying to determine what changed.
>>
>> It appears there is a configuration setting 'SLF4JLogPrependSessionID’ described as "Controls 
>> whether session ID is prepended to log message.”
>>
>> The behavior of this setting has been completely changed by the following commit of source file 
>> ‘SLF4JLog.java’...
>>
>> https://github.com/quickfix-j/quickfixj/commit/0eb3359059d3551dde588f3cff6c836119141cf6#diff-82a6b6a09255551e3683d8943e3e4263 
>>
>>
>> It appears the intent of this change did not create the desired effect as my log “categories" now 
>> all have the SessionID appended. (e.g. 'SENDER.TARGET.eventFIX.4.4:SENDER->TARGET: ')
>>
>> The current workaround is to configure... SLF4JLogPrependSessionID=N
>>
>> Would someone please elaborate on the intended use of configuration setting 
>> ‘SLF4JLogPrependSessionID’.
>>
>> Regards - Tommy
>
>
>
> _______________________________________________
> 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

Re: [Quickfixj-users] back...

[Rekha H. <rek...@or...>]

Congratulations Chris !!!

On Mon, Jul 8, 2019 at 11:56 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/
>
>
> Indeed, congratulations Chris!
>
> Best,
>
> Philip Whitehouse
>
> > On 8 Jul 2019, at 17:17, Colin DuPlantis <co...@ma...> wrote:
> >
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> >
> >
> > Welcome back and congratulations on your fecundity!
> >
> >> On 7/8/19 4:14 AM, Christoph John via Quickfixj-users wrote:
> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> >> QuickFIX/J Support: http://www.quickfixj.org/support/
> >>
> >>
> >> Hi,
> >>
> >> sorry if anyone did wait for a reply from me personally or on the QFJ
> project.
> >> I am now back from a somewhat extended paternity leave. :)
> >>
> >> Cheers,
> >> Chris.
> >>
> > --
> > Colin DuPlantis
> > Chief Architect, Marketcetera
> > Download, Run, Trade
> > 888.868.4884
> > https://www.marketcetera.com
> >
> >
> >
> > _______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


-- 
Regards

Rekha Hindlekar  |  Sr. Technical Lead  |  OroSoft Solutions Pvt. Ltd.
*T: +91 22 2854 0911 | *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."