quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Kenny S. <ks...@co...>]

If you decide to make some changes, we would be interested to see what you
find out.  There are already a few interesting
branches<http://github.com/jaubrey/quickfix/network>on the quickfix
github page, one of which is performance related that will
probably get merged at some point.

--
Kenny Stone
Connamara Systems, LLC


On Wed, Nov 18, 2009 at 5:02 PM, Dale Wilson <wi...@oc...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> Rick Lane wrote:
> > We were recently taking a look through the FIX42_MessageCracker and
> > MessageFactory code (we're using the .NET wrapper for Quickfix)  to
> > see if we could make some improvements in our order routing internal
> > latency.  We noticed that in both crack() and create()
> >
> > 1) it was doing string comparisons for the message type (when for FIX
> > 4.2 all message types are a single character)
> > 2) it was doing if-statements rather than a switch statement
> > 3) the if-statement for ExecutionReport (which is the most frequent
> > type of message) was 30th in this list!
> >
> > So we figured we could speed this up substantially by:
> >
> > 1) creating a switch() statement (that is constant time) instead of 60
> > or so if-statements and
> > 2) simply switch on the int value of the character (since we know it's
> > only 1 character)
> >
> > However, in practice, we haven't noticed any speed gains and we almost
> > seem to think we're seeing /slower /performance (this is tough to
> > measure because we have to measure in conjunction with WireShark to
> > see how long the message was outside our server (transit latency) and
> > subtract that from the measured time in code).
> >
> > We're wondering if perhaps we aren't doing something correctly at
> > compile time, if anyone has seen these if-statements and thought the
> > same thing we thought, and if anyone has any input in general here.
> >
> > Any help is greatly appreciated.
> I recently spent several months reducing the latency in the QuickFAST
> (not QuickFIX) decoder by two orders of magnitude (i.e. a factor of
> 100)  These observations are based on that work:
>
> With the complexity of C++ and the sometimes remarkable ability of
> modern compilers to optimize code, inspecting the C++ source code to
> improve performance is rarely effective.  For example, there are some
> compilers that generate exactly the same code for a switch statement and
> a chain of if-else's. As you pointed out, if the possible values are
> sufficiently constrained it is possible to decide which code to execute
> in constant time.   Trying to improve performance by rearranging source
> code with a compiler like that can be an exercise in futility.
>
> A similar argument applies to the string comparison.  If the comparison
> is inline and the values being compared to are constant literals (like,
> for example FIX tags) then the compiler may very well generate that
> single character comparison for you!
>
> The first step in improving performance should ALWAYS be to measure.
> You need to run a profiler and watch the system under load.   If you
> work on a section of the code that is responsible for, say 1% of the
> overall latency, and you find the perfect optimization, the best result
> you could hope for is a 1% improvement in the overall system.
>
> The next step in improving performance is to eliminate the noise.
> Admittedly in the real world you need to be concerned with network
> transmission time and efficiency of the communication stack, etc.  but
> if you're trying to improve the latency introduced by QuickFIX, you need
> to get rid of these variables altogether, not just factor them out..
> Otherwise trivial variations in the behavior of the network will totally
> swamp the performance differences you are trying to measure.   [Which
> brings up a different point.   The payoff in improving the network can
> be far higher than the payoff in improving code at the QuickFIX level,
> but I'll assume that's already done and you still want better
> performance..]
>
> When the profiler directs your attention to a particular portion of the
> code and you very carefully hand-optimize that section of code to
> squeeze every possible CPU cycle out of it, run the profiler again!
> Don't assume that just because the code looks faster, that it will
> actually run faster.  During the QuickFAST optimization process I spent
> a lot of time creating a cache of very commonly used objects that could
> be reused rather than being "new" ed and "deleted" every time.  Net
> result -- the performance was worse.  I ended up throwing all that work
> away, and trying a different approach.
>
> And lastly, I hope you'll share the results of your efforts.  I am very
> interested in what works and what doesn't work when trying to improve
> program performance.
>
> Regards,
>
> Dale
>
> --
> Dale Wilson
> Principal Software Engineer
> Object Computing, Inc. (www.ociweb.com)
> Lead developer for QuickFAST (http:www.quickfast.org)
>
>
>
>
>
>
>
>
>
> >
> > Rick
> >
> > P.S.  I'm not sure what the process is (it's been so long now) but if
> > you could add dan...@ti... <mailto:dan...@ti...> to
> > the mailing list so it will accept emails from him.  Thanks again.
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Dale W. <wi...@oc...>]

Hi Rick,

Rick Lane wrote:
> We were recently taking a look through the FIX42_MessageCracker and 
> MessageFactory code (we're using the .NET wrapper for Quickfix)  to 
> see if we could make some improvements in our order routing internal 
> latency.  We noticed that in both crack() and create() 
>
> 1) it was doing string comparisons for the message type (when for FIX 
> 4.2 all message types are a single character)
> 2) it was doing if-statements rather than a switch statement
> 3) the if-statement for ExecutionReport (which is the most frequent 
> type of message) was 30th in this list!
>
> So we figured we could speed this up substantially by:
>
> 1) creating a switch() statement (that is constant time) instead of 60 
> or so if-statements and
> 2) simply switch on the int value of the character (since we know it's 
> only 1 character)
>
> However, in practice, we haven't noticed any speed gains and we almost 
> seem to think we're seeing /slower /performance (this is tough to 
> measure because we have to measure in conjunction with WireShark to 
> see how long the message was outside our server (transit latency) and 
> subtract that from the measured time in code).
>
> We're wondering if perhaps we aren't doing something correctly at 
> compile time, if anyone has seen these if-statements and thought the 
> same thing we thought, and if anyone has any input in general here.
>
> Any help is greatly appreciated.
I recently spent several months reducing the latency in the QuickFAST 
(not QuickFIX) decoder by two orders of magnitude (i.e. a factor of 
100)  These observations are based on that work:

With the complexity of C++ and the sometimes remarkable ability of 
modern compilers to optimize code, inspecting the C++ source code to 
improve performance is rarely effective.  For example, there are some 
compilers that generate exactly the same code for a switch statement and 
a chain of if-else's. As you pointed out, if the possible values are 
sufficiently constrained it is possible to decide which code to execute 
in constant time.   Trying to improve performance by rearranging source 
code with a compiler like that can be an exercise in futility.

A similar argument applies to the string comparison.  If the comparison 
is inline and the values being compared to are constant literals (like, 
for example FIX tags) then the compiler may very well generate that 
single character comparison for you!

The first step in improving performance should ALWAYS be to measure.  
You need to run a profiler and watch the system under load.   If you 
work on a section of the code that is responsible for, say 1% of the 
overall latency, and you find the perfect optimization, the best result 
you could hope for is a 1% improvement in the overall system.

The next step in improving performance is to eliminate the noise.   
Admittedly in the real world you need to be concerned with network 
transmission time and efficiency of the communication stack, etc.  but 
if you're trying to improve the latency introduced by QuickFIX, you need 
to get rid of these variables altogether, not just factor them out..  
Otherwise trivial variations in the behavior of the network will totally 
swamp the performance differences you are trying to measure.   [Which 
brings up a different point.   The payoff in improving the network can 
be far higher than the payoff in improving code at the QuickFIX level, 
but I'll assume that's already done and you still want better performance..]

When the profiler directs your attention to a particular portion of the 
code and you very carefully hand-optimize that section of code to 
squeeze every possible CPU cycle out of it, run the profiler again!  
Don't assume that just because the code looks faster, that it will 
actually run faster.  During the QuickFAST optimization process I spent 
a lot of time creating a cache of very commonly used objects that could 
be reused rather than being "new" ed and "deleted" every time.  Net 
result -- the performance was worse.  I ended up throwing all that work 
away, and trying a different approach.

And lastly, I hope you'll share the results of your efforts.  I am very 
interested in what works and what doesn't work when trying to improve 
program performance.

Regards,

Dale

--
Dale Wilson
Principal Software Engineer 
Object Computing, Inc. (www.ociweb.com)
Lead developer for QuickFAST (http:www.quickfast.org)









>
> Rick
>
> P.S.  I'm not sure what the process is (it's been so long now) but if 
> you could add dan...@ti... <mailto:dan...@ti...> to 
> the mailing list so it will accept emails from him.  Thanks again.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Rick L. <ric...@gm...>]

the point is probably moot -- it seems that Session.sendToTarget() is really
the bottleneck.  We're seeing roughly 250-300 microseconds (or 80% of our
entire internal latency) for this call alone.  I wonder if anyone has had
any success in speeding this up?  is it simply the socket API that is this
slow?

On Wed, Nov 18, 2009 at 4:04 PM, Rick Lane <ric...@gm...> wrote:

> Greetings,
>
> We were recently taking a look through the FIX42_MessageCracker and
> MessageFactory code (we're using the .NET wrapper for Quickfix)  to see if
> we could make some improvements in our order routing internal latency.  We
> noticed that in both crack() and create()
>
> 1) it was doing string comparisons for the message type (when for FIX 4.2
> all message types are a single character)
> 2) it was doing if-statements rather than a switch statement
> 3) the if-statement for ExecutionReport (which is the most frequent type of
> message) was 30th in this list!
>
> So we figured we could speed this up substantially by:
>
> 1) creating a switch() statement (that is constant time) instead of 60 or
> so if-statements and
> 2) simply switch on the int value of the character (since we know it's only
> 1 character)
>
> However, in practice, we haven't noticed any speed gains and we almost seem
> to think we're seeing *slower *performance (this is tough to measure
> because we have to measure in conjunction with WireShark to see how long the
> message was outside our server (transit latency) and subtract that from the
> measured time in code).
>
> We're wondering if perhaps we aren't doing something correctly at compile
> time, if anyone has seen these if-statements and thought the same thing we
> thought, and if anyone has any input in general here.
>
> Any help is greatly appreciated.
>
> Rick
>
> P.S.  I'm not sure what the process is (it's been so long now) but if you
> could add dan...@ti... to the mailing list so it will accept
> emails from him.  Thanks again.
>

[Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Rick L. <ric...@gm...>]

Greetings,

We were recently taking a look through the FIX42_MessageCracker and
MessageFactory code (we're using the .NET wrapper for Quickfix)  to see if
we could make some improvements in our order routing internal latency.  We
noticed that in both crack() and create()

1) it was doing string comparisons for the message type (when for FIX 4.2
all message types are a single character)
2) it was doing if-statements rather than a switch statement
3) the if-statement for ExecutionReport (which is the most frequent type of
message) was 30th in this list!

So we figured we could speed this up substantially by:

1) creating a switch() statement (that is constant time) instead of 60 or so
if-statements and
2) simply switch on the int value of the character (since we know it's only
1 character)

However, in practice, we haven't noticed any speed gains and we almost seem
to think we're seeing *slower *performance (this is tough to measure because
we have to measure in conjunction with WireShark to see how long the message
was outside our server (transit latency) and subtract that from the measured
time in code).

We're wondering if perhaps we aren't doing something correctly at compile
time, if anyone has seen these if-statements and thought the same thing we
thought, and if anyone has any input in general here.

Any help is greatly appreciated.

Rick

P.S.  I'm not sure what the process is (it's been so long now) but if you
could add dan...@ti... to the mailing list so it will accept emails
from him.  Thanks again.

Re: [Quickfix-developers] (no subject)

[marksasson <ma...@at...>]

I got the following response via email: 

From: Blabos de Blebe [mailto:bl...@gm...] 
Sent: Tuesday, November 17, 2009 5:02 AM
To: Mark Sasson
Subject: Re: [Quickfix-developers] (no subject)

Hi,

Here, we have an application that is a client and a server
simultaneously too, and works fine.

Our approach was to create a FIX::Application for initiators and
another to acceptors.

Our application (written only in C++) connects clients and / or
servers who do not have access (who knows what language they were
written ...).

Sometimes we have to analyze the sockets status, connections, etc,etc,
but it works well.

Some sockets communications have obscure pitfalls depending on which
operation system you are.

Blabos


marksasson wrote:
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> 
> I am a quickfix developer who wrote some quickfix applications. We have an
> application which is both a server and a client written in C#. It is a
> client of the vendor but also a server for another client.  The client
> communicating with the server/client written in C++. Once in a while the
> communication is broken. Our C# server stops responding to our C++ client
> and does not send heartbeat or even respond to a TestRequest that the
> client
> sends. As result our client disconnects from the session and repeatedly
> sends a logon message to the server. The C# server keeps disconnecting the
> client believing that the original session is still in progress and the
> client get a socket reset. This goes on until we restart both.
> Has anyone seen anything like that before? Did anyone try running a
> application that is both server and client? Could you please point me in
> the
> right direction?
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

-- 
View this message in context: http://old.nabble.com/%28no-subject%29-tp26376288p26395046.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] (no subject)

[Mark S. <ma...@at...>]

I am a quickfix developer who wrote some quickfix applications. We have an
application which is both a server and a client written in C#. It is a
client of the vendor but also a server for another client.  The client
communicating with the server/client written in C++. Once in a while the
communication is broken. Our C# server stops responding to our C++ client
and does not send heartbeat or even respond to a TestRequest that the client
sends. As result our client disconnects from the session and repeatedly
sends a logon message to the server. The C# server keeps disconnecting the
client believing that the original session is still in progress and the
client get a socket reset. This goes on until we restart both.
Has anyone seen anything like that before? Did anyone try running a
application that is both server and client? Could you please point me in the
right direction?

Re: [Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

If anyone is interested I submitted a bug report on this. I also attached
two patch files that can be used to fix the issue.  It appears to be fixed
on my end with the patch in place. 

 

                http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=2895449&group_id=37535&atid
=1126912> &aid=2895449&group_id=37535&atid=1126912

 

 

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Tuesday, November 10, 2009 3:06 PM
To: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

 

Apparently this appears to be a bug in how the connection workflow is set
up.  What seems to happen is 

 

1)      When the Initiator is initialized, a connection for every configured
Session is created and placed in the "disconnected" bin

2)      Later, a SocketInitiator::onStart which invokes the
Initiator::connect method

3)      Each connection in the "disconnected" bin is tested and then passed
to the SocketInitiator::doConnect method, which 

a.       removes the connection from the "disconnected" bin and places it in
the "pending" bin

b.      calls "connect" on the connection

4)      If the connection connects all is well, however if a connection is
not made by some timeout value, SocketInitiator::onTimeout is invoked, which

a.       Check to see a retry is allowed based on the last time it was tried

b.      Attempts to reconnect using the Initiator::connect method (as in
item #2, above).

 

The issue is that when the connect method is called again, the connection(s)
that timed out were never moved from the "pending" bin to the "disconnected"
bin and therefore a connection is never retried.  This is because the
connect method only works on connections in the "disconnected" bin - which
makes sense.

 

I will be summiting a bug report as soon as I can get an OpenID and log into
the appropriate SourceForge bug tracker.  

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Monday, November 09, 2009 1:22 PM
To: qui...@li...
Subject: [Quickfix-developers] Initiator Reconnect?

 

I am using the C++ library for QuickFIX version 1.12.4.  

 

I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library).
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn't come up
within 15 seconds, the client doesn't attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html

 

To make things clear here are the two scenarios I quickly outlined:  

a.       Client starts before Server

b.      Execute my application

c.       Wait a few seconds

d.      Client application logs "Connecting to localhost on port 5001"

e.      Start executor server (using run_executor_cpp)

f.        Executor starts up successfully

g.       Client application never retries to connect to executor server

h.      Server exists/crashes before Client

i.         Start executor server (using run_executor_cpp)

j.        Executor starts up successfully

k.       Execute my application

l.         Connection is made and login successful

m.    Kill executor server (manually for testing)

n.      Client application gets disconnect and logout event

o.      Client application attempts to reconnect and logs "Connecting to
localhost on port 5001"

p.      Wait 15 or so seconds

q.      Start executor server (using run_executor_cpp)

r.        Executor starts up successfully

s.       Client application never retries to connect to executor server

 

Should I be doing something in code to get this reconnect behavior working?

 

Thanks,

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

[Quickfix-developers] Have issues with MarketDataRequest....

[<ch...@gm...>]

Hi 
I want to send a market data request message .
In the Application My fromApp and OnMessage is not getting invoked in
response to the message; instead ToApp is getting involed. 
Below are logs , Code for Market data message and confg file are given
below. I want to receive the response of MarketDataRequest. for which i want
fromApp to be get triggered. As i have pasted my logs. i want to figure out
that why i not receiving the response form the FIX server . Please help me
how i can figure out this issue.

Thanks,
Asad

FIX LOGS:

 8=FIX.4.4 9=80 35=4 49=ISLD 56=TW 34=129 52=20091102-19:48:21 43=Y 57=user3
123=Y 36=175 10=010
8=FIX.4.4 9=203 35=V 1=ACCT1@TW 15=USD 34=108 38=10000 49=TW 50=user3
52=20091102-19:48:32.589 55=GBP/USD 56=ISLD 57=qfstream 108=10 146=1 265=0
448=BANK1 453=1 262=MARKETDATAID 263=1 264=1 267=2 269=0 269=1 10=152
8=FIX.4.4 9=174 35=X 49=ISLD 56=TW 34=175 52=20091102-19:48:30 115=BANK1
57=user3 262=MARKETDATAID 268=2 279=2 269=0 279=2 269=1 58=Provider
withdrawing customer from a shared stream. 10=194
8=FIX.4.4 9=134 35=3 34=109 49=TW 50=user3 52=20091102-19:48:33.051 56=ISLD
128=BANK1 45=175 58=Tag appears more than once 371=269 372=X 373=13 10=019
8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=176 52=20091102-19:48:30 115=BANK1
57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63935 15=USD
271=10000 299=S.7809825/1100 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
271=10000 299=S.7809825/1100 10=173
8=FIX.4.4 9=133 35=3 34=110 49=TW 50=user3 52=20091102-19:48:33.270 56=ISLD
128=BANK1 45=176 58=Tag appears more than once 371=15 372=X 373=13 10=211
8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=177 52=20091102-19:48:30 115=BANK1
57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63910 15=USD
271=10000 299=S.7809825/1101 279=0 269=0 55=GBP/USD 270=1.63890 15=USD
271=10000 299=S.7809825/1101 10=165
8=FIX.4.4 9=133 35=3 34=111 49=TW 50=user3 52=20091102-19:48:33.414 56=ISLD
128=BANK1 45=177 58=Tag appears more than once 371=15 372=X 373=13 10=213
8=FIX.4.4 9=75 35=1 34=112 49=TW 50=user3 52=20091102-19:48:36.283 56=ISLD
112=TEST 10=112
8=FIX.4.4 9=71 35=0 49=ISLD 56=TW 34=178 52=20091102-19:48:33 57=user3
112=TEST 10=176
8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=179 52=20091102-19:48:34 115=BANK1
57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63915 15=USD
271=10000 299=S.7809825/1102 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
271=10000 299=S.7809825/1102 10=182
8=FIX.4.4 9=133 35=3 34=113 49=TW 50=user3 52=20091102-19:48:37.339 56=ISLD
128=BANK1 45=179 58=Tag appears more than once 371=15 372=X 373=13 10=227
8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=180 52=20091102-19:48:37 115=BANK1
57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63905 15=USD
271=10000 299=S.7809825/1103 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
271=10000 299=S.7809825/1103 10=178
8=FIX.4.4 9=133 35=3 34=114 49=TW 50=user3 52=20091102-19:48:40.364 56=ISLD
128=BANK1 45=180 58=Tag appears more than once 371=15 372=X 373=13 10=212


Here is my code: 


void Application::queryMarketDataRequest()
{
  std::cout << "\nMarketDataRequest\n";
 
 FIX::Message message;
 
 
  FIX::MDReqID mdReqID( "MARKETDATAID" );
  FIX::SubscriptionRequestType subType(
FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES );
  FIX::MarketDepth marketDepth( 1 );
  FIX44::MarketDataRequest::NoMDEntryTypes marketDataEntryGroup;
  FIX::MDEntryType mdEntryType( FIX::MDEntryType_BID );
  FIX44::MarketDataRequest message( mdReqID, subType, marketDepth );
  marketDataEntryGroup.set( mdEntryType );
  message.addGroup( marketDataEntryGroup );
 
  
  FIX::MDEntryType mdEntryType1( FIX::MDEntryType_OFFER );
  marketDataEntryGroup.set( mdEntryType1 );
  message.addGroup( marketDataEntryGroup );

 
 message.getHeader().setField(FIX::SenderCompID("TW"));
 message.getHeader().setField(FIX::TargetCompID("ISLD"));
 message.getHeader().setField(FIX::TargetSubID("qfstream"));
 message.getHeader().setField(FIX::SenderSubID("user3"));
 message.getHeader().setField(35, "V");
 message.getHeader().setField(265, "0");
 message.getHeader().setField(1, "ACCT1@TW");
 
 message.getHeader().setField(146, "1");
 message.getHeader().setField(55, "GBP/USD");
 message.getHeader().setField(38, "10000");
 message.getHeader().setField(15, "USD");
 message.getHeader().setField(453, "1");

 message.getHeader().setField(108, "10");
 FIX::Session::sendToTarget( message,"FIXMDR" );
}
 
void
Application::fromApp( const FIX::Message& message, const FIX::SessionID&
sessionID ) 
throw
( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue,
FIX::UnsupportedMessageType ) 
{
crack( message, sessionID );
std::cout << std::endl << 
" formApp IN: " << message << std::endl; 
}
void
Application::toApp( FIX::Message& message, const FIX::SessionID& sessionID ) 
throw
( FIX::DoNotSend ) 
{
try 
{
FIX::PossDupFlag possDupFlag;
message.getHeader().getField( possDupFlag );
if ( possDupFlag ) throw FIX::DoNotSend(); 
}
catch ( FIX::FieldNotFound& ) {} 
std::cout << std::endl
<< 
"toApp OUT: " << message << std::endl; 
}
void
Application::onMessage( const FIX44::MarketDataRequest& message, const
FIX::SessionID& id ) 
{
std::cout<<
"\n in onMessage for marketdata "<<message<<std::endl<<message; 
}


Here is the config file:
 
 
# default settings for sessions 
[DEFAULT]
ConnectionType=initiator 
ReconnectInterval=20
LogonTimeout=30
StartTime=00:00:00
EndTime=23:00:00
HeartBtInt=10
#SocketConnectHost=localhost
SocketConnectHost=127.0.0.1
SocketConnectPort=9000
FileLogPath=c:\qfixlogs\
FileStorePath=c:\qfixstore\
[SESSION]
BeginString=FIX.4.4
TargetCompID=ISLD
SessionQualifier=FIXMDR
TargetSubID=qfstream 
SenderCompID=TW
SenderSubID=user3 
RawData=1234567
HeartBtInt=10
FileLogPath=c:\qfixlogs\
FileStorePath=c:\qfixstore\
UseDataDictionary=N
DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml

-- 
View this message in context: http://old.nabble.com/Have-issues-with-MarketDataRequest....-tp26304404p26304404.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

Apparently this appears to be a bug in how the connection workflow is set
up.  What seems to happen is 

 

1)      When the Initiator is initialized, a connection for every configured
Session is created and placed in the "disconnected" bin

2)      Later, a SocketInitiator::onStart which invokes the
Initiator::connect method

3)      Each connection in the "disconnected" bin is tested and then passed
to the SocketInitiator::doConnect method, which 

a.       removes the connection from the "disconnected" bin and places it in
the "pending" bin

b.      calls "connect" on the connection

4)      If the connection connects all is well, however if a connection is
not made by some timeout value, SocketInitiator::onTimeout is invoked, which

a.       Check to see a retry is allowed based on the last time it was tried

b.      Attempts to reconnect using the Initiator::connect method (as in
item #2, above).

 

The issue is that when the connect method is called again, the connection(s)
that timed out were never moved from the "pending" bin to the "disconnected"
bin and therefore a connection is never retried.  This is because the
connect method only works on connections in the "disconnected" bin - which
makes sense.

 

I will be summiting a bug report as soon as I can get an OpenID and log into
the appropriate SourceForge bug tracker.  

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Monday, November 09, 2009 1:22 PM
To: qui...@li...
Subject: [Quickfix-developers] Initiator Reconnect?

 

I am using the C++ library for QuickFIX version 1.12.4.  

 

I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library).
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn't come up
within 15 seconds, the client doesn't attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html

 

To make things clear here are the two scenarios I quickly outlined:  

a.       Client starts before Server

b.      Execute my application

c.       Wait a few seconds

d.      Client application logs "Connecting to localhost on port 5001"

e.      Start executor server (using run_executor_cpp)

f.        Executor starts up successfully

g.       Client application never retries to connect to executor server

h.      Server exists/crashes before Client

i.         Start executor server (using run_executor_cpp)

j.        Executor starts up successfully

k.       Execute my application

l.         Connection is made and login successful

m.    Kill executor server (manually for testing)

n.      Client application gets disconnect and logout event

o.      Client application attempts to reconnect and logs "Connecting to
localhost on port 5001"

p.      Wait 15 or so seconds

q.      Start executor server (using run_executor_cpp)

r.        Executor starts up successfully

s.       Client application never retries to connect to executor server

 

Should I be doing something in code to get this reconnect behavior working?

 

Thanks,

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

Re: [Quickfix-developers] Initiator Reconnect?

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

I don't have any more ideas.  Post your config?


On Mon, Nov 9, 2009 at 2:30 PM, Robert Levas
<le...@qe...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I actually had the ReconnectInterval property set and the reconnect attempt
> only occurred once. If the server was not up at that time, no additional
> reconnects are made.
>
> Robert
>
>
> -----Original Message-----
> From: Robert Levas [mailto:le...@qe...]
> Sent: Monday, November 09, 2009 3:10 PM
> To: 'Grant Birchmeier'
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Initiator Reconnect?
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Doh... when looking at the configuration docs, I searched for "disconnect",
> "drop", etc... and apparently never looked for "reconnect".  I will try this
> and see if it works, however according to the docs, the default is 30
> seconds and I waited longer that for the reconnect.  Also according to what
> I observed, a reconnect was attempting once after 15 seconds.
>
> Thanks for pointing me in (hopefully) the right direction.
>
> Rob
>
>
>
> -----Original Message-----
> From: Grant Birchmeier [mailto:gbi...@co...]
> Sent: Monday, November 09, 2009 1:35 PM
> To: le...@qe...
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Initiator Reconnect?
>
> What does your config look like?  Is your initiator configured to
> attempt to reconnect?
>
> See "ReconnectInterval" in the "Initiator" section:
> http://quickfixengine.org/quickfix/doc/html/configuration.html
>
> -Grant
>
> On Mon, Nov 9, 2009 at 12:22 PM, Robert Levas
> <le...@qe...> wrote:
>> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>
>> I am using the C++ library for QuickFIX version 1.12.4.
>>
>>
>>
>> I have a FIX::Application implementation that successfully connects to and
> logs into the executor example application (that comes with the library).
> Things seem to be working as expected however if the client starts up after
> the executor server or the executor server goes down and doesn’t come up
> within 15 seconds, the client doesn’t attempt to connect to it. I assume
> that  should expect the client to retry connecting to the server but that is
> not happening and do I see anything relevant in the docs at
> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>
>>
>>
>> To make things clear here are the two scenarios I quickly outlined:
>>
>> 1)      Client starts before Server
>>
>> a.       Execute my application
>>
>> b.      Wait a few seconds
>>
>> c.       Client application logs “Connecting to localhost on port 5001”
>>
>> d.      Start executor server (using run_executor_cpp)
>>
>> e.      Executor starts up successfully
>>
>> f.        Client application never retries to connect to executor server
>>
>> 2)      Server exists/crashes before Client
>>
>> a.       Start executor server (using run_executor_cpp)
>>
>> b.      Executor starts up successfully
>>
>> c.       Execute my application
>>
>> d.      Connection is made and login successful
>>
>> e.      Kill executor server (manually for testing)
>>
>> f.        Client application gets disconnect and logout event
>>
>> g.       Client application attempts to reconnect and logs “Connecting to
> localhost on port 5001”
>>
>> h.      Wait 15 or so seconds
>>
>> i.         Start executor server (using run_executor_cpp)
>>
>> j.        Executor starts up successfully
>>
>> k.       Client application never retries to connect to executor server
>>
>>
>>
>> Should I be doing something in code to get this reconnect behavior
> working?
>>
>>
>>
>> Thanks,
>>
>> Robert Levas
>>
>> Systems Architect/Developer
>>
>> QED Financial Systems, Inc.
>>
>> 10,000 Sagemore
>> Marlton, New Jersey 08053 USA
>>
>> tel       856.797.1200
>>
>> fax      856.797.9719
>>
>> email   le...@QE...
>>
>> This electronic message is intended only for the receipt by, and the
> personal and confidential use of, the designated recipient(s) named
>> above.  If you are not an intended recipient of this electronic message
> you are hereby notified that any review, dissemination, distribution
>> or copy of this message is strictly prohibited.  QED Financial Systems,
> Inc. reserves all rights to the content of this electronic message,
>> which is the exclusive property of QED Financial Systems.
>>
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
> ----------------------------------------------------------------------------
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

I actually had the ReconnectInterval property set and the reconnect attempt
only occurred once. If the server was not up at that time, no additional
reconnects are made.

Robert


-----Original Message-----
From: Robert Levas [mailto:le...@qe...] 
Sent: Monday, November 09, 2009 3:10 PM
To: 'Grant Birchmeier'
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Doh... when looking at the configuration docs, I searched for "disconnect",
"drop", etc... and apparently never looked for "reconnect".  I will try this
and see if it works, however according to the docs, the default is 30
seconds and I waited longer that for the reconnect.  Also according to what
I observed, a reconnect was attempting once after 15 seconds. 

Thanks for pointing me in (hopefully) the right direction.

Rob



-----Original Message-----
From: Grant Birchmeier [mailto:gbi...@co...] 
Sent: Monday, November 09, 2009 1:35 PM
To: le...@qe...
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

What does your config look like?  Is your initiator configured to
attempt to reconnect?

See "ReconnectInterval" in the "Initiator" section:
http://quickfixengine.org/quickfix/doc/html/configuration.html

-Grant

On Mon, Nov 9, 2009 at 12:22 PM, Robert Levas
<le...@qe...> wrote:
> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I am using the C++ library for QuickFIX version 1.12.4.
>
>
>
> I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library). 
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn’t come up
within 15 seconds, the client doesn’t attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html
>
>
>
> To make things clear here are the two scenarios I quickly outlined:
>
> 1)      Client starts before Server
>
> a.       Execute my application
>
> b.      Wait a few seconds
>
> c.       Client application logs “Connecting to localhost on port 5001”
>
> d.      Start executor server (using run_executor_cpp)
>
> e.      Executor starts up successfully
>
> f.        Client application never retries to connect to executor server
>
> 2)      Server exists/crashes before Client
>
> a.       Start executor server (using run_executor_cpp)
>
> b.      Executor starts up successfully
>
> c.       Execute my application
>
> d.      Connection is made and login successful
>
> e.      Kill executor server (manually for testing)
>
> f.        Client application gets disconnect and logout event
>
> g.       Client application attempts to reconnect and logs “Connecting to
localhost on port 5001”
>
> h.      Wait 15 or so seconds
>
> i.         Start executor server (using run_executor_cpp)
>
> j.        Executor starts up successfully
>
> k.       Client application never retries to connect to executor server
>
>
>
> Should I be doing something in code to get this reconnect behavior
working?
>
>
>
> Thanks,
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message
you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems,
Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
> trial. Simplify your report design, integration and deployment - and focus
on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



----------------------------------------------------------------------------
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus
on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

Doh... when looking at the configuration docs, I searched for "disconnect",
"drop", etc... and apparently never looked for "reconnect".  I will try this
and see if it works, however according to the docs, the default is 30
seconds and I waited longer that for the reconnect.  Also according to what
I observed, a reconnect was attempting once after 15 seconds. 

Thanks for pointing me in (hopefully) the right direction.

Rob



-----Original Message-----
From: Grant Birchmeier [mailto:gbi...@co...] 
Sent: Monday, November 09, 2009 1:35 PM
To: le...@qe...
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

What does your config look like?  Is your initiator configured to
attempt to reconnect?

See "ReconnectInterval" in the "Initiator" section:
http://quickfixengine.org/quickfix/doc/html/configuration.html

-Grant

On Mon, Nov 9, 2009 at 12:22 PM, Robert Levas
<le...@qe...> wrote:
> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I am using the C++ library for QuickFIX version 1.12.4.
>
>
>
> I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library). 
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn’t come up
within 15 seconds, the client doesn’t attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html
>
>
>
> To make things clear here are the two scenarios I quickly outlined:
>
> 1)      Client starts before Server
>
> a.       Execute my application
>
> b.      Wait a few seconds
>
> c.       Client application logs “Connecting to localhost on port 5001”
>
> d.      Start executor server (using run_executor_cpp)
>
> e.      Executor starts up successfully
>
> f.        Client application never retries to connect to executor server
>
> 2)      Server exists/crashes before Client
>
> a.       Start executor server (using run_executor_cpp)
>
> b.      Executor starts up successfully
>
> c.       Execute my application
>
> d.      Connection is made and login successful
>
> e.      Kill executor server (manually for testing)
>
> f.        Client application gets disconnect and logout event
>
> g.       Client application attempts to reconnect and logs “Connecting to
localhost on port 5001”
>
> h.      Wait 15 or so seconds
>
> i.         Start executor server (using run_executor_cpp)
>
> j.        Executor starts up successfully
>
> k.       Client application never retries to connect to executor server
>
>
>
> Should I be doing something in code to get this reconnect behavior
working?
>
>
>
> Thanks,
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message
you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems,
Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
> trial. Simplify your report design, integration and deployment - and focus
on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Initiator Reconnect?

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

What does your config look like?  Is your initiator configured to
attempt to reconnect?

See "ReconnectInterval" in the "Initiator" section:
http://quickfixengine.org/quickfix/doc/html/configuration.html

-Grant

On Mon, Nov 9, 2009 at 12:22 PM, Robert Levas
<le...@qe...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I am using the C++ library for QuickFIX version 1.12.4.
>
>
>
> I have a FIX::Application implementation that successfully connects to and logs into the executor example application (that comes with the library).  Things seem to be working as expected however if the client starts up after the executor server or the executor server goes down and doesn’t come up within 15 seconds, the client doesn’t attempt to connect to it. I assume that  should expect the client to retry connecting to the server but that is not happening and do I see anything relevant in the docs at http://www.quickfixengine.org/quickfix/doc/html/index.html
>
>
>
> To make things clear here are the two scenarios I quickly outlined:
>
> 1)      Client starts before Server
>
> a.       Execute my application
>
> b.      Wait a few seconds
>
> c.       Client application logs “Connecting to localhost on port 5001”
>
> d.      Start executor server (using run_executor_cpp)
>
> e.      Executor starts up successfully
>
> f.        Client application never retries to connect to executor server
>
> 2)      Server exists/crashes before Client
>
> a.       Start executor server (using run_executor_cpp)
>
> b.      Executor starts up successfully
>
> c.       Execute my application
>
> d.      Connection is made and login successful
>
> e.      Kill executor server (manually for testing)
>
> f.        Client application gets disconnect and logout event
>
> g.       Client application attempts to reconnect and logs “Connecting to localhost on port 5001”
>
> h.      Wait 15 or so seconds
>
> i.         Start executor server (using run_executor_cpp)
>
> j.        Executor starts up successfully
>
> k.       Client application never retries to connect to executor server
>
>
>
> Should I be doing something in code to get this reconnect behavior working?
>
>
>
> Thanks,
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems, Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

I am using the C++ library for QuickFIX version 1.12.4.  

 

I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library).
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn't come up
within 15 seconds, the client doesn't attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html

 

To make things clear here are the two scenarios I quickly outlined:  

1)      Client starts before Server

a.       Execute my application

b.      Wait a few seconds

c.       Client application logs "Connecting to localhost on port 5001"

d.      Start executor server (using run_executor_cpp)

e.      Executor starts up successfully

f.        Client application never retries to connect to executor server

2)      Server exists/crashes before Client

a.       Start executor server (using run_executor_cpp)

b.      Executor starts up successfully

c.       Execute my application

d.      Connection is made and login successful

e.      Kill executor server (manually for testing)

f.        Client application gets disconnect and logout event

g.       Client application attempts to reconnect and logs "Connecting to
localhost on port 5001"

h.      Wait 15 or so seconds

i.         Start executor server (using run_executor_cpp)

j.        Executor starts up successfully

k.       Client application never retries to connect to executor server

 

Should I be doing something in code to get this reconnect behavior working?

 

Thanks,

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email    <mailto:le...@QE...>
le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

Re: [Quickfix-developers] Logout after Logon

[Vipula <vi...@gm...>]

Hi,
Does this happens all the time ? Check your config file for start and end
times. If you are trying to login at a time out side the session times your
client can send a logout signal.  The time inthe config file is UTC time.
Hope this helps.
Vipula

2009/11/6 Dale Wilson <wi...@oc...>

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Fabio Renggli wrote:
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi together
> >
> > Can anybody tell me, why my quickfix engine sends automatically a logout
> response to the inititor when he sends a logon.
> > thanks for your answers.
> >
> Replying to a logon with a logout is the standard way to reject the
> logon.   There are many reasons why a login might fail.  Sometimes there
> will be a text field in the logout message that explains what went
> wrong.  You can also look in the logs for that session to see if there
> is a message there.
>
> Dale
>
>
> > Best regards.
> > Fabio
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] market data request message

[<ch...@gm...>]

Grant:
Thanks for your valued response.
 
Yes its form the program that sends MarketDataRequest. I can understand that
my program should be triggering toApp() when i send a message. Sorry if i
was unable to communicate well, I want to receive the response of
MarketDataRequest. for which i want fromApp to be get triggered. As i have
pasted my logs. i want to figure out that why i not receiving the response
form the FIX server .
 
Looking forward to your respons.
 
Thanks.
Asad.  



Grant Birchmeier wrote:
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> I think you have it backward.  The code you've pasted is from program
> that sends MarketDataRequest, right?  Your program SHOULD be
> triggering toApp(), and SHOULD NOT be triggering fromApp(), when it
> sends this message.
> 
> toApp() is triggered by OUTGOING messages.  Read it as "to the other app".
> 
> fromApp() is triggered by INCOMING messages.  Read it as "from the other
> app".
> 
> Also, please look at this page:
> http://quickfixengine.org/quickfix/doc/html/sending_messages.html
> Your queryMarketDataRequest function should look at lot more like the
> "DO THIS!" example on the bottom.  You should not need to set fields
> directly on the header like you are.
> 
> -Grant
> 
> 
> On Wed, Nov 4, 2009 at 3:05 PM, choudhry asad <ch...@gm...> wrote:
>> Grant:
>>
>> Thanks for the reply. I have looked in to it, but unable to figure out
>> where
>> is the issue still toApp is getting invoked, instead of fromApp. Below is
>> my
>> code for market data request message and the config file. If you can
>> please
>> have a look in to it and suggest me where is the issue.
>>
>> code for market data request, toAPP, fromAPP and OnMessage :
>>
>> void Application::queryMarketDataRequest()
>> {
>>   std::cout << "\nMarketDataRequest\n";
>>
>>  FIX::Message message;
>>
>>
>>   FIX::MDReqID mdReqID( "MARKETDATAID" );
>>   FIX::SubscriptionRequestType subType(
>> FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES );
>>   FIX::MarketDepth marketDepth( 1 );
>>   FIX44::MarketDataRequest::NoMDEntryTypes marketDataEntryGroup;
>>   FIX::MDEntryType mdEntryType( FIX::MDEntryType_BID );
>>   FIX44::MarketDataRequest message( mdReqID, subType, marketDepth );
>>   marketDataEntryGroup.set( mdEntryType );
>>   message.addGroup( marketDataEntryGroup );
>>
>>
>>   FIX::MDEntryType mdEntryType1( FIX::MDEntryType_OFFER );
>>   marketDataEntryGroup.set( mdEntryType1 );
>>   message.addGroup( marketDataEntryGroup );
>>
>>  message.getHeader().setField(FIX::SenderCompID("TW"));
>>  message.getHeader().setField(FIX::TargetCompID("ISLD"));
>>  message.getHeader().setField(FIX::TargetSubID("qfstream"));
>>  message.getHeader().setField(FIX::SenderSubID("user3"));
>>  message.getHeader().setField(35, "V");
>>  message.getHeader().setField(265, "0");
>>  message.getHeader().setField(1, "ACCT1@TW");
>>
>>  message.getHeader().setField(146, "1");
>>  message.getHeader().setField(55, "GBP/USD");
>>  message.getHeader().setField(38, "10000");
>>  message.getHeader().setField(15, "USD");
>>  message.getHeader().setField(453, "1");
>>  message.getHeader().setField(108, "10");
>>  FIX::Session::sendToTarget( message,"FIXMDR" );
>> }
>>
>>
>> void
>>
>> Application::fromApp( const FIX::Message& message, const FIX::SessionID&
>> sessionID )
>>
>> throw
>>
>> ( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue,
>> FIX::UnsupportedMessageType )
>>
>> {
>>
>> crack( message, sessionID );
>>
>> std::cout << std::endl <<
>>
>> " formApp IN: " << message << std::endl;
>>
>> }
>>
>> void
>>
>> Application::toApp( FIX::Message& message, const FIX::SessionID&
>> sessionID )
>>
>> throw
>>
>> ( FIX::DoNotSend )
>>
>> {
>>
>> try
>>
>> {
>>
>> FIX::PossDupFlag possDupFlag;
>>
>> message.getHeader().getField( possDupFlag );
>>
>> if ( possDupFlag ) throw FIX::DoNotSend();
>>
>> }
>>
>> catch ( FIX::FieldNotFound& ) {}
>>
>> std::cout << std::endl
>>
>> <<
>>
>> "toApp OUT: " << message << std::endl;
>>
>> }
>>
>> void
>>
>> Application::onMessage( const FIX44::MarketDataRequest& message, const
>> FIX::SessionID& id )
>>
>> {
>>
>> std::cout<<
>>
>> "\n in onMessage for marketdata "<<message<<std::endl<<message;
>>
>> }
>>
>> Here is the config file:
>>
>>
>> # default settings for sessions
>> [DEFAULT]
>> ConnectionType=initiator
>> ReconnectInterval=20
>> LogonTimeout=30
>> StartTime=00:00:00
>> EndTime=23:00:00
>> HeartBtInt=10
>> #SocketConnectHost=localhost
>> SocketConnectHost=127.0.0.1
>> SocketConnectPort=9000
>> FileLogPath=c:\qfixlogs\
>> FileStorePath=c:\qfixstore\
>> [SESSION]
>> BeginString=FIX.4.4
>> TargetCompID=ISLD
>> SessionQualifier=FIXMDR
>> TargetSubID=qfstream
>> SenderCompID=TW
>> SenderSubID=user3
>> RawData=1234567
>> HeartBtInt=10
>> FileLogPath=c:\qfixlogs\
>> FileStorePath=c:\qfixstore\
>> UseDataDictionary=N
>> DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml
>>
>> On Wed, Nov 4, 2009 at 8:31 PM, Grant Birchmeier
>> <gbi...@co...>
>> wrote:
>>>
>>> It appears that app TW is sending out your MarketDataRequest just fine.
>>>
>>> It is rejecting the app ISLD's market data (35=X) response ("Tag
>>> appears more than once").
>>>
>>> Which app, TW or ISLD, are you asking about?  When an app receives a
>>> message, it triggers fromApp(), which should almost always call
>>> crack(), which will call onMessage(<type>).
>>>
>>> When an app sends a message, the message goes through toApp(), to give
>>> you a chance to intercept or abort the message.  Myself, I rarely have
>>> need to use this function.
>>>
>>> So, in your apps:
>>> 1) TW will invoke toApp() when it sends the MarketDataRequest.
>>> 2) When ISLD receives the MarketDataRequest, it will invoke fromApp(),
>>> then crack(), then onMessage(MarketDataRequest).
>>>
>>> -Grant
>>>
>>>
>>> On Wed, Nov 4, 2009 at 4:32 AM, ch...@gm... <ch...@gm...>
>>> wrote:
>>> > QuickFIX Documentation:
>>> > http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> > QuickFIX Support: http://www.quickfixengine.org/services.html
>>> >
>>> >
>>> > Hi I want to send a market data request message .
>>> >
>>> > i the Application My fromApp and OnMessage is not getting invoked in
>>> > response to the message; instead ToApp is getting involed.
>>> > Below are logs please have a look and suggest my how to fix this
>>> > issue.............
>>> >
>>> > Thanks,
>>> > Asad
>>> >
>>> > 8=FIX.4.4 9=80 35=4 49=ISLD 56=TW 34=129 52=20091102-19:48:21 43=Y
>>> > 57=user3
>>> > 123=Y 36=175 10=010
>>> > 8=FIX.4.4 9=203 35=V 1=ACCT1@TW 15=USD 34=108 38=10000 49=TW 50=user3
>>> > 52=20091102-19:48:32.589 55=GBP/USD 56=ISLD 57=qfstream 108=10 146=1
>>> > 265=0
>>> > 448=BANK1 453=1 262=MARKETDATAID 263=1 264=1 267=2 269=0 269=1 10=152
>>> > 8=FIX.4.4 9=174 35=X 49=ISLD 56=TW 34=175 52=20091102-19:48:30
>>> 115=BANK1
>>> > 57=user3 262=MARKETDATAID 268=2 279=2 269=0 279=2 269=1 58=Provider
>>> > withdrawing customer from a shared stream. 10=194
>>> > 8=FIX.4.4 9=134 35=3 34=109 49=TW 50=user3 52=20091102-19:48:33.051
>>> > 56=ISLD
>>> > 128=BANK1 45=175 58=Tag appears more than once 371=269 372=X 373=13
>>> > 10=019
>>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=176 52=20091102-19:48:30
>>> 115=BANK1
>>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63935
>>> > 15=USD
>>> > 271=10000 299=S.7809825/1100 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>>> > 271=10000 299=S.7809825/1100 10=173
>>> > 8=FIX.4.4 9=133 35=3 34=110 49=TW 50=user3 52=20091102-19:48:33.270
>>> > 56=ISLD
>>> > 128=BANK1 45=176 58=Tag appears more than once 371=15 372=X 373=13
>>> > 10=211
>>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=177 52=20091102-19:48:30
>>> 115=BANK1
>>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63910
>>> > 15=USD
>>> > 271=10000 299=S.7809825/1101 279=0 269=0 55=GBP/USD 270=1.63890 15=USD
>>> > 271=10000 299=S.7809825/1101 10=165
>>> > 8=FIX.4.4 9=133 35=3 34=111 49=TW 50=user3 52=20091102-19:48:33.414
>>> > 56=ISLD
>>> > 128=BANK1 45=177 58=Tag appears more than once 371=15 372=X 373=13
>>> > 10=213
>>> > 8=FIX.4.4 9=75 35=1 34=112 49=TW 50=user3 52=20091102-19:48:36.283
>>> > 56=ISLD
>>> > 112=TEST 10=112
>>> > 8=FIX.4.4 9=71 35=0 49=ISLD 56=TW 34=178 52=20091102-19:48:33 57=user3
>>> > 112=TEST 10=176
>>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=179 52=20091102-19:48:34
>>> 115=BANK1
>>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63915
>>> > 15=USD
>>> > 271=10000 299=S.7809825/1102 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>>> > 271=10000 299=S.7809825/1102 10=182
>>> > 8=FIX.4.4 9=133 35=3 34=113 49=TW 50=user3 52=20091102-19:48:37.339
>>> > 56=ISLD
>>> > 128=BANK1 45=179 58=Tag appears more than once 371=15 372=X 373=13
>>> > 10=227
>>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=180 52=20091102-19:48:37
>>> 115=BANK1
>>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63905
>>> > 15=USD
>>> > 271=10000 299=S.7809825/1103 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>>> > 271=10000 299=S.7809825/1103 10=178
>>> > 8=FIX.4.4 9=133 35=3 34=114 49=TW 50=user3 52=20091102-19:48:40.364
>>> > 56=ISLD
>>> > 128=BANK1 45=180 58=Tag appears more than once 371=15 372=X 373=13
>>> > 10=212
>>> > --
>>> > View this message in context:
>>> >
>>> http://old.nabble.com/market-data-request-message-tp26193248p26193248.html
>>> > Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>>> >
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> > 30-Day
>>> > trial. Simplify your report design, integration and deployment - and
>>> > focus on
>>> > what you do best, core application coding. Discover what's new with
>>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> > _______________________________________________
>>> > Quickfix-developers mailing list
>>> > Qui...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>> >
>>
>>
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and focus
> on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 
> 

-- 
View this message in context: http://old.nabble.com/market-data-request-message-tp26193248p26230832.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] market data request message

[choudhry a. <ch...@gm...>]

Grant:
Thanks for your valued response.

Yes its form the program that sends MarketDataRequest. I can understand that
my program should be triggering toApp() when i send a message. Sorry if i
was unable to communicate well, I want to receive the response of
MarketDataRequest. for which i want fromApp to be get triggered. As i have
pasted my logs. i want to figure out that why i not receiving the response
form the FIX server .

Looking forward to your respons.

Thanks.
Asad.

On Thu, Nov 5, 2009 at 1:31 AM, Grant Birchmeier
<gbi...@co...>wrote:

> I think you have it backward.  The code you've pasted is from program
> that sends MarketDataRequest, right?  Your program SHOULD be
> triggering toApp(), and SHOULD NOT be triggering fromApp(), when it
> sends this message.
>
> toApp() is triggered by OUTGOING messages.  Read it as "to the other app".
>
> fromApp() is triggered by INCOMING messages.  Read it as "from the other
> app".
>
> Also, please look at this page:
> http://quickfixengine.org/quickfix/doc/html/sending_messages.html
> Your queryMarketDataRequest function should look at lot more like the
> "DO THIS!" example on the bottom.  You should not need to set fields
> directly on the header like you are.
>
> -Grant
>
>
> On Wed, Nov 4, 2009 at 3:05 PM, choudhry asad <ch...@gm...> wrote:
> > Grant:
> >
> > Thanks for the reply. I have looked in to it, but unable to figure out
> where
> > is the issue still toApp is getting invoked, instead of fromApp. Below is
> my
> > code for market data request message and the config file. If you can
> please
> > have a look in to it and suggest me where is the issue.
> >
> > code for market data request, toAPP, fromAPP and OnMessage :
> >
> > void Application::queryMarketDataRequest()
> > {
> >   std::cout << "\nMarketDataRequest\n";
> >
> >  FIX::Message message;
> >
> >
> >   FIX::MDReqID mdReqID( "MARKETDATAID" );
> >   FIX::SubscriptionRequestType subType(
> > FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES );
> >   FIX::MarketDepth marketDepth( 1 );
> >   FIX44::MarketDataRequest::NoMDEntryTypes marketDataEntryGroup;
> >   FIX::MDEntryType mdEntryType( FIX::MDEntryType_BID );
> >   FIX44::MarketDataRequest message( mdReqID, subType, marketDepth );
> >   marketDataEntryGroup.set( mdEntryType );
> >   message.addGroup( marketDataEntryGroup );
> >
> >
> >   FIX::MDEntryType mdEntryType1( FIX::MDEntryType_OFFER );
> >   marketDataEntryGroup.set( mdEntryType1 );
> >   message.addGroup( marketDataEntryGroup );
> >
> >  message.getHeader().setField(FIX::SenderCompID("TW"));
> >  message.getHeader().setField(FIX::TargetCompID("ISLD"));
> >  message.getHeader().setField(FIX::TargetSubID("qfstream"));
> >  message.getHeader().setField(FIX::SenderSubID("user3"));
> >  message.getHeader().setField(35, "V");
> >  message.getHeader().setField(265, "0");
> >  message.getHeader().setField(1, "ACCT1@TW");
> >
> >  message.getHeader().setField(146, "1");
> >  message.getHeader().setField(55, "GBP/USD");
> >  message.getHeader().setField(38, "10000");
> >  message.getHeader().setField(15, "USD");
> >  message.getHeader().setField(453, "1");
> >  message.getHeader().setField(108, "10");
> >  FIX::Session::sendToTarget( message,"FIXMDR" );
> > }
> >
> >
> > void
> >
> > Application::fromApp( const FIX::Message& message, const FIX::SessionID&
> > sessionID )
> >
> > throw
> >
> > ( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue,
> > FIX::UnsupportedMessageType )
> >
> > {
> >
> > crack( message, sessionID );
> >
> > std::cout << std::endl <<
> >
> > " formApp IN: " << message << std::endl;
> >
> > }
> >
> > void
> >
> > Application::toApp( FIX::Message& message, const FIX::SessionID&
> sessionID )
> >
> > throw
> >
> > ( FIX::DoNotSend )
> >
> > {
> >
> > try
> >
> > {
> >
> > FIX::PossDupFlag possDupFlag;
> >
> > message.getHeader().getField( possDupFlag );
> >
> > if ( possDupFlag ) throw FIX::DoNotSend();
> >
> > }
> >
> > catch ( FIX::FieldNotFound& ) {}
> >
> > std::cout << std::endl
> >
> > <<
> >
> > "toApp OUT: " << message << std::endl;
> >
> > }
> >
> > void
> >
> > Application::onMessage( const FIX44::MarketDataRequest& message, const
> > FIX::SessionID& id )
> >
> > {
> >
> > std::cout<<
> >
> > "\n in onMessage for marketdata "<<message<<std::endl<<message;
> >
> > }
> >
> > Here is the config file:
> >
> >
> > # default settings for sessions
> > [DEFAULT]
> > ConnectionType=initiator
> > ReconnectInterval=20
> > LogonTimeout=30
> > StartTime=00:00:00
> > EndTime=23:00:00
> > HeartBtInt=10
> > #SocketConnectHost=localhost
> > SocketConnectHost=127.0.0.1
> > SocketConnectPort=9000
> > FileLogPath=c:\qfixlogs\
> > FileStorePath=c:\qfixstore\
> > [SESSION]
> > BeginString=FIX.4.4
> > TargetCompID=ISLD
> > SessionQualifier=FIXMDR
> > TargetSubID=qfstream
> > SenderCompID=TW
> > SenderSubID=user3
> > RawData=1234567
> > HeartBtInt=10
> > FileLogPath=c:\qfixlogs\
> > FileStorePath=c:\qfixstore\
> > UseDataDictionary=N
> > DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml
> >
> > On Wed, Nov 4, 2009 at 8:31 PM, Grant Birchmeier <
> gbi...@co...>
> > wrote:
> >>
> >> It appears that app TW is sending out your MarketDataRequest just fine.
> >>
> >> It is rejecting the app ISLD's market data (35=X) response ("Tag
> >> appears more than once").
> >>
> >> Which app, TW or ISLD, are you asking about?  When an app receives a
> >> message, it triggers fromApp(), which should almost always call
> >> crack(), which will call onMessage(<type>).
> >>
> >> When an app sends a message, the message goes through toApp(), to give
> >> you a chance to intercept or abort the message.  Myself, I rarely have
> >> need to use this function.
> >>
> >> So, in your apps:
> >> 1) TW will invoke toApp() when it sends the MarketDataRequest.
> >> 2) When ISLD receives the MarketDataRequest, it will invoke fromApp(),
> >> then crack(), then onMessage(MarketDataRequest).
> >>
> >> -Grant
> >>
> >>
> >> On Wed, Nov 4, 2009 at 4:32 AM, ch...@gm... <ch...@gm...>
> >> wrote:
> >> > QuickFIX Documentation:
> >> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> >> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >> >
> >> >
> >> > Hi I want to send a market data request message .
> >> >
> >> > i the Application My fromApp and OnMessage is not getting invoked in
> >> > response to the message; instead ToApp is getting involed.
> >> > Below are logs please have a look and suggest my how to fix this
> >> > issue.............
> >> >
> >> > Thanks,
> >> > Asad
> >> >
> >> > 8=FIX.4.4 9=80 35=4 49=ISLD 56=TW 34=129 52=20091102-19:48:21 43=Y
> >> > 57=user3
> >> > 123=Y 36=175 10=010
> >> > 8=FIX.4.4 9=203 35=V 1=ACCT1@TW 15=USD 34=108 38=10000 49=TW 50=user3
> >> > 52=20091102-19:48:32.589 55=GBP/USD 56=ISLD 57=qfstream 108=10 146=1
> >> > 265=0
> >> > 448=BANK1 453=1 262=MARKETDATAID 263=1 264=1 267=2 269=0 269=1 10=152
> >> > 8=FIX.4.4 9=174 35=X 49=ISLD 56=TW 34=175 52=20091102-19:48:30
> 115=BANK1
> >> > 57=user3 262=MARKETDATAID 268=2 279=2 269=0 279=2 269=1 58=Provider
> >> > withdrawing customer from a shared stream. 10=194
> >> > 8=FIX.4.4 9=134 35=3 34=109 49=TW 50=user3 52=20091102-19:48:33.051
> >> > 56=ISLD
> >> > 128=BANK1 45=175 58=Tag appears more than once 371=269 372=X 373=13
> >> > 10=019
> >> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=176 52=20091102-19:48:30
> 115=BANK1
> >> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63935
> >> > 15=USD
> >> > 271=10000 299=S.7809825/1100 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> >> > 271=10000 299=S.7809825/1100 10=173
> >> > 8=FIX.4.4 9=133 35=3 34=110 49=TW 50=user3 52=20091102-19:48:33.270
> >> > 56=ISLD
> >> > 128=BANK1 45=176 58=Tag appears more than once 371=15 372=X 373=13
> >> > 10=211
> >> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=177 52=20091102-19:48:30
> 115=BANK1
> >> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63910
> >> > 15=USD
> >> > 271=10000 299=S.7809825/1101 279=0 269=0 55=GBP/USD 270=1.63890 15=USD
> >> > 271=10000 299=S.7809825/1101 10=165
> >> > 8=FIX.4.4 9=133 35=3 34=111 49=TW 50=user3 52=20091102-19:48:33.414
> >> > 56=ISLD
> >> > 128=BANK1 45=177 58=Tag appears more than once 371=15 372=X 373=13
> >> > 10=213
> >> > 8=FIX.4.4 9=75 35=1 34=112 49=TW 50=user3 52=20091102-19:48:36.283
> >> > 56=ISLD
> >> > 112=TEST 10=112
> >> > 8=FIX.4.4 9=71 35=0 49=ISLD 56=TW 34=178 52=20091102-19:48:33 57=user3
> >> > 112=TEST 10=176
> >> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=179 52=20091102-19:48:34
> 115=BANK1
> >> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63915
> >> > 15=USD
> >> > 271=10000 299=S.7809825/1102 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> >> > 271=10000 299=S.7809825/1102 10=182
> >> > 8=FIX.4.4 9=133 35=3 34=113 49=TW 50=user3 52=20091102-19:48:37.339
> >> > 56=ISLD
> >> > 128=BANK1 45=179 58=Tag appears more than once 371=15 372=X 373=13
> >> > 10=227
> >> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=180 52=20091102-19:48:37
> 115=BANK1
> >> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63905
> >> > 15=USD
> >> > 271=10000 299=S.7809825/1103 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> >> > 271=10000 299=S.7809825/1103 10=178
> >> > 8=FIX.4.4 9=133 35=3 34=114 49=TW 50=user3 52=20091102-19:48:40.364
> >> > 56=ISLD
> >> > 128=BANK1 45=180 58=Tag appears more than once 371=15 372=X 373=13
> >> > 10=212
> >> > --
> >> > View this message in context:
> >> >
> http://old.nabble.com/market-data-request-message-tp26193248p26193248.html
> >> > Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> >> > 30-Day
> >> > trial. Simplify your report design, integration and deployment - and
> >> > focus on
> >> > what you do best, core application coding. Discover what's new with
> >> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> > _______________________________________________
> >> > Quickfix-developers mailing list
> >> > Qui...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >> >
> >
> >
>

Re: [Quickfix-developers] Logout after Logon

[Dale W. <wi...@oc...>]

Fabio Renggli wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi together
>
> Can anybody tell me, why my quickfix engine sends automatically a logout response to the inititor when he sends a logon.
> thanks for your answers.
>   
Replying to a logon with a logout is the standard way to reject the 
logon.   There are many reasons why a login might fail.  Sometimes there 
will be a text field in the logout message that explains what went 
wrong.  You can also look in the logs for that session to see if there 
is a message there.

Dale


> Best regards.
> Fabio
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>   

[Quickfix-developers] Logout after Logon

[Fabio R. <FRe...@1e...>]

Hi together

Can anybody tell me, why my quickfix engine sends automatically a logout response to the inititor when he sends a logon.
thanks for your answers.

Best regards.
Fabio

Re: [Quickfix-developers] market data request message

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

I think you have it backward.  The code you've pasted is from program
that sends MarketDataRequest, right?  Your program SHOULD be
triggering toApp(), and SHOULD NOT be triggering fromApp(), when it
sends this message.

toApp() is triggered by OUTGOING messages.  Read it as "to the other app".

fromApp() is triggered by INCOMING messages.  Read it as "from the other app".

Also, please look at this page:
http://quickfixengine.org/quickfix/doc/html/sending_messages.html
Your queryMarketDataRequest function should look at lot more like the
"DO THIS!" example on the bottom.  You should not need to set fields
directly on the header like you are.

-Grant


On Wed, Nov 4, 2009 at 3:05 PM, choudhry asad <ch...@gm...> wrote:
> Grant:
>
> Thanks for the reply. I have looked in to it, but unable to figure out where
> is the issue still toApp is getting invoked, instead of fromApp. Below is my
> code for market data request message and the config file. If you can please
> have a look in to it and suggest me where is the issue.
>
> code for market data request, toAPP, fromAPP and OnMessage :
>
> void Application::queryMarketDataRequest()
> {
>   std::cout << "\nMarketDataRequest\n";
>
>  FIX::Message message;
>
>
>   FIX::MDReqID mdReqID( "MARKETDATAID" );
>   FIX::SubscriptionRequestType subType(
> FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES );
>   FIX::MarketDepth marketDepth( 1 );
>   FIX44::MarketDataRequest::NoMDEntryTypes marketDataEntryGroup;
>   FIX::MDEntryType mdEntryType( FIX::MDEntryType_BID );
>   FIX44::MarketDataRequest message( mdReqID, subType, marketDepth );
>   marketDataEntryGroup.set( mdEntryType );
>   message.addGroup( marketDataEntryGroup );
>
>
>   FIX::MDEntryType mdEntryType1( FIX::MDEntryType_OFFER );
>   marketDataEntryGroup.set( mdEntryType1 );
>   message.addGroup( marketDataEntryGroup );
>
>  message.getHeader().setField(FIX::SenderCompID("TW"));
>  message.getHeader().setField(FIX::TargetCompID("ISLD"));
>  message.getHeader().setField(FIX::TargetSubID("qfstream"));
>  message.getHeader().setField(FIX::SenderSubID("user3"));
>  message.getHeader().setField(35, "V");
>  message.getHeader().setField(265, "0");
>  message.getHeader().setField(1, "ACCT1@TW");
>
>  message.getHeader().setField(146, "1");
>  message.getHeader().setField(55, "GBP/USD");
>  message.getHeader().setField(38, "10000");
>  message.getHeader().setField(15, "USD");
>  message.getHeader().setField(453, "1");
>  message.getHeader().setField(108, "10");
>  FIX::Session::sendToTarget( message,"FIXMDR" );
> }
>
>
> void
>
> Application::fromApp( const FIX::Message& message, const FIX::SessionID&
> sessionID )
>
> throw
>
> ( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue,
> FIX::UnsupportedMessageType )
>
> {
>
> crack( message, sessionID );
>
> std::cout << std::endl <<
>
> " formApp IN: " << message << std::endl;
>
> }
>
> void
>
> Application::toApp( FIX::Message& message, const FIX::SessionID& sessionID )
>
> throw
>
> ( FIX::DoNotSend )
>
> {
>
> try
>
> {
>
> FIX::PossDupFlag possDupFlag;
>
> message.getHeader().getField( possDupFlag );
>
> if ( possDupFlag ) throw FIX::DoNotSend();
>
> }
>
> catch ( FIX::FieldNotFound& ) {}
>
> std::cout << std::endl
>
> <<
>
> "toApp OUT: " << message << std::endl;
>
> }
>
> void
>
> Application::onMessage( const FIX44::MarketDataRequest& message, const
> FIX::SessionID& id )
>
> {
>
> std::cout<<
>
> "\n in onMessage for marketdata "<<message<<std::endl<<message;
>
> }
>
> Here is the config file:
>
>
> # default settings for sessions
> [DEFAULT]
> ConnectionType=initiator
> ReconnectInterval=20
> LogonTimeout=30
> StartTime=00:00:00
> EndTime=23:00:00
> HeartBtInt=10
> #SocketConnectHost=localhost
> SocketConnectHost=127.0.0.1
> SocketConnectPort=9000
> FileLogPath=c:\qfixlogs\
> FileStorePath=c:\qfixstore\
> [SESSION]
> BeginString=FIX.4.4
> TargetCompID=ISLD
> SessionQualifier=FIXMDR
> TargetSubID=qfstream
> SenderCompID=TW
> SenderSubID=user3
> RawData=1234567
> HeartBtInt=10
> FileLogPath=c:\qfixlogs\
> FileStorePath=c:\qfixstore\
> UseDataDictionary=N
> DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml
>
> On Wed, Nov 4, 2009 at 8:31 PM, Grant Birchmeier <gbi...@co...>
> wrote:
>>
>> It appears that app TW is sending out your MarketDataRequest just fine.
>>
>> It is rejecting the app ISLD's market data (35=X) response ("Tag
>> appears more than once").
>>
>> Which app, TW or ISLD, are you asking about?  When an app receives a
>> message, it triggers fromApp(), which should almost always call
>> crack(), which will call onMessage(<type>).
>>
>> When an app sends a message, the message goes through toApp(), to give
>> you a chance to intercept or abort the message.  Myself, I rarely have
>> need to use this function.
>>
>> So, in your apps:
>> 1) TW will invoke toApp() when it sends the MarketDataRequest.
>> 2) When ISLD receives the MarketDataRequest, it will invoke fromApp(),
>> then crack(), then onMessage(MarketDataRequest).
>>
>> -Grant
>>
>>
>> On Wed, Nov 4, 2009 at 4:32 AM, ch...@gm... <ch...@gm...>
>> wrote:
>> > QuickFIX Documentation:
>> > http://www.quickfixengine.org/quickfix/doc/html/index.html
>> > QuickFIX Support: http://www.quickfixengine.org/services.html
>> >
>> >
>> > Hi I want to send a market data request message .
>> >
>> > i the Application My fromApp and OnMessage is not getting invoked in
>> > response to the message; instead ToApp is getting involed.
>> > Below are logs please have a look and suggest my how to fix this
>> > issue.............
>> >
>> > Thanks,
>> > Asad
>> >
>> > 8=FIX.4.4 9=80 35=4 49=ISLD 56=TW 34=129 52=20091102-19:48:21 43=Y
>> > 57=user3
>> > 123=Y 36=175 10=010
>> > 8=FIX.4.4 9=203 35=V 1=ACCT1@TW 15=USD 34=108 38=10000 49=TW 50=user3
>> > 52=20091102-19:48:32.589 55=GBP/USD 56=ISLD 57=qfstream 108=10 146=1
>> > 265=0
>> > 448=BANK1 453=1 262=MARKETDATAID 263=1 264=1 267=2 269=0 269=1 10=152
>> > 8=FIX.4.4 9=174 35=X 49=ISLD 56=TW 34=175 52=20091102-19:48:30 115=BANK1
>> > 57=user3 262=MARKETDATAID 268=2 279=2 269=0 279=2 269=1 58=Provider
>> > withdrawing customer from a shared stream. 10=194
>> > 8=FIX.4.4 9=134 35=3 34=109 49=TW 50=user3 52=20091102-19:48:33.051
>> > 56=ISLD
>> > 128=BANK1 45=175 58=Tag appears more than once 371=269 372=X 373=13
>> > 10=019
>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=176 52=20091102-19:48:30 115=BANK1
>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63935
>> > 15=USD
>> > 271=10000 299=S.7809825/1100 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>> > 271=10000 299=S.7809825/1100 10=173
>> > 8=FIX.4.4 9=133 35=3 34=110 49=TW 50=user3 52=20091102-19:48:33.270
>> > 56=ISLD
>> > 128=BANK1 45=176 58=Tag appears more than once 371=15 372=X 373=13
>> > 10=211
>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=177 52=20091102-19:48:30 115=BANK1
>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63910
>> > 15=USD
>> > 271=10000 299=S.7809825/1101 279=0 269=0 55=GBP/USD 270=1.63890 15=USD
>> > 271=10000 299=S.7809825/1101 10=165
>> > 8=FIX.4.4 9=133 35=3 34=111 49=TW 50=user3 52=20091102-19:48:33.414
>> > 56=ISLD
>> > 128=BANK1 45=177 58=Tag appears more than once 371=15 372=X 373=13
>> > 10=213
>> > 8=FIX.4.4 9=75 35=1 34=112 49=TW 50=user3 52=20091102-19:48:36.283
>> > 56=ISLD
>> > 112=TEST 10=112
>> > 8=FIX.4.4 9=71 35=0 49=ISLD 56=TW 34=178 52=20091102-19:48:33 57=user3
>> > 112=TEST 10=176
>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=179 52=20091102-19:48:34 115=BANK1
>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63915
>> > 15=USD
>> > 271=10000 299=S.7809825/1102 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>> > 271=10000 299=S.7809825/1102 10=182
>> > 8=FIX.4.4 9=133 35=3 34=113 49=TW 50=user3 52=20091102-19:48:37.339
>> > 56=ISLD
>> > 128=BANK1 45=179 58=Tag appears more than once 371=15 372=X 373=13
>> > 10=227
>> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=180 52=20091102-19:48:37 115=BANK1
>> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63905
>> > 15=USD
>> > 271=10000 299=S.7809825/1103 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
>> > 271=10000 299=S.7809825/1103 10=178
>> > 8=FIX.4.4 9=133 35=3 34=114 49=TW 50=user3 52=20091102-19:48:40.364
>> > 56=ISLD
>> > 128=BANK1 45=180 58=Tag appears more than once 371=15 372=X 373=13
>> > 10=212
>> > --
>> > View this message in context:
>> > http://old.nabble.com/market-data-request-message-tp26193248p26193248.html
>> > Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> > 30-Day
>> > trial. Simplify your report design, integration and deployment - and
>> > focus on
>> > what you do best, core application coding. Discover what's new with
>> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > Quickfix-developers mailing list
>> > Qui...@li...
>> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>> >
>
>

Re: [Quickfix-developers] market data request message

[choudhry a. <ch...@gm...>]

Grant:

Thanks for the reply. I have looked in to it, but unable to figure out where
is the issue still toApp is getting invoked, instead of fromApp. Below is my
code for market data request message and the config file. If you can please
have a look in to it and suggest me where is the issue.

code for market data request, toAPP, fromAPP and OnMessage :

void Application::queryMarketDataRequest()
{
  std::cout << "\nMarketDataRequest\n";


 FIX::Message message;


  FIX::MDReqID mdReqID( "MARKETDATAID" );
  FIX::SubscriptionRequestType subType(
FIX::SubscriptionRequestType_SNAPSHOT_PLUS_UPDATES );
  FIX::MarketDepth marketDepth( 1 );
  FIX44::MarketDataRequest::NoMDEntryTypes marketDataEntryGroup;
  FIX::MDEntryType mdEntryType( FIX::MDEntryType_BID );
  FIX44::MarketDataRequest message( mdReqID, subType, marketDepth );
  marketDataEntryGroup.set( mdEntryType );
  message.addGroup( marketDataEntryGroup );


  FIX::MDEntryType mdEntryType1( FIX::MDEntryType_OFFER );
  marketDataEntryGroup.set( mdEntryType1 );
  message.addGroup( marketDataEntryGroup );


 message.getHeader().setField(FIX::SenderCompID("TW"));
 message.getHeader().setField(FIX::TargetCompID("ISLD"));
 message.getHeader().setField(FIX::TargetSubID("qfstream"));
 message.getHeader().setField(FIX::SenderSubID("user3"));
 message.getHeader().setField(35, "V");
 message.getHeader().setField(265, "0");
 message.getHeader().setField(1, "ACCT1@TW");

 message.getHeader().setField(146, "1");
 message.getHeader().setField(55, "GBP/USD");
 message.getHeader().setField(38, "10000");
 message.getHeader().setField(15, "USD");
 message.getHeader().setField(453, "1");

 message.getHeader().setField(108, "10");
 FIX::Session::sendToTarget( message,"FIXMDR" );
}


void Application::fromApp( const FIX::Message& message,
constFIX::SessionID& sessionID )

throw( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue,
FIX::UnsupportedMessageType )

{

crack( message, sessionID );

std::cout << std::endl << " formApp IN: " << message << std::endl;

}

void Application::toApp( FIX::Message& message, const FIX::SessionID&
sessionID )

throw( FIX::DoNotSend )

{

try

{

FIX::PossDupFlag possDupFlag;

message.getHeader().getField( possDupFlag );

if ( possDupFlag ) throw FIX::DoNotSend();

}

catch ( FIX::FieldNotFound& ) {}

std::cout << std::endl

<< "toApp OUT: " << message << std::endl;

}

void Application::onMessage( const FIX44::MarketDataRequest& message,
constFIX::SessionID& id )

{

std::cout<<"\n in onMessage for marketdata "<<message<<std::endl<<message;

}

Here is the config file:


# default settings for sessions
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=20
LogonTimeout=30
StartTime=00:00:00
EndTime=23:00:00
HeartBtInt=10
#SocketConnectHost=localhost
SocketConnectHost=127.0.0.1
SocketConnectPort=9000
FileLogPath=c:\qfixlogs\
FileStorePath=c:\qfixstore\
[SESSION]
BeginString=FIX.4.4
TargetCompID=ISLD
SessionQualifier=FIXMDR
TargetSubID=qfstream
SenderCompID=TW
SenderSubID=user3
RawData=1234567
HeartBtInt=10
FileLogPath=c:\qfixlogs\
FileStorePath=c:\qfixstore\
UseDataDictionary=N
DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml

On Wed, Nov 4, 2009 at 8:31 PM, Grant Birchmeier
<gbi...@co...>wrote:

> It appears that app TW is sending out your MarketDataRequest just fine.
>
> It is rejecting the app ISLD's market data (35=X) response ("Tag
> appears more than once").
>
> Which app, TW or ISLD, are you asking about?  When an app receives a
> message, it triggers fromApp(), which should almost always call
> crack(), which will call onMessage(<type>).
>
> When an app sends a message, the message goes through toApp(), to give
> you a chance to intercept or abort the message.  Myself, I rarely have
> need to use this function.
>
> So, in your apps:
> 1) TW will invoke toApp() when it sends the MarketDataRequest.
> 2) When ISLD receives the MarketDataRequest, it will invoke fromApp(),
> then crack(), then onMessage(MarketDataRequest).
>
> -Grant
>
>
> On Wed, Nov 4, 2009 at 4:32 AM, ch...@gm... <ch...@gm...>
> wrote:
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> >
> > Hi I want to send a market data request message .
> >
> > i the Application My fromApp and OnMessage is not getting invoked in
> > response to the message; instead ToApp is getting involed.
> > Below are logs please have a look and suggest my how to fix this
> > issue.............
> >
> > Thanks,
> > Asad
> >
> > 8=FIX.4.4 9=80 35=4 49=ISLD 56=TW 34=129 52=20091102-19:48:21 43=Y
> 57=user3
> > 123=Y 36=175 10=010
> > 8=FIX.4.4 9=203 35=V 1=ACCT1@TW 15=USD 34=108 38=10000 49=TW 50=user3
> > 52=20091102-19:48:32.589 55=GBP/USD 56=ISLD 57=qfstream 108=10 146=1
> 265=0
> > 448=BANK1 453=1 262=MARKETDATAID 263=1 264=1 267=2 269=0 269=1 10=152
> > 8=FIX.4.4 9=174 35=X 49=ISLD 56=TW 34=175 52=20091102-19:48:30 115=BANK1
> > 57=user3 262=MARKETDATAID 268=2 279=2 269=0 279=2 269=1 58=Provider
> > withdrawing customer from a shared stream. 10=194
> > 8=FIX.4.4 9=134 35=3 34=109 49=TW 50=user3 52=20091102-19:48:33.051
> 56=ISLD
> > 128=BANK1 45=175 58=Tag appears more than once 371=269 372=X 373=13
> 10=019
> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=176 52=20091102-19:48:30 115=BANK1
> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63935 15=USD
> > 271=10000 299=S.7809825/1100 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> > 271=10000 299=S.7809825/1100 10=173
> > 8=FIX.4.4 9=133 35=3 34=110 49=TW 50=user3 52=20091102-19:48:33.270
> 56=ISLD
> > 128=BANK1 45=176 58=Tag appears more than once 371=15 372=X 373=13 10=211
> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=177 52=20091102-19:48:30 115=BANK1
> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63910 15=USD
> > 271=10000 299=S.7809825/1101 279=0 269=0 55=GBP/USD 270=1.63890 15=USD
> > 271=10000 299=S.7809825/1101 10=165
> > 8=FIX.4.4 9=133 35=3 34=111 49=TW 50=user3 52=20091102-19:48:33.414
> 56=ISLD
> > 128=BANK1 45=177 58=Tag appears more than once 371=15 372=X 373=13 10=213
> > 8=FIX.4.4 9=75 35=1 34=112 49=TW 50=user3 52=20091102-19:48:36.283
> 56=ISLD
> > 112=TEST 10=112
> > 8=FIX.4.4 9=71 35=0 49=ISLD 56=TW 34=178 52=20091102-19:48:33 57=user3
> > 112=TEST 10=176
> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=179 52=20091102-19:48:34 115=BANK1
> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63915 15=USD
> > 271=10000 299=S.7809825/1102 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> > 271=10000 299=S.7809825/1102 10=182
> > 8=FIX.4.4 9=133 35=3 34=113 49=TW 50=user3 52=20091102-19:48:37.339
> 56=ISLD
> > 128=BANK1 45=179 58=Tag appears more than once 371=15 372=X 373=13 10=227
> > 8=FIX.4.4 9=237 35=X 49=ISLD 56=TW 34=180 52=20091102-19:48:37 115=BANK1
> > 57=user3 262=MARKETDATAID 268=2 279=0 269=1 55=GBP/USD 270=1.63905 15=USD
> > 271=10000 299=S.7809825/1103 279=0 269=0 55=GBP/USD 270=1.63885 15=USD
> > 271=10000 299=S.7809825/1103 10=178
> > 8=FIX.4.4 9=133 35=3 34=114 49=TW 50=user3 52=20091102-19:48:40.364
> 56=ISLD
> > 128=BANK1 45=180 58=Tag appears more than once 371=15 372=X 373=13 10=212
> > --
> > View this message in context:
> http://old.nabble.com/market-data-request-message-tp26193248p26193248.html
> > Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>

Re: [Quickfix-developers] Messagecreation

[Fabio R. <FRe...@1e...>]

Thank you. It works like this.

Regards
Fabio

________________________________________
Von: Kenny Stone [ks...@co...]
Gesendet: Mittwoch, 4. November 2009 16:54
An: qui...@li...
Betreff: Re: [Quickfix-developers] Messagecreation

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Re: [Quickfix-developers] Messagecreation

[Kenny S. <ks...@co...>]

You need to use a DataDictionary when constructing the message.

Message( const std::string& string, const FIX::DataDictionary&
dataDictionary, bool validate = true )

--
Kenny Stone
Connamara Systems, LLC


On Wed, Nov 4, 2009 at 9:49 AM, Fabio Renggli <FRe...@1e...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> yes and that's the problem: look at this: 146=1?55=101337?167=PUT? this
> string is ok. because 146 says that a repeating group starts and 55 is the
> starttag in this group. but in the new message there it looks like this:
> 146=1?167=PUT?206=E?225= and the tag 55 is just at the beginning of the
> message.
>
> regards.
> ________________________________________
> Von: Grant Birchmeier [gbi...@co...]
> Gesendet: Mittwoch, 4. November 2009 16:40
> An: Fabio Renggli
> Cc: Mikhail Veygman; qui...@li...
> Betreff: Re: [Quickfix-developers] Messagecreation
>
> How does the fixstring not work?  The strings should be
> FIX-equivalent.  FIX doesn't care about order except in repeating
> groups.
>
>
> On Wed, Nov 4, 2009 at 10:29 AM, Fabio Renggli <FRe...@1e...>
> wrote:
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > So there is no way to create a message from an existing and valid
> fixstring without getting a crap of a fixstring which doesn't work?
> >
> > ________________________________________
> > Von: Mikhail Veygman [mve...@gm...]
> > Gesendet: Mittwoch, 4. November 2009 16:25
> > An: Fabio Renggli
> > Cc: qui...@li...
> > Betreff: Re: [Quickfix-developers] Messagecreation
> >
> > If you notice all the fields after the header are in numeric order.
> > In general it is easier to process this when you have them in some sort
> > of order especially if the internal structures can be represented as
> > arrays and use the field numbers as indexes.
> > -
> > Regards,
> >
> > Mikhail Veygman
> >
> >
> > -----Original Message-----
> > From: Fabio Renggli <FRe...@1e...>
> > To: qui...@li...
> > <qui...@li...>
> > Subject: [Quickfix-developers] Messagecreation
> > Date: Wed, 4 Nov 2009 16:06:35 +0100
> >
> > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi
> >
> > I try to create a message like this:
> >
> > Message message = new Message(string FixString);
> >
> > As FixString I put:
> >
> >
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:00:03.565?56=Merrill?131=1?146=1?55=101337?167=PUT?541=20101101?225=20091104?240=20101108?206=E?711=1?311=ABBN.VX?457=1?458=CH0012221716?459=I-?462=1?316=120?941=CHF?308=XSWX?318=CHF?10025=1?10060=1?303=1?537=1?54=2?854=0?38=25000?64=20091109?15=CHF?232=1?233=ISDAREF?234=1235465?735=1?695=B?692=3?62=20091030-14:30:50?453=2?448=VON?447=D?452=7?448=MER?447=D?452=17?5508=1?10001=0?10005=0?10010=0?10=227?
> >
> >
> >
> >
> > And the afterwards sended message looks like this:
> >
> >
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:01:00.676?56=Merrill?15=CHF?38=25000?54=2?55=101337?62=20091030-14:30:50?64=20091109?131=1?146=1?167=PUT?206=E?225=20091104?232=1?233=ISDAREF?234=1235465?240=20101108?303=1?308=XSWX?311=ABBN.VX?316=120?318=CHF?447=D?447=D?448=VON?448=MER?452=7?452=17?453=2?457=1?458=CH0012221716?459=I-?462=1?537=1?541=20101101?692=3?695=B?711=1?735=1?854=0?941=CHF?5508=1?10001=0?10005=0?10010=0?10025=1?10060=1?10=228?
> >
> > So there the same information in it, but in a totally different order.
> > Can anybody explain me why this happens?
> >
> > Best Regards
> > Fabio
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________ Quickfix-developers
> mailing list Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> > trial. Simplify your report design, integration and deployment - and
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Messagecreation

[Fabio R. <FRe...@1e...>]

yes and that's the problem: look at this: 146=1?55=101337?167=PUT? this string is ok. because 146 says that a repeating group starts and 55 is the starttag in this group. but in the new message there it looks like this: 146=1?167=PUT?206=E?225= and the tag 55 is just at the beginning of the message.

regards.
________________________________________
Von: Grant Birchmeier [gbi...@co...]
Gesendet: Mittwoch, 4. November 2009 16:40
An: Fabio Renggli
Cc: Mikhail Veygman; qui...@li...
Betreff: Re: [Quickfix-developers] Messagecreation

How does the fixstring not work?  The strings should be
FIX-equivalent.  FIX doesn't care about order except in repeating
groups.


On Wed, Nov 4, 2009 at 10:29 AM, Fabio Renggli <FRe...@1e...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> So there is no way to create a message from an existing and valid fixstring without getting a crap of a fixstring which doesn't work?
>
> ________________________________________
> Von: Mikhail Veygman [mve...@gm...]
> Gesendet: Mittwoch, 4. November 2009 16:25
> An: Fabio Renggli
> Cc: qui...@li...
> Betreff: Re: [Quickfix-developers] Messagecreation
>
> If you notice all the fields after the header are in numeric order.
> In general it is easier to process this when you have them in some sort
> of order especially if the internal structures can be represented as
> arrays and use the field numbers as indexes.
> -
> Regards,
>
> Mikhail Veygman
>
>
> -----Original Message-----
> From: Fabio Renggli <FRe...@1e...>
> To: qui...@li...
> <qui...@li...>
> Subject: [Quickfix-developers] Messagecreation
> Date: Wed, 4 Nov 2009 16:06:35 +0100
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi
>
> I try to create a message like this:
>
> Message message = new Message(string FixString);
>
> As FixString I put:
>
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:00:03.565?56=Merrill?131=1?146=1?55=101337?167=PUT?541=20101101?225=20091104?240=20101108?206=E?711=1?311=ABBN.VX?457=1?458=CH0012221716?459=I-?462=1?316=120?941=CHF?308=XSWX?318=CHF?10025=1?10060=1?303=1?537=1?54=2?854=0?38=25000?64=20091109?15=CHF?232=1?233=ISDAREF?234=1235465?735=1?695=B?692=3?62=20091030-14:30:50?453=2?448=VON?447=D?452=7?448=MER?447=D?452=17?5508=1?10001=0?10005=0?10010=0?10=227?
>
>
>
>
> And the afterwards sended message looks like this:
>
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:01:00.676?56=Merrill?15=CHF?38=25000?54=2?55=101337?62=20091030-14:30:50?64=20091109?131=1?146=1?167=PUT?206=E?225=20091104?232=1?233=ISDAREF?234=1235465?240=20101108?303=1?308=XSWX?311=ABBN.VX?316=120?318=CHF?447=D?447=D?448=VON?448=MER?452=7?452=17?453=2?457=1?458=CH0012221716?459=I-?462=1?537=1?541=20101101?692=3?695=B?711=1?735=1?854=0?941=CHF?5508=1?10001=0?10005=0?10010=0?10025=1?10060=1?10=228?
>
> So there the same information in it, but in a totally different order.
> Can anybody explain me why this happens?
>
> Best Regards
> Fabio
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Messagecreation

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

How does the fixstring not work?  The strings should be
FIX-equivalent.  FIX doesn't care about order except in repeating
groups.


On Wed, Nov 4, 2009 at 10:29 AM, Fabio Renggli <FRe...@1e...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> So there is no way to create a message from an existing and valid fixstring without getting a crap of a fixstring which doesn't work?
>
> ________________________________________
> Von: Mikhail Veygman [mve...@gm...]
> Gesendet: Mittwoch, 4. November 2009 16:25
> An: Fabio Renggli
> Cc: qui...@li...
> Betreff: Re: [Quickfix-developers] Messagecreation
>
> If you notice all the fields after the header are in numeric order.
> In general it is easier to process this when you have them in some sort
> of order especially if the internal structures can be represented as
> arrays and use the field numbers as indexes.
> -
> Regards,
>
> Mikhail Veygman
>
>
> -----Original Message-----
> From: Fabio Renggli <FRe...@1e...>
> To: qui...@li...
> <qui...@li...>
> Subject: [Quickfix-developers] Messagecreation
> Date: Wed, 4 Nov 2009 16:06:35 +0100
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi
>
> I try to create a message like this:
>
> Message message = new Message(string FixString);
>
> As FixString I put:
>
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:00:03.565?56=Merrill?131=1?146=1?55=101337?167=PUT?541=20101101?225=20091104?240=20101108?206=E?711=1?311=ABBN.VX?457=1?458=CH0012221716?459=I-?462=1?316=120?941=CHF?308=XSWX?318=CHF?10025=1?10060=1?303=1?537=1?54=2?854=0?38=25000?64=20091109?15=CHF?232=1?233=ISDAREF?234=1235465?735=1?695=B?692=3?62=20091030-14:30:50?453=2?448=VON?447=D?452=7?448=MER?447=D?452=17?5508=1?10001=0?10005=0?10010=0?10=227?
>
>
>
>
> And the afterwards sended message looks like this:
>
> 8=FIX.4.4?9=434?35=R?34=1?49=Vontobel?52=20091104-15:01:00.676?56=Merrill?15=CHF?38=25000?54=2?55=101337?62=20091030-14:30:50?64=20091109?131=1?146=1?167=PUT?206=E?225=20091104?232=1?233=ISDAREF?234=1235465?240=20101108?303=1?308=XSWX?311=ABBN.VX?316=120?318=CHF?447=D?447=D?448=VON?448=MER?452=7?452=17?453=2?457=1?458=CH0012221716?459=I-?462=1?537=1?541=20101101?692=3?695=B?711=1?735=1?854=0?941=CHF?5508=1?10001=0?10005=0?10010=0?10025=1?10060=1?10=228?
>
> So there the same information in it, but in a totally different order.
> Can anybody explain me why this happens?
>
> Best Regards
> Fabio
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>