quickfix-users — QuickFIX user support

[Quickfix-users] A couple questions

[Mike P. <mi...@fo...>]

What needs to be done to get the examples to use MySql for storing messages?  
I've a MySQL server running, and the schema has been loaded.  I added both a 
MySQLLogPassword and MySQLStorePassword to the ordermatch.cfg config file.  
The docs seem to state that all the other MySQL related config parameters 
have defaults.

Also, I can't get banzai to run. I get the following:

Exception in thread "main" 
java.lang.UnsatisfiedLinkError: /home/users/mikep/bu_exclude/quickfix/src/java/.libs/libquickfix_jni.so.9.0.0: /home/users/mikep/tmp/quickfix/src/C++/.libs/libquickfix.so.5: 
undefined symbol: _ZNKSt11logic_error4whatEv
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1485)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at Banzai.<clinit>(Unknown Source)


Here are the libraries that were installed:

libquickfix.la  
libquickfix.so.5      
libquickfix_jni.la  
libquickfix_jni.so.9      
quickfix.jar
libquickfix.so  
libquickfix.so.5.0.0  
libquickfix_jni.so  
libquickfix_jni.so.9.0.0


I saw some previous posts that seemed to imply the library versions were 
incorrect, but I'm not sure what the problem is here.

Thanks,
Mike

Re: [Quickfix-users] Query on QuickFIX 1.9.3 Version --Oren

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

Dinesh,

No, unfortunately this did not make it into 1.9.3.  It will go into the =20=

next release.  You will have to apply this patch manually right now.

--oren

On Nov 10, 2004, at 4:54 AM, Dinesh Belaguli wrote:

> Hi oren,
> =A0=A0=A0 The problem mentioned below (i.e., Session Establishment =
when the =20
> startTime is reached)is working fine with Max Solution. so is this fix =
=20
> available in the latest version of quickfix.
> =A0=A0=A0
>  thanx
> dinesh.
> -----Original Message-----
> From: Requenes, Max [mailto:Max...@sa...]
> Sent: Monday, November 08, 2004 7:57 PM
> To: Dinesh Belaguli; qui...@li...; =20
> qui...@li...
> Subject: RE: [Quickfix-developers] Sessions are not established when =20=

> it reaches the startTime.
>
> Do you happen to be using ThreadedSocketInitiator?
> =A0
> I ran into a similar problem. I fixed it by modifying =20
> ThreadedSocketInitiator::onStart()
> =A0
> change this:
> connect();
> while ( !m_stop )
> =A0 process_sleep(1);
> =A0
> to this:
>
> while ( !m_stop ) {
> =A0 connect();
> =A0 process_sleep(1);
> }
> =A0
> =A0
> I submitted this fix to the mailing list before, but got no response.
> http://sourceforge.net/mailarchive/forum.php?=20
> thread_id=3D4325707&forum_id=3D103
> =A0
> Let me know if this helps.
> -----Original Message-----
> From: Dinesh Belaguli [mailto:Din...@in...]
> Sent: Monday, November 08, 2004 4:05 AM
> To: qui...@li...; =20
> qui...@li...
> Cc: Dinesh Belaguli
> Subject: [Quickfix-developers] Sessions are not established when it =20=

> reaches the startTime.
> Importance: High
>
>
> hi,
> =A0I have two programmes acting one as client and other as server.
> in the quickfixConfig.cfg (configuration file) i have configured the =20=

> start and EndTime as follows.
>
> StartTime=3D08:45:00
> EndTime=3D08:10:00=A0
>
> the above timings are in GMT.
> for convenience i changed my system time to GMT.
>
> I started the server programme before running the client programme.
>
>
>
> Two cases.
> 1) when i start my client programme before the start Time say 08:40:00
> =A0=A0=A0=A0=A0=A0=A0 connection established successfully but the =
sessions are not =20
> created that is fine.
> =A0=A0=A0=A0=A0=A0=A0 but when the time reaches 8:45 it didn't =
(create) establish =20
> the sessions (ideally it should establish the sessions know.)
>
> =A0=A0=A0=A0=A0=A0=A0
>
>  2) when i start the client programme some where after the startTime =20=

> say 8:48 then it established sessions.
>
> i want to know y the sessions are not created in the first case as i =20=

> have explained..
> can any one through some light on this..
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 BELOW is My Configuration =
File i.e. at client side.
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
>
>
>
>  [DEFAULT]
> ConnectionType=3Dinitiator
> HeartBtInt=3D20
> FileStorePath=3Dstore
> FileLogPath=3Dlogs
>
> StartTime=3D08:45:00
> EndTime=3D08:10:00
>
> ResetOnDisconnect=3DN
> ResetOnLogout=3DN
> ProviderPassword=3D
> SenderSubID=3D
> OnLogonResetMsgSeqNo=3Dfalse
>
>
>
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DITLClientMD
> TargetCompID=3DITLServer
> UseDataDictionary=3DY
> ValidateFieldsOutOfOrder=3DY
> DataDictionary=3Djava/spec/barclay/FIX42.xml
> CheckLatency=3DN
> SocketConnectHost=3Dlocalhost
> SocketConnectPort=3D5007
>
>
>
>
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DITLClientOrder
> TargetCompID=3DITLServer
> UseDataDictionary=3DY
> ValidateFieldsOutOfOrder=3DY
> DataDictionary=3Djava/spec/barclay/FIX42.xml
> CheckLatency=3DN
> SocketConnectHost=3Dlocalhost
> SocketConnectPort=3D5007
>
>
>
> Thanx.
> Dinesh.
>
>
>
>
> DISCLAIMER: This e-mail message and any attachments are intended =20
> solely for the use of the individual or entity to which it is =20
> addressed and may contain information that is confidential or legally =20=

> privileged. If you are not the intended recipient, you are hereby =20
> notified that any dissemination, distribution, copying or other use of =
=20
> this message or its attachments is strictly prohibited. If you have =20=

> received this message in error, please notify the sender immediately =20=

> and permanently delete this message and any attachments.
>
>

[Quickfix-users] Query on QuickFIX 1.9.3 Version --Oren

[Dinesh B. <Din...@in...>]

Hi oren,
    The problem mentioned below (i.e., Session Establishment when the =
startTime is reached)is working fine with Max Solution. so is this fix =
available in the latest version of quickfix.
   =20
thanx
dinesh.

-----Original Message-----
From: Requenes, Max [mailto:Max...@sa...]
Sent: Monday, November 08, 2004 7:57 PM
To: Dinesh Belaguli; qui...@li...; =
qui...@li...
Subject: RE: [Quickfix-developers] Sessions are not established when it =
reaches the startTime.


Do you happen to be using ThreadedSocketInitiator?
=20
I ran into a similar problem. I fixed it by modifying =
ThreadedSocketInitiator::onStart()
=20
change this:
connect();
while ( !m_stop )
  process_sleep(1);
=20
to this:

while ( !m_stop ) {
  connect();
  process_sleep(1);
}
=20
=20
I submitted this fix to the mailing list before, but got no response.
http://sourceforge.net/mailarchive/forum.php?thread_id=3D4325707 =
<http://sourceforge.net/mailarchive/forum.php?thread_id=3D4325707&forum_i=
d=3D103> &forum_id=3D103
=20
Let me know if this helps.

-----Original Message-----
From: Dinesh Belaguli [mailto:Din...@in...]
Sent: Monday, November 08, 2004 4:05 AM
To: qui...@li...; =
qui...@li...
Cc: Dinesh Belaguli
Subject: [Quickfix-developers] Sessions are not established when it =
reaches the startTime.
Importance: High



	hi,=20
 I have two programmes acting one as client and other as server.=20
in the quickfixConfig.cfg (configuration file) i have configured the =
start and EndTime as follows.=20

	StartTime=3D08:45:00=20
EndTime=3D08:10:00 =20

	the above timings are in GMT.=20
for convenience i changed my system time to GMT.=20

	I started the server programme before running the client programme.=20


	Two cases.=20
1) when i start my client programme before the start Time say 08:40:00=20
        connection established successfully but the sessions are not =
created that is fine.=20
        but when the time reaches 8:45 it didn't (create) establish the =
sessions (ideally it should establish the sessions know.)

	       =20

	2) when i start the client programme some where after the startTime say =
8:48 then it established sessions.=20

	i want to know y the sessions are not created in the first case as i =
have explained..=20
can any one through some light on this..=20


	                BELOW is My Configuration File i.e. at client side.=20
               =20


	[DEFAULT]=20
ConnectionType=3Dinitiator=20
HeartBtInt=3D20=20
FileStorePath=3Dstore=20
FileLogPath=3Dlogs=20

	StartTime=3D08:45:00=20
EndTime=3D08:10:00=20

	ResetOnDisconnect=3DN=20
ResetOnLogout=3DN=20
ProviderPassword=3D=20
SenderSubID=3D=20
OnLogonResetMsgSeqNo=3Dfalse=20


	[SESSION]=20
BeginString=3DFIX.4.2=20
SenderCompID=3DITLClientMD=20
TargetCompID=3DITLServer=20
UseDataDictionary=3DY=20
ValidateFieldsOutOfOrder=3DY=20
DataDictionary=3Djava/spec/barclay/FIX42.xml=20
CheckLatency=3DN=20
SocketConnectHost=3Dlocalhost=20
SocketConnectPort=3D5007=20



	[SESSION]=20
BeginString=3DFIX.4.2=20
SenderCompID=3DITLClientOrder=20
TargetCompID=3DITLServer=20
UseDataDictionary=3DY=20
ValidateFieldsOutOfOrder=3DY=20
DataDictionary=3Djava/spec/barclay/FIX42.xml=20
CheckLatency=3DN=20
SocketConnectHost=3Dlocalhost=20
SocketConnectPort=3D5007=20


	Thanx.=20
Dinesh.=20



DISCLAIMER: This e-mail message and any attachments are intended solely =
for the use of the individual or entity to which it is addressed and may =
contain information that is confidential or legally privileged. If you =
are not the intended recipient, you are hereby notified that any =
dissemination, distribution, copying or other use of this message or its =
attachments is strictly prohibited. If you have received this message in =
error, please notify the sender immediately and permanently delete this =
message and any attachments.=20

[Quickfix-users] QuickFIX 1.9.3 Available

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

QuickFIX 1.9.3 is now available at http://www.quickfixengine.org/

Release Notes:  
https://sourceforge.net/project/shownotes.php?release_id=280488

This is mostly a series of bug fixes, some pretty important depending  
on which API / features you use.  Look through the release notes to see  
if this version fixes one of these problems.  Many of these fixes were  
direct results of reports to the bug tracker.  There are a few requests  
that were cut off from this version.  To see which issues are still  
open, see the open reports in the bug tracker:  
http://www.quickfixengine.org/bugtracker/query.php? 
op=doquery&status[]=2

All of these are either pretty insignificant, a feature request, or  
have a reasonable work-around.

One of the more important aspects of this version is it fixes  
instability problems with .NET.  Also the various reports concerning  
several aspects of repeating groups have been addressed.  There is also  
some more robust session handling logic and message parsing.

Upgrading is a recommended for 1.9.x users.

When upgrading note that the MessageStore::get( int, std::string& )  
method is gone.  If you are currently overloading this in a message  
store, you can simply get rid of it, it's no longer needed.

--oren

[Quickfix-users] RE: [Quickfix-developers] Sessions are not established when it re aches the startTime.

[Requenes, M. <Max...@sa...>]

Do you happen to be using ThreadedSocketInitiator?
 
I ran into a similar problem. I fixed it by modifying
ThreadedSocketInitiator::onStart()
 
change this:
connect();
while ( !m_stop )
  process_sleep(1);
 
to this:
while ( !m_stop ) {
  connect();
  process_sleep(1);
}
 
 
I submitted this fix to the mailing list before, but got no response.
http://sourceforge.net/mailarchive/forum.php?thread_id=4325707
<http://sourceforge.net/mailarchive/forum.php?thread_id=4325707&forum_id=103
> &forum_id=103
 
Let me know if this helps.

-----Original Message-----
From: Dinesh Belaguli [mailto:Din...@in...]
Sent: Monday, November 08, 2004 4:05 AM
To: qui...@li...;
qui...@li...
Cc: Dinesh Belaguli
Subject: [Quickfix-developers] Sessions are not established when it reaches
the startTime.
Importance: High



	hi, 
 I have two programmes acting one as client and other as server. 
in the quickfixConfig.cfg (configuration file) i have configured the start
and EndTime as follows. 

	StartTime=08:45:00 
EndTime=08:10:00  

	the above timings are in GMT. 
for convenience i changed my system time to GMT. 

	I started the server programme before running the client programme. 


	Two cases. 
1) when i start my client programme before the start Time say 08:40:00 
        connection established successfully but the sessions are not created
that is fine. 
        but when the time reaches 8:45 it didn't (create) establish the
sessions (ideally it should establish the sessions know.)

	        

	2) when i start the client programme some where after the startTime
say 8:48 then it established sessions. 

	i want to know y the sessions are not created in the first case as i
have explained.. 
can any one through some light on this.. 


	                BELOW is My Configuration File i.e. at client side. 
                


	[DEFAULT] 
ConnectionType=initiator 
HeartBtInt=20 
FileStorePath=store 
FileLogPath=logs 

	StartTime=08:45:00 
EndTime=08:10:00 

	ResetOnDisconnect=N 
ResetOnLogout=N 
ProviderPassword= 
SenderSubID= 
OnLogonResetMsgSeqNo=false 


	[SESSION] 
BeginString=FIX.4.2 
SenderCompID=ITLClientMD 
TargetCompID=ITLServer 
UseDataDictionary=Y 
ValidateFieldsOutOfOrder=Y 
DataDictionary=java/spec/barclay/FIX42.xml 
CheckLatency=N 
SocketConnectHost=localhost 
SocketConnectPort=5007 



	[SESSION] 
BeginString=FIX.4.2 
SenderCompID=ITLClientOrder 
TargetCompID=ITLServer 
UseDataDictionary=Y 
ValidateFieldsOutOfOrder=Y 
DataDictionary=java/spec/barclay/FIX42.xml 
CheckLatency=N 
SocketConnectHost=localhost 
SocketConnectPort=5007 


	Thanx. 
Dinesh. 



DISCLAIMER: This e-mail message and any attachments are intended solely for
the use of the individual or entity to which it is addressed and may contain
information that is confidential or legally privileged.  If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution, copying or other use of this message or its attachments is
strictly prohibited.  If you have received this message in error, please
notify the sender immediately and permanently delete this message and any
attachments. 

[Quickfix-users] Dout on Session Establishment.

[Dinesh B. <Din...@in...>]

Hi,
 When the sessions are established actually only after login?
i have a query=20
 let us say i will start my FIXEngine client to connect to the provider

case 1) Provider is Down.
	what happens to my client programme if the provider(Server) is down. =
will it establish the connection and sends login request once the server =
comes up( for establishing the sessions)

Case 2) Provider is up but not accepting the Login messages.
	if i start my FIXEngine Client programme it will establish the =
Connection but when the sessions are established and how..

we are using quickfix8.0 version.

can any one clearly explain me on this issue..

thanx
dinesh.

[Quickfix-users] Sessions are not established when it reaches the startTime.

[Dinesh B. <Din...@in...>]

	hi,
	 I have two programmes acting one as client and other as server.
	in the quickfixConfig.cfg (configuration file) i have configured the =
start and EndTime as follows.

	StartTime=3D08:45:00
	EndTime=3D08:10:00 =20

	the above timings are in GMT.
	for convenience i changed my system time to GMT.

	I started the server programme before running the client programme.


	Two cases.
	1) when i start my client programme before the start Time say 08:40:00
		connection established successfully but the sessions are not created =
that is fine.
		but when the time reaches 8:45 it didn't (create) establish the =
sessions (ideally it should establish the sessions know.)
	=09

	2) when i start the client programme some where after the startTime say =
8:48 then it established sessions.

	i want to know y the sessions are not created in the first case as i =
have explained..
	can any one through some light on this..


			BELOW is My Configuration File i.e. at client side.
		=09


	[DEFAULT]
	ConnectionType=3Dinitiator
	HeartBtInt=3D20
	FileStorePath=3Dstore
	FileLogPath=3Dlogs

	StartTime=3D08:45:00
	EndTime=3D08:10:00=20

	ResetOnDisconnect=3DN
	ResetOnLogout=3DN
	ProviderPassword=3D
	SenderSubID=3D
	OnLogonResetMsgSeqNo=3Dfalse


	[SESSION]
	BeginString=3DFIX.4.2
	SenderCompID=3DITLClientMD
	TargetCompID=3DITLServer
	UseDataDictionary=3DY
	ValidateFieldsOutOfOrder=3DY
	DataDictionary=3Djava/spec/barclay/FIX42.xml
	CheckLatency=3DN
	SocketConnectHost=3Dlocalhost
	SocketConnectPort=3D5007



	[SESSION]
	BeginString=3DFIX.4.2
	SenderCompID=3DITLClientOrder
	TargetCompID=3DITLServer
	UseDataDictionary=3DY
	ValidateFieldsOutOfOrder=3DY
	DataDictionary=3Djava/spec/barclay/FIX42.xml
	CheckLatency=3DN
	SocketConnectHost=3Dlocalhost
	SocketConnectPort=3D5007


	Thanx.
	Dinesh.

[Quickfix-users] Multiple sessions with different start and end times

[Shamanth <sha...@in...>]

Hi=20
=20
I am using quickfix 1.8
=20
I have a provider who has some complex session timing settings. within a =
day, they start and stop the sessions at multiple times, but reset the =
sequence number only once. And also they are down on weekends.
=20
I wanted to have multiple sessions configured for this provider with the =
same SenderCompID, TargetCompID and BeginString, But each of these =
sessions would have different starttime and endtime.
=20
Problem: Sequence numbers get reset everytime any of the session's =
starttime/endtime is crossed. Is it possible to configure quickfix not =
to reset the sequence numbers based on starttime and endtime.
=20
thanks
R Shamanth

Re: [Quickfix-developers] RE: [Quickfix-users] Logon Ack seqNo

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

Yes, this change is going into the next version.

--oren

On Oct 20, 2004, at 5:25 AM, Shamanth wrote:

> Hi Oren
> =A0
> Thanks for the reply, Regarding Answer 2 below,
>  =A0
> You are right, Acceptor is not a quickfix engine, but a custom built=20=

> one used by one of our providers. It seems, he is sending this huge=20
> number(2147483647)=A0in resend requests to signify infinity.=A0
> =A0
> I think the code you have give below, should solve this problem. Is it=20=

> possible to incorporate this change in the next release of quickfix.
> =A0
> thanks
> R Shamanth
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, October 19, 2004 8:29 PM
> To: Shamanth
> Cc: qui...@li...;=20
> qui...@li...
> Subject: Re: [Quickfix-users] Logon Ack seqNo
>
>
> Answer1:
>
>
>
>  No. This is in fact normal behavior. Whenever a message is sent the=20=

> sequence number has to be incremented. Just because we did not receive=20=

> an ack, does not necessarily mean the counter-party did not receive=20
> the logon. If the sequence number was not incremented, and they had=20
> actually received it without acknowledging, you would then encounter=20=

> disconnect scenarios due to too low sequence numbers at some point. A=20=

> much worse position to be in as it cannot be resolved automatically.
>
>
>
>  Having a sequence number that is too high isn't much of a problem=20
> since the two engines can resolve this on their own. And since in this=20=

> case we are talking about logon messages, all that is required is a=20
> single gap fill message to put everything in order.
>
>
>
>  Answer2:
>
>
>
>  Depends on the version. For FIX.4.2 and higher, the value should be=20=

> 0. For versions 4.1 and earlier, a special value of 999999 is used.=20
> I'm a bit curious as to what is going on here. Is both the initiator=20=

> and acceptor QuickFIX. It seems strange because since QuickFIX 1.6,=20
> the EndSeqNo is always send either 0 or 999999, never another value.=20=

> Based on this I'm guessing the acceptor in this scenario is not=20
> QuickFIX, is this correct?
>
>
>
>  As to the effect of the value 2147483647, I suspect your application=20=

> has stopped responding because you now got the message store trying to=20=

> look up a hell of a lot of messages in a tight loop. I suspect we can=20=

> have QuickFIX handle this situation more gracefully if we consider=20
> such a situation equivalent to an infinite request as such:
>
>
>
>  if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
>
>  beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||
>
>  endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle=20
> bizarrely large numbers
>
>  { endSeqNo =3D getExpectedSenderNum() - 1; }
>
>
>
>
>  On Oct 19, 2004, at 7:08 AM, Shamanth wrote:
>
>
>
>  Hi
>
>
>
> I am using quickfix 1.8,
>
>
>
> While testing due to some network problems we got disconnected from=20
> the "Acceptor". In the mean time, our "initiator" tried reconnecting=20=

> to the "acceptor" every 30secs.
>
>
>
> It tried it 8 times before it could get an ack for its logon message.
>
>
>
>
> Problem1: Our initiator, sent 8 logon messages and only the 9th logon=20=

> message was ack by the acceptor. But in the meantime, our initiator=20
> incremented its MsgSeqNo, so when both the initiator and acceptor got=20=

> connected, there was a mismatch of SeqNo, and the =93acceptor=94 send =
a=20
> resendRequest to the =93initiator=94
>
>
>
> Question: Is there a way we can prevent the quickfix initiator from=20
> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
>
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the=20=

> SeqNo of the messages received was correct.
>
>
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request=20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages,=20=

> so it considers it as an error condition and stops responding to the=20=

> acceptor. Is =932147483647=94 the maximum value in resend request as =
per=20
> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
> considered as the maximum number?
>
>
>
> thanks
>
>
>
> R Shamanth

Re: [Quickfix-users] 1.9.2 body lenght mismatch

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

Shamanth,

This looks like a problem that has been fixed.  The fix is available in =20=

CVS and will be released with 1.9.3

--oren

On Oct 20, 2004, at 4:23 AM, Shamanth wrote:

> Hi
> =C2=A0
> I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =20=

> downloaded the source and build them in windows.
>  Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI =20
> wrappers, and not the C++ code directly
> =C2=A0
> Problem:
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
> =C2=A0
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
> =C2=A0
> In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> =C2=A0
> Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
=20
> of 1.8, then every thing works fine. I notice this problem only with =20=

> 1.9.2 jars and dlls.
> =C2=A0
> This is how the XML looks with 1.8 jars and dlls
> =C2=A0
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> </message>
> =C2=A0
> any idea what could be the problem, has any one else faced the same =20=

> problem.
> =C2=A0
> thanks
> R Shamanth

Re: [Quickfix-users] 1.9.2 body lenght mismatch

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

Can you post the code you are using to create this message?

--oren

On Oct 20, 2004, at 4:23 AM, Shamanth wrote:

> Hi
> =C2=A0
> I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =20=

> downloaded the source and build them in windows.
>  Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI =20
> wrappers, and not the C++ code directly
> =C2=A0
> Problem:
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
> =C2=A0
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
> =C2=A0
> In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> =C2=A0
> Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
=20
> of 1.8, then every thing works fine. I notice this problem only with =20=

> 1.9.2 jars and dlls.
> =C2=A0
> This is how the XML looks with 1.8 jars and dlls
> =C2=A0
> <message>
> =C2=A0 <header>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
> =C2=A0 </header>
> =C2=A0 <body>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0=C2=A0=C2=A0 <group>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
> =C2=A0=C2=A0=C2=A0 </group>
> =C2=A0 </body>
> =C2=A0 <trailer>
> =C2=A0 </trailer>
> </message>
> =C2=A0
> any idea what could be the problem, has any one else faced the same =20=

> problem.
> =C2=A0
> thanks
> R Shamanth

RE: [Quickfix-users] Logon Ack seqNo

[Shamanth <sha...@in...>]

Hi Oren
=20
Thanks for the reply, Regarding Answer 2 below,=20
=20
You are right, Acceptor is not a quickfix engine, but a custom built one =
used by one of our providers. It seems, he is sending this huge =
number(2147483647) in resend requests to signify infinity.=20
=20
I think the code you have give below, should solve this problem. Is it =
possible to incorporate this change in the next release of quickfix.
=20
thanks
R Shamanth

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: Tuesday, October 19, 2004 8:29 PM
To: Shamanth
Cc: qui...@li...; =
qui...@li...
Subject: Re: [Quickfix-users] Logon Ack seqNo



Answer1:=20


No. This is in fact normal behavior. Whenever a message is sent the =
sequence number has to be incremented. Just because we did not receive =
an ack, does not necessarily mean the counter-party did not receive the =
logon. If the sequence number was not incremented, and they had actually =
received it without acknowledging, you would then encounter disconnect =
scenarios due to too low sequence numbers at some point. A much worse =
position to be in as it cannot be resolved automatically.=20


Having a sequence number that is too high isn't much of a problem since =
the two engines can resolve this on their own. And since in this case we =
are talking about logon messages, all that is required is a single gap =
fill message to put everything in order.=20


Answer2:=20


Depends on the version. For FIX.4.2 and higher, the value should be 0. =
For versions 4.1 and earlier, a special value of 999999 is used. I'm a =
bit curious as to what is going on here. Is both the initiator and =
acceptor QuickFIX. It seems strange because since QuickFIX 1.6, the =
EndSeqNo is always send either 0 or 999999, never another value. Based =
on this I'm guessing the acceptor in this scenario is not QuickFIX, is =
this correct?=20


As to the effect of the value 2147483647, I suspect your application has =
stopped responding because you now got the message store trying to look =
up a hell of a lot of messages in a tight loop. I suspect we can have =
QuickFIX handle this situation more gracefully if we consider such a =
situation equivalent to an infinite request as such:=20


if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||=20

beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||=20

endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle bizarrely =
large numbers=20

{ endSeqNo =3D getExpectedSenderNum() - 1; }=20



On Oct 19, 2004, at 7:08 AM, Shamanth wrote:=20


Hi=20


I am using quickfix 1.8,=20


While testing due to some network problems we got disconnected from the =
"Acceptor". In the mean time, our "initiator" tried reconnecting to the =
"acceptor" every 30secs.=20


It tried it 8 times before it could get an ack for its logon message.=20



Problem1: Our initiator, sent 8 logon messages and only the 9th logon =
message was ack by the acceptor. But in the meantime, our initiator =
incremented its MsgSeqNo, so when both the initiator and acceptor got =
connected, there was a mismatch of SeqNo, and the =93acceptor=94 send a =
resendRequest to the =93initiator=94=20


Question: Is there a way we can prevent the quickfix initiator from =
incrementing its SeqNo, if it did not receive Ack for its Logon msg.=20


NOTE: Only the SeqNo of the messages sent was incremented, while the =
SeqNo of the messages received was correct.=20




Problem2: After connecting again the Acceptor sent, a resend request =
FROM: 0 TO: 2147483647, our initiator had not sent so many messages, so =
it considers it as an error condition and stops responding to the =
acceptor. Is =932147483647=94 the maximum value in resend request as per =
fix protocol or should =930=94(infinity) be considered as the max =
valueis considered as the maximum number?=20


thanks=20


R Shamanth=20

[Quickfix-users] 1.9.2 body lenght mismatch

[Shamanth <sha...@in...>]

Hi
=20
I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =
downloaded the source and build them in windows.=20
Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI wrappers, =
and not the C++ code directly
=20
Problem:
When I send a MarketDataRequest, I get the following error in the =
Acceptor, I have pasted the original message also below.
=20
<20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
 =
(8=3DFIX.4.2?9=3D151?35=3DV?34=3D2?49=3DITLClientMD?52=3D2004102008:37:50=
.617?56=3DITLServer?146=3D1?55=3DEUR/USD?146=3D1?55=3DEUR/USD?146=3D1?55=3D=
EUR/USD?262=3D123456?263=3D1?264=3D0?265=3D1?267=3D2?269=3D0?269=3D1?267=3D=
2?269=3D0?269=3D1?267=3D2?269=3D0?269=3D1?10=3D165?)
<20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
  (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
=20
In my initiator log, I am printing the XML of the message before =
sending, I see that it is not getting resolved properly
<message>
  <header>
    <field number=3D"8"><![CDATA[FIX.4.2]]></field>
    <field number=3D"35"><![CDATA[V]]></field>
    <field number=3D"34"><![CDATA[2]]></field>
    <field number=3D"49"><![CDATA[ITLClientMD]]></field>
    <field number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
    <field number=3D"56"><![CDATA[ITLServer]]></field>
  </header>
  <body>
    <field number=3D"146"><![CDATA[1]]></field>
    <field number=3D"146"><![CDATA[1]]></field>
    <field number=3D"262"><![CDATA[123456]]></field>
    <field number=3D"263"><![CDATA[1]]></field>
    <field number=3D"264"><![CDATA[0]]></field>
    <field number=3D"265"><![CDATA[1]]></field>
    <field number=3D"267"><![CDATA[2]]></field>
    <field number=3D"267"><![CDATA[2]]></field>
    <group>
      <field number=3D"55"><![CDATA[EUR/USD]]></field>
    </group>
    <group>
      <field number=3D"269"><![CDATA[0]]></field>
    </group>
    <group>
      <field number=3D"269"><![CDATA[1]]></field>
    </group>
  </body>
  <trailer>
  </trailer>
=20
Note: If I replace the quickfix.jar, quickfix.lib and quickfix_jni.dll =
of 1.8, then every thing works fine. I notice this problem only with =
1.9.2 jars and dlls.
=20
This is how the XML looks with 1.8 jars and dlls
=20
<message>
  <header>
    <field number=3D"8" value=3D"FIX.4.2"/>
    <field number=3D"35" value=3D"V"/>
    <field number=3D"34" value=3D"2"/>
    <field number=3D"49" value=3D"ITLClientMD"/>
    <field number=3D"52" value=3D"20041020-08:47:49.679"/>
    <field number=3D"56" value=3D"ITLServer"/>
  </header>
  <body>
    <field number=3D"146" value=3D"1"/>
    <field number=3D"262" value=3D"123456"/>
    <field number=3D"263" value=3D"1"/>
    <field number=3D"264" value=3D"0"/>
    <field number=3D"265" value=3D"1"/>
    <field number=3D"267" value=3D"2"/>
    <group>
      <field number=3D"55" value=3D"EUR/USD"/>
    </group>
    <group>
      <field number=3D"269" value=3D"0"/>
    </group>
    <group>
      <field number=3D"269" value=3D"1"/>
    </group>
  </body>
  <trailer>
  </trailer>
</message>
=20
any idea what could be the problem, has any one else faced the same =
problem.
=20
thanks
R Shamanth

Re: [Quickfix-developers] Re: [Quickfix-users] Logon Ack seqNo

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

On a slightly related note.  I've noticed that QuickFIX can be a
little over-aggressive in terms of issuing ResendRequest messages and
I think it might make sense to implement some level of throttling on
these.

For example, if a counterparty has a large-ish number of messages in
flight when a gap is detected, each will cause QF to issue a
ResendRequest for the same range of missed messages.  The remote side
will honor all of these, resulting in several times the necessary
message traffic to fill the gap.

It might make sense to keep track of the range and time of the most
recent ResendRequest in the SessionState and not send a new
ResendRequest if the outstanding one would satisfy the same range of
messages and no more than <X> seconds has elapsed.

-- 
Caleb Epstein
cal...@gm...

Re: [Quickfix-users] Logon Ack seqNo

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

Correction:

That condition should read, 'endSeqNo >=3D getExpectedSenderNum()'

On Oct 19, 2004, at 9:59 AM, Oren Miller wrote:

> Answer1:
>
> No.  This is in fact normal behavior.  Whenever a message is sent the=20=

> sequence number has to be incremented.  Just because we did not=20
> receive an ack, does not necessarily mean the counter-party did not=20
> receive the logon.  If the sequence number was not incremented, and=20
> they had actually received it without acknowledging, you would then=20
> encounter disconnect scenarios due to too low sequence numbers at some=20=

> point.  A much worse position to be in as it cannot be resolved=20
> automatically.
>
> Having a sequence number that is too high isn't much of a problem=20
> since the two engines can resolve this on their own.  And since in=20
> this case we are talking about logon messages, all that is required is=20=

> a single gap fill message to put everything in order.
>
> Answer2:
>
> Depends on the version.  For FIX.4.2 and higher, the value should be=20=

> 0.  For versions 4.1 and earlier, a special value of 999999 is used. =20=

> I'm a bit curious as to what is going on here.  Is both the initiator=20=

> and acceptor QuickFIX.  It seems strange because since QuickFIX 1.6,=20=

> the EndSeqNo is always send either 0 or 999999, never another value. =20=

> Based on this I'm guessing the acceptor in this scenario is not=20
> QuickFIX, is this correct?
>
> As to the effect of the value 2147483647, I suspect your application=20=

> has stopped responding because you now got the message store trying to=20=

> look up a hell of a lot of messages in a tight loop.  I suspect we can=20=

> have QuickFIX handle this situation more gracefully if we consider=20
> such a situation equivalent to an infinite request as such:
>
>   if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
>        beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D =
999999 ||
>        endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle=20=

> bizarrely large numbers
>   { endSeqNo =3D getExpectedSenderNum() - 1; }
>
>
> On Oct 19, 2004, at 7:08 AM, Shamanth wrote:
>
>> Hi
>>
>> I am using quickfix 1.8,
>>
>> While testing due to some network problems we got disconnected from=20=

>> the "Acceptor". In the mean time, our "initiator" tried reconnecting=20=

>> to the "acceptor" every 30secs.
>>
>>  It tried it 8 times before it could get an ack for its logon =
message.
>>
>>
>> Problem1: Our initiator, sent 8 logon messages and only the 9th logon=20=

>> message was ack by the acceptor. But in the meantime, our initiator=20=

>> incremented its MsgSeqNo, so when both the initiator and acceptor got=20=

>> connected, there was a mismatch of SeqNo, and the =93acceptor=94 send =
a=20
>> resendRequest to the =93initiator=94
>>
>> Question: Is there a way we can prevent the quickfix initiator from=20=

>> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>>
>> NOTE: Only the SeqNo of the messages sent was incremented, while the=20=

>> SeqNo of the messages received was correct.
>>
>>
>>
>> Problem2: After connecting again the Acceptor sent, a resend request=20=

>> FROM: 0 TO: 2147483647, our initiator had not sent so many messages,=20=

>> so it considers it as an error condition and stops responding to the=20=

>> acceptor. Is =932147483647=94 the maximum value in resend request as =
per=20
>> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
>> considered as the maximum number?
>>
>> thanks
>>
>> R Shamanth

Re: [Quickfix-users] Logon Ack seqNo

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

Answer1:

No.  This is in fact normal behavior.  Whenever a message is sent the=20
sequence number has to be incremented.  Just because we did not receive=20=

an ack, does not necessarily mean the counter-party did not receive the=20=

logon.  If the sequence number was not incremented, and they had=20
actually received it without acknowledging, you would then encounter=20
disconnect scenarios due to too low sequence numbers at some point.  A=20=

much worse position to be in as it cannot be resolved automatically.

Having a sequence number that is too high isn't much of a problem since=20=

the two engines can resolve this on their own.  And since in this case=20=

we are talking about logon messages, all that is required is a single=20
gap fill message to put everything in order.

Answer2:

Depends on the version.  For FIX.4.2 and higher, the value should be 0.=20=

  For versions 4.1 and earlier, a special value of 999999 is used.  I'm=20=

a bit curious as to what is going on here.  Is both the initiator and=20
acceptor QuickFIX.  It seems strange because since QuickFIX 1.6, the=20
EndSeqNo is always send either 0 or 999999, never another value.  Based=20=

on this I'm guessing the acceptor in this scenario is not QuickFIX, is=20=

this correct?

As to the effect of the value 2147483647, I suspect your application=20
has stopped responding because you now got the message store trying to=20=

look up a hell of a lot of messages in a tight loop.  I suspect we can=20=

have QuickFIX handle this situation more gracefully if we consider such=20=

a situation equivalent to an infinite request as such:

   if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
        beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D =
999999 ||
        endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle=20=

bizarrely large numbers
   { endSeqNo =3D getExpectedSenderNum() - 1; }

On Oct 19, 2004, at 7:08 AM, Shamanth wrote:

> Hi
>
> I am using quickfix 1.8,
>
> While testing due to some network problems we got disconnected from=20
> the "Acceptor". In the mean time, our "initiator" tried reconnecting=20=

> to the "acceptor" every 30secs.
>
>  It tried it 8 times before it could get an ack for its logon message.
>
>  Problem1: Our initiator, sent 8 logon messages and only the 9th logon=20=

> message was ack by the acceptor. But in the meantime, our initiator=20
> incremented its MsgSeqNo, so when both the initiator and acceptor got=20=

> connected, there was a mismatch of SeqNo, and the =93acceptor=94 send =
a=20
> resendRequest to the =93initiator=94
>
> Question: Is there a way we can prevent the quickfix initiator from=20
> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the=20=

> SeqNo of the messages received was correct.
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request=20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages,=20=

> so it considers it as an error condition and stops responding to the=20=

> acceptor. Is =932147483647=94 the maximum value in resend request as =
per=20
> fix protocol or should =930=94(infinity) be considered as the max =
valueis=20
> considered as the maximum number?
>
> thanks
>  R Shamanth

[Quickfix-users] Logon Ack seqNo

[Shamanth <sha...@in...>]

Hi

I am using quickfix 1.8,

While testing due to some network problems we got disconnected from the =
"Acceptor". In the mean time, our "initiator" tried reconnecting to the =
"acceptor" every 30secs.=20
It tried it 8 times before it could get an ack for its logon message.=20

Problem1: Our initiator, sent 8 logon messages and only the 9th logon =
message was ack by the acceptor. But in the meantime, our initiator =
incremented its MsgSeqNo, so when both the initiator and acceptor got =
connected, there was a mismatch of SeqNo, and the "acceptor" send a =
resendRequest to the "initiator"
Question: Is there a way we can prevent the quickfix initiator from =
incrementing its SeqNo, if it did not receive Ack for its Logon msg.
NOTE: Only the SeqNo of the messages sent was incremented, while the =
SeqNo of the messages received was correct.


Problem2: After connecting again the Acceptor sent, a resend request =
FROM: 0 TO: 2147483647, our initiator had not sent so many messages, so =
it considers it as an error condition and stops responding to the =
acceptor. Is "2147483647" the maximum value in resend request as per fix =
protocol or should "0"(infinity) be considered as the max valueis =
considered as the maximum number?

thanks
R Shamanth

Re: [Quickfix-users] solaris 8 SIGSEV

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

Guido,

It looks like the crash is happening inside the STL, which I can't 
really explain.  I don't know, maybe there is something wrong with the 
installation.  Maybe try compiling against STL port and see if you 
still get such problems.

--oren

On Oct 14, 2004, at 2:28 AM, Guido Landi wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> i think you you mean this saying 'full stack trace'(but not so sure):
>
> root@ssfdb # /usr/local/bin/gdb ./ut
> GNU gdb 6.0
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
> details.
> This GDB was configured as "sparc-sun-solaris2.8"...
> (gdb) set arg '-p 1025'
> (gdb) run
> Starting program: /export/home/zeuli/svil/quickfix/src/.libs/ut '-p 
> 1025'
> [New LWP 1]
> [New LWP 2]
> [New LWP 3]
> <ut>
>   <output>
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string const,
> std::string>, std::_Select1st<std::pair<std::string const, 
> std::string> >,
> std::less<std::string>, std::allocator<std::pair<std::string const,
> std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
> __k=@0xff369034) at stl_tree.h:496
> 496           { return static_cast<_Const_Link_type>(__x->_M_right); }
> (gdb) bt
> #0  0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string 
> const,
> std::string>, std::_Select1st<std::pair<std::string const, 
> std::string> >,
> std::less<std::string>, std::allocator<std::pair<std::string const,
> std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
> __k=@0xff369034) at stl_tree.h:496
> #1  0xff2bd4a0 in FIX::Dictionary::getString(std::string const&, bool)
> const (
>     this=0xffbe6eb0, key=@0xff369034, capitalize=false) at 
> stl_map.h:513
> #2  0xff2b02cc in FIX::operator>>(std::istream&, 
> FIX::SessionSettings&) (
>     stream=@0xffbe6eb0, s=@0xff369034) at Fields.h:40
>
>
>
>
>> Guido,
>>
>> QuickFIX will not work with 2.96 even if you does compile.  Regardless
>> of the status of QF with this compiler, I wouldn't recommend any C++
>> development be done with it.  See this note from the gcc team:
>> http://gcc.gnu.org/gcc-2.96.html.  I would recommend upgrading to a 
>> 3.x
>> compiler or dropping down to 2.95
>>
>> As per your Solaris problems, can you provide a full stack trace
>> instead of a system call trace?
>>
>> --oren
>>
>> On Oct 13, 2004, at 9:38 AM, Guido Landi wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX FAQ:
>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>> hi list,
>>>
>>> i'm trying to use quickfix on solaris 8(sparc) but i have encoutered
>>> many
>>> problems:
>>> i can build version 1.9.0(with gnu-gcc and all dependancies listed on
>>> the
>>> INSTALL doc as the latest version found at sunfreeware.com) but all 
>>> the
>>> binary received a SIGSEV from the system, here is the output of the 
>>> ut
>>> test:
>>>
>>> root@ssfdb # ./ut -p 1025
>>> <ut>
>>>   <output>
>>> Segmentation Fault - core dumped
>>>
>>> And here is the ending part of a strace:
>>>
>>> ioctl(1, TCGETA, 0xFFBE6F8C)                    = 0
>>> <ut>
>>> write(1, " < u t >\n", 5)                       = 5
>>>   <output>
>>> write(1, "     < o u t p u t >\n", 11)          = 11
>>> open("/usr/share/lib/zoneinfo/MET", O_RDONLY)   = 3
>>> read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 755
>>> close(3)                                        = 0
>>> brk(0x00283660)                                 = 0
>>> brk(0x00285660)                                 = 0
>>> sigaction(SIGPIPE, 0xFFBE7010, 0x00000000)      = 0
>>> brk(0x00285660)                                 = 0
>>> brk(0x00289660)                                 = 0
>>>     Incurred fault #6, FLTBOUNDS  %pc = 0xFF3172A4
>>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>>     Received signal #11, SIGSEGV [default]
>>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>>         *** process killed ***
>>> root@me#
>>>
>>> has anyone experienced similar problem, or can anyone use quickfix on
>>> solaris without problems?
>>>
>>> 1.9.2 build but on my system but say:
>>> BUILD SUCCESSFUL
>>> [...]
>>> gcc -g -O2 -I/usr/local/include/libxml2 -I/include -I/include/solaris
>>> -o
>>> .libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib
>>> -L/usr/openwin/lib -L/usr/local/ssl/lib -lrt 
>>> /usr/local/lib/libxml2.so
>>> -lz
>>> -lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty
>>> -R/usr/local/lib
>>> Undefined                       first referenced
>>>  symbol                             in file
>>> std::basic_ifstream<char, std::char_traits<char> 
>>> >::basic_ifstream(char
>>> const*, std::_Ios_Openmode)C++/.libs/libquickfix.so
>>> [many other messages like this]
>>> ld: fatal: Symbol referencing errors. No output written to .libs/at
>>> collect2: ld returned 1 exit status
>>> *** Error code 1
>>>
>>> After stracing and debugging(with gdb) with no results(my c and unix
>>> internals skills are not enough) i tried to compile 1.9.2 on linux 
>>> and
>>> found another problem.  Dependencies on INSTALL docs does not 
>>> specify a
>>> gcc version to use, so i try with a RedHat AES 2.1 that comes with 
>>> gcc
>>> 2.96 but it wont compile saying:
>>>
>>> In file included from ../Field.h:32,
>>>                  from FieldBaseTestCase.h:26,
>>>                  from FieldBaseTestCase.cpp:27:
>>> ../FieldConvertors.h:32:18: limits: No such file or directory
>>>
>>> note that i can find a *ulimits* include for C++ on my system(that 
>>> seem
>>> something like a forward on the C limits.h)or a *limits.h* include 
>>> for
>>> plain C.
>>>
>>> After all i try with a version of SuSE that comes with gcc3 and it
>>> magically works!! ...but unfortunately i can't use SuSE for doing 
>>> that
>>> work.
>>>
>>>
>>> any hints or help would be appreciated!
>>> Guido Landi.
>>>
>>> p.s.
>>> excuse me but my english is poor as you can see!
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: IT Product Guide on
>>> ITManagersJournal
>>> Use IT products in your business? Tell us what you think of them. 
>>> Give
>>> us
>>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>>> out
>>> more
>>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>>> _______________________________________________
>>> Quickfix-users mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>>
>>
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] Problem parsing repeating group

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

Nathan,

We have duplicated and verified the presence of this bug in 1.9.2.  =20
This had actually already been fixed and checked into CVS.  The fix =20
will be made available in the upcoming 1.9.3, or you can get the latest =20=

from the CVS repository at any time.

--oren

On Oct 18, 2004, at 10:37 AM, Kidd, Nathan wrote:

> QuickFIX Documentation: =20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: =20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I an sending a security list request ("x") to a target server =20
> belonging to a
> 3rd party. In response I get a list of securitylist messages ("y").
>
> The FIX spec supplied by the 3rd party indicates that a user defined =20=

> field
> 6138 can occur within the Instrument component. I've therefore added =20=

> the user
> defined tag to the XML file we are using for validation.
>
> An example message (header not shown):
>
> 146=3D1=0155=3DMN
> =
5500K=0148=3D20=0122=3D8=01461=3DOCXXXS=01200=3D200411=01541=3D20041119=01=
225=3D20040823=01202=3D55=20
> =
00=01231=3D1=016138=3D1=01711=3D1=01311=3DMNX04EXE=0115=3DEUR=01320=3D1=01=
322=3D03E382B50000=01560=3D0=01=20
> 393=3D5015=01893=3DN=01325=3DN=0110=3D009=01
>
> However, quickfix doesn't read the message in correctly, and results =20=

> in field
> 711 being parsed twice. This means that when the body length check is =20=

> done,
> quickfix calculates it incorrectly, resulting in the following error:
>
> 20041018-15:07:19 : Invalid message: Expected BodyLength=3D242, =
Recieved
> BodyLength=3D236
>
> Debugging reveals that quickfix appears to be reading field 6138 as =20=

> part of
> the 711 group, and reading field 711 twice (hence the incorrect =20
> length).
>
> Does anyone recognised what I may have done incorrectly?
>
> Many thanks,
> Nathan
>
> This is from my xml:
>
>
>   <components>
>     <component name=3D"Instrument">
>       <field name=3D"Symbol" required=3D"Y" />
>       <field name=3D"SymbolSfx" required=3D"N" />
>       <field name=3D"SecurityID" required=3D"N" />
>       <field name=3D"SecurityIDSource" required=3D"N" />
>       <group name=3D"NoSecurityAltID" required=3D"N">
>         <field name=3D"SecurityAltID" required=3D"N" />
>         <field name=3D"SecurityAltIDSource" required=3D"N" />
>       </group>
>       <field name=3D"Product" required=3D"N" />
>       <field name=3D"CFICode" required=3D"N" />
>       <field name=3D"SecurityType" required=3D"N" />
>       <field name=3D"SecuritySubType" required=3D"N" />
>       <field name=3D"MaturityMonthYear" required=3D"N" />
>       <field name=3D"MaturityDate" required=3D"N" />
>       <field name=3D"CouponPaymentDate" required=3D"N" />
>       <field name=3D"IssueDate" required=3D"N" />
>       <field name=3D"RepoCollateralSecurityType" required=3D"N" />
>       <field name=3D"RepurchaseTerm" required=3D"N" />
>       <field name=3D"RepurchaseRate" required=3D"N" />
>       <field name=3D"Factor" required=3D"N" />
>       <field name=3D"CreditRating" required=3D"N" />
>       <field name=3D"InstrRegistry" required=3D"N" />
>       <field name=3D"CountryOfIssue" required=3D"N" />
>       <field name=3D"StateOrProvinceOfIssue" required=3D"N" />
>       <field name=3D"LocaleOfIssue" required=3D"N" />
>       <field name=3D"RedemptionDate" required=3D"N" />
>       <field name=3D"StrikePrice" required=3D"N" />
>       <field name=3D"StrikeCurrency" required=3D"N" />
>       <field name=3D"OptAttribute" required=3D"N" />
>       <field name=3D"ContractMultiplier" required=3D"N" />
>       <field name=3D"TickSize" required=3D"Y" />
>       <field name=3D"CouponRate" required=3D"N" />
>       <field name=3D"SecurityExchange" required=3D"N" />
>       <field name=3D"Issuer" required=3D"N" />
>       <field name=3D"EncodedIssuerLen" required=3D"N" />
>       <field name=3D"EncodedIssuer" required=3D"N" />
>       <field name=3D"SecurityDesc" required=3D"N" />
>       <field name=3D"EncodedSecurityDescLen" required=3D"N" />
>       <field name=3D"EncodedSecurityDesc" required=3D"N" />
>       <field name=3D"Pool" required=3D"N" />
>       <field name=3D"ContractSettlMonth" required=3D"N" />
>       <field name=3D"CPProgram" required=3D"N" />
>       <field name=3D"CPRegType" required=3D"N" />
>       <group name=3D"NoEvents" required=3D"N">
>         <field name=3D"EventType" required=3D"N" />
>         <field name=3D"EventDate" required=3D"N" />
>         <field name=3D"EventPx" required=3D"N" />
>         <field name=3D"EventText" required=3D"N" />
>       </group>
>       <field name=3D"DatedDate" required=3D"N" />
>       <field name=3D"InterestAccrualDate" required=3D"N" />
>     </component>
> <SNIP><SNIP><SNIP>
> 	<field number=3D"6138" name=3D"TickSize" type=3D"PRICE" />
> =09
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D=3D=3D=3D=3D=3D
> This message is for the sole use of the intended recipient. If you =20
> received
> this message in error please delete it and notify us. If this message =20=

> was
> misdirected, CSFB does not waive any confidentiality or privilege. =
CSFB
> retains and monitors electronic communications sent through its =20
> network.
> Instructions transmitted over this system are not binding on CSFB =20
> until they
> are confirmed by us. Message transmission is not guaranteed to be =20
> secure.
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D=3D=3D=3D=3D=3D
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on =20
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give =
=20
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
=20
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

RE: [Quickfix-users] Problem parsing repeating group

[Kidd, N. <nat...@cs...>]

I'm using version 1.9.2 on Solaris (I've linked with libxml2-2.4.13)

Cheers,
Nathan

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]
Sent: 18 October 2004 16:46
To: Kidd, Nathan
Cc: 'qui...@li...'
Subject: Re: [Quickfix-users] Problem parsing repeating group


Nathan, can you also please mention the version of QuickFIX you are  
running?

--oren

On Oct 18, 2004, at 10:37 AM, Kidd, Nathan wrote:

> QuickFIX Documentation:  
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:  
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I an sending a security list request ("x") to a target server  
> belonging to a
> 3rd party. In response I get a list of securitylist messages ("y").
>
> The FIX spec supplied by the 3rd party indicates that a user defined  
> field
> 6138 can occur within the Instrument component. I've therefore added  
> the user
> defined tag to the XML file we are using for validation.
>
> An example message (header not shown):
>
> 146=1
55=MN
> 5500K
48=20
22=8
461=OCXXXS
200=200411
541=20041119
225=20040823
202=55 
> 00
231=1
6138=1
711=1
311=MNX04EXE
15=EUR
320=1
322=03E382B50000
560=0
 
> 393=5015
893=N
325=N
10=009

>
> However, quickfix doesn't read the message in correctly, and results  
> in field
> 711 being parsed twice. This means that when the body length check is  
> done,
> quickfix calculates it incorrectly, resulting in the following error:
>
> 20041018-15:07:19 : Invalid message: Expected BodyLength=242, Recieved
> BodyLength=236
>
> Debugging reveals that quickfix appears to be reading field 6138 as  
> part of
> the 711 group, and reading field 711 twice (hence the incorrect  
> length).
>
> Does anyone recognised what I may have done incorrectly?
>
> Many thanks,
> Nathan
>
> This is from my xml:
>
>
>   <components>
>     <component name="Instrument">
>       <field name="Symbol" required="Y" />
>       <field name="SymbolSfx" required="N" />
>       <field name="SecurityID" required="N" />
>       <field name="SecurityIDSource" required="N" />
>       <group name="NoSecurityAltID" required="N">
>         <field name="SecurityAltID" required="N" />
>         <field name="SecurityAltIDSource" required="N" />
>       </group>
>       <field name="Product" required="N" />
>       <field name="CFICode" required="N" />
>       <field name="SecurityType" required="N" />
>       <field name="SecuritySubType" required="N" />
>       <field name="MaturityMonthYear" required="N" />
>       <field name="MaturityDate" required="N" />
>       <field name="CouponPaymentDate" required="N" />
>       <field name="IssueDate" required="N" />
>       <field name="RepoCollateralSecurityType" required="N" />
>       <field name="RepurchaseTerm" required="N" />
>       <field name="RepurchaseRate" required="N" />
>       <field name="Factor" required="N" />
>       <field name="CreditRating" required="N" />
>       <field name="InstrRegistry" required="N" />
>       <field name="CountryOfIssue" required="N" />
>       <field name="StateOrProvinceOfIssue" required="N" />
>       <field name="LocaleOfIssue" required="N" />
>       <field name="RedemptionDate" required="N" />
>       <field name="StrikePrice" required="N" />
>       <field name="StrikeCurrency" required="N" />
>       <field name="OptAttribute" required="N" />
>       <field name="ContractMultiplier" required="N" />
>       <field name="TickSize" required="Y" />
>       <field name="CouponRate" required="N" />
>       <field name="SecurityExchange" required="N" />
>       <field name="Issuer" required="N" />
>       <field name="EncodedIssuerLen" required="N" />
>       <field name="EncodedIssuer" required="N" />
>       <field name="SecurityDesc" required="N" />
>       <field name="EncodedSecurityDescLen" required="N" />
>       <field name="EncodedSecurityDesc" required="N" />
>       <field name="Pool" required="N" />
>       <field name="ContractSettlMonth" required="N" />
>       <field name="CPProgram" required="N" />
>       <field name="CPRegType" required="N" />
>       <group name="NoEvents" required="N">
>         <field name="EventType" required="N" />
>         <field name="EventDate" required="N" />
>         <field name="EventPx" required="N" />
>         <field name="EventText" required="N" />
>       </group>
>       <field name="DatedDate" required="N" />
>       <field name="InterestAccrualDate" required="N" />
>     </component>
> <SNIP><SNIP><SNIP>
> 	<field number="6138" name="TickSize" type="PRICE" />
> 	
>
> ======================================================================= 
> =======
> This message is for the sole use of the intended recipient. If you  
> received
> this message in error please delete it and notify us. If this message  
> was
> misdirected, CSFB does not waive any confidentiality or privilege. CSFB
> retains and monitors electronic communications sent through its  
> network.
> Instructions transmitted over this system are not binding on CSFB  
> until they
> are confirmed by us. Message transmission is not guaranteed to be  
> secure.
> ======================================================================= 
> =======
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on  
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give  
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out  
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>


==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

Re: [Quickfix-users] Problem parsing repeating group

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

Nathan, can you also please mention the version of QuickFIX you are =20
running?

--oren

On Oct 18, 2004, at 10:37 AM, Kidd, Nathan wrote:

> QuickFIX Documentation: =20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: =20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I an sending a security list request ("x") to a target server =20
> belonging to a
> 3rd party. In response I get a list of securitylist messages ("y").
>
> The FIX spec supplied by the 3rd party indicates that a user defined =20=

> field
> 6138 can occur within the Instrument component. I've therefore added =20=

> the user
> defined tag to the XML file we are using for validation.
>
> An example message (header not shown):
>
> 146=3D1=0155=3DMN
> =
5500K=0148=3D20=0122=3D8=01461=3DOCXXXS=01200=3D200411=01541=3D20041119=01=
225=3D20040823=01202=3D55=20
> =
00=01231=3D1=016138=3D1=01711=3D1=01311=3DMNX04EXE=0115=3DEUR=01320=3D1=01=
322=3D03E382B50000=01560=3D0=01=20
> 393=3D5015=01893=3DN=01325=3DN=0110=3D009=01
>
> However, quickfix doesn't read the message in correctly, and results =20=

> in field
> 711 being parsed twice. This means that when the body length check is =20=

> done,
> quickfix calculates it incorrectly, resulting in the following error:
>
> 20041018-15:07:19 : Invalid message: Expected BodyLength=3D242, =
Recieved
> BodyLength=3D236
>
> Debugging reveals that quickfix appears to be reading field 6138 as =20=

> part of
> the 711 group, and reading field 711 twice (hence the incorrect =20
> length).
>
> Does anyone recognised what I may have done incorrectly?
>
> Many thanks,
> Nathan
>
> This is from my xml:
>
>
>   <components>
>     <component name=3D"Instrument">
>       <field name=3D"Symbol" required=3D"Y" />
>       <field name=3D"SymbolSfx" required=3D"N" />
>       <field name=3D"SecurityID" required=3D"N" />
>       <field name=3D"SecurityIDSource" required=3D"N" />
>       <group name=3D"NoSecurityAltID" required=3D"N">
>         <field name=3D"SecurityAltID" required=3D"N" />
>         <field name=3D"SecurityAltIDSource" required=3D"N" />
>       </group>
>       <field name=3D"Product" required=3D"N" />
>       <field name=3D"CFICode" required=3D"N" />
>       <field name=3D"SecurityType" required=3D"N" />
>       <field name=3D"SecuritySubType" required=3D"N" />
>       <field name=3D"MaturityMonthYear" required=3D"N" />
>       <field name=3D"MaturityDate" required=3D"N" />
>       <field name=3D"CouponPaymentDate" required=3D"N" />
>       <field name=3D"IssueDate" required=3D"N" />
>       <field name=3D"RepoCollateralSecurityType" required=3D"N" />
>       <field name=3D"RepurchaseTerm" required=3D"N" />
>       <field name=3D"RepurchaseRate" required=3D"N" />
>       <field name=3D"Factor" required=3D"N" />
>       <field name=3D"CreditRating" required=3D"N" />
>       <field name=3D"InstrRegistry" required=3D"N" />
>       <field name=3D"CountryOfIssue" required=3D"N" />
>       <field name=3D"StateOrProvinceOfIssue" required=3D"N" />
>       <field name=3D"LocaleOfIssue" required=3D"N" />
>       <field name=3D"RedemptionDate" required=3D"N" />
>       <field name=3D"StrikePrice" required=3D"N" />
>       <field name=3D"StrikeCurrency" required=3D"N" />
>       <field name=3D"OptAttribute" required=3D"N" />
>       <field name=3D"ContractMultiplier" required=3D"N" />
>       <field name=3D"TickSize" required=3D"Y" />
>       <field name=3D"CouponRate" required=3D"N" />
>       <field name=3D"SecurityExchange" required=3D"N" />
>       <field name=3D"Issuer" required=3D"N" />
>       <field name=3D"EncodedIssuerLen" required=3D"N" />
>       <field name=3D"EncodedIssuer" required=3D"N" />
>       <field name=3D"SecurityDesc" required=3D"N" />
>       <field name=3D"EncodedSecurityDescLen" required=3D"N" />
>       <field name=3D"EncodedSecurityDesc" required=3D"N" />
>       <field name=3D"Pool" required=3D"N" />
>       <field name=3D"ContractSettlMonth" required=3D"N" />
>       <field name=3D"CPProgram" required=3D"N" />
>       <field name=3D"CPRegType" required=3D"N" />
>       <group name=3D"NoEvents" required=3D"N">
>         <field name=3D"EventType" required=3D"N" />
>         <field name=3D"EventDate" required=3D"N" />
>         <field name=3D"EventPx" required=3D"N" />
>         <field name=3D"EventText" required=3D"N" />
>       </group>
>       <field name=3D"DatedDate" required=3D"N" />
>       <field name=3D"InterestAccrualDate" required=3D"N" />
>     </component>
> <SNIP><SNIP><SNIP>
> 	<field number=3D"6138" name=3D"TickSize" type=3D"PRICE" />
> =09
>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D=3D=3D=3D=3D=3D
> This message is for the sole use of the intended recipient. If you =20
> received
> this message in error please delete it and notify us. If this message =20=

> was
> misdirected, CSFB does not waive any confidentiality or privilege. =
CSFB
> retains and monitors electronic communications sent through its =20
> network.
> Instructions transmitted over this system are not binding on CSFB =20
> until they
> are confirmed by us. Message transmission is not guaranteed to be =20
> secure.
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D=3D=3D=3D=3D=3D
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on =20
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give =
=20
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
=20
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

[Quickfix-users] Problem parsing repeating group

[Kidd, N. <nat...@cs...>]

I an sending a security list request ("x") to a target server belonging to a
3rd party. In response I get a list of securitylist messages ("y").

The FIX spec supplied by the 3rd party indicates that a user defined field
6138 can occur within the Instrument component. I've therefore added the user
defined tag to the XML file we are using for validation.

An example message (header not shown):

146=1
55=MN
5500K
48=20
22=8
461=OCXXXS
200=200411
541=20041119
225=20040823
202=5500
231=1
6138=1
711=1
311=MNX04EXE
15=EUR
320=1
322=03E382B50000
560=0
393=5015
893=N
325=N
10=009


However, quickfix doesn't read the message in correctly, and results in field
711 being parsed twice. This means that when the body length check is done,
quickfix calculates it incorrectly, resulting in the following error:

20041018-15:07:19 : Invalid message: Expected BodyLength=242, Recieved
BodyLength=236

Debugging reveals that quickfix appears to be reading field 6138 as part of
the 711 group, and reading field 711 twice (hence the incorrect length).

Does anyone recognised what I may have done incorrectly?

Many thanks,
Nathan

This is from my xml:


  <components>
    <component name="Instrument">
      <field name="Symbol" required="Y" />
      <field name="SymbolSfx" required="N" />
      <field name="SecurityID" required="N" />
      <field name="SecurityIDSource" required="N" />
      <group name="NoSecurityAltID" required="N">
        <field name="SecurityAltID" required="N" />
        <field name="SecurityAltIDSource" required="N" />
      </group>
      <field name="Product" required="N" />
      <field name="CFICode" required="N" />
      <field name="SecurityType" required="N" />
      <field name="SecuritySubType" required="N" />
      <field name="MaturityMonthYear" required="N" />
      <field name="MaturityDate" required="N" />
      <field name="CouponPaymentDate" required="N" />
      <field name="IssueDate" required="N" />
      <field name="RepoCollateralSecurityType" required="N" />
      <field name="RepurchaseTerm" required="N" />
      <field name="RepurchaseRate" required="N" />
      <field name="Factor" required="N" />
      <field name="CreditRating" required="N" />
      <field name="InstrRegistry" required="N" />
      <field name="CountryOfIssue" required="N" />
      <field name="StateOrProvinceOfIssue" required="N" />
      <field name="LocaleOfIssue" required="N" />
      <field name="RedemptionDate" required="N" />
      <field name="StrikePrice" required="N" />
      <field name="StrikeCurrency" required="N" />
      <field name="OptAttribute" required="N" />
      <field name="ContractMultiplier" required="N" />
      <field name="TickSize" required="Y" />
      <field name="CouponRate" required="N" />
      <field name="SecurityExchange" required="N" />
      <field name="Issuer" required="N" />
      <field name="EncodedIssuerLen" required="N" />
      <field name="EncodedIssuer" required="N" />
      <field name="SecurityDesc" required="N" />
      <field name="EncodedSecurityDescLen" required="N" />
      <field name="EncodedSecurityDesc" required="N" />
      <field name="Pool" required="N" />
      <field name="ContractSettlMonth" required="N" />
      <field name="CPProgram" required="N" />
      <field name="CPRegType" required="N" />
      <group name="NoEvents" required="N">
        <field name="EventType" required="N" />
        <field name="EventDate" required="N" />
        <field name="EventPx" required="N" />
        <field name="EventText" required="N" />
      </group>
      <field name="DatedDate" required="N" />
      <field name="InterestAccrualDate" required="N" />
    </component>
<SNIP><SNIP><SNIP>
	<field number="6138" name="TickSize" type="PRICE" />
	

==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

Re: [Quickfix-users] solaris 8 SIGSEV

[Guido L. <gui...@in...>]

i think you you mean this saying 'full stack trace'(but not so sure):

root@ssfdb # /usr/local/bin/gdb ./ut
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) set arg '-p 1025'
(gdb) run
Starting program: /export/home/zeuli/svil/quickfix/src/.libs/ut '-p 1025'
[New LWP 1]
[New LWP 2]
[New LWP 3]
<ut>
  <output>

Program received signal SIGSEGV, Segmentation fault.
0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string const,
std::string>, std::_Select1st<std::pair<std::string const, std::string> >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
__k=@0xff369034) at stl_tree.h:496
496           { return static_cast<_Const_Link_type>(__x->_M_right); }
(gdb) bt
#0  0xff3172a4 in std::_Rb_tree<std::string, std::pair<std::string const,
std::string>, std::_Select1st<std::pair<std::string const, std::string> >,
std::less<std::string>, std::allocator<std::pair<std::string const,
std::string> > >::find(std::string const&) const (this=0xffbe6eb4,
__k=@0xff369034) at stl_tree.h:496
#1  0xff2bd4a0 in FIX::Dictionary::getString(std::string const&, bool)
const (
    this=0xffbe6eb0, key=@0xff369034, capitalize=false) at stl_map.h:513
#2  0xff2b02cc in FIX::operator>>(std::istream&, FIX::SessionSettings&) (
    stream=@0xffbe6eb0, s=@0xff369034) at Fields.h:40




> Guido,
>
> QuickFIX will not work with 2.96 even if you does compile.  Regardless
> of the status of QF with this compiler, I wouldn't recommend any C++
> development be done with it.  See this note from the gcc team:
> http://gcc.gnu.org/gcc-2.96.html.  I would recommend upgrading to a 3.x
> compiler or dropping down to 2.95
>
> As per your Solaris problems, can you provide a full stack trace
> instead of a system call trace?
>
> --oren
>
> On Oct 13, 2004, at 9:38 AM, Guido Landi wrote:
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ:
>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> hi list,
>>
>> i'm trying to use quickfix on solaris 8(sparc) but i have encoutered
>> many
>> problems:
>> i can build version 1.9.0(with gnu-gcc and all dependancies listed on
>> the
>> INSTALL doc as the latest version found at sunfreeware.com) but all the
>> binary received a SIGSEV from the system, here is the output of the ut
>> test:
>>
>> root@ssfdb # ./ut -p 1025
>> <ut>
>>   <output>
>> Segmentation Fault - core dumped
>>
>> And here is the ending part of a strace:
>>
>> ioctl(1, TCGETA, 0xFFBE6F8C)                    = 0
>> <ut>
>> write(1, " < u t >\n", 5)                       = 5
>>   <output>
>> write(1, "     < o u t p u t >\n", 11)          = 11
>> open("/usr/share/lib/zoneinfo/MET", O_RDONLY)   = 3
>> read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 755
>> close(3)                                        = 0
>> brk(0x00283660)                                 = 0
>> brk(0x00285660)                                 = 0
>> sigaction(SIGPIPE, 0xFFBE7010, 0x00000000)      = 0
>> brk(0x00285660)                                 = 0
>> brk(0x00289660)                                 = 0
>>     Incurred fault #6, FLTBOUNDS  %pc = 0xFF3172A4
>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>     Received signal #11, SIGSEGV [default]
>>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>>         *** process killed ***
>> root@me#
>>
>> has anyone experienced similar problem, or can anyone use quickfix on
>> solaris without problems?
>>
>> 1.9.2 build but on my system but say:
>> BUILD SUCCESSFUL
>> [...]
>> gcc -g -O2 -I/usr/local/include/libxml2 -I/include -I/include/solaris
>> -o
>> .libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib
>> -L/usr/openwin/lib -L/usr/local/ssl/lib -lrt /usr/local/lib/libxml2.so
>> -lz
>> -lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty
>> -R/usr/local/lib
>> Undefined                       first referenced
>>  symbol                             in file
>> std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char
>> const*, std::_Ios_Openmode)C++/.libs/libquickfix.so
>> [many other messages like this]
>> ld: fatal: Symbol referencing errors. No output written to .libs/at
>> collect2: ld returned 1 exit status
>> *** Error code 1
>>
>> After stracing and debugging(with gdb) with no results(my c and unix
>> internals skills are not enough) i tried to compile 1.9.2 on linux and
>> found another problem.  Dependencies on INSTALL docs does not specify a
>> gcc version to use, so i try with a RedHat AES 2.1 that comes with gcc
>> 2.96 but it wont compile saying:
>>
>> In file included from ../Field.h:32,
>>                  from FieldBaseTestCase.h:26,
>>                  from FieldBaseTestCase.cpp:27:
>> ../FieldConvertors.h:32:18: limits: No such file or directory
>>
>> note that i can find a *ulimits* include for C++ on my system(that seem
>> something like a forward on the C limits.h)or a *limits.h* include for
>> plain C.
>>
>> After all i try with a version of SuSE that comes with gcc3 and it
>> magically works!! ...but unfortunately i can't use SuSE for doing that
>> work.
>>
>>
>> any hints or help would be appreciated!
>> Guido Landi.
>>
>> p.s.
>> excuse me but my english is poor as you can see!
>>
>>
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on
>> ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. Give
>> us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
>> more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Quickfix-users mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>>
>
>

Re: [Quickfix-users] solaris 8 SIGSEV

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

Guido,

QuickFIX will not work with 2.96 even if you does compile.  Regardless 
of the status of QF with this compiler, I wouldn't recommend any C++ 
development be done with it.  See this note from the gcc team: 
http://gcc.gnu.org/gcc-2.96.html.  I would recommend upgrading to a 3.x 
compiler or dropping down to 2.95

As per your Solaris problems, can you provide a full stack trace 
instead of a system call trace?

--oren

On Oct 13, 2004, at 9:38 AM, Guido Landi wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> hi list,
>
> i'm trying to use quickfix on solaris 8(sparc) but i have encoutered 
> many
> problems:
> i can build version 1.9.0(with gnu-gcc and all dependancies listed on 
> the
> INSTALL doc as the latest version found at sunfreeware.com) but all the
> binary received a SIGSEV from the system, here is the output of the ut
> test:
>
> root@ssfdb # ./ut -p 1025
> <ut>
>   <output>
> Segmentation Fault - core dumped
>
> And here is the ending part of a strace:
>
> ioctl(1, TCGETA, 0xFFBE6F8C)                    = 0
> <ut>
> write(1, " < u t >\n", 5)                       = 5
>   <output>
> write(1, "     < o u t p u t >\n", 11)          = 11
> open("/usr/share/lib/zoneinfo/MET", O_RDONLY)   = 3
> read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 755
> close(3)                                        = 0
> brk(0x00283660)                                 = 0
> brk(0x00285660)                                 = 0
> sigaction(SIGPIPE, 0xFFBE7010, 0x00000000)      = 0
> brk(0x00285660)                                 = 0
> brk(0x00289660)                                 = 0
>     Incurred fault #6, FLTBOUNDS  %pc = 0xFF3172A4
>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>     Received signal #11, SIGSEGV [default]
>       siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
>         *** process killed ***
> root@me#
>
> has anyone experienced similar problem, or can anyone use quickfix on
> solaris without problems?
>
> 1.9.2 build but on my system but say:
> BUILD SUCCESSFUL
> [...]
> gcc -g -O2 -I/usr/local/include/libxml2 -I/include -I/include/solaris 
> -o
> .libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib
> -L/usr/openwin/lib -L/usr/local/ssl/lib -lrt /usr/local/lib/libxml2.so 
> -lz
> -lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty
> -R/usr/local/lib
> Undefined                       first referenced
>  symbol                             in file
> std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char
> const*, std::_Ios_Openmode)C++/.libs/libquickfix.so
> [many other messages like this]
> ld: fatal: Symbol referencing errors. No output written to .libs/at
> collect2: ld returned 1 exit status
> *** Error code 1
>
> After stracing and debugging(with gdb) with no results(my c and unix
> internals skills are not enough) i tried to compile 1.9.2 on linux and
> found another problem.  Dependencies on INSTALL docs does not specify a
> gcc version to use, so i try with a RedHat AES 2.1 that comes with gcc
> 2.96 but it wont compile saying:
>
> In file included from ../Field.h:32,
>                  from FieldBaseTestCase.h:26,
>                  from FieldBaseTestCase.cpp:27:
> ../FieldConvertors.h:32:18: limits: No such file or directory
>
> note that i can find a *ulimits* include for C++ on my system(that seem
> something like a forward on the C limits.h)or a *limits.h* include for
> plain C.
>
> After all i try with a version of SuSE that comes with gcc3 and it
> magically works!! ...but unfortunately i can't use SuSE for doing that
> work.
>
>
> any hints or help would be appreciated!
> Guido Landi.
>
> p.s.
> excuse me but my english is poor as you can see!
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

[Quickfix-users] solaris 8 SIGSEV

[Guido L. <gui...@in...>]

hi list,

i'm trying to use quickfix on solaris 8(sparc) but i have encoutered many
problems:
i can build version 1.9.0(with gnu-gcc and all dependancies listed on the
INSTALL doc as the latest version found at sunfreeware.com) but all the
binary received a SIGSEV from the system, here is the output of the ut
test:

root@ssfdb # ./ut -p 1025
<ut>
  <output>
Segmentation Fault - core dumped

And here is the ending part of a strace:

ioctl(1, TCGETA, 0xFFBE6F8C)                    = 0
<ut>
write(1, " < u t >\n", 5)                       = 5
  <output>
write(1, "     < o u t p u t >\n", 11)          = 11
open("/usr/share/lib/zoneinfo/MET", O_RDONLY)   = 3
read(3, " T Z i f\0\0\0\0\0\0\0\0".., 8192)     = 755
close(3)                                        = 0
brk(0x00283660)                                 = 0
brk(0x00285660)                                 = 0
sigaction(SIGPIPE, 0xFFBE7010, 0x00000000)      = 0
brk(0x00285660)                                 = 0
brk(0x00289660)                                 = 0
    Incurred fault #6, FLTBOUNDS  %pc = 0xFF3172A4
      siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
    Received signal #11, SIGSEGV [default]
      siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFF4
        *** process killed ***
root@me#

has anyone experienced similar problem, or can anyone use quickfix on
solaris without problems?

1.9.2 build but on my system but say:
BUILD SUCCESSFUL
[...]
gcc -g -O2 -I/usr/local/include/libxml2 -I/include -I/include/solaris -o
.libs/at at.o  C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib
-L/usr/openwin/lib -L/usr/local/ssl/lib -lrt /usr/local/lib/libxml2.so -lz
-lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty
-R/usr/local/lib
Undefined                       first referenced
 symbol                             in file
std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char
const*, std::_Ios_Openmode)C++/.libs/libquickfix.so
[many other messages like this]
ld: fatal: Symbol referencing errors. No output written to .libs/at
collect2: ld returned 1 exit status
*** Error code 1

After stracing and debugging(with gdb) with no results(my c and unix
internals skills are not enough) i tried to compile 1.9.2 on linux and
found another problem.  Dependencies on INSTALL docs does not specify a
gcc version to use, so i try with a RedHat AES 2.1 that comes with gcc
2.96 but it wont compile saying:

In file included from ../Field.h:32,
                 from FieldBaseTestCase.h:26,
                 from FieldBaseTestCase.cpp:27:
../FieldConvertors.h:32:18: limits: No such file or directory

note that i can find a *ulimits* include for C++ on my system(that seem
something like a forward on the C limits.h)or a *limits.h* include for
plain C.

After all i try with a version of SuSE that comes with gcc3 and it
magically works!! ...but unfortunately i can't use SuSE for doing that
work.


any hints or help would be appreciated!
Guido Landi.

p.s.
excuse me but my english is poor as you can see!