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

Re: [Quickfixj-users] Representing Forex pairs

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

Hi,

I'm not familiar with FOREX but a search in http://fiximate.fixtrading.org/latestEP/ shows that 
there is the following tag:
http://fiximate.fixtrading.org/latestEP/en/FIX.5.0SP2_EP240/tag871.html

This tag has a value for instrument nominator and denominator.

Cheers,
Chris.


On 18/10/2018 10:27, Tsz Shun Chow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hi all,
>
> Which are the standard FIX tags to represent the numerator and the denominator of an underlying 
> FOREX pair? So far I couldn’t find any.
>
> Cheers,
> Jason
>
>
> _______________________________________________
> 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] Representing Forex pairs

[Tsz S. C. <jas...@gm...>]

Hi all,

Which are the standard FIX tags to represent the numerator and the
denominator of an underlying FOREX pair? So far I couldn’t find any.

Cheers,
Jason

Re: [Quickfixj-users] FIX Log Replayer

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

No.  You are not the first to ask this.  This tool does not exist because
no such tool can be so naively-implemented.

Any such tool would need to alter timestamps, alter sequence numbers, and
recompute checksums.  And what should it do if your client app behaves in a
way that it didn't when the recording was first taken?  What about the
timing of heartbeats or test-request messages?

What you probably really need is a test application that will create a FIX
counterparty and send messages according to a predetermined script, in
response to your application-under-test's behavior.  That script will
likely be adapted from a log, but it can't be an actual log.

Any mature software firm that does FIX development has probably developed
their own version of this.  I recommend that you give it a shot; it's not
terribly difficult, you'll learn a lot, and it'll be a valuable tool for
your firm going forward.

On Wed, Oct 17, 2018 at 11:58 AM bhavishya goyal <bha...@gm...>
wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Hi,
>
> Is there any open source which can be used to replay logs from fix message
> file ?
>
> --
> Regards
> Bhavishya Goyal
> _______________________________________________
> 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] In case of disconnect relogin is not working

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

Didn't you read my reply regarding the log time stamps?
Maybe check your spam folder or read them in the mailing list archive. 
Also I would check with version 2.1.0 which is the most recent version. Why did you try with 2.0.0?

Chris. 

Am 17. Oktober 2018 18:52:48 MESZ schrieb bhavishya goyal <bha...@gm...>:
>QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>QuickFIX/J Support: http://www.quickfixj.org/support/

[Quickfixj-users] FIX Log Replayer

[bhavishya g. <bha...@gm...>]

Hi,

Is there any open source which can be used to replay logs from fix message
file ?

-- 
Regards
Bhavishya Goyal

Re: [Quickfixj-users] In case of disconnect relogin is not working

[bhavishya g. <bha...@gm...>]

I tried with quickfix version 2.0.0 as well and same issue is coming.
Please can any body help me on this issue ?

My application is sending logon request and getting logon response and
session get logged in perfectly at first time . After some time session get
disconnected due to heartbeat timeout and my application send login again
and acceptor send login response within same second but my initiator don't
get connected after 10 second it send another login request. Ideally it
should not send login request again.

Event logs are

20181015-13:36:34: Sent test request TEST

20181015-13:37:01: Disconnecting: Timed out waiting for heartbeat

20181015-13:37:02: Initiated logon request

20181015-13:37:13: Disconnecting: Timed out waiting for logon response

20181015-13:37:32: Disconnecting: Socket exception (/192.168.40.29:31815):
java.io.IOException: Connection reset by peer

20181015-13:38:02: Initiated logon request

Message logs
8=FIX.4.2^A9=69^A35=A^A34=1064^A49=test^A52=20181015-13:37:02.570^A56=test^A98=0^A108=30^A10=075^A
8=FIX.4.2^A9=000593^A35=A^A34=001527^A43=N^A52=20181015-13:37:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=
s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize
Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary
Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange With
Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer
Fill,12/Maximize Fill^A8035=5bc41694.^A10=210^A
8=FIX.4.2^A9=69^A35=A^A34=1065^A49=test^A52=20181015-13:38:02.569^A56=test^A98=0^A108=30^A10=085^A
8=FIX.4.2^A9=000593^A35=A^A34=001528^A43=N^A52=20181015-13:38:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=
s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize
Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary
Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange With
Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer
Fill,12/Maximize Fill^A8035=5bc41694.^A10=212^A


As you can see we send login request at 20181015-13:37:02.570 and get
response at 20181015-13:37:02 then still it send one more login request.

Any help would be really appreciated


I have removed actual SendercompId and Target comp Id




-- 
Regards
Bhavishya Goyal

Re: [Quickfixj-users] In case of disconnect relogin is not working

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

Actually, you do not know if you got the first Logon response at 13:37:02. That is only the 
SendingTime of the counterparty. It is not clear from the log you pasted when you really received 
the message as there are no logging timestamps.

Chris.

On 16/10/2018 16:13, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hmm, looks like a timing problem. Which version of QFJ are you using?
>
> Chris.
>
> On 16/10/18 15:11, bhavishya goyal wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>>
>> My application is sending logon request and getting logon response and session get logged in 
>> perfectly at first time . After some time session get disconnected due to heartbeat timeout and 
>> my application send login again and acceptor send login response within same second but my 
>> initiator don't get connected after 10 second it send another login request. Ideally it should 
>> not send login request again.
>>
>> Event logs are
>>
>>
>> |20181015-13:36:34: Sent test request TEST 20181015-13:37:01: Disconnecting: Timed out waiting 
>> for heartbeat 20181015-13:37:02: Initiated logon request 20181015-13:37:13: Disconnecting: Timed 
>> out waiting for logon response 20181015-13:37:32: Disconnecting: Socket exception 
>> (/192.168.40.29:31815 <http://192.168.40.29:31815>): java.io.IOException: Connection reset by 
>> peer 20181015-13:38:02: Initiated logon request|
>> Message logs
>>
>> |8=FIX.4.2^A9=69^A35=A^A34=1064^A49=test^A52=20181015-13:37:02.570^A56=test^A98=0^A108=30^A10=075^A 
>> 8=FIX.4.2^A9=000593^A35=A^A34=001527^A43=N^A52=20181015-13:37:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com 
>> <http://s3.amazonaws.com>^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize 
>> Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume 
>> Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer 
>> Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=210^A 
>> 8=FIX.4.2^A9=69^A35=A^A34=1065^A49=test^A52=20181015-13:38:02.569^A56=test^A98=0^A108=30^A10=085^A 
>> 8=FIX.4.2^A9=000593^A35=A^A34=001528^A43=N^A52=20181015-13:38:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com 
>> <http://s3.amazonaws.com>^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize 
>> Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume 
>> Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer 
>> Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=212^A|
>>
>> I have removed actual SendercompId and Target comp Id
>>
>> As you can see we send login request at 20181015-13:37:02.570 and get response at 
>> 20181015-13:37:02 then still it send one more login request.
>>
>> Any help would be really appreciated
>>
>>
>>
>> Regards
>> Bhavishya Goyal
>>
>>

-- 
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] In case of disconnect relogin is not working

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

Hmm, looks like a timing problem. Which version of QFJ are you using?

Chris.

On 16/10/18 15:11, bhavishya goyal wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
>
> My application is sending logon request and getting logon response and session get logged in 
> perfectly at first time . After some time session get disconnected due to heartbeat timeout and my 
> application send login again and acceptor send login response within same second but my initiator 
> don't get connected after 10 second it send another login request. Ideally it should not send 
> login request again.
>
> Event logs are
>
>
> |20181015-13:36:34: Sent test request TEST 20181015-13:37:01: Disconnecting: Timed out waiting for 
> heartbeat 20181015-13:37:02: Initiated logon request 20181015-13:37:13: Disconnecting: Timed out 
> waiting for logon response 20181015-13:37:32: Disconnecting: Socket exception 
> (/192.168.40.29:31815 <http://192.168.40.29:31815>): java.io.IOException: Connection reset by peer 
> 20181015-13:38:02: Initiated logon request|
> Message logs
>
> |8=FIX.4.2^A9=69^A35=A^A34=1064^A49=test^A52=20181015-13:37:02.570^A56=test^A98=0^A108=30^A10=075^A 
> 8=FIX.4.2^A9=000593^A35=A^A34=001527^A43=N^A52=20181015-13:37:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com 
> <http://s3.amazonaws.com>^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize 
> Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume 
> Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer 
> Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=210^A 
> 8=FIX.4.2^A9=69^A35=A^A34=1065^A49=test^A52=20181015-13:38:02.569^A56=test^A98=0^A108=30^A10=085^A 
> 8=FIX.4.2^A9=000593^A35=A^A34=001528^A43=N^A52=20181015-13:38:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com 
> <http://s3.amazonaws.com>^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize 
> Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary Exchange,3/Highest Volume 
> Exchange With Rebate,4/High Volume Exchange With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer 
> Rebate,11/Prefer Fill,12/Maximize Fill^A8035=5bc41694.^A10=212^A|
>
> I have removed actual SendercompId and Target comp Id
>
> As you can see we send login request at 20181015-13:37:02.570 and get response at 
> 20181015-13:37:02 then still it send one more login request.
>
> Any help would be really appreciated
>
>
>
> Regards
> Bhavishya Goyal
>
>
>
>
> _______________________________________________
> 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] In case of disconnect relogin is not working

[bhavishya g. <bha...@gm...>]

My application is sending logon request and getting logon response and
session get logged in perfectly at first time . After some time session get
disconnected due to heartbeat timeout and my application send login again
and acceptor send login response within same second but my initiator don't
get connected after 10 second it send another login request. Ideally it
should not send login request again.

Event logs are


20181015-13:36:34: Sent test request TEST
20181015-13:37:01: Disconnecting: Timed out waiting for heartbeat
20181015-13:37:02: Initiated logon request
20181015-13:37:13: Disconnecting: Timed out waiting for logon response
20181015-13:37:32: Disconnecting: Socket exception
(/192.168.40.29:31815): java.io.IOException: Connection reset by peer
20181015-13:38:02: Initiated logon request

Message logs


8=FIX.4.2^A9=69^A35=A^A34=1064^A49=test^A52=20181015-13:37:02.570^A56=test^A98=0^A108=30^A10=075^A
8=FIX.4.2^A9=000593^A35=A^A34=001527^A43=N^A52=20181015-13:37:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize
Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary
Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange
With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer
Fill,12/Maximize Fill^A8035=5bc41694.^A10=210^A
8=FIX.4.2^A9=69^A35=A^A34=1065^A49=test^A52=20181015-13:38:02.569^A56=test^A98=0^A108=30^A10=085^A
8=FIX.4.2^A9=000593^A35=A^A34=001528^A43=N^A52=20181015-13:38:02^A49=test^A56=test^A98=0^A108=30^A6247=prod^A6272=AMEX/OPT,CBOE/OPT,PHLX/OPT,PSE/OPT,DTB/OPT,ISE/OPT,BELFOX/OPT,GLOBEX/FOP,MONEP/OPT,SOFFEX/OPT,FTA/OPT,ASX/OPT,BOX/OPT,ECBOT/FOP,IBCX/BAG,BATS/OPT,NASDAQOM/OPT,ICEEU/OPT^A6382=S3^A6387=s3.amazonaws.com^A6386=0WWXP5X5ZAMQC93NZR82^A6492=1^A6541=1^A6530=1^A6550=1^A6560=1/Maximize
Rebate,9/Prefer Rebate,11/Prefer Fill,12/Maximize Fill,2/Primary
Exchange,3/Highest Volume Exchange With Rebate,4/High Volume Exchange
With Lowest Fee^A6749=1/Maximize Rebate,9/Prefer Rebate,11/Prefer
Fill,12/Maximize Fill^A8035=5bc41694.^A10=212^A

I have removed actual SendercompId and Target comp Id

As you can see we send login request at 20181015-13:37:02.570 and get
response at 20181015-13:37:02 then still it send one more login request.

Any help would be really appreciated



Regards
Bhavishya Goyal

Re: [Quickfixj-users] Message Resliency On FIX Initiator side

[Rahul G. <rah...@ho...>]

Thanks a lot Colin and Eric.

I will try out both your solutions

Thanks
Rahul
________________________________
From: eri...@re... <eri...@re...>
Sent: Monday, October 15, 2018 6:58 PM
To: qui...@li...; qui...@li...; chr...@ma...
Subject: Re: [Quickfixj-users] Message Resliency On FIX Initiator side

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

Re: [Quickfixj-users] Message Resliency On FIX Initiator side

[<eri...@re...>]

What are you trying to test? The ability to recover missed messages? You can drop the session and edit the sequence numbers in the fix session files

Eric Goebelbecker
eri...@re...




On Mon, Oct 15, 2018 at 9:19 AM -0400, "Rahul Gaur" <rah...@ho...<mailto:rah...@ho...>> wrote:

Hi Chris,

Thanks for the information.

Comments inline

[Chris]what do you mean by "how it can be tested"? Pull the network cable?? ;) Alternatively you could ask the other side to kill their Acceptor.
[Rahul]As soon as I pull the network cable or kill the Acceptor(Our own FIX simulator as external Acceptor is not in our control), the FIX session immediately detects that the TCP/IP connection is broken and marks itself as disconnected. This makes simulating this scenario nearly impossible(at least for me:) ). That's why I asked if someone has ever tested this on the Initiator side and If someone can suggest testing this in a predictable manner. Or, if any quickfixj expert can confirm that using FileStoreFactory  on initiator side will ensure the expectation as you suggested => 'The expectation would be that the remote side gets all missing messages by re-requesting them via ResendRequest on the next Logon'.

Thanks
Rahul
________________________________
From: Christoph John <chr...@ma...>
Sent: Monday, October 15, 2018 5:25 PM
To: qui...@li...; Rahul Gaur
Subject: Re: [Quickfixj-users] Message Resliency On FIX Initiator side

Hi,

what do you mean by "how it can be tested"? Pull the network cable?? ;) Alternatively you could ask the other side to kill their Acceptor.
The expectation would be that the remote side gets all missing messages by re-requesting them via ResendRequest on the next Logon.

Cheers,
Chris.

On 15/10/18 13:48, Rahul Gaur wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_documentation_&d=DwMFAw&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=jWh6MsSrup23rUP3itTekkNswiyLMJiWm9psyiA_GKQ&s=n4swQWszEeKmGxF4aMbNSwsO909tZUvlCB3YPwwYpuo&e=>
QuickFIX/J Support: http://www.quickfixj.org/support/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.quickfixj.org_support_&d=DwMFAw&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=jWh6MsSrup23rUP3itTekkNswiyLMJiWm9psyiA_GKQ&s=Wjwir8oX5eS3kuc34V2mTD0esJoGC9okWkj3KEkd7zA&e=>





Hi All,

We have a typical FIX setup in which we have one Initiator connecting to an external Acceptor and are exchanging FIX messages with each other. On Initiator side we are using FileStoreFactory as MessageFactory and caching 10000 outgoing messages. We need to test a resiliency scenario wherein the Acceptor goes down while some of the messages from Initiator are still in-flight. Can you suggest how it can be tested and also what is the expectation in the above scenario.

The quickfixj version on initiator side is 1.6.3

Thanks
Rahul






_______________________________________________
Quickfixj-users mailing list
Qui...@li...<mailto:Qui...@li...>
https://lists.sourceforge.net/lists/listinfo/quickfixj-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_quickfixj-2Dusers&d=DwMFAw&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=jWh6MsSrup23rUP3itTekkNswiyLMJiWm9psyiA_GKQ&s=JLpIlXgSVnq2hWpSbJuwP1vzfgSR39qeupWWCdzdzaA&e=>



--
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...<mailto:chr...@ma...>

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.macd.com&d=DwMFAw&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=o7YI_4EZ5O7Q26HQ0aGkeMo3ueGrutp1y6y7ced_zAA&m=jWh6MsSrup23rUP3itTekkNswiyLMJiWm9psyiA_GKQ&s=KImLhWwonKMsx8cE9OdsviyFA03aB-LrQ_Z2Q62EYlQ&e=>

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Message Resliency On FIX Initiator side

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

Rahul,


Even with the session disconnected you can still send messages. They 
will be queued until the session is available again.


As for testing, I would just mock up an Acceptor with QFJ that just 
kills the connection after x number of messages. You can have it wait 
30s and restart itself. This will test your initiator's ability to not 
drop any messages in this scenario. Whether the acceptor does or not is 
not your responsibility.


- Colin


On 10/15/2018 06:16 AM, Rahul Gaur wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi Chris,
>
> Thanks for the information.
>
> Comments inline
>
> *[Chris]*what do you mean by "how it can be tested"? Pull the network 
> cable?? ;) Alternatively you could ask the other side to kill their 
> Acceptor.
> *[Rahul]*As soon as I pull the network cable or kill the Acceptor(Our 
> own FIX simulator as external Acceptor is not in our control), the FIX 
> session immediately detects that the TCP/IP connection is broken and 
> marks itself as disconnected. This makes simulating this scenario 
> nearly impossible(at least for me:) ). That's why I asked if someone 
> has ever tested this on the Initiator side and If someone can suggest 
> testing this in a predictable manner. Or, if any quickfixj expert can 
> confirm that using *FileStoreFactory *on initiator side will ensure 
> the expectation as you suggested => 'The expectation would be that the 
> remote side gets all missing messages by re-requesting them via 
> ResendRequest on the next Logon'.
>
> Thanks
> Rahul
> ------------------------------------------------------------------------
> *From:* Christoph John <chr...@ma...>
> *Sent:* Monday, October 15, 2018 5:25 PM
> *To:* qui...@li...; Rahul Gaur
> *Subject:* Re: [Quickfixj-users] Message Resliency On FIX Initiator side
> Hi,
>
> what do you mean by "how it can be tested"? Pull the network cable?? 
> ;) Alternatively you could ask the other side to kill their Acceptor.
> The expectation would be that the remote side gets all missing 
> messages by re-requesting them via ResendRequest on the next Logon.
>
> Cheers,
> Chris.
>
> On 15/10/18 13:48, Rahul Gaur wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>> Hi All,
>>
>> We have a typical FIX setup in which we have one Initiator connecting 
>> to an external Acceptor and are exchanging FIX messages with each 
>> other. On *Initiator *side we are using *FileStoreFactory *as 
>> MessageFactory and caching 10000 outgoing messages. We need to test a 
>> resiliency scenario wherein the Acceptor goes down while some of the 
>> messages from Initiator are still in-flight. Can you suggest how it 
>> can be tested and also what is the expectation in the above scenario.
>>
>> The quickfixj version on initiator side is *1.6.3*
>>
>> Thanks
>> Rahul
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

Re: [Quickfixj-users] Message Resliency On FIX Initiator side

[Rahul G. <rah...@ho...>]

Hi Chris,

Thanks for the information.

Comments inline

[Chris]what do you mean by "how it can be tested"? Pull the network cable?? ;) Alternatively you could ask the other side to kill their Acceptor.
[Rahul]As soon as I pull the network cable or kill the Acceptor(Our own FIX simulator as external Acceptor is not in our control), the FIX session immediately detects that the TCP/IP connection is broken and marks itself as disconnected. This makes simulating this scenario nearly impossible(at least for me:) ). That's why I asked if someone has ever tested this on the Initiator side and If someone can suggest testing this in a predictable manner. Or, if any quickfixj expert can confirm that using FileStoreFactory  on initiator side will ensure the expectation as you suggested => 'The expectation would be that the remote side gets all missing messages by re-requesting them via ResendRequest on the next Logon'.

Thanks
Rahul
________________________________
From: Christoph John <chr...@ma...>
Sent: Monday, October 15, 2018 5:25 PM
To: qui...@li...; Rahul Gaur
Subject: Re: [Quickfixj-users] Message Resliency On FIX Initiator side

Hi,

what do you mean by "how it can be tested"? Pull the network cable?? ;) Alternatively you could ask the other side to kill their Acceptor.
The expectation would be that the remote side gets all missing messages by re-requesting them via ResendRequest on the next Logon.

Cheers,
Chris.

On 15/10/18 13:48, Rahul Gaur wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/





Hi All,

We have a typical FIX setup in which we have one Initiator connecting to an external Acceptor and are exchanging FIX messages with each other. On Initiator side we are using FileStoreFactory as MessageFactory and caching 10000 outgoing messages. We need to test a resiliency scenario wherein the Acceptor goes down while some of the messages from Initiator are still in-flight. Can you suggest how it can be tested and also what is the expectation in the above scenario.

The quickfixj version on initiator side is 1.6.3

Thanks
Rahul






_______________________________________________
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

Re: [Quickfixj-users] Message Resliency On FIX Initiator side

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

Hi,

what do you mean by "how it can be tested"? Pull the network cable?? ;) Alternatively you could ask 
the other side to kill their Acceptor.
The expectation would be that the remote side gets all missing messages by re-requesting them via 
ResendRequest on the next Logon.

Cheers,
Chris.

On 15/10/18 13:48, Rahul Gaur wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi All,
>
> We have a typical FIX setup in which we have one Initiator connecting to an external Acceptor and 
> are exchanging FIX messages with each other. On *Initiator *side we are using *FileStoreFactory 
> *as MessageFactory and caching 10000 outgoing messages. We need to test a resiliency scenario 
> wherein the Acceptor goes down while some of the messages from Initiator are still in-flight. Can 
> you suggest how it can be tested and also what is the expectation in the above scenario.
>
> The quickfixj version on initiator side is *1.6.3*
>
> Thanks
> Rahul
>
>
>
>
>
> _______________________________________________
> 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] Message Resliency On FIX Initiator side

[Rahul G. <rah...@ho...>]

Hi All,

We have a typical FIX setup in which we have one Initiator connecting to an external Acceptor and are exchanging FIX messages with each other. On Initiator side we are using FileStoreFactory as MessageFactory and caching 10000 outgoing messages. We need to test a resiliency scenario wherein the Acceptor goes down while some of the messages from Initiator are still in-flight. Can you suggest how it can be tested and also what is the expectation in the above scenario.

The quickfixj version on initiator side is 1.6.3

Thanks
Rahul

Re: [Quickfixj-users] MsgSeqNum too low...

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

Note that, usually, you'll arrange with the counter parties when to 
reset the session. QFJ will reset the sequence number automatically at 
the start of the session. I have rarely (ever?) had to explicitly set 
141 on messages and usually the counters don't appreciate it and might 
not even respect it.


On 09/27/2018 06:59 PM, Ross Yakulis wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Good point I will try that.  I missed that.  Just starting out on Fix 
> and learning.
>
>
>> On Sep 27, 2018, at 11:40 AM, Colin DuPlantis <co...@ma... 
>> <mailto:co...@ma...>> wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> I'm not sure what you're responding to, but, you can accomplish this 
>> more easily through configuration:
>>
>> /ResetOnLogon/ 	Determines if sequence numbers should be reset before 
>> sending/receiving a logon request. 	Y
>> N 	N
>> /ResetOnLogout/ 	Determines if sequence numbers should be reset to 1 
>> after a normal logout termination. 	Y
>> N 	N
>> /ResetOnDisconnect/ 	Determines if sequence numbers should be reset 
>> to 1 after an abnormal termination. 	Y
>> N 	N
>> /ResetOnError/ 	Session setting for doing an automatic reset when an 
>> error occurs. A reset means disconnect, sequence numbers reset, store 
>> cleaned and reconnect, as for a daily reset. 	Y
>> N 	N
>>
>>
>> On 09/27/2018 11:15 AM, yakulis wrote:
>>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>> I found this worked.
>>>
>>> 	public void toAdmin(Message message, SessionID sessionID) {
>>> 		log.debug("Admin Message to FixEngine -> " +
>>> getMessageTypeString(message));
>>> 		logMessage(message);
>>> 		MsgType messageType = getMessageType(message);
>>>
>>> 		if (messageType.valueEquals(MsgType.LOGON)) {
>>> 			log.debug("Logon, setting reset sequence flag");
>>> 			message.setField(new ResetSeqNumFlag(true));
>>> 			logMessage(message);
>>> 		} else if (messageType.valueEquals(MsgType.HEARTBEAT)) {
>>>
>>>
>>>
>>>
>>> --
>>> Sent from:http://quickfix-j.364392.n2.nabble.com/
>>>
>>>
>>> _______________________________________________
>>> Quickfixj-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>
>> -- 
>> Colin DuPlantis
>> Chief Architect, Marketcetera
>> Download, Run, Trade
>> 888.868.4884 +1.541.306.6556
>> http://www.marketcetera.org
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li... 
>> <mailto:Qui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> NOTICE: This communication may contain information that is privileged 
> or confidential. It may be read and used solely by the intended 
> recipient(s), and any review, use or distribution by others is 
> STRICTLY PROHIBITED. If you are not the intended recipient, you are 
> prohibited from disclosing, copying, distributing or using any of this 
> information. If you received this communication in error, please 
> contact the sender immediately and destroy the material in its 
> entirety, whether electronic or hard copy. No assurance is given that 
> this e-mail or any attachments are free of viruses or other harmful code.
>
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] MsgSeqNum too low...

[Ross Y. <ros...@em...>]

Good point I will try that.  I missed that.  Just starting out on Fix and learning.


> On Sep 27, 2018, at 11:40 AM, Colin DuPlantis <co...@ma...> wrote:
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> 
> 
> I'm not sure what you're responding to, but, you can accomplish this more easily through configuration:
> 
> ResetOnLogon	Determines if sequence numbers should be reset before sending/receiving a logon request.	Y
> N	N
> ResetOnLogout	Determines if sequence numbers should be reset to 1 after a normal logout termination.	Y
> N	N
> ResetOnDisconnect	Determines if sequence numbers should be reset to 1 after an abnormal termination.	Y
> N	N
> ResetOnError	Session setting for doing an automatic reset when an error occurs. A reset means disconnect, sequence numbers reset, store cleaned and reconnect, as for a daily reset.	Y
> N	N
> 
> On 09/27/2018 11:15 AM, yakulis wrote:
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/>
>> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>> 
>> 
>> I found this worked.
>> 
>> 	public void toAdmin(Message message, SessionID sessionID) {
>> 		log.debug("Admin Message to FixEngine -> " +
>> getMessageTypeString(message));
>> 		logMessage(message);
>> 		MsgType messageType = getMessageType(message);
>> 
>> 		if (messageType.valueEquals(MsgType.LOGON)) {
>> 			log.debug("Logon, setting reset sequence flag");
>> 			message.setField(new ResetSeqNumFlag(true));
>> 			logMessage(message);
>> 		} else if (messageType.valueEquals(MsgType.HEARTBEAT)) {
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://quickfix-j.364392.n2.nabble.com/ <http://quickfix-j.364392.n2.nabble.com/>
>> 
>> 
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li... <mailto:Qui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
> 
> -- 
> Colin DuPlantis
> Chief Architect, Marketcetera
> Download, Run, Trade
> 888.868.4884 +1.541.306.6556
> http://www.marketcetera.org <http://www.marketcetera.org/>_______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users


-- 
NOTICE: This communication may contain information that is privileged or 
confidential. It may be read and used solely by the intended recipient(s), 
and any review, use or distribution by others is STRICTLY PROHIBITED. If 
you are not the intended recipient, you are prohibited from disclosing, 
copying, distributing or using any of this information. If you received 
this communication in error, please contact the sender immediately and 
destroy the material in its entirety, whether electronic or hard copy. No 
assurance is given that this e-mail or any attachments are free of viruses 
or other harmful code.

Re: [Quickfixj-users] MsgSeqNum too low...

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

I'm not sure what you're responding to, but, you can accomplish this 
more easily through configuration:

/ResetOnLogon/ 	Determines if sequence numbers should be reset before 
sending/receiving a logon request. 	Y
N 	N
/ResetOnLogout/ 	Determines if sequence numbers should be reset to 1 
after a normal logout termination. 	Y
N 	N
/ResetOnDisconnect/ 	Determines if sequence numbers should be reset to 1 
after an abnormal termination. 	Y
N 	N
/ResetOnError/ 	Session setting for doing an automatic reset when an 
error occurs. A reset means disconnect, sequence numbers reset, store 
cleaned and reconnect, as for a daily reset. 	Y
N 	N


On 09/27/2018 11:15 AM, yakulis wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> I found this worked.
>
> 	public void toAdmin(Message message, SessionID sessionID) {
> 		log.debug("Admin Message to FixEngine -> " +
> getMessageTypeString(message));
> 		logMessage(message);
> 		MsgType messageType = getMessageType(message);
>
> 		if (messageType.valueEquals(MsgType.LOGON)) {
> 			log.debug("Logon, setting reset sequence flag");
> 			message.setField(new ResetSeqNumFlag(true));
> 			logMessage(message);
> 		} else if (messageType.valueEquals(MsgType.HEARTBEAT)) {
>
>
>
>
> --
> Sent from: http://quickfix-j.364392.n2.nabble.com/
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884 +1.541.306.6556
http://www.marketcetera.org

Re: [Quickfixj-users] MsgSeqNum too low...

[yakulis <ros...@em...>]

I found this worked.

	public void toAdmin(Message message, SessionID sessionID) {
		log.debug("Admin Message to FixEngine -> " +
getMessageTypeString(message));
		logMessage(message);
		MsgType messageType = getMessageType(message);

		if (messageType.valueEquals(MsgType.LOGON)) {
			log.debug("Logon, setting reset sequence flag");
			message.setField(new ResetSeqNumFlag(true));
			logMessage(message);
		} else if (messageType.valueEquals(MsgType.HEARTBEAT)) {




--
Sent from: http://quickfix-j.364392.n2.nabble.com/

Re: [Quickfixj-users] Unable to route quickfixj.events to log via Log4j (over SLF4J)

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

Maybe you could give Colin'shinta try.

Moreover, I ran the test suite and saw files like these generated in the temp dir:
FIX.4.2-SENDER1536593511974-TARGET1536593511974.messages.log
FIX.4.2-SENDER1536593511974-TARGET1536593511974.event.log

They contained some events and a test message (created by the FileLogTest). So I would assume that 
it should work and also suspect some kindof log4j problem/anomaly.

Cheers,
Chris.


On 10/09/18 17:10, Xiau Wei Toon wrote:
> No problem. I've moved this requirement to future releases since there are more urgent deliveries 
> to complete first, thus no more available information on my part.
>
> Would be great if you could advise on how you'd do it so I can reflect on this once it comes back 
> onto my plate.
>
> Thanks.
>
> On Mon, 10 Sep 2018, 10:12 pm Christoph John, <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Sorry, I did not have time to follow this up. Did you find something out in the meantime or
>     have a reproducable test case?
>
>     Thanks,
>     Chris.
>
>
>     On 31/08/18 10:29, Christoph John via Quickfixj-users wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>     QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>>     OK, good news. Just wanted to make sure since there were some minor changes to the SLF4JLog
>>     class in the last release.
>>
>>     I might find some time next week to set up a little test.
>>
>>     Chris.
>>
>>     On 31/08/18 10:25, Xiau Wei Toon wrote:
>>>     Reverted to 2.0.0, does not work. In fact, we absolutely must use 2.1 since we rely on the
>>>     new rawString method.
>>>
>>>     If you were the one implementing, how would you do it? The requirement is simple. I want to
>>>     route all event messages regardless of session into a daily rolling file using Log4j.
>>>
>>>     On Fri, 31 Aug 2018, 4:11 pm Christoph John, <chr...@ma...
>>>     <mailto:chr...@ma...>> wrote:
>>>
>>>         Hmm, OK.
>>>         Just to rule outany regression error: could you please test with version 2.0.0?
>>>
>>>         Thanks,
>>>         Chris.
>>>
>>>
>>>         On 31/08/18 10:06, Xiau Wei Toon wrote:
>>>>         Indeed that is correct. The logfile is created but permanently empty. I have:
>>>>         1. Removed all the default slf4j configuration from session settings
>>>>         2. Added appender for log4j.logger.quickfixj.errorEvent
>>>>
>>>>         Files are created, but empty. I redirect all the screen logs from java execute line to
>>>>         a dumpfile and I can see all quickfixj events and msg logs generated without any WARN
>>>>         or ERROR. Turning on additivity will not make a copy in system_debug.log as well.
>>>>         Version2.1 is the one used.
>>>>
>>>>
>>>>         On Fri, 31 Aug 2018, 3:31 pm Christoph John, <chr...@ma...
>>>>         <mailto:chr...@ma...>> wrote:
>>>>
>>>>             So you are saying the file ./logs/quickfix.log gets created but with no content? No
>>>>             messages and no events?
>>>>             The SLF4J settings you are passing are the default ones as far as I can see. What
>>>>             happens if you omit them?
>>>>             I have just seen there is an undocumented setting SLF4JLogErrorEventCategory which
>>>>             defaults to "quickfixj.errorEvent". What happens if you add that to your settings?
>>>>
>>>>             IMHO it can only be a minor config error since this feature is used by many people.
>>>>             Which QFJ version are you using BTW?
>>>>
>>>>             Chris.
>>>>
>>>>             On 31/08/18 08:59, ToonXW wrote:
>>>>>             QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>>             QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>>             I have been trying to route all event logs to one daily rolling log file,
>>>>>             however it is unclear what is going wrong. I verified that quickfixj picked
>>>>>             up the log4j.properties file (by forcing an exception) and also confirmed
>>>>>             that the target log file was created post startup. Please advise.
>>>>>
>>>>>             *SessionSettings:*
>>>>>             SLF4JLogEventCategory=quickfixj.event
>>>>>             SLF4JLogIncomingMessageCategory=quickfixj.incoming
>>>>>             SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>>>>>             SLF4JLogPrependSessionID=Y
>>>>>             SLF4JLogHeartbeats=Y
>>>>>
>>>>>             *When building ThreadedSocketInitiator:*
>>>>>             LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>>>>
>>>>>             *log4j.properties:*
>>>>>             # Root logger option
>>>>>             log4j.rootLogger=DEBUG, core
>>>>>             # Write to log files, support date rolling.
>>>>>             log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>>>>>             log4j.appender.core.Append=true
>>>>>             log4j.appender.core.File=./logs/system_debug.log
>>>>>             log4j.appender.core.DatePattern='.'yyyy-MM-dd
>>>>>             log4j.appender.core.layout=org.apache.log4j.PatternLayout
>>>>>             log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>>>>>             %-5p %c{1}:%L - %m%n
>>>>>             # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>>>>>             quickfixj.outgoing
>>>>>             log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>>>>>             log4j.additivity.quickfixj.event=false;
>>>>>             log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>>>>>             log4j.appender.quickfixEvents.Append=true
>>>>>             log4j.appender.quickfixEvents.File=./logs/quickfix.log
>>>>>             log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>>>>>             log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>>>>>             log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>>>>>             HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>>>>
>>>
>>>         -- 
>>>         Christoph John
>>>         Software Engineering
>>>         T +49 241 557080-28
>>>         chr...@ma... <mailto:chr...@ma...>
>>>
>>>         MACD GmbH
>>>         Oppenhoffallee 103
>>>         52066 Aachen, Germany
>>>         www.macd.com <http://www.macd.com>
>>>
>>>         Amtsgericht Aachen: HRB 8151
>>>         Ust.-Id: DE 813021663
>>>         Geschäftsführer: George Macdonald
>>>
>>
>>     -- 
>>     Christoph John
>>     Software Engineering
>>     T +49 241 557080-28
>>     chr...@ma... <mailto:chr...@ma...>
>>
>>     MACD GmbH
>>     Oppenhoffallee 103
>>     52066 Aachen, Germany
>>     www.macd.com <http://www.macd.com>
>>
>>     Amtsgericht Aachen: HRB 8151
>>     Ust.-Id: DE 813021663
>>     Geschäftsführer: George Macdonald
>>
>>
>>     ------------------------------------------------------------------------------
>>     Check out the vibrant tech community on one of the world's most
>>     engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     Qui...@li... <mailto:Qui...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma... <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Unable to route quickfixj.events to log via Log4j (over SLF4J)

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

FWIW, I looked at the logger.properties file OP provided.

The file, itself, looked accurate. I find in times like this that, 
sometimes, Log4J is not looking at the file I think it's looking at. I 
would add '-Dlog4j.debug' to the application and check the first few 
lines at startup to verify the config file used is the one expected.


On 09/10/2018 07:12 AM, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Sorry, I did not have time to follow this up. Did you find something 
> out in the meantime or have a reproducable test case?
>
> Thanks,
> Chris.
>
>
> On 31/08/18 10:29, Christoph John via Quickfixj-users wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>> QuickFIX/J Support:http://www.quickfixj.org/support/
>>
>>
>>
>>
>> OK, good news. Just wanted to make sure since there were some minor 
>> changes to the SLF4JLog class in the last release.
>>
>> I might find some time next week to set up a little test.
>>
>> Chris.
>>
>> On 31/08/18 10:25, Xiau Wei Toon wrote:
>>> Reverted to 2.0.0, does not work. In fact, we absolutely must use 
>>> 2.1 since we rely on the new rawString method.
>>>
>>> If you were the one implementing, how would you do it? The 
>>> requirement is simple. I want to route all event messages regardless 
>>> of session into a daily rolling file using Log4j.
>>>
>>> On Fri, 31 Aug 2018, 4:11 pm Christoph John, 
>>> <chr...@ma... <mailto:chr...@ma...>> wrote:
>>>
>>>     Hmm, OK.
>>>     Just to rule outany regression error: could you please test with
>>>     version 2.0.0?
>>>
>>>     Thanks,
>>>     Chris.
>>>
>>>
>>>     On 31/08/18 10:06, Xiau Wei Toon wrote:
>>>>     Indeed that is correct. The logfile is created but permanently
>>>>     empty. I have:
>>>>     1. Removed all the default slf4j configuration from session
>>>>     settings
>>>>     2. Added appender for log4j.logger.quickfixj.errorEvent
>>>>
>>>>     Files are created, but empty. I redirect all the screen logs
>>>>     from java execute line to a dumpfile and I can see all
>>>>     quickfixj events and msg logs generated without any WARN or
>>>>     ERROR. Turning on additivity will not make a copy in
>>>>     system_debug.log as well. Version2.1 is the one used.
>>>>
>>>>
>>>>     On Fri, 31 Aug 2018, 3:31 pm Christoph John,
>>>>     <chr...@ma... <mailto:chr...@ma...>> wrote:
>>>>
>>>>         So you are saying the file ./logs/quickfix.log gets created
>>>>         but with no content? No messages and no events?
>>>>         The SLF4J settings you are passing are the default ones as
>>>>         far as I can see. What happens if you omit them?
>>>>         I have just seen there is an undocumented setting
>>>>         SLF4JLogErrorEventCategory which defaults to
>>>>         "quickfixj.errorEvent". What happens if you add that to
>>>>         your settings?
>>>>
>>>>         IMHO it can only be a minor config error since this feature
>>>>         is used by many people. Which QFJ version are you using BTW?
>>>>
>>>>         Chris.
>>>>
>>>>         On 31/08/18 08:59, ToonXW wrote:
>>>>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>>         QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>>
>>>>>
>>>>>         I have been trying to route all event logs to one daily rolling log file,
>>>>>         however it is unclear what is going wrong. I verified that quickfixj picked
>>>>>         up the log4j.properties file (by forcing an exception) and also confirmed
>>>>>         that the target log file was created post startup. Please advise.
>>>>>
>>>>>         *SessionSettings:*
>>>>>         SLF4JLogEventCategory=quickfixj.event
>>>>>         SLF4JLogIncomingMessageCategory=quickfixj.incoming
>>>>>         SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>>>>>         SLF4JLogPrependSessionID=Y
>>>>>         SLF4JLogHeartbeats=Y
>>>>>
>>>>>         *When building ThreadedSocketInitiator:*
>>>>>         LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>>>>
>>>>>         *log4j.properties:*
>>>>>         # Root logger option
>>>>>         log4j.rootLogger=DEBUG, core
>>>>>         # Write to log files, support date rolling.
>>>>>         log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>>>>>         log4j.appender.core.Append=true
>>>>>         log4j.appender.core.File=./logs/system_debug.log
>>>>>         log4j.appender.core.DatePattern='.'yyyy-MM-dd
>>>>>         log4j.appender.core.layout=org.apache.log4j.PatternLayout
>>>>>         log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>>>>>         %-5p %c{1}:%L - %m%n
>>>>>         # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>>>>>         quickfixj.outgoing
>>>>>         log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>>>>>         log4j.additivity.quickfixj.event=false;
>>>>>         log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>>>>>         log4j.appender.quickfixEvents.Append=true
>>>>>         log4j.appender.quickfixEvents.File=./logs/quickfix.log
>>>>>         log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>>>>>         log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>>>>>         log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>>>>>         HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>>>>
>>>
>>>     -- 
>>>     Christoph John
>>>     Software Engineering
>>>     T +49 241 557080-28
>>>     chr...@ma... <mailto:chr...@ma...>
>>>
>>>     MACD GmbH
>>>     Oppenhoffallee 103
>>>     52066 Aachen, Germany
>>>     www.macd.com <http://www.macd.com>
>>>
>>>     Amtsgericht Aachen: HRB 8151
>>>     Ust.-Id: DE 813021663
>>>     Geschäftsführer: George Macdonald
>>>
>>
>> -- 
>> Christoph John
>> Software Engineering
>> T +49 241 557080-28
>> chr...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germany
>> www.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
> -- 
> Christoph John
> Software Engineering
> T +49 241 557080-28
> chr...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884 +1.541.306.6556
http://www.marketcetera.org

Re: [Quickfixj-users] Unable to route quickfixj.events to log via Log4j (over SLF4J)

[Xiau W. T. <tx...@gm...>]

No problem. I've moved this requirement to future releases since there are
more urgent deliveries to complete first, thus no more available
information on my part.

Would be great if you could advise on how you'd do it so I can reflect on
this once it comes back onto my plate.

Thanks.

On Mon, 10 Sep 2018, 10:12 pm Christoph John, <chr...@ma...>
wrote:

> Sorry, I did not have time to follow this up. Did you find something out
> in the meantime or have a reproducable test case?
>
> Thanks,
> Chris.
>
>
> On 31/08/18 10:29, Christoph John via Quickfixj-users wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> OK, good news. Just wanted to make sure since there were some minor
> changes to the SLF4JLog class in the last release.
>
> I might find some time next week to set up a little test.
>
> Chris.
>
> On 31/08/18 10:25, Xiau Wei Toon wrote:
>
> Reverted to 2.0.0, does not work. In fact, we absolutely must use 2.1
> since we rely on the new rawString method.
>
> If you were the one implementing, how would you do it? The requirement is
> simple. I want to route all event messages regardless of session into a
> daily rolling file using Log4j.
>
> On Fri, 31 Aug 2018, 4:11 pm Christoph John, <chr...@ma...>
> wrote:
>
>> Hmm, OK.
>> Just to rule out any regression error: could you please test with
>> version 2.0.0?
>>
>> Thanks,
>> Chris.
>>
>>
>> On 31/08/18 10:06, Xiau Wei Toon wrote:
>>
>> Indeed that is correct. The logfile is created but permanently empty. I
>> have:
>> 1. Removed all the default slf4j configuration from session settings
>> 2. Added appender for log4j.logger.quickfixj.errorEvent
>>
>> Files are created, but empty. I redirect all the screen logs from java
>> execute line to a dumpfile and I can see all quickfixj events and msg logs
>> generated without any WARN or ERROR. Turning on additivity will not make a
>> copy in system_debug.log as well. Version2.1 is the one used.
>>
>>
>> On Fri, 31 Aug 2018, 3:31 pm Christoph John, <chr...@ma...>
>> wrote:
>>
>>> So you are saying the file ./logs/quickfix.log gets created but with no
>>> content? No messages and no events?
>>> The SLF4J settings you are passing are the default ones as far as I can
>>> see. What happens if you omit them?
>>> I have just seen there is an undocumented setting
>>> SLF4JLogErrorEventCategory which defaults to "quickfixj.errorEvent".
>>> What happens if you add that to your settings?
>>>
>>> IMHO it can only be a minor config error since this feature is used by
>>> many people. Which QFJ version are you using BTW?
>>>
>>> Chris.
>>>
>>> On 31/08/18 08:59, ToonXW wrote:
>>>
>>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>>
>>>
>>> I have been trying to route all event logs to one daily rolling log file,
>>> however it is unclear what is going wrong. I verified that quickfixj picked
>>> up the log4j.properties file (by forcing an exception) and also confirmed
>>> that the target log file was created post startup. Please advise.
>>>
>>> *SessionSettings:*
>>> SLF4JLogEventCategory=quickfixj.event
>>> SLF4JLogIncomingMessageCategory=quickfixj.incoming
>>> SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>>> SLF4JLogPrependSessionID=Y
>>> SLF4JLogHeartbeats=Y
>>>
>>> *When building ThreadedSocketInitiator:*
>>> LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>>
>>> *log4j.properties:*
>>> # Root logger option
>>> log4j.rootLogger=DEBUG, core
>>> # Write to log files, support date rolling.
>>> log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>>> log4j.appender.core.Append=true
>>> log4j.appender.core.File=./logs/system_debug.log
>>> log4j.appender.core.DatePattern='.'yyyy-MM-dd
>>> log4j.appender.core.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>>> %-5p %c{1}:%L - %m%n
>>> # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>>> quickfixj.outgoing
>>> log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>>> log4j.additivity.quickfixj.event=false;
>>> log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>>> log4j.appender.quickfixEvents.Append=true
>>> log4j.appender.quickfixEvents.File=./logs/quickfix.log
>>> log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>>> log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>>> log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>>> HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>>
>>>
>>>
>> --
>> Christoph John
>> Software Engineering
>> T +49 241 557...@ma...
>>
>> MACD GmbH
>> Oppenhoffallee 103
>> 52066 Aachen, Germanywww.macd.com
>>
>> Amtsgericht Aachen: HRB 8151
>> Ust.-Id: DE 813021663
>> Geschäftsführer: George Macdonald
>>
>>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Quickfixj-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> 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
>
>

Re: [Quickfixj-users] Unable to route quickfixj.events to log via Log4j (over SLF4J)

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

Sorry, I did not have time to follow this up. Did you find something out in the meantime or have a 
reproducable test case?

Thanks,
Chris.


On 31/08/18 10:29, Christoph John via Quickfixj-users wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> OK, good news. Just wanted to make sure since there were some minor changes to the SLF4JLog class 
> in the last release.
>
> I might find some time next week to set up a little test.
>
> Chris.
>
> On 31/08/18 10:25, Xiau Wei Toon wrote:
>> Reverted to 2.0.0, does not work. In fact, we absolutely must use 2.1 since we rely on the new 
>> rawString method.
>>
>> If you were the one implementing, how would you do it? The requirement is simple. I want to route 
>> all event messages regardless of session into a daily rolling file using Log4j.
>>
>> On Fri, 31 Aug 2018, 4:11 pm Christoph John, <chr...@ma... 
>> <mailto:chr...@ma...>> wrote:
>>
>>     Hmm, OK.
>>     Just to rule outany regression error: could you please test with version 2.0.0?
>>
>>     Thanks,
>>     Chris.
>>
>>
>>     On 31/08/18 10:06, Xiau Wei Toon wrote:
>>>     Indeed that is correct. The logfile is created but permanently empty. I have:
>>>     1. Removed all the default slf4j configuration from session settings
>>>     2. Added appender for log4j.logger.quickfixj.errorEvent
>>>
>>>     Files are created, but empty. I redirect all the screen logs from java execute line to a
>>>     dumpfile and I can see all quickfixj events and msg logs generated without any WARN or
>>>     ERROR. Turning on additivity will not make a copy in system_debug.log as well. Version2.1 is
>>>     the one used.
>>>
>>>
>>>     On Fri, 31 Aug 2018, 3:31 pm Christoph John, <chr...@ma...
>>>     <mailto:chr...@ma...>> wrote:
>>>
>>>         So you are saying the file ./logs/quickfix.log gets created but with no content? No
>>>         messages and no events?
>>>         The SLF4J settings you are passing are the default ones as far as I can see. What
>>>         happens if you omit them?
>>>         I have just seen there is an undocumented setting SLF4JLogErrorEventCategory which
>>>         defaults to "quickfixj.errorEvent". What happens if you add that to your settings?
>>>
>>>         IMHO it can only be a minor config error since this feature is used by many people.
>>>         Which QFJ version are you using BTW?
>>>
>>>         Chris.
>>>
>>>         On 31/08/18 08:59, ToonXW wrote:
>>>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>>         QuickFIX/J Support:http://www.quickfixj.org/support/
>>>>
>>>>
>>>>         I have been trying to route all event logs to one daily rolling log file,
>>>>         however it is unclear what is going wrong. I verified that quickfixj picked
>>>>         up the log4j.properties file (by forcing an exception) and also confirmed
>>>>         that the target log file was created post startup. Please advise.
>>>>
>>>>         *SessionSettings:*
>>>>         SLF4JLogEventCategory=quickfixj.event
>>>>         SLF4JLogIncomingMessageCategory=quickfixj.incoming
>>>>         SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>>>>         SLF4JLogPrependSessionID=Y
>>>>         SLF4JLogHeartbeats=Y
>>>>
>>>>         *When building ThreadedSocketInitiator:*
>>>>         LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>>>
>>>>         *log4j.properties:*
>>>>         # Root logger option
>>>>         log4j.rootLogger=DEBUG, core
>>>>         # Write to log files, support date rolling.
>>>>         log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>>>>         log4j.appender.core.Append=true
>>>>         log4j.appender.core.File=./logs/system_debug.log
>>>>         log4j.appender.core.DatePattern='.'yyyy-MM-dd
>>>>         log4j.appender.core.layout=org.apache.log4j.PatternLayout
>>>>         log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>>>>         %-5p %c{1}:%L - %m%n
>>>>         # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>>>>         quickfixj.outgoing
>>>>         log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>>>>         log4j.additivity.quickfixj.event=false;
>>>>         log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>>>>         log4j.appender.quickfixEvents.Append=true
>>>>         log4j.appender.quickfixEvents.File=./logs/quickfix.log
>>>>         log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>>>>         log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>>>>         log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>>>>         HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>>>
>>
>>     -- 
>>     Christoph John
>>     Software Engineering
>>     T +49 241 557080-28
>>     chr...@ma... <mailto:chr...@ma...>
>>
>>     MACD GmbH
>>     Oppenhoffallee 103
>>     52066 Aachen, Germany
>>     www.macd.com <http://www.macd.com>
>>
>>     Amtsgericht Aachen: HRB 8151
>>     Ust.-Id: DE 813021663
>>     Geschäftsführer: George Macdonald
>>
>
> -- 
> Christoph John
> Software Engineering
> T +49 241 557080-28
> chr...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germany
> www.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Christoph John
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] Unable to route quickfixj.events to log via Log4j (over SLF4J)

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

OK, good news. Just wanted to make sure since there were some minor changes to the SLF4JLog class in 
the last release.

I might find some time next week to set up a little test.

Chris.

On 31/08/18 10:25, Xiau Wei Toon wrote:
> Reverted to 2.0.0, does not work. In fact, we absolutely must use 2.1 since we rely on the new 
> rawString method.
>
> If you were the one implementing, how would you do it? The requirement is simple. I want to route 
> all event messages regardless of session into a daily rolling file using Log4j.
>
> On Fri, 31 Aug 2018, 4:11 pm Christoph John, <chr...@ma... 
> <mailto:chr...@ma...>> wrote:
>
>     Hmm, OK.
>     Just to rule outany regression error: could you please test with version 2.0.0?
>
>     Thanks,
>     Chris.
>
>
>     On 31/08/18 10:06, Xiau Wei Toon wrote:
>>     Indeed that is correct. The logfile is created but permanently empty. I have:
>>     1. Removed all the default slf4j configuration from session settings
>>     2. Added appender for log4j.logger.quickfixj.errorEvent
>>
>>     Files are created, but empty. I redirect all the screen logs from java execute line to a
>>     dumpfile and I can see all quickfixj events and msg logs generated without any WARN or ERROR.
>>     Turning on additivity will not make a copy in system_debug.log as well. Version2.1 is the one
>>     used.
>>
>>
>>     On Fri, 31 Aug 2018, 3:31 pm Christoph John, <chr...@ma...
>>     <mailto:chr...@ma...>> wrote:
>>
>>         So you are saying the file ./logs/quickfix.log gets created but with no content? No
>>         messages and no events?
>>         The SLF4J settings you are passing are the default ones as far as I can see. What happens
>>         if you omit them?
>>         I have just seen there is an undocumented setting SLF4JLogErrorEventCategory which
>>         defaults to "quickfixj.errorEvent". What happens if you add that to your settings?
>>
>>         IMHO it can only be a minor config error since this feature is used by many people. Which
>>         QFJ version are you using BTW?
>>
>>         Chris.
>>
>>         On 31/08/18 08:59, ToonXW wrote:
>>>         QuickFIX/J Documentation:http://www.quickfixj.org/documentation/
>>>         QuickFIX/J Support:http://www.quickfixj.org/support/
>>>
>>>
>>>         I have been trying to route all event logs to one daily rolling log file,
>>>         however it is unclear what is going wrong. I verified that quickfixj picked
>>>         up the log4j.properties file (by forcing an exception) and also confirmed
>>>         that the target log file was created post startup. Please advise.
>>>
>>>         *SessionSettings:*
>>>         SLF4JLogEventCategory=quickfixj.event
>>>         SLF4JLogIncomingMessageCategory=quickfixj.incoming
>>>         SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>>>         SLF4JLogPrependSessionID=Y
>>>         SLF4JLogHeartbeats=Y
>>>
>>>         *When building ThreadedSocketInitiator:*
>>>         LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>>
>>>         *log4j.properties:*
>>>         # Root logger option
>>>         log4j.rootLogger=DEBUG, core
>>>         # Write to log files, support date rolling.
>>>         log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>>>         log4j.appender.core.Append=true
>>>         log4j.appender.core.File=./logs/system_debug.log
>>>         log4j.appender.core.DatePattern='.'yyyy-MM-dd
>>>         log4j.appender.core.layout=org.apache.log4j.PatternLayout
>>>         log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>>>         %-5p %c{1}:%L - %m%n
>>>         # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>>>         quickfixj.outgoing
>>>         log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>>>         log4j.additivity.quickfixj.event=false;
>>>         log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>>>         log4j.appender.quickfixEvents.Append=true
>>>         log4j.appender.quickfixEvents.File=./logs/quickfix.log
>>>         log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>>>         log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>>>         log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>>>         HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>>
>
>     -- 
>     Christoph John
>     Software Engineering
>     T +49 241 557080-28
>     chr...@ma... <mailto:chr...@ma...>
>
>     MACD GmbH
>     Oppenhoffallee 103
>     52066 Aachen, Germany
>     www.macd.com <http://www.macd.com>
>
>     Amtsgericht Aachen: HRB 8151
>     Ust.-Id: DE 813021663
>     Geschäftsführer: George Macdonald
>

-- 
Christoph John
Software Engineering
T +49 241 557080-28
chr...@ma...

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

Re: [Quickfixj-users] Unable to route quickfixj.events to log via Log4j (over SLF4J)

[Xiau W. T. <tx...@gm...>]

Reverted to 2.0.0, does not work. In fact, we absolutely must use 2.1 since
we rely on the new rawString method.

If you were the one implementing, how would you do it? The requirement is
simple. I want to route all event messages regardless of session into a
daily rolling file using Log4j.

On Fri, 31 Aug 2018, 4:11 pm Christoph John, <chr...@ma...>
wrote:

> Hmm, OK.
> Just to rule out any regression error: could you please test with version
> 2.0.0?
>
> Thanks,
> Chris.
>
>
> On 31/08/18 10:06, Xiau Wei Toon wrote:
>
> Indeed that is correct. The logfile is created but permanently empty. I
> have:
> 1. Removed all the default slf4j configuration from session settings
> 2. Added appender for log4j.logger.quickfixj.errorEvent
>
> Files are created, but empty. I redirect all the screen logs from java
> execute line to a dumpfile and I can see all quickfixj events and msg logs
> generated without any WARN or ERROR. Turning on additivity will not make a
> copy in system_debug.log as well. Version2.1 is the one used.
>
>
> On Fri, 31 Aug 2018, 3:31 pm Christoph John, <chr...@ma...>
> wrote:
>
>> So you are saying the file ./logs/quickfix.log gets created but with no
>> content? No messages and no events?
>> The SLF4J settings you are passing are the default ones as far as I can
>> see. What happens if you omit them?
>> I have just seen there is an undocumented setting
>> SLF4JLogErrorEventCategory which defaults to "quickfixj.errorEvent".
>> What happens if you add that to your settings?
>>
>> IMHO it can only be a minor config error since this feature is used by
>> many people. Which QFJ version are you using BTW?
>>
>> Chris.
>>
>> On 31/08/18 08:59, ToonXW wrote:
>>
>> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>> QuickFIX/J Support: http://www.quickfixj.org/support/
>>
>>
>> I have been trying to route all event logs to one daily rolling log file,
>> however it is unclear what is going wrong. I verified that quickfixj picked
>> up the log4j.properties file (by forcing an exception) and also confirmed
>> that the target log file was created post startup. Please advise.
>>
>> *SessionSettings:*
>> SLF4JLogEventCategory=quickfixj.event
>> SLF4JLogIncomingMessageCategory=quickfixj.incoming
>> SLF4JLogOutgoingMessageCategory=quickfixj.outgoing
>> SLF4JLogPrependSessionID=Y
>> SLF4JLogHeartbeats=Y
>>
>> *When building ThreadedSocketInitiator:*
>> LogFactory logFactory = new SLF4JLogFactory(sessionSettings);
>>
>> *log4j.properties:*
>> # Root logger option
>> log4j.rootLogger=DEBUG, core
>> # Write to log files, support date rolling.
>> log4j.appender.core=org.apache.log4j.DailyRollingFileAppender
>> log4j.appender.core.Append=true
>> log4j.appender.core.File=./logs/system_debug.log
>> log4j.appender.core.DatePattern='.'yyyy-MM-dd
>> log4j.appender.core.layout=org.apache.log4j.PatternLayout
>> log4j.appender.core.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss.SSS}
>> %-5p %c{1}:%L - %m%n
>> # Quickfixj appender(s): quickfixj.event / quickfixj.incoming /
>> quickfixj.outgoing
>> log4j.logger.quickfixj.event=DEBUG, quickfixEvents
>> log4j.additivity.quickfixj.event=false;
>> log4j.appender.quickfixEvents=org.apache.log4j.DailyRollingFileAppender
>> log4j.appender.quickfixEvents.Append=true
>> log4j.appender.quickfixEvents.File=./logs/quickfix.log
>> log4j.appender.quickfixEvents.DatePattern='.'yyyy-MM-dd
>> log4j.appender.quickfixEvents.layout=org.apache.log4j.PatternLayout
>> log4j.appender.quickfixEvents.layout.ConversionPattern=%d{yyyy-MM-dd
>> HH:mm:ss.SSS} %-5p %c{1}:%L - %m%n
>>
>>
>>
> --
> 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
>
>