quickfix-developers — QuickFIX developers forum

[Quickfix-developers] error in included SQL script

[Andrew M. <an...@nm...>]

Looks like messages_log_table.sql is creating the wrong table name.


C:\quickfix\src\sql\mysql>more messages_log_table.sql
USE quickfix;
DROP TABLE IF EXISTS messages_log;
CREATE TABLE incoming_log (
   id INT UNSIGNED NOT NULL AUTO_INCREMENT,
   time DATETIME NOT NULL,
   beginstring CHAR(8) NOT NULL,
   sendercompid VARCHAR(64) NOT NULL,
   targetcompid VARCHAR(64) NOT NULL,
   session_qualifier VARCHAR(64) NOT NULL,
   text BLOB NOT NULL,
   PRIMARY KEY (id)
);

[Quickfix-developers] source for 15 minute delayed quotes

[Clark S. <cla...@ya...>]

I would like to build an order matching engine, for simulating real time trading with fix clients in the development stages.

I would like to make this engine available to anyone who registers a testing account with me. This will be a free service.

I have tried the order matching / testing engines at SLK, Arca, and two other firms. All of them fall short.

I would like to have bids and offers which reflect the market conditions delayed by 15 minutes, so that all information is considered public information, and I don't have to worry about disseminating prices.

What is a good source of 15 minute delayed data?

		
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

Re: [Quickfix-developers] RE: Request resend

[Caleb E. <cal...@gm...>]

On 4/12/06, Fad <s.f...@gm...> wrote:
>
> The problem has resolved.
> In toApp method of my Application I worte code like that present in the
> QuickFix examples  :
>
> void KCApplication::toApp( FIX::Message& message, const FIX::SessionID&
> sessionID )
> throw( FIX::DoNotSend )
> {
> try
>   {
>     FIX::PossDupFlag possDupFlag;
>     message.getHeader().getField( possDupFlag );
>     if ( possDupFlag )
>         {
>                 throw FIX::DoNotSend();
>         }
>   }


This is at least the second time I can recall someone has been bitten by
copying this example code.  I'm going to remove that check for possDupFlag.
I've removed this section of Application::toApp from the example program to
hopefully prevent future misunderstandings like this.


> this code don't work properly, I replace that code with this and all is
> ok:


The code works exactly as it should.  It doesn't process messages with the
PossDup flag set.  This is arguably dumb, but it works exactly as designed.

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] RE: Request resend

[Fad <s.f...@gm...>]

The problem has resolved. 
In toApp method of my Application I worte code like that present in the
QuickFix examples  :

void KCApplication::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& ) {}

 if (m_ApptoApp)
	m_ApptoApp(appdata,(void *)&message,(void *)&sessionID);
}

this code don't work properly, I replace that code with this and all is ok:

void KCApplication::toApp( FIX::Message& message, const FIX::SessionID&
sessionID )
throw( FIX::DoNotSend )
{
 if (m_ApptoApp)
	m_ApptoApp(appdata,(void *)&message,(void *)&sessionID);
}


Thank you to all for the help that you have given me.
Stefano.
--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3881004
Sent from the QuickFIX - Dev forum at Nabble.com.

RE: [Quickfix-developers] Processing missed messages

[Robin S. <Rob...@re...>]

Steve,
=20
thanks for the clarification on expected behaviour. You are correct,
turns out the 're-sync' code was added outside of quickfix as a
work-around for another system. Without it I do see the missed messages.
=20
Thanks again for the reply.
=20
-Robin

________________________________

From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: 12 April 2006 09:34
To: qui...@li...
Subject: RE: [Quickfix-developers] Processing missed messages


Hi Rob,
=20
Generally speaking, you should be have received 205 and 206 (assuming
they are not admin messages). The log output you sent indicated QFJ was
requesting messages to be resent starting at 207. I would have expected
it to request a resend for 205 to 0 (infinity). Where is the log message
"Re-Sync Target MsgSeqNum to 207" coming from? It doesn't appear to be a
log message from the QFJ session.
=20
Steve


________________________________

	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Robin Scott
	Sent: Wednesday, April 12, 2006 1:29 AM
	To: qui...@li...
	Subject: [Quickfix-developers] Processing missed messages
=09
=09
	Hi,
	=20
	working with QuickFixJ 1.0.0b3. I have a scenario where quickfix
is not behaving as I would expect it to, would appreciate comment on
whether my expectation is reasonable.
	=20
	1. starting at an arbitary point in the session, my application
receives message seq nums 205 and 206 in rapid succession from the
target such that they have been received by the quickfixj comms code but
NOT yet posted to my application.
	=20
	2. message number 205 is posted to my application in fromApp
	=20
	3. while processing 205 my application dies
	=20
	4. the application is restarted and it receives a logon from the
target with seqnum of 207. I observe the following in the console :
	=20
	11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Received logon response
	11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x MsgSeqNum too high, expecting 205 but
received 207
	11/04/06 22:21:29.807 GMT [QFJ Socket Acceptor 131303f] FIX
Event : Re-Sync Target MsgSeqNum to 207
	11/04/06 22:21:29.838 GMT [QFJ Socket Acceptor 131303f] FIX
toAdmin  : FIX.4.2:J75515N->x ResendRequest ...
	11/04/06 22:21:29.988 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Sent ResendRequest FROM: 207 TO: 0
	=20
	indicating quickfix on behalf of my application has requested
the missing messages. All great so far.
	=20
	5. The next I see however in the console is :
	=20
	11/04/06 22:21:30.338 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Processing QUEUED message: 207
=09
	because quickfix has worked through the resent messages and
caught up with where the target system expects it to be.
	=20
	My problem with this is that my application did not get a chance
to process 205 again (it never completed the first time) and never even
got to see 206. I would have hoped that quickfix would act like a
message queue implementation in this case and ensure that the
application layer got to see every message at least once and in order.
	=20
	I have looked through the source and, although I haven't
debugged the above, it looks like isTargetTooLow->doTargetTooLow in
Session.verify(...) could be responsible for swallowing these messages.
It looks deliberate though, anyone help me by explaining why?
	=20
	-Rob
=09
=09
	To find out more about Reuters visit www.about.reuters.com
=09
	Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views
of Reuters Ltd.
=09



To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, exc=
ept where the sender specifically states them to be the views of Reuters Lt=
d.

RE: [Quickfix-developers] Processing missed messages

[Steve B. <sb...@sm...>]

Hi Rob,
=20
Generally speaking, you should be have received 205 and 206 (assuming
they are not admin messages). The log output you sent indicated QFJ was
requesting messages to be resent starting at 207. I would have expected
it to request a resend for 205 to 0 (infinity). Where is the log message
"Re-Sync Target MsgSeqNum to 207" coming from? It doesn't appear to be a
log message from the QFJ session.
=20
Steve


________________________________

	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Robin Scott
	Sent: Wednesday, April 12, 2006 1:29 AM
	To: qui...@li...
	Subject: [Quickfix-developers] Processing missed messages
=09
=09
	Hi,
	=20
	working with QuickFixJ 1.0.0b3. I have a scenario where quickfix
is not behaving as I would expect it to, would appreciate comment on
whether my expectation is reasonable.
	=20
	1. starting at an arbitary point in the session, my application
receives message seq nums 205 and 206 in rapid succession from the
target such that they have been received by the quickfixj comms code but
NOT yet posted to my application.
	=20
	2. message number 205 is posted to my application in fromApp
	=20
	3. while processing 205 my application dies
	=20
	4. the application is restarted and it receives a logon from the
target with seqnum of 207. I observe the following in the console :
	=20
	11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Received logon response
	11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x MsgSeqNum too high, expecting 205 but
received 207
	11/04/06 22:21:29.807 GMT [QFJ Socket Acceptor 131303f] FIX
Event : Re-Sync Target MsgSeqNum to 207
	11/04/06 22:21:29.838 GMT [QFJ Socket Acceptor 131303f] FIX
toAdmin  : FIX.4.2:J75515N->x ResendRequest ...
	11/04/06 22:21:29.988 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Sent ResendRequest FROM: 207 TO: 0
	=20
	indicating quickfix on behalf of my application has requested
the missing messages. All great so far.
	=20
	5. The next I see however in the console is :
	=20
	11/04/06 22:21:30.338 GMT [QFJ Socket Acceptor 131303f] FIX
Event    : FIX.4.2:J75515N->x Processing QUEUED message: 207
=09
	because quickfix has worked through the resent messages and
caught up with where the target system expects it to be.
	=20
	My problem with this is that my application did not get a chance
to process 205 again (it never completed the first time) and never even
got to see 206. I would have hoped that quickfix would act like a
message queue implementation in this case and ensure that the
application layer got to see every message at least once and in order.
	=20
	I have looked through the source and, although I haven't
debugged the above, it looks like isTargetTooLow->doTargetTooLow in
Session.verify(...) could be responsible for swallowing these messages.
It looks deliberate though, anyone help me by explaining why?
	=20
	-Rob
=09
=09
	To find out more about Reuters visit www.about.reuters.com
=09
	Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be the views
of Reuters Ltd.
=09

Re: [Quickfix-developers] RE: Request resend

[Fad <s.f...@gm...>]

Oren Miller wrote:
> 
> If you really really must do this (do you?  really?), then you will need 
> to lower the clients expected sequence number in order to trick QuickFIX 
> into passing those messages to you again.  So if you want to get message 
> 90-current, lower your expected sequence number to 90, then send your 
> ResendRequest.
> 
> Please keep in mind that QuickFIX is a messaging protocol, not an OMS.  
> You must take responsibility to persist any data you want to keep around.
> 

Ok, I have understood that QuickFix is a messaging protocol, but I try to
decrease the clients expected sequence number. When client has started,
automatically send to server a ResendRequest but the server send a
sequenceReset-GapFill instead all the 'lost messagges'.

It is correct..?

Thanks,
Stefano
--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877509
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] RE: Request resend

[Oren M. <or...@qu...>]

Because you have already received those messages.  ResendRequests are 
designed for use by the protocol to ensure message delivery.  They are 
*not* designed for you to repopulate your data structures.  When you 
send a query out for messages, QuickFIX knows it has already processed 
and passed them on to you, it will not pass them to you again.  An 
engine must guarantee that all messages are delivered in order.  If you 
have already processed message 100, and you ask for messages 90-99, 
QuickFIX would be breaking that guarantee by passing you messages out of 
order, and messages you have already processed to boot.

If you really really must do this (do you?  really?), then you will need 
to lower the clients expected sequence number in order to trick QuickFIX 
into passing those messages to you again.  So if you want to get message 
90-current, lower your expected sequence number to 90, then send your 
ResendRequest.

Please keep in mind that QuickFIX is a messaging protocol, not an OMS.  
You must take responsibility to persist any data you want to keep around.

--oren

Fad wrote:

>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>I have checked and the messages are present in the MessageStore. 
>The messages that I expect to receive are of type: "ExecutionReport"
>(Application message)
>My application uses FileStore.
>
>The message aren't resend by QuickFix engine.. Why?
>
>
>
>--
>View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877118
>Sent from the QuickFIX - Dev forum at Nabble.com.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>  
>

Re: [Quickfix-developers] RE: Request resend

[Fad <s.f...@gm...>]

Yes, I'm sure.. The messages ara Application messages.

Stefano.
--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877148
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] RE: Request resend

[Fad <s.f...@gm...>]

I have checked and the messages are present in the MessageStore. 
The messages that I expect to receive are of type: "ExecutionReport"
(Application message)
My application uses FileStore.

The message aren't resend by QuickFix engine.. Why?



--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3877118
Sent from the QuickFIX - Dev forum at Nabble.com.

[Quickfix-developers] frustrating "problem" with Resend Request

[Shawn Y. <sya...@ge...>]

I'm dealing with an exchange that uses a broken FIX.4.2
implementation.  After working around some issues, I'm
stuck on this one.

The exchange believes that every exchange message
following a gap in the sequence numbers should trigger
a Resend Request from my client, apparently until the
gap has been fully resent.

QuickFIX has code in file Session.cpp, member function
Session::doTargetTooHigh(), around line 1500, to
prevent exactly the redundant Resend Requests that
this exchange requires.

I believe QuickFIX is correct, but is there an easy way
for me to workaround this behavior so that QuickFIX
will send the redundant Resend Requests?

Logs included below so you can see what I'm talking
about.  The missing messages are numbered 6, 7, and 8.
They all get properly resent by the exchange even with
my client only sending a single Resend Request (third
message in the log below).

The exchange believes the fourth message in the log
(exchange message numbered 10) should trigger another
Resend Request even though as you can see the bottom
three messages are the successfully-resent messages
coming in.  The exchange doesn't look like they are
going to budge even though QuickFIX probably knows
better than they do what's correct.

If anyone can suggest an easy workaround not
requiring changes to QuickFIX code, I could really
use it.



20060412-00:08:15 : Created session
20060412-00:08:15 : Connecting to 10.1.63.82 on port 7001
20060412-00:08:15 : Connection succeeded
20060412-00:08:15 : Initiated logon request
20060412-00:08:21 : Received logon response
20060412-00:08:21 : MsgSeqNum too high, expecting 6 but received 9
20060412-00:08:21 : Sent ResendRequest FROM: 6 TO: 0
20060412-00:08:21 : MsgSeqNum too high, expecting 6 but received 10
20060412-00:08:21 : Already sent ResendRequest FROM: 6 TO: 8. Not =
sending another.
20060412-00:08:25 : ResendRequest for messages FROM: 6 TO: 8 has been =
satisfied.



8=3DFIX.4.2|9=3D98|35=3DA|34=3D6|49=3DJ79519N|50=3DLZL|52=3D20060412-00:0=
8:15.899|56=3DCME|57=3DG|142=3D3|95=3D6|96=3D???|98=3D0|108=3D30|10=3D102=
|

8=3DFIX.4.2|9=3D79|35=3DA|49=3DCME|56=3DJ79519N|52=3D20060412-00:08:21|34=
=3D9|369=3D6|50=3DG|57=3DLZL|108=3D30|98=3D0|10=3D080|

8=3DFIX.4.2|9=3D80|35=3D2|34=3D7|49=3DJ79519N|50=3DLZL|52=3D20060412-00:0=
8:21.304|56=3DCME|57=3DG|142=3D3|7=3D6|16=3D0|10=3D085|

8=3DFIX.4.2|9=3D86|35=3D1|49=3DCME|56=3DJ79519N|52=3D20060412-00:08:21|34=
=3D10|369=3D6|50=3DG|57=3DLZL|112=3D1144800501323|10=3D175|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D6|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000C|17=3D0020060411080743TN0064|20=3D0|31=3D102975|32=3D1|37=3D200604110=
034|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:07:43|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000C|10=3D096|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D7|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000D|17=3D0020060411080751TN0066|20=3D0|31=3D102975|32=3D1|37=3D200604110=
035|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:07:51|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000D|10=3D100|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D8|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000E|17=3D0020060411080800TN0068|20=3D0|31=3D102975|32=3D1|37=3D200604110=
036|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:08:00|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000E|10=3D096|



Thanks,

Shawn Yarbrough
Senior E-Trading Developer
Gelber Group, LLC
sya...@ge...

Re: [Quickfix-developers] (no subject)

[Oren M. <or...@qu...>]

Yeah, I've implemented this sort of thing for market data projects  
(not sure where it is at the moment unfortunately).  It would  
probably be useful to distribute such a thing with quickfix.

If you don't care about overhead (either memory or disk writes), then  
you can use either of those stores if you use the ResetOnDisconnect  
and ResetOnLogout settings.  These will make sure your sequence  
numbers get reset to 1 no matter what store you use.  If you are  
worried about the overhead, then what should work would be to  
implement some sort of NullStore which implements the sequence/ 
creation time methods like the memory store.  Then just make the set 
() method do nothing, and have the get() method always return an  
empty vector.  Then using those two configuration settings you should  
get the effect you are looking for.

--oren

On Apr 11, 2006, at 7:23 PM, Brendan Boerner wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> In our application using QuickFIX I'm creating a FIX 4.2 server which
> will send MarketDataSnapshotFullRefresh messages to a client.
>
> In this application we don't wish to store messages if the client is
> disconnected - the client will simply receive current
> MarketDataSnapshotFullRefresh messages as become available after it
> connects, restarting with MsgSeqNum=1.
>
> I didn't see anything in {File,Memory}MessageStore which would
> implement this.  I wanted to check w/the list to see if I'll need to
> implement my own implementation of MessageStoreFactory and
> MessageStore or have I overlooked something?
>
> Regards,
> Brendan
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] (no subject)

[Brendan B. <br...@ka...>]

Hi,

In our application using QuickFIX I'm creating a FIX 4.2 server which
will send MarketDataSnapshotFullRefresh messages to a client.

In this application we don't wish to store messages if the client is
disconnected - the client will simply receive current
MarketDataSnapshotFullRefresh messages as become available after it
connects, restarting with MsgSeqNum=1.

I didn't see anything in {File,Memory}MessageStore which would
implement this.  I wanted to check w/the list to see if I'll need to
implement my own implementation of MessageStoreFactory and
MessageStore or have I overlooked something?

Regards,
Brendan

Re: [Quickfix-developers] Problems building applications (not quickfix itself) using XCode / OS X

[Brian C. <co...@oc...>]

I successfully tried a minimal project using XCode 2.2 (gcc 3.3 and  
4.0). I also turned off zerolink and added "-lquickfix" to "Other  
Linker Flags".

Brian Coyner
Object Computing, Inc.



On Apr 11, 2006, at 6:35 PM, Oren Miller wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I just tried creating a new XCode project (I'm still on version  
> 2.0).  I put in bare code to create a simple QuickFIX initiator.
>
> The only two settings I changed are setting ZeroLink to false, and  
> adding -lquickfix to Other Linker Flags (is this where you did  
> it).  I was then able to run the application.
>
> --oren
>
> Derrick Johnson wrote:
>
>> Tiger 10.4.6
>> G5 / 1.8GHz / 1GB RAM
>> XCode 2.2
>>
>> I followed the directions and did the following with no errors at  
>> all (w00t):
>>
>> 1. Built and installed libquickfix.dylib and libquickfix.la  (the  
>> install script automatically put them in /usr/bin/local and I made  
>> sure I was root to do this step)
>>
>> 2. Built (using make) their tests (runut and runat and  
>> runat_threaded).  All worked 100% with no errors.
>>
>> 3. Build (using make) their examples and ran them.  Again, no  
>> errors at all.
>>
>> ============= Problem starts here ===============
>>
>> I created my own code snippet (C++ command line tool was the  
>> project type I used in Xcode).  I then added the quickfix headers  
>> directory to [Project / Edit Project Settings / HEADER_SEARCH_PATHS].
>> The compile step ran flawlessly.
>>
>> The link phase failed miserably.  It couldn't find the quickfix  
>> library at all (BTW I had ZeroLink disabled), which makes sense  
>> because I didn't add it to the project ;-)
>> So I tried to add this in [Targets / Link Libraries With Files]  
>> but I couldn't get the dialog box to go to /usr/local/lib (It  
>> wouldn't display in the window).  When I went to my root volume,  
>> it only displayed the "Apple" direectories like "/Library" and "/ 
>> Users".
>>
>> I am massively stuck.  I can probably get it to work with their  
>> makefile but I'd like to get it to build in XCode for several  
>> reasons.
>>
>> BTW, if it helps, I tried debugging this by exiting Xcode and on  
>> the command line running "xcodebuild", which, as expected, failed  
>> in the exact same way.  I added "-l quickfix" at the end and it  
>> still didn't work (it said it couldn't  find the quickfix file).
>> Interestingly, when I removed *_only_ * the -isysroot option, it  
>> WORKED.  WTF, this is supposed to affect header files only,  
>> according to g++-4.0 documentation.
>>
>> Any help is GREATLY appreciated.  Thanks in advance.
>>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Problems building applications (not quickfix itself) using XCode / OS X

[Oren M. <or...@qu...>]

I just tried creating a new XCode project (I'm still on version 2.0).  I 
put in bare code to create a simple QuickFIX initiator.

The only two settings I changed are setting ZeroLink to false, and 
adding -lquickfix to Other Linker Flags (is this where you did it).  I 
was then able to run the application.

--oren

Derrick Johnson wrote:

> Tiger 10.4.6
> G5 / 1.8GHz / 1GB RAM
> XCode 2.2
>
> I followed the directions and did the following with no errors at all 
> (w00t):
>
> 1. Built and installed libquickfix.dylib and libquickfix.la  (the 
> install script automatically put them in /usr/bin/local and I made 
> sure I was root to do this step)
>
> 2. Built (using make) their tests (runut and runat and 
> runat_threaded).  All worked 100% with no errors.
>
> 3. Build (using make) their examples and ran them.  Again, no errors 
> at all.
>
> ============= Problem starts here ===============
>
> I created my own code snippet (C++ command line tool was the project 
> type I used in Xcode).  
> I then added the quickfix headers directory to [Project / Edit Project 
> Settings / HEADER_SEARCH_PATHS].
> The compile step ran flawlessly.
>
> The link phase failed miserably.  It couldn't find the quickfix 
> library at all (BTW I had ZeroLink disabled), which makes sense 
> because I didn't add it to the project ;-) 
>
> So I tried to add this in [Targets / Link Libraries With Files] but I 
> couldn't get the dialog box to go to /usr/local/lib (It wouldn't 
> display in the window).  When I went to my root volume, it only 
> displayed the "Apple" direectories like "/Library" and "/Users".
>
> I am massively stuck.  I can probably get it to work with their 
> makefile but I'd like to get it to build in XCode for several reasons.
>
> BTW, if it helps, I tried debugging this by exiting Xcode and on the 
> command line running "xcodebuild", which, as expected, failed in the 
> exact same way.  I added "-l quickfix" at the end and it still didn't 
> work (it said it couldn't  find the quickfix file).  
>
> Interestingly, when I removed *_only_ * the -isysroot option, it 
> WORKED.  WTF, this is supposed to affect header files only, according 
> to g++-4.0 documentation.
>
> Any help is GREATLY appreciated.  Thanks in advance.
>

[Quickfix-developers] Processing missed messages

[Robin S. <Rob...@re...>]

Hi,
=20
working with QuickFixJ 1.0.0b3. I have a scenario where quickfix is not
behaving as I would expect it to, would appreciate comment on whether my
expectation is reasonable.
=20
1. starting at an arbitary point in the session, my application receives
message seq nums 205 and 206 in rapid succession from the target such
that they have been received by the quickfixj comms code but NOT yet
posted to my application.
=20
2. message number 205 is posted to my application in fromApp
=20
3. while processing 205 my application dies
=20
4. the application is restarted and it receives a logon from the target
with seqnum of 207. I observe the following in the console :
=20
11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX Event    :
FIX.4.2:J75515N->x Received logon response
11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX Event    :
FIX.4.2:J75515N->x MsgSeqNum too high, expecting 205 but received 207
11/04/06 22:21:29.807 GMT [QFJ Socket Acceptor 131303f] FIX Event :
Re-Sync Target MsgSeqNum to 207
11/04/06 22:21:29.838 GMT [QFJ Socket Acceptor 131303f] FIX toAdmin  :
FIX.4.2:J75515N->x ResendRequest ...
11/04/06 22:21:29.988 GMT [QFJ Socket Acceptor 131303f] FIX Event    :
FIX.4.2:J75515N->x Sent ResendRequest FROM: 207 TO: 0
=20
indicating quickfix on behalf of my application has requested the
missing messages. All great so far.
=20
5. The next I see however in the console is :
=20
11/04/06 22:21:30.338 GMT [QFJ Socket Acceptor 131303f] FIX Event    :
FIX.4.2:J75515N->x Processing QUEUED message: 207

because quickfix has worked through the resent messages and caught up
with where the target system expects it to be.
=20
My problem with this is that my application did not get a chance to
process 205 again (it never completed the first time) and never even got
to see 206. I would have hoped that quickfix would act like a message
queue implementation in this case and ensure that the application layer
got to see every message at least once and in order.
=20
I have looked through the source and, although I haven't debugged the
above, it looks like isTargetTooLow->doTargetTooLow in
Session.verify(...) could be responsible for swallowing these messages.
It looks deliberate though, anyone help me by explaining why?
=20
-Rob


To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, exc=
ept where the sender specifically states them to be the views of Reuters Lt=
d.

[Quickfix-developers] ......from previous OS X post, here is the exact error message

[Derrick J. <der...@ma...>]

=== BUILDING NATIVE TARGET OMS WITH CONFIGURATION Debug ===

Checking Dependencies...

Ld /Users/derrickj/Projects/OMS/build/Debug/OMS normal ppc
     cd /Users/derrickj/Projects/OMS
     /usr/bin/g++-4.0 -o /Users/derrickj/Projects/OMS/build/Debug/OMS  
-L/Users/derrickj/Projects/OMS/build/Debug -F/Users/derrickj/Projects/ 
OMS/build/Debug -filelist /Users/derrickj/Projects/OMS/build/ 
OMS.build/Debug/OMS.build/Objects-normal/ppc/OMS.LinkFileList -arch  
ppc -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
/usr/bin/ld: Undefined symbols:
FIX::SessionSettings::SessionSettings(std::basic_string<char,  
std::char_traits<char>, std::allocator<char> > const&)
collect2: ld returned 1 exit status
** BUILD FAILED **
Colossus:~/projects/OMS derrickj$

[Quickfix-developers] Problems building applications (not quickfix itself) using XCode / OS X

[Derrick J. <der...@ma...>]

Tiger 10.4.6
G5 / 1.8GHz / 1GB RAM
XCode 2.2

I followed the directions and did the following with no errors at all  
(w00t):

1. Built and installed libquickfix.dylib and libquickfix.la  (the  
install script automatically put them in /usr/bin/local and I made  
sure I was root to do this step)

2. Built (using make) their tests (runut and runat and  
runat_threaded).  All worked 100% with no errors.

3. Build (using make) their examples and ran them.  Again, no errors  
at all.

============= Problem starts here ===============

I created my own code snippet (C++ command line tool was the project  
type I used in Xcode).
I then added the quickfix headers directory to [Project / Edit  
Project Settings / HEADER_SEARCH_PATHS].
The compile step ran flawlessly.

The link phase failed miserably.  It couldn't find the quickfix  
library at all (BTW I had ZeroLink disabled), which makes sense  
because I didn't add it to the project ;-)

So I tried to add this in [Targets / Link Libraries With Files] but I  
couldn't get the dialog box to go to /usr/local/lib (It wouldn't  
display in the window).  When I went to my root volume, it only  
displayed the "Apple" direectories like "/Library" and "/Users".

I am massively stuck.  I can probably get it to work with their  
makefile but I'd like to get it to build in XCode for several reasons.

BTW, if it helps, I tried debugging this by exiting Xcode and on the  
command line running "xcodebuild", which, as expected, failed in the  
exact same way.  I added "-l quickfix" at the end and it still didn't  
work (it said it couldn't  find the quickfix file).

Interestingly, when I removed _only_  the -isysroot option, it  
WORKED.  WTF, this is supposed to affect header files only, according  
to g++-4.0 documentation.

Any help is GREATLY appreciated.  Thanks in advance.

Re: [Quickfix-developers] RE: Request resend

[Caleb E. <cal...@gm...>]

On 4/11/06, Fad <s.f...@gm...> wrote:

But if the client-server session are not syncronized, the quickFix engine
> instead of resend the 'lost message' sends however the SeqReset-GapFill
> message with PossDupFlag set to "Y" (in the logs file thera are the
> message
> that the server should resend).


The engine will do this only if:

   - The messages do not exist in the MessageStore
   - The messages are considered to be admin-type messages

The presence of the messages in the server's outgoing log files does not
mean that they can be resent or have been persisted in the MessageStore,
only that they were sent on the connection at some time.  Only messages
which have been persisted to a MessageStore can be resent.  The logs don't
play any part in this.

What kind of MessageStore is your application using?  Have you possibly
customized the "Message::isAdmin" method to return true for this custom
MsgType "UY"?

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] UnsatisfiedLinkError with MS VisualStudio 2005

[Andrew M. <an...@nm...>]

When I build QF using VS2005 (8.x) I get the error below when I run it. 
It runs on machines that have VS2005 installed but I would like to be able 
to distribute my app on machines w/out installing VS2005 or the .NET 
framework.  Can anyone tell me specifically what files need to be 
included to avoid that?

Thanks,
Andrew

Exception in thread "main" java.lang.UnsatisfiedLinkError: 
Z:\javaclasses\quickfix\quickfix_jni.dll: This application has failed to start because the 
application configuration is incorrect. Reinstalling the application may fix this 
problem
         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
         at java.lang.Runtime.loadLibrary0(Runtime.java:822)
         at java.lang.System.loadLibrary(System.java:992)
         at multifix.mfix.<clinit>(mfix.java:75)

Re: [Quickfix-developers] RE: Request resend

[Oren M. <or...@qu...>]

Are you sure those "lost" messages are not administrative messages?  
QuickFIX will not resend administrative messages (it is not necessary 
and in fact harmful).

--oren

Fad wrote:

>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>
>
>Dave Linaker wrote:
>  
>
>> 
>>If you are doing this then I would expect you to see the following from
>>CLIENT_ALL1's perspective:
>> 
>>- CLIENT_ALL1 receives MsgSeqNum 81768 (Next expected seq num changes to
>>81769)
>>- CLIENT_ALL1 receives MsgSeqNum 81769 (Next expected seq num changes to
>>81770)
>>- CLIENT_ALL1 receives MsgSeqNum 81770 (Next expected seq num changes to
>>81771)
>>- CLIENT_ALL1 manually sends ResendRequest 7=81768|16=81770
>>- CLIENT_ALL1 receives MsgSeqNum 81768 (igored because Next expected seq
>>num changes to 81771)
>>- CLIENT_ALL1 receives MsgSeqNum 81769 (igored because Next expected seq
>>num changes to 81771)
>>- CLIENT_ALL1 receives MsgSeqNum 81770 (igored because Next expected seq
>>num changes to 81771)
>> 
>>
>>    
>>
>
>It is not true, infact the client after send "ResendRequest" recive a
>SeqReset-GapFill with PossDupFlag set to "Y". It's ok, because the
>client-server session are syncronized.
>
>But if the client-server session are not syncronized, the quickFix engine
>instead of resend the 'lost message' sends however the SeqReset-GapFill
>message with PossDupFlag set to "Y" (in the logs file thera are the message
>that the server should resend).
>
>Stefano.
>
>--
>View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3868937
>Sent from the QuickFIX - Dev forum at Nabble.com.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>  
>

[Quickfix-developers] RE: Request resend

[Fad <s.f...@gm...>]

Dave Linaker wrote:
> 
>  
> If you are doing this then I would expect you to see the following from
> CLIENT_ALL1's perspective:
>  
> - CLIENT_ALL1 receives MsgSeqNum 81768 (Next expected seq num changes to
> 81769)
> - CLIENT_ALL1 receives MsgSeqNum 81769 (Next expected seq num changes to
> 81770)
> - CLIENT_ALL1 receives MsgSeqNum 81770 (Next expected seq num changes to
> 81771)
> - CLIENT_ALL1 manually sends ResendRequest 7=81768|16=81770
> - CLIENT_ALL1 receives MsgSeqNum 81768 (igored because Next expected seq
> num changes to 81771)
> - CLIENT_ALL1 receives MsgSeqNum 81769 (igored because Next expected seq
> num changes to 81771)
> - CLIENT_ALL1 receives MsgSeqNum 81770 (igored because Next expected seq
> num changes to 81771)
>  
> 

It is not true, infact the client after send "ResendRequest" recive a
SeqReset-GapFill with PossDupFlag set to "Y". It's ok, because the
client-server session are syncronized.

But if the client-server session are not syncronized, the quickFix engine
instead of resend the 'lost message' sends however the SeqReset-GapFill
message with PossDupFlag set to "Y" (in the logs file thera are the message
that the server should resend).

Stefano.

--
View this message in context: http://www.nabble.com/Request-resend-t1430121.html#a3868937
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] Request resend

[Fad <s.f...@gm...>]

Server uses FileStore and "UY" is my custom type message.
The difference in the timestamp is not a problem, the Fix messages that I
had post are only for example.

However in the tests that I have done, I  have found that:

*** In syncronized session ***
if the client send a "ResendRequest", the QuickFix engine on server side
answers with SeqReset-GapFill with PossDupFlag set to "Y". 
It is perfect for me.

*** In not syncronized session ***
If the client send a "ResendRequest", the QuickFix engine on server side
instead of resend the message that are stored in message's log, it send
SeqReset-GapFill with PossDupFlag set to "Y".
It is not all right for me.

Stefano.

P.S. Sorry for double emails.

--
View this message in context: http://www.nabble.com/Request-resend-t1427100.html#a3868722
Sent from the QuickFIX - Dev forum at Nabble.com.

Re: [Quickfix-developers] Request resend

[Caleb E. <cal...@gm...>]

On 4/11/06, Fad <s.f...@gm...> wrote:
>
> For example, in the server's message log there are:
> 8=3D
> FIX.4.2=019=3D160=0135=3DUY=0134=3D81768=0149=3DSPHERA_ALL=0152=3D2006041=
0-16:01:34.267=0156=3DCLIENT_ALL1=0155=3DTXT=01207=3DAFF=01262=3DInfo94=011=
0074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=
=3DS=0110083=3D0=0110=3D180=01
> 8=3D
> FIX.4.2=019=3D159=0135=3DUY=0134=3D81769=0149=3DSPHERA_ALL=0152=3D2006041=
0-16:01:34.283=0156=3DCLIENT_ALL1=0155=3DMS=01207=3DAFF=01262=3DInfo95=0110=
074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=3D=
S=0110083=3D0=0110=3D092=01
> 8=3D
> FIX.4.2=019=3D160=0135=3DUY=0134=3D81770=0149=3DSPHERA_ALL=0152=3D2006041=
0-16:01:34.298=0156=3DCLIENT_ALL1=0155=3DOLI=01207=3DAFF=01262=3DInfo96=011=
0074=3DVCH=0110076=3D0=0110077=3D0=0110080=3D0=0110081=3D00:00:00=0110082=
=3DS=0110083=3D0=0110=3D151=01
>
> If the client send a ResendRequest to server like this:
> 8=3D
> FIX.4.2=019=3D82=0135=3D2=0134=3D10=0149=3DCLIENT_ALL1=0152=3D20060411-06=
:52:07.507=0156=3DSPHERA_ALL=017=3D81768=0116=3D81770=0110=3D086=01
>
> The QuickFix engine on server side  doesn't send nothing.. Why..?
>

Is the server using a persistent type of MessageStore, like the FileStore o=
r
one of the database-backed Stores?  What is MsgType "UY"?  The prsesence of
the field MDReqID screams market data to me, which makes me wonder if these
messages would even be candidates for resending.  Additionally, the
timestamp on the ResendRequest appears to be 14 hours after those messages
were sent.  Is it possible that the session has reset itself during that
time?

The session log should give some more detail about what is happening on the
server side (e.g received resend request, resending message, sending
sequence reset, etc).

PS.  You are sending double emails.  Please use "Reply to All" and send onl=
y
one message.

--
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] Request resend

[Dave L. <dav...@ma...>]

[20060411-09:43:20.896][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D196=0135=3D8=0134=3D1058=0149=3DFixGateway=0152=3D20060411-08:43:=
20.896=0156=3DFixClient2=016=3D0=0111=3D1=0114=3D0=0117=3D20060411exe0000=
0001=0120=3D0=0122=3D1=0137=3D20060411ord00000001=0138=3D1000=0139=3D0=01=
40=3D2=0144=3D76.5=0148=3DABC=0154=3D1=0155=3DABC=01150=3D0=01151=3D1000=01=
10=3D034=01
[20060411-09:43:20.976][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D197=0135=3D8=0134=3D1059=0149=3DFixGateway=0152=3D20060411-08:43:=
20.976=0156=3DFixClient2=016=3D0=0111=3D2=0114=3D0=0117=3D20060411exe0000=
0002=0120=3D0=0122=3D1=0137=3D20060411ord00000002=0138=3D1000=0139=3D0=01=
40=3D2=0144=3D23.25=0148=3DDEF=0154=3D1=0155=3DDEF=01150=3D0=01151=3D1000=
=0110=3D098=01
[20060411-09:43:21.036][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D197=0135=3D8=0134=3D1060=0149=3DFixGateway=0152=3D20060411-08:43:=
21.036=0156=3DFixClient2=016=3D0=0111=3D3=0114=3D0=0117=3D20060411exe0000=
0003=0120=3D0=0122=3D1=0137=3D20060411ord00000003=0138=3D1000=0139=3D0=01=
40=3D2=0144=3D12.32=0148=3DGHI=0154=3D1=0155=3DGHI=01150=3D0=01151=3D1000=
=0110=3D095=01
[20060411-09:43:50.899][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D66=0135=3D0=0149=3DFixClient2=0156=3DFixGateway=0134=3D1057=0152=3D=
20060411-08:43:50.899=0110=3D047=01
[20060411-09:43:51.019][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D66=0135=3D0=0134=3D1061=0149=3DFixGateway=0152=3D20060411-08:43:5=
1.019=0156=3DFixClient2=0110=3D027=01
[20060411-09:44:20.942][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D66=0135=3D0=0149=3DFixClient2=0156=3DFixGateway=0134=3D1058=0152=3D=
20060411-08:44:20.942=0110=3D035=01
[20060411-09:44:21.072][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D66=0135=3D0=0134=3D1062=0149=3DFixGateway=0152=3D20060411-08:44:2=
1.072=0156=3DFixClient2=0110=3D025=01
[20060411-09:44:23.676][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D81=0135=3D2=0149=3DFixClient2=0156=3DFixGateway=0134=3D1059=0152=3D=
20060411-08:44:23.676=017=3D1058=0116=3D1060=0110=3D217=01
[20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D227=0135=3D8=0134=3D1058=0143=3DY=0149=3DFixGateway=0152=3D200604=
11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:20.896=016=3D0=01=
11=3D1=0114=3D0=0117=3D20060411exe00000001=0120=3D0=0122=3D1=0137=3D20060=
411ord00000001=0138=3D1000=0139=3D0=0140=3D2=0144=3D76.5=0148=3DABC=0154=3D=
1=0155=3DABC=01150=3D0=01151=3D1000=0110=3D036=01
[20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D228=0135=3D8=0134=3D1059=0143=3DY=0149=3DFixGateway=0152=3D200604=
11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:20.976=016=3D0=01=
11=3D2=0114=3D0=0117=3D20060411exe00000002=0120=3D0=0122=3D1=0137=3D20060=
411ord00000002=0138=3D1000=0139=3D0=0140=3D2=0144=3D23.25=0148=3DDEF=0154=
=3D1=0155=3DDEF=01150=3D0=01151=3D1000=0110=3D100=01
[20060411-09:44:23.686][DETAIL][FIX.4.2:FixClient2->FixGateway]8=3DFIX.4.=
2=019=3D228=0135=3D8=0134=3D1060=0143=3DY=0149=3DFixGateway=0152=3D200604=
11-08:44:23.686=0156=3DFixClient2=01122=3D20060411-08:43:21.036=016=3D0=01=
11=3D3=0114=3D0=0117=3D20060411exe00000003=0120=3D0=0122=3D1=0137=3D20060=
411ord00000003=0138=3D1000=0139=3D0=0140=3D2=0144=3D12.32=0148=3DGHI=0154=
=3D1=0155=3DGHI=01150=3D0=01151=3D1000=0110=3D097=01