Marketcetera.org › m-etc-dev

FIX connection issue

9 messages Options
Embed this post
Permalink
gm-mrktc

FIX connection issue

Reply Threaded More More options
Print post
Permalink
Steven,

So to summarize the message flow that your logs show (if the lines below are not in monospace font, it'll probably look pretty strange):

    OMS (ours)          FIX-SIMULATOR (yours)
1)  Logon (141=Y) --->
2)                <---  Logon
3)  Logon         --->
4)                <---  Logon

Where 141 is field ResetSeqNumFlag.  After 4, QuickFIX is throwing an exception.

Having looked at the QuickFIX/J code, here's what we think is happening.  The OMS is sending a logon request with ResetSeqNumFlag(141)='Y'.  It expects a Logon message in return that also has ResetSeqNumFlag set to 'Y', but receives a logon request without ResetSeqNumFlag in it (message 2).  At this point your FIX SIMULATOR believes the logon handshake is done.  The OMS however treats message 2 as a new logon request and replies with a logon response (message 3, which according to the FIX protocol is syntactically identical to a new logon request).  The OMS now believes the Logon handshake is complete. The FIX-SIMULATOR--now somewhat confused--replies to what it sees as a logon request (message 3) with another logon response (message 4).

At which point, QuickFIX/J says "enough already" and throws an exception.  So I think the upshot is that because QuickFIX/J is expecting the ResetSeqNumFlag to be returned in the logon response (message 2), things are getting fouled up.

One thing to try would be to go into the oms.properties file and change ResetSeqNumFlag=N, and retry the connection.  You may need to delete the "store" directory before you do that.  Please let us know if this helps.

We are going to forward this issue to the QuickFIX/J list to solicit some opinions about how to deal with this.

graham



On 8/24/06, Stephen Cooper <[hidden email]> wrote:

> Graham,
>
> Apologies for the delay.  Here are some logs.  They show two sets of
> login messages, then Marketcetera logs out, ending the session.  Any
> ideas?
>
> Thanks,
> Steve
>
> 1. Your OMS log:
>
> Initialized top-level logger mktctrRoot.
> 16:53:17,951  INFO [main] marketcetera.oms.OrderManagementSystem
> (OrderManagemen

> tSystem.java:75) - Starting OMS.
> JCyclone: Loading stages
> -- Loading <output>
> -- Loading <ordermanager>
> JCyclone: Programming stages
> Program Stage <output>Program Stage <ordermanager>JCyclone: Initializing
> stages
> -- Initializing <output>
> 16:53:18,092  INFO [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:22) - Initializing stage [output].
> 16:53:18,092 DEBUG [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:29) - No next stage for output
> -- Initializing <ordermanager>
> 16:53:18,092  INFO [main] marketcetera.oms.OrderManager
> ( JCycloneStageBase.java:
> 22) - Initializing stage [ordermanager].
> 16:53:18,092 DEBUG [main] marketcetera.oms.OrderManager
> (JCycloneSource.java:26)
>  - Setting next stage to be [output]
> JCyclone: Starting stages
> -- Starting <output>
> TP <output>: initial 1, min 1, max 1, blockTime 1000, idleTime 1000
> ThreadPool <output>: Adding 1 threads to pool, size 1
> ThreadPool <output>: Starting 1 threads
> -- Starting <ordermanager>
> TP <ordermanager>: initial 1, min 1, max 1, blockTime 1000, idleTime
> 1000
> ThreadPool <ordermanager>: Adding 1 threads to pool, size 1
> ThreadPool <ordermanager>: Starting 1 threads
> 16:53:18,108  INFO [main] marketcetera.oms.JMSAdapterSource
> (JCyclonePluginSourc
> e.java:19) - Initializing plugin [jmsadapter].
> 16:53:18,108 DEBUG [main] marketcetera.oms.JMSAdapterSource
> (JCycloneSource.java

> :26) - Setting next stage to be [ordermanager]
> 16:53:18,108 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:82) - cre
> ating a JMSAdapter for url tcp://localhost:61616
> 16:53:18,717 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:160) - Fi
> nished attempt to drain oms-commands
> 16:53:18,733 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java :132) - co
> nnecting incoming queue oms-commands
> 16:53:18,748 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:194) - co
> nnecting outgoing topic oms-messages
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:2
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:1
> 16:53:18,764  INFO [main] marketcetera.oms.FIXSessionAdapterSource
> (JCyclonePlug

> inSource.java:19) - Initializing plugin [quickfixadapter].
> 16:53:18,764 DEBUG [main] marketcetera.oms.FIXSessionAdapterSource
> (JCycloneSour
> ce.java:26) - Setting next stage to be [ordermanager]
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Session
> FIX.4.2:VFCLIENT0
> 1->MLTS2 schedule is daily, 00:00:00 UTC - 00:00:00 UTC)
> 16:53:18,967 DEBUG [main] marketcetera.quickfix.QuickFIXInitiator
> (QuickFIXIniti
> ator.java:165) - new session created: FIX.4.2:VFCLIENT01->MLTS2
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Created session:
> FIX.4.2:
> VFCLIENT01->MLTS2)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Initiated logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Received logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Responding to
> logon request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event>
> (quickfix.SessionException
>  Logon state is not valid for message (MsgType=A))
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Disconnecting)
>
> 2. My FIX Engine Log:  (VFCLIENT01 is Marketcetera, and MLTS2 is my
> OMS.)
>
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 76
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 1
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.155"
>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         UNKNOWN             [  141] = Y
>         CheckSum            [   10] = 097
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 1
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 106
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 70
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 2
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.201"

>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 039
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 2
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 107
> 20060824-16:53:19 FIXClient::OnDisconnect() event for MLTS2
>
>
>

_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
Stephen Cooper

RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)

Graham,

 

I made the following changes to oms.properties, including some things I just made up to see if they worked:

 

# FIX constants

DataDictionary=FIX42.xml

UseDataDictionary=Y

ResetOnLogout=N         //was Y

ResetOnDisconnect=N   //was Y

ResetSeqNumFlag=N     //added this, probably no affect

ResetOnLogon=N          //added this, probably no affect

 

I also deleted store/ directory and the net effect was that the same thing happened, only that the 141=Y was omitted.

 

Any ideas?

 

Thanks,

Steve

 

From: Graham Miller [mailto:[hidden email]]
Sent: Thursday, August 24, 2006 7:48 PM
To: Stephen Cooper
Cc: Marketcetera dev
Subject: FIX connection issue

 

Steven,

So to summarize the message flow that your logs show (if the lines below are not in monospace font, it'll probably look pretty strange):

    OMS (ours)          FIX-SIMULATOR (yours)
1)  Logon (141=Y) --->
2)                <---  Logon
3)  Logon         --->
4)                <---  Logon

Where 141 is field ResetSeqNumFlag.  After 4, QuickFIX is throwing an exception.

Having looked at the QuickFIX/J code, here's what we think is happening.  The OMS is sending a logon request with ResetSeqNumFlag(141)='Y'.  It expects a Logon message in return that also has ResetSeqNumFlag set to 'Y', but receives a logon request without ResetSeqNumFlag in it (message 2).  At this point your FIX SIMULATOR believes the logon handshake is done.  The OMS however treats message 2 as a new logon request and replies with a logon response (message 3, which according to the FIX protocol is syntactically identical to a new logon request).  The OMS now believes the Logon handshake is complete. The FIX-SIMULATOR--now somewhat confused--replies to what it sees as a logon request (message 3) with another logon response (message 4).

At which point, QuickFIX/J says "enough already" and throws an exception.  So I think the upshot is that because QuickFIX/J is expecting the ResetSeqNumFlag to be returned in the logon response (message 2), things are getting fouled up.

One thing to try would be to go into the oms.properties file and change ResetSeqNumFlag=N, and retry the connection.  You may need to delete the "store" directory before you do that.  Please let us know if this helps.

We are going to forward this issue to the QuickFIX/J list to solicit some opinions about how to deal with this.

graham



On 8/24/06, Stephen Cooper <[hidden email]> wrote:
> Graham,
>
> Apologies for the delay.  Here are some logs.  They show two sets of
> login messages, then Marketcetera logs out, ending the session.  Any
> ideas?
>
> Thanks,
> Steve
>
> 1. Your OMS log:
>
> Initialized top-level logger mktctrRoot.
> 16:53:17,951  INFO [main] marketcetera.oms.OrderManagementSystem
> (OrderManagemen
> tSystem.java:75) - Starting OMS.
> JCyclone: Loading stages
> -- Loading <output>
> -- Loading <ordermanager>
> JCyclone: Programming stages
> Program Stage <output>Program Stage <ordermanager>JCyclone: Initializing
> stages
> -- Initializing <output>
> 16:53:18,092  INFO [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:22) - Initializing stage [output].
> 16:53:18,092 DEBUG [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:29) - No next stage for output
> -- Initializing <ordermanager>
> 16:53:18,092  INFO [main] marketcetera.oms.OrderManager
> ( JCycloneStageBase.java:
> 22) - Initializing stage [ordermanager].
> 16:53:18,092 DEBUG [main] marketcetera.oms.OrderManager
> (JCycloneSource.java:26)
>  - Setting next stage to be [output]
> JCyclone: Starting stages
> -- Starting <output>
> TP <output>: initial 1, min 1, max 1, blockTime 1000, idleTime 1000
> ThreadPool <output>: Adding 1 threads to pool, size 1
> ThreadPool <output>: Starting 1 threads
> -- Starting <ordermanager>
> TP <ordermanager>: initial 1, min 1, max 1, blockTime 1000, idleTime
> 1000
> ThreadPool <ordermanager>: Adding 1 threads to pool, size 1
> ThreadPool <ordermanager>: Starting 1 threads
> 16:53:18,108  INFO [main] marketcetera.oms.JMSAdapterSource
> (JCyclonePluginSourc
> e.java:19) - Initializing plugin [jmsadapter].
> 16:53:18,108 DEBUG [main] marketcetera.oms.JMSAdapterSource
> (JCycloneSource.java
> :26) - Setting next stage to be [ordermanager]
> 16:53:18,108 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:82) - cre
> ating a JMSAdapter for url tcp://localhost:61616
> 16:53:18,717 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:160) - Fi
> nished attempt to drain oms-commands
> 16:53:18,733 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java :132) - co
> nnecting incoming queue oms-commands
> 16:53:18,748 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:194) - co
> nnecting outgoing topic oms-messages
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:2
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:1
> 16:53:18,764  INFO [main] marketcetera.oms.FIXSessionAdapterSource
> (JCyclonePlug
> inSource.java:19) - Initializing plugin [quickfixadapter].
> 16:53:18,764 DEBUG [main] marketcetera.oms.FIXSessionAdapterSource
> (JCycloneSour
> ce.java:26) - Setting next stage to be [ordermanager]
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Session
> FIX.4.2:VFCLIENT0
> 1->MLTS2 schedule is daily, 00:00:00 UTC - 00:00:00 UTC)
> 16:53:18,967 DEBUG [main] marketcetera.quickfix.QuickFIXInitiator
> (QuickFIXIniti
> ator.java:165) - new session created: FIX.4.2:VFCLIENT01->MLTS2
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Created session:
> FIX.4.2:
> VFCLIENT01->MLTS2)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Initiated logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Received logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Responding to
> logon request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event>
> (quickfix.SessionException
>  Logon state is not valid for message (MsgType=A))
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Disconnecting)
>
> 2. My FIX Engine Log:  (VFCLIENT01 is Marketcetera, and MLTS2 is my
> OMS.)
>
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 76
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 1
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.155"
>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         UNKNOWN             [  141] = Y
>         CheckSum            [   10] = 097
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 1
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 106
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 70
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 2
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.201"
>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 039
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 2
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 107
> 20060824-16:53:19 FIXClient::OnDisconnect() event for MLTS2
>
>
>

This e-mail message and its attachments are confidential, intended only for the addressee(s) named above and may contain information that is proprietary, privileged, or otherwise exempt from disclosure. If you receive this message in error please notify us at [hidden email] and immediately delete this message and its attachments from your system.

Miletus Trading, LLC is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication.


_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
gm-mrktc

Re: FIX connection issue

Reply Threaded More More options
Print post
Permalink
Stephen,
Well that seems to shoot a hole in my theory. We have a thread started in the QuickFIX mailing list to see if they can shed any light on the issue.

So you're saying that the logs look exactly the same except for the 141='Y' in the initial message. If the're different could you post them again?

Thanks for spending time on this. 

graham


On 8/25/06, Stephen Cooper <[hidden email]> wrote:

Graham,

 

I made the following changes to oms.properties, including some things I just made up to see if they worked:

 

# FIX constants

DataDictionary=FIX42.xml

UseDataDictionary=Y

ResetOnLogout=N         //was Y

ResetOnDisconnect=N   //was Y

ResetSeqNumFlag=N     //added this, probably no affect

ResetOnLogon=N          //added this, probably no affect

 

I also deleted store/ directory and the net effect was that the same thing happened, only that the 141=Y was omitted.

 

Any ideas?

 

Thanks,

Steve

 

From: Graham Miller [mailto:[hidden email]]
Sent: Thursday, August 24, 2006 7:48 PM
To: Stephen Cooper
Cc: Marketcetera dev
Subject: FIX connection issue

 

Steven,

So to summarize the message flow that your logs show (if the lines below are not in monospace font, it'll probably look pretty strange):

    OMS (ours)          FIX-SIMULATOR (yours)
1)  Logon (141=Y) --->
2)                <---  Logon
3)  Logon         --->
4)                <---  Logon

Where 141 is field ResetSeqNumFlag.  After 4, QuickFIX is throwing an exception.

Having looked at the QuickFIX/J code, here's what we think is happening.  The OMS is sending a logon request with ResetSeqNumFlag(141)='Y'.  It expects a Logon message in return that also has ResetSeqNumFlag set to 'Y', but receives a logon request without ResetSeqNumFlag in it (message 2).  At this point your FIX SIMULATOR believes the logon handshake is done.  The OMS however treats message 2 as a new logon request and replies with a logon response (message 3, which according to the FIX protocol is syntactically identical to a new logon request).  The OMS now believes the Logon handshake is complete. The FIX-SIMULATOR--now somewhat confused--replies to what it sees as a logon request (message 3) with another logon response (message 4).

At which point, QuickFIX/J says "enough already" and throws an exception.  So I think the upshot is that because QuickFIX/J is expecting the ResetSeqNumFlag to be returned in the logon response (message 2), things are getting fouled up.

One thing to try would be to go into the oms.properties file and change ResetSeqNumFlag=N, and retry the connection.  You may need to delete the "store" directory before you do that.  Please let us know if this helps.

We are going to forward this issue to the QuickFIX/J list to solicit some opinions about how to deal with this.

graham



On 8/24/06, Stephen Cooper <[hidden email]> wrote:
> Graham,
>
> Apologies for the delay.  Here are some logs.  They show two sets of
> login messages, then Marketcetera logs out, ending the session.  Any
> ideas?
>
> Thanks,
> Steve
>
> 1. Your OMS log:
>
> Initialized top-level logger mktctrRoot.
> 16:53:17,951  INFO [main] marketcetera.oms.OrderManagementSystem
> (OrderManagemen
> tSystem.java:75) - Starting OMS.
> JCyclone: Loading stages
> -- Loading <output>
> -- Loading <ordermanager>
> JCyclone: Programming stages
> Program Stage <output>Program Stage <ordermanager>JCyclone: Initializing
> stages
> -- Initializing <output>
> 16:53:18,092  INFO [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:22) - Initializing stage [output].
> 16:53:18,092 DEBUG [main] marketcetera.jcyclone.OutputStage
> (JCycloneStageBase.j
> ava:29) - No next stage for output
> -- Initializing <ordermanager>
> 16:53:18,092  INFO [main] marketcetera.oms.OrderManager
> ( JCycloneStageBase.java:
> 22) - Initializing stage [ordermanager].
> 16:53:18,092 DEBUG [main] marketcetera.oms.OrderManager
> (JCycloneSource.java:26)
>  - Setting next stage to be [output]
> JCyclone: Starting stages
> -- Starting <output>
> TP <output>: initial 1, min 1, max 1, blockTime 1000, idleTime 1000
> ThreadPool <output>: Adding 1 threads to pool, size 1
> ThreadPool <output>: Starting 1 threads
> -- Starting <ordermanager>
> TP <ordermanager>: initial 1, min 1, max 1, blockTime 1000, idleTime
> 1000
> ThreadPool <ordermanager>: Adding 1 threads to pool, size 1
> ThreadPool <ordermanager>: Starting 1 threads
> 16:53:18,108  INFO [main] marketcetera.oms.JMSAdapterSource
> (JCyclonePluginSourc
> e.java:19) - Initializing plugin [jmsadapter].
> 16:53:18,108 DEBUG [main] marketcetera.oms.JMSAdapterSource
> (JCycloneSource.java
> :26) - Setting next stage to be [ordermanager]
> 16:53:18,108 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:82) - cre
> ating a JMSAdapter for url tcp://localhost:61616
> 16:53:18,717 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:160) - Fi
> nished attempt to drain oms-commands
> 16:53:18,733 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java :132) - co
> nnecting incoming queue oms-commands
> 16:53:18,748 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:194) - co
> nnecting outgoing topic oms-messages
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:2
> 16:53:18,764 DEBUG [main] marketcetera.jms.JMSAdapter
> (JMSAdapter.java:293) - Ad
> apter for tcp://localhost:61616 started for client
> ID:WRKS27-3780-1156452798264-
> 2:1
> 16:53:18,764  INFO [main] marketcetera.oms.FIXSessionAdapterSource
> (JCyclonePlug
> inSource.java:19) - Initializing plugin [quickfixadapter].
> 16:53:18,764 DEBUG [main] marketcetera.oms.FIXSessionAdapterSource
> (JCycloneSour
> ce.java:26) - Setting next stage to be [ordermanager]
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Session
> FIX.4.2:VFCLIENT0
> 1->MLTS2 schedule is daily, 00:00:00 UTC - 00:00:00 UTC)
> 16:53:18,967 DEBUG [main] marketcetera.quickfix.QuickFIXInitiator
> (QuickFIXIniti
> ator.java:165) - new session created: FIX.4.2:VFCLIENT01->MLTS2
> <20060824-20:53:18, FIX.4.2:VFCLIENT01->MLTS2, event> (Created session:
> FIX.4.2:
> VFCLIENT01->MLTS2)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Initiated logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Received logon
> request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Responding to
> logon request)
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event>
> (quickfix.SessionException
>  Logon state is not valid for message (MsgType=A))
> <20060824-20:53:19, FIX.4.2:VFCLIENT01->MLTS2, event> (Disconnecting)
>
> 2. My FIX Engine Log:  (VFCLIENT01 is Marketcetera, and MLTS2 is my
> OMS.)
>
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 76
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 1
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.155"
>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         UNKNOWN             [  141] = Y
>         CheckSum            [   10] = 097
> 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 1
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 106
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 70
>         MsgType             [   35] = A // Logon
>         MsgSeqNum           [   34] = 2
>         SenderCompID        [   49] = VFCLIENT01
>         SendingTime         [   52] = "20060824-20:53:19.201"
>         TargetCompID        [   56] = MLTS2
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 039
> 20060824-16:53:19 [    2] FIXMESSAGE [A] Logon
>         BeginString         [    8] = FIX.4.2
>         BodyLength          [    9] = 66
>         MsgType             [   35] = A // Logon
>         SenderCompID        [   49] = MLTS2
>         TargetCompID        [   56] = VFCLIENT01
>         MsgSeqNum           [   34] = 2
>         SendingTime         [   52] = "20060824-20:53:19"
>         EncryptMethod       [   98] = 0 // None
>         HeartBtInt          [  108] = 30
>         CheckSum            [   10] = 107
> 20060824-16:53:19 FIXClient::OnDisconnect() event for MLTS2
>
>
>

This e-mail message and its attachments are confidential, intended only for the addressee(s) named above and may contain information that is proprietary, privileged, or otherwise exempt from disclosure. If you receive this message in error please notify us at [hidden email] and immediately delete this message and its attachments from your system.

Miletus Trading, LLC is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication.



_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
Stephen Cooper

RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by gm-mrktc
Some javascript/style in this post has been disabled (why?)

Graham,

 

Logs follow.

 

My FIX Engine Log:

(VFCLIENT01 is Marketceteram MLTS2 is Miletus’ FIX engine.)

 

20060828-10:36:41 [    1] FIXMESSAGE [A] Logon

        BeginString         [    8] = FIX.4.2

        BodyLength          [    9] = 76

        MsgType             [   35] = A // Logon

        MsgSeqNum           [   34] = 1

        SenderCompID        [   49] = VFCLIENT01

        SendingTime         [   52] = "20060828-14:36:41.026"

        TargetCompID        [   56] = MLTS2

        EncryptMethod       [   98] = 0 // None

        HeartBtInt          [  108] = 30

        UNKNOWN             [  141] = Y

        CheckSum            [   10] = 097

 

20060828-10:36:41 [    1] FIXMESSAGE [A] Logon

        BeginString         [    8] = FIX.4.2

        BodyLength          [    9] = 66

        MsgType             [   35] = A // Logon

        SenderCompID        [   49] = MLTS2

        TargetCompID        [   56] = VFCLIENT01

        MsgSeqNum           [   34] = 1

        SendingTime         [   52] = "20060828-14:36:41"

        EncryptMethod       [   98] = 0 // None

        HeartBtInt          [  108] = 30

        CheckSum            [   10] = 109

 

20060828-10:36:41 [    2] FIXMESSAGE [A] Logon

        BeginString         [    8] = FIX.4.2

        BodyLength          [    9] = 70

        MsgType             [   35] = A // Logon

        MsgSeqNum           [   34] = 2

        SenderCompID        [   49] = VFCLIENT01

        SendingTime         [   52] = "20060828-14:36:41.073"

        TargetCompID        [   56] = MLTS2

        EncryptMethod       [   98] = 0 // None

        HeartBtInt          [  108] = 30

        CheckSum            [   10] = 049

 

20060828-10:36:41 [    2] FIXMESSAGE [A] Logon

        BeginString         [    8] = FIX.4.2

        BodyLength          [    9] = 66

        MsgType             [   35] = A // Logon

        SenderCompID        [   49] = MLTS2

        TargetCompID        [   56] = VFCLIENT01

        MsgSeqNum           [   34] = 2

        SendingTime         [   52] = "20060828-14:36:41"

        EncryptMethod       [   98] = 0 // None

        HeartBtInt          [  108] = 30

        CheckSum            [   10] = 110

FIXMESSAGEEND

 

20060828-10:36:41 FIXClient::OnDisconnect() event for MLTS2

 

Marketcetera log:

 

C:\data\oms\devel\marketcetera\marketcetera-platform-0.1.2-SNAPSHOT-bin>java -Dj

ava.util.logging.config.file=java.util.logging.properties -classpath conf;lib/ac

tivemq-4.0.jar;lib/commons-i18n-20060814.jar;lib/core-0.1.2-SNAPSHOT.jar;lib/csv

-1.0.jar;lib/jcyclone-core-marketcetera-0.1-20060619.231640-2.jar;lib/jcyclone-c

ore-marketcetera-0.1-SNAPSHOT.jar;lib/log4j-1.2.13.jar;lib/mina-core-0.9.3.jar;l

ib/oms-0.1.2-SNAPSHOT.jar;lib/orderloader-0.1.2-SNAPSHOT.jar;lib/quickfixj-1.0.0

-final.jar;lib/slf4j-jdk14-1.0.1.jar;   org.marketcetera.oms.OrderManagementSyst

em

Initialized top-level logger mktctrRoot.

10:36:39,823  INFO [main] marketcetera.oms.OrderManagementSystem (OrderManagemen

tSystem.java:75) - Starting OMS.

JCyclone: Loading stages

-- Loading <output>

-- Loading <ordermanager>

JCyclone: Programming stages

Program Stage <output>Program Stage <ordermanager>JCyclone: Initializing stages

-- Initializing <output>

10:36:39,948  INFO [main] marketcetera.jcyclone.OutputStage (JCycloneStageBase.j

ava:22) - Initializing stage [output].

10:36:39,948 DEBUG [main] marketcetera.jcyclone.OutputStage (JCycloneStageBase.j

ava:29) - No next stage for output

-- Initializing <ordermanager>

10:36:39,948  INFO [main] marketcetera.oms.OrderManager (JCycloneStageBase.java:

22) - Initializing stage [ordermanager].

10:36:39,948 DEBUG [main] marketcetera.oms.OrderManager (JCycloneSource.java:26)

 - Setting next stage to be [output]

JCyclone: Starting stages

-- Starting <output>

TP <output>: initial 1, min 1, max 1, blockTime 1000, idleTime 1000

ThreadPool <output>: Adding 1 threads to pool, size 1

ThreadPool <output>: Starting 1 threads

-- Starting <ordermanager>

TP <ordermanager>: initial 1, min 1, max 1, blockTime 1000, idleTime 1000

ThreadPool <ordermanager>: Adding 1 threads to pool, size 1

ThreadPool <ordermanager>: Starting 1 threads

10:36:39,963  INFO [main] marketcetera.oms.JMSAdapterSource (JCyclonePluginSourc

e.java:19) - Initializing plugin [jmsadapter].

10:36:39,963 DEBUG [main] marketcetera.oms.JMSAdapterSource (JCycloneSource.java

:26) - Setting next stage to be [ordermanager]

10:36:39,979 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:82) - cre

ating a JMSAdapter for url tcp://localhost:61616

10:36:40,573 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:160) - Fi

nished attempt to drain oms-commands

10:36:40,588 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:132) - co

nnecting incoming queue oms-commands

10:36:40,604 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:194) - co

nnecting outgoing topic oms-messages

10:36:40,604 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:293) - Ad

apter for tcp://localhost:61616 started for client ID:WRKS27-2287-1156775800120-

2:2

10:36:40,604 DEBUG [main] marketcetera.jms.JMSAdapter (JMSAdapter.java:293) - Ad

apter for tcp://localhost:61616 started for client ID:WRKS27-2287-1156775800120-

2:1

10:36:40,620  INFO [main] marketcetera.oms.FIXSessionAdapterSource (JCyclonePlug

inSource.java:19) - Initializing plugin [quickfixadapter].

10:36:40,620 DEBUG [main] marketcetera.oms.FIXSessionAdapterSource (JCycloneSour

ce.java:26) - Setting next stage to be [ordermanager]

<20060828-14:36:40, FIX.4.2:VFCLIENT01->MLTS2, event> (Session FIX.4.2:VFCLIENT0

1->MLTS2 schedule is daily, 00:00:00 UTC - 00:00:00 UTC)

10:36:40,838 DEBUG [main] marketcetera.quickfix.QuickFIXInitiator (QuickFIXIniti

ator.java:165) - new session created: FIX.4.2:VFCLIENT01->MLTS2

<20060828-14:36:40, FIX.4.2:VFCLIENT01->MLTS2, event> (Created session: FIX.4.2:

VFCLIENT01->MLTS2)

<20060828-14:36:41, FIX.4.2:VFCLIENT01->MLTS2, event> (Initiated logon request)

<20060828-14:36:41, FIX.4.2:VFCLIENT01->MLTS2, event> (Received logon request)

<20060828-14:36:41, FIX.4.2:VFCLIENT01->MLTS2, event> (Responding to logon reque

st)

<20060828-14:36:41, FIX.4.2:VFCLIENT01->MLTS2, event> (quickfix.SessionException

 Logon state is not valid for message (MsgType=A))

<20060828-14:36:41, FIX.4.2:VFCLIENT01->MLTS2, event> (Disconnecting)

10:36:43,682  INFO [Thread-2] marketcetera.oms.OrderManagementSystem (Applicatio

nBase.java:126) - Shutting down application.

-- Unloading Plugin <jmsadapter>

10:36:43,698 DEBUG [Thread-2] marketcetera.oms.JMSAdapterSource (JCycloneSource.

java:36) - Getting Destroyed

-- Unloading Plugin <quickfixadapter>

10:36:43,698 DEBUG [Thread-2] marketcetera.oms.FIXSessionAdapterSource (JCyclone

Source.java:36) - Getting Destroyed

JCyclone: Stopping ThreadManager default

ThreadPool <output>: Stopping 1 threads

ThreadPool <output>: Stopping now 1 threads

ThreadPool <ordermanager>: Stopping 1 threads

ThreadPool <ordermanager>: Stopping now 1 threads

-- Stopping <output>

-- Destroying <output>

10:36:43,916 DEBUG [Thread-2] marketcetera.jcyclone.OutputStage (JCycloneSource.

java:36) - Getting Destroyed

-- Stopping <ordermanager>

-- Destroying <ordermanager>

10:36:43,916 DEBUG [Thread-2] marketcetera.oms.OrderManager (JCycloneSource.java

:36) - Getting Destroyed

-- Unloading <output>

-- Unloading <ordermanager>

Terminate batch job (Y/N)?

 

 

 

 

From: Graham Miller [mailto:[hidden email]]
Sent: Friday, August 25, 2006 6:07 PM
To: Stephen Cooper
Cc: Marketcetera dev
Subject: Re: FIX connection issue

 

Stephen,
Well that seems to shoot a hole in my theory. We have a thread started in the QuickFIX mailing list to see if they can shed any light on the issue.

So you're saying that the logs look exactly the same except for the 141='Y' in the initial message. If the're different could you post them again?

Thanks for spending time on this. 

graham

On 8/25/06, Stephen Cooper <[hidden email]> wrote:

Graham,

 

I made the following changes to oms.properties, including some things I just made up to see if they worked:

 

# FIX constants

DataDictionary=FIX42.xml

UseDataDictionary=Y

ResetOnLogout=N         //was Y

ResetOnDisconnect=N   //was Y
toli

Re: RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Stephen Cooper
Stephen,

Looks like we left out another flag that we think is causing the error
you are experiencing.  Can you set:
SendResetSeqNumFlag=N
and make sure that these are still set to N:
ResetOnLogout=N
ResetOnDisconnect=N

in the oms.properties file and try again? That should eliminate the
initial sending of the 141 field from our OMS which confuses your FIX
engine.
You'll need to delete the store/ directory again (otherise, QuickfixJ
will spend some time resetting the sequence numbers after logon).

Please let me know how that goes.  Sorry, took us a while to track this down.


On 8/25/06, Stephen Cooper <[hidden email]> wrote:

>
>
>
>
> Graham,
>
>
>
> I made the following changes to oms.properties, including some things I just
> made up to see if they worked:
>
>
>
> # FIX constants
>
> DataDictionary=FIX42.xml
>
> UseDataDictionary=Y
>
> ResetOnLogout=N         //was Y
>
> ResetOnDisconnect=N   //was Y
>
> ResetSeqNumFlag=N     //added this, probably no affect
>
> ResetOnLogon=N          //added this, probably no affect
>
>
>
> I also deleted store/ directory and the net effect was that the same thing
> happened, only that the 141=Y was omitted.
>
>
>
> Any ideas?
>
--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.
_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
Stephen Cooper

RE: RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by gm-mrktc
Toli,

This seems to be working for us now.  Am I correct in thinking that even
if you send 141=Y in login, we should not send 141=Y in the echo login
message?

Thanks,
Steve

-----Original Message-----
From: Toli Kuznets [mailto:[hidden email]]
Sent: Monday, August 28, 2006 7:12 PM
To: Stephen Cooper
Cc: Graham Miller; Marketcetera dev
Subject: Re: [m-etc-dev] RE: FIX connection issue

Stephen,

Looks like we left out another flag that we think is causing the error
you are experiencing.  Can you set:
SendResetSeqNumFlag=N
and make sure that these are still set to N:
ResetOnLogout=N
ResetOnDisconnect=N

in the oms.properties file and try again? That should eliminate the
initial sending of the 141 field from our OMS which confuses your FIX
engine.
You'll need to delete the store/ directory again (otherise, QuickfixJ
will spend some time resetting the sequence numbers after logon).

Please let me know how that goes.  Sorry, took us a while to track this
down.


On 8/25/06, Stephen Cooper <[hidden email]> wrote:
>
>
>
>
> Graham,
>
>
>
> I made the following changes to oms.properties, including some things
I just

> made up to see if they worked:
>
>
>
> # FIX constants
>
> DataDictionary=FIX42.xml
>
> UseDataDictionary=Y
>
> ResetOnLogout=N         //was Y
>
> ResetOnDisconnect=N   //was Y
>
> ResetSeqNumFlag=N     //added this, probably no affect
>
> ResetOnLogon=N          //added this, probably no affect
>
>
>
> I also deleted store/ directory and the net effect was that the same
thing
> happened, only that the 141=Y was omitted.
>
>
>
> Any ideas?
>
--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

----------
This e-mail message and its attachments are confidential, intended only for the addressee(s) named above and may contain information that is proprietary, privileged, or otherwise exempt from disclosure. If you receive this message in error please notify us at [hidden email] and immediately delete this message and its attachments from your system.

Miletus Trading, LLC is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication.


_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
gm-mrktc

Re: RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
Stephen,

I looked through the FIX 4.2 spec, and it doesn't have language
specifically regarding the Logon message used to start a conversation,
w.r.t. ResetSeqNumFlag(141).  However, it does contain this telling
language about using the Logon message to reset a connection as part
of a 24-hour connection scheme:

> When using the ResetSeqNumFlag to maintain 24 hour connectivity and establish a new > set of sequence numbers, the process should be as follows. ... the initiator should send a > Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. The acceptor should > respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. ...

That seems to indicate in that instance, the correct response is to
include 141=Y as an acknowledgement of reciept of the same.

Certainly this is how QuickFIX/J implements it.  When we run the same
interaction as you on our exchange simulator that is based on
QuickFIX/J, what we see is 141=Y in the response Logon message.

We will crosspost a similar message on the QuickFIX/J list for further guidance.

graham


On 8/29/06, Stephen Cooper <[hidden email]> wrote:

> Toli,
>
> This seems to be working for us now.  Am I correct in thinking that even
> if you send 141=Y in login, we should not send 141=Y in the echo login
> message?
>
> Thanks,
> Steve
>
> -----Original Message-----
> From: Toli Kuznets [mailto:[hidden email]]
> Sent: Monday, August 28, 2006 7:12 PM
> To: Stephen Cooper
> Cc: Graham Miller; Marketcetera dev
> Subject: Re: [m-etc-dev] RE: FIX connection issue
>
> Stephen,
>
> Looks like we left out another flag that we think is causing the error
> you are experiencing.  Can you set:
> SendResetSeqNumFlag=N
> and make sure that these are still set to N:
> ResetOnLogout=N
> ResetOnDisconnect=N
>
> in the oms.properties file and try again? That should eliminate the
> initial sending of the 141 field from our OMS which confuses your FIX
> engine.
> You'll need to delete the store/ directory again (otherise, QuickfixJ
> will spend some time resetting the sequence numbers after logon).
>
> Please let me know how that goes.  Sorry, took us a while to track this
> down.
>
>
> On 8/25/06, Stephen Cooper <[hidden email]> wrote:
> >
> >
> >
> >
> > Graham,
> >
> >
> >
> > I made the following changes to oms.properties, including some things
> I just
> > made up to see if they worked:
> >
> >
> >
> > # FIX constants
> >
> > DataDictionary=FIX42.xml
> >
> > UseDataDictionary=Y
> >
> > ResetOnLogout=N         //was Y
> >
> > ResetOnDisconnect=N   //was Y
> >
> > ResetSeqNumFlag=N     //added this, probably no affect
> >
> > ResetOnLogon=N          //added this, probably no affect
> >
> >
> >
> > I also deleted store/ directory and the net effect was that the same
> thing
> > happened, only that the 141=Y was omitted.
> >
> >
> >
> > Any ideas?
> >
> --
> Toli Kuznets
> http://www.marketcetera.com: Open-Source Trading Platform
> download.run.trade.
>
> ----------
> This e-mail message and its attachments are confidential, intended only for the addressee(s) named above and may contain information that is proprietary, privileged, or otherwise exempt from disclosure. If you receive this message in error please notify us at [hidden email] and immediately delete this message and its attachments from your system.
>
> Miletus Trading, LLC is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication.
>
>
>
_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
Stephen Cooper

RE: RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by gm-mrktc
Seems that the bug would be on your end, then, or on QuickFix/J side,
since our engine is sending correct response.

Meanwhile, another question:  Can the OrderLoader support other message
types, e.g. Replace Requests, Cxl Requests?


-----Original Message-----
From: Graham Miller [mailto:[hidden email]]
Sent: Tuesday, August 29, 2006 4:25 PM
To: Stephen Cooper
Cc: Toli Kuznets; Marketcetera dev
Subject: Re: [m-etc-dev] RE: FIX connection issue

Stephen,

I looked through the FIX 4.2 spec, and it doesn't have language
specifically regarding the Logon message used to start a conversation,
w.r.t. ResetSeqNumFlag(141).  However, it does contain this telling
language about using the Logon message to reset a connection as part
of a 24-hour connection scheme:

> When using the ResetSeqNumFlag to maintain 24 hour connectivity and
establish a new > set of sequence numbers, the process should be as
follows. ... the initiator should send a > Logon with ResetSeqNumFlag
set to Y and with MsgSeqNum of 1. The acceptor should > respond with a
Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. ...

That seems to indicate in that instance, the correct response is to
include 141=Y as an acknowledgement of reciept of the same.

Certainly this is how QuickFIX/J implements it.  When we run the same
interaction as you on our exchange simulator that is based on
QuickFIX/J, what we see is 141=Y in the response Logon message.

We will crosspost a similar message on the QuickFIX/J list for further
guidance.

graham


On 8/29/06, Stephen Cooper <[hidden email]> wrote:
> Toli,
>
> This seems to be working for us now.  Am I correct in thinking that
even

> if you send 141=Y in login, we should not send 141=Y in the echo login
> message?
>
> Thanks,
> Steve
>
> -----Original Message-----
> From: Toli Kuznets [mailto:[hidden email]]
> Sent: Monday, August 28, 2006 7:12 PM
> To: Stephen Cooper
> Cc: Graham Miller; Marketcetera dev
> Subject: Re: [m-etc-dev] RE: FIX connection issue
>
> Stephen,
>
> Looks like we left out another flag that we think is causing the error
> you are experiencing.  Can you set:
> SendResetSeqNumFlag=N
> and make sure that these are still set to N:
> ResetOnLogout=N
> ResetOnDisconnect=N
>
> in the oms.properties file and try again? That should eliminate the
> initial sending of the 141 field from our OMS which confuses your FIX
> engine.
> You'll need to delete the store/ directory again (otherise, QuickfixJ
> will spend some time resetting the sequence numbers after logon).
>
> Please let me know how that goes.  Sorry, took us a while to track
this

> down.
>
>
> On 8/25/06, Stephen Cooper <[hidden email]> wrote:
> >
> >
> >
> >
> > Graham,
> >
> >
> >
> > I made the following changes to oms.properties, including some
things

> I just
> > made up to see if they worked:
> >
> >
> >
> > # FIX constants
> >
> > DataDictionary=FIX42.xml
> >
> > UseDataDictionary=Y
> >
> > ResetOnLogout=N         //was Y
> >
> > ResetOnDisconnect=N   //was Y
> >
> > ResetSeqNumFlag=N     //added this, probably no affect
> >
> > ResetOnLogon=N          //added this, probably no affect
> >
> >
> >
> > I also deleted store/ directory and the net effect was that the same
> thing
> > happened, only that the 141=Y was omitted.
> >
> >
> >
> > Any ideas?
> >
> --
> Toli Kuznets
> http://www.marketcetera.com: Open-Source Trading Platform
> download.run.trade.
>
> ----------
> This e-mail message and its attachments are confidential, intended
only for the addressee(s) named above and may contain information that
is proprietary, privileged, or otherwise exempt from disclosure. If you
receive this message in error please notify us at
[hidden email] and immediately delete this message and
its attachments from your system.
>
> Miletus Trading, LLC is not responsible for any recommendation,
solicitation, offer or agreement or any information about any
transaction, customer account or account activity contained in this
communication.
>
>
>
_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
gm-mrktc

RE: FIX connection issue

Reply Threaded More More options
Print post
Permalink
On 8/29/06, Stephen Cooper <[hidden email]> wrote:
> Seems that the bug would be on your end, then, or on QuickFix/J side,
> since our engine is sending correct response.

Well, it doesn't seem that your engine ever responds with 141=Y in a
Logon message.  For example this is the second message in the
conversation referenced above (following a Logon with 141=Y from the
OMS)

> > 20060824-16:53:19 [    1] FIXMESSAGE [A] Logon
> >         BeginString         [    8] = FIX.4.2
> >         BodyLength          [    9] = 66
> >         MsgType             [   35] = A // Logon
> >         SenderCompID        [   49] = MLTS2
> >         TargetCompID        [   56] = VFCLIENT01
> >         MsgSeqNum           [   34] = 1
> >         SendingTime         [   52] = "20060824-20:53:19"
> >         EncryptMethod       [   98] = 0 // None
> >         HeartBtInt          [  108] = 30
> >         CheckSum            [   10] = 106


> Meanwhile, another question:  Can the OrderLoader support other message
> types, e.g. Replace Requests, Cxl Requests?

Right now the only message type supported by the OrderLoader is "New
Order - Single  (MsgType = D)".  Would you be interested in support
for other message types?

graham


>
>
> -----Original Message-----
> From: Graham Miller [mailto:[hidden email]]
> Sent: Tuesday, August 29, 2006 4:25 PM
> To: Stephen Cooper
> Cc: Toli Kuznets; Marketcetera dev
> Subject: Re: [m-etc-dev] RE: FIX connection issue
>
> Stephen,
>
> I looked through the FIX 4.2 spec, and it doesn't have language
> specifically regarding the Logon message used to start a conversation,
> w.r.t. ResetSeqNumFlag(141).  However, it does contain this telling
> language about using the Logon message to reset a connection as part
> of a 24-hour connection scheme:
>
> > When using the ResetSeqNumFlag to maintain 24 hour connectivity and
> establish a new > set of sequence numbers, the process should be as
> follows. ... the initiator should send a > Logon with ResetSeqNumFlag
> set to Y and with MsgSeqNum of 1. The acceptor should > respond with a
> Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1. ...
>
> That seems to indicate in that instance, the correct response is to
> include 141=Y as an acknowledgement of reciept of the same.
>
> Certainly this is how QuickFIX/J implements it.  When we run the same
> interaction as you on our exchange simulator that is based on
> QuickFIX/J, what we see is 141=Y in the response Logon message.
>
> We will crosspost a similar message on the QuickFIX/J list for further
> guidance.
>
> graham
>
>
> On 8/29/06, Stephen Cooper <[hidden email]> wrote:
> > Toli,
> >
> > This seems to be working for us now.  Am I correct in thinking that
> even
> > if you send 141=Y in login, we should not send 141=Y in the echo login
> > message?
> >
> > Thanks,
> > Steve
> >
> > -----Original Message-----
> > From: Toli Kuznets [mailto:[hidden email]]
> > Sent: Monday, August 28, 2006 7:12 PM
> > To: Stephen Cooper
> > Cc: Graham Miller; Marketcetera dev
> > Subject: Re: [m-etc-dev] RE: FIX connection issue
> >
> > Stephen,
> >
> > Looks like we left out another flag that we think is causing the error
> > you are experiencing.  Can you set:
> > SendResetSeqNumFlag=N
> > and make sure that these are still set to N:
> > ResetOnLogout=N
> > ResetOnDisconnect=N
> >
> > in the oms.properties file and try again? That should eliminate the
> > initial sending of the 141 field from our OMS which confuses your FIX
> > engine.
> > You'll need to delete the store/ directory again (otherise, QuickfixJ
> > will spend some time resetting the sequence numbers after logon).
> >
> > Please let me know how that goes.  Sorry, took us a while to track
> this
> > down.
> >
> >
> > On 8/25/06, Stephen Cooper <[hidden email]> wrote:
> > >
> > >
> > >
> > >
> > > Graham,
> > >
> > >
> > >
> > > I made the following changes to oms.properties, including some
> things
> > I just
> > > made up to see if they worked:
> > >
> > >
> > >
> > > # FIX constants
> > >
> > > DataDictionary=FIX42.xml
> > >
> > > UseDataDictionary=Y
> > >
> > > ResetOnLogout=N         //was Y
> > >
> > > ResetOnDisconnect=N   //was Y
> > >
> > > ResetSeqNumFlag=N     //added this, probably no affect
> > >
> > > ResetOnLogon=N          //added this, probably no affect
> > >
> > >
> > >
> > > I also deleted store/ directory and the net effect was that the same
> > thing
> > > happened, only that the 141=Y was omitted.
> > >
> > >
> > >
> > > Any ideas?
> > >
> > --
> > Toli Kuznets
> > http://www.marketcetera.com: Open-Source Trading Platform
> > download.run.trade.
> >
> > ----------
> > This e-mail message and its attachments are confidential, intended
> only for the addressee(s) named above and may contain information that
> is proprietary, privileged, or otherwise exempt from disclosure. If you
> receive this message in error please notify us at
> [hidden email] and immediately delete this message and
> its attachments from your system.
> >
> > Miletus Trading, LLC is not responsible for any recommendation,
> solicitation, offer or agreement or any information about any
> transaction, customer account or account activity contained in this
> communication.
> >
> >
> >
>
_______________________________________________
m-etc-dev mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-dev
Free Embeddable Forum Powered by Nabble Help