quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Problem in Sending andRecievingmessagesusingQuickFIX

[Pramod.S.Warrier <pwa...@in...>]

Hi,
    I dont think that is the case. Because its not the quickfix which is issuing the Logoff message. Its the SunGard Engine that is
closing the connection and sending my program the logoff message (onLogoff function is being called). And its written in the log file of
SunGard that this may be because of some communication problem. As for my initiator its only sending Logon messages to the SunGrad
acceptor. And retrying after the ReconnectInterval specified after it gets a Logoff message from the other side.
    So i would like to know the possible reasons for getting these communication problems using QuickFIX ?

Thanks and Regards,
Pramod.


OM...@th... wrote:

> The other possibility is that SunGuard is sending a sequence number that is
> lower than QuickFIX is expecting.  This would cause QuickFIX to immediately
> kill the connection.
>
> --oren
>

Re: [Quickfix-developers] Problem in Sending and RecievingmessagesusingQuickFIX

[<OM...@th...>]

The other possibility is that SunGuard is sending a sequence number that is
lower than QuickFIX is expecting.  This would cause QuickFIX to immediately
kill the connection.

--oren


                                                                                                                                              
                      "Pramod.S.Warrier"                                                                                                      
                      @THOUGHTWORKS_COM               To:       OM...@th...                                                      
                      Sent by:                        cc:       PJS...@Th..., qui...@li...,        
                      pramod@THOUGHTWORKS_COM          qui...@li...                                        
                                                      Subject:  Re: [Quickfix-developers] Problem in Sending and                              
                                                       RecievingmessagesusingQuickFIX                                                         
                      08/06/2002 09:05 AM                                                                                                     
                                                                                                                                              
                                                                                                                                              




Hi,
    Yes they are on different messages. And as you suggested, first the
problem was because of the Time not being
synchronised and that was displyed in the log file generated by the SunGard
Engine and in the quickfix logs also I used to
get the error message (Sending Time Problem).
    But now I have syncronised the time and the error messages that I had
mailed you earlier were after making those changes.
Are there any other issues due to which such communication problems can
arise? I mean are there any reasons for the initiator
not recieving the messages that are sent to it ?

    Besides I also have another query. I wanted to know if I could test the
messages that are being generated by my initiator
program without having to write the whole acceptor program ? I mean some
site or some other application which will take as
input any FIX messages generated by my initiator and give as output whether
the message is valid or not.

Thanks and Rgds,
Pramod.


OM...@th... wrote:

> Are they on different machines?  First thing I would check is that their
> clocks are synchronized (by default within 120 seconds of each other).
> Alternatively you can turn this check off in QuickFIX by setting the
> CheckLatency config to N.  You can also change the amount of acceptable
> latency by setting the MaxLatency field.
>
> I definately think it is time to institute some quality logging into
> QuickFIX...
>
> --oren
>
(See attached file: pwarrier.vcf)

Re: [Quickfix-developers] Problem in Sending and RecievingmessagesusingQuickFIX

[Pramod.S.Warrier <pwa...@in...>]

Hi,
    Yes they are on different messages. And as you suggested, first the problem was because of the Time not being
synchronised and that was displyed in the log file generated by the SunGard Engine and in the quickfix logs also I used to
get the error message (Sending Time Problem).
    But now I have syncronised the time and the error messages that I had mailed you earlier were after making those changes.
Are there any other issues due to which such communication problems can arise? I mean are there any reasons for the initiator
not recieving the messages that are sent to it ?

    Besides I also have another query. I wanted to know if I could test the messages that are being generated by my initiator
program without having to write the whole acceptor program ? I mean some site or some other application which will take as
input any FIX messages generated by my initiator and give as output whether the message is valid or not.

Thanks and Rgds,
Pramod.


OM...@th... wrote:

> Are they on different machines?  First thing I would check is that their
> clocks are synchronized (by default within 120 seconds of each other).
> Alternatively you can turn this check off in QuickFIX by setting the
> CheckLatency config to N.  You can also change the amount of acceptable
> latency by setting the MaxLatency field.
>
> I definately think it is time to institute some quality logging into
> QuickFIX...
>
> --oren
>

Re: [Quickfix-developers] Problem in Sending and Recieving messagesusingQuickFIX

[<OM...@th...>]

Are they on different machines?  First thing I would check is that their
clocks are synchronized (by default within 120 seconds of each other).
Alternatively you can turn this check off in QuickFIX by setting the
CheckLatency config to N.  You can also change the amount of acceptable
latency by setting the MaxLatency field.

I definately think it is time to institute some quality logging into
QuickFIX...

--oren



                                                                                                                                              
                      "Pramod.S.Warrier"                                                                                                      
                      @THOUGHTWORKS_COM               To:       OM...@th...                                                      
                      Sent by:                        cc:       qui...@li...,                                    
                      pramod@THOUGHTWORKS_COM          qui...@li...                                        
                                                      Subject:  Re: [Quickfix-developers] Problem in Sending and Recieving                    
                                                       messagesusingQuickFIX                                                                  
                      08/06/2002 08:31 AM                                                                                                     
                                                                                                                                              
                                                                                                                                              




Hi,
    Yes you were exactly right. When I made the changes in the cfg file
(pointed the DataDictionaryPath to the place where my XML file was) , my
acceptor has started
receiving the messages with Repeating Groups also.
    Thanks for the help.

    Besides I have one more doubt and I hope you can help me out. The
problem is that, I am now trying to use my initiator with the acceptor
which uses SunGard FIXEngine
4.5. Here when I am trying to Logon, I am always receiving Logout message.
That is because the authentication is failing or some other problem. But
when I look at the Logs
of the SunGard program, it shows that it had received the Logon message
from my initiator and it had also sent me the Logon message in response.
But I am not receiving this
message. Besides this, the logs of the SunGard program says that there is
some communication problem.
    What could be the possible area where I am erring? And what are the
possible reasons for communication problem ? I have posted this query to
SunGard  also. But if u
could help me out then it would be really great !!

Thanx and Rgds,
Pramod.

OM...@th... wrote:

> Ok, this is what is probably going on.  In order to parse messages with
> repeating groups, you must supply a data dictionary to your receiving
> application.  It is the data dictionary that tells your app how to
properly
> parse these messages.  FIX has certain rules about which field is the
> delimiter, what order these fields need to be in etc.  What is probably
> happening is you don't have your data dictionary set to anything.  It is
> therefore considering the message garbled and the engine is ignoring it.
> I'd say try assigining the FIX42.xml as the data dictionary to your
> acceptor and see if you get better results.
>
> --oren
>
(See attached file: pwarrier.vcf)

Re: [Quickfix-developers] Problem in Sending and Recieving messagesusingQuickFIX

[Pramod.S.Warrier <pwa...@in...>]

Hi,
    Yes you were exactly right. When I made the changes in the cfg file (pointed the DataDictionaryPath to the place where my XML file was) , my acceptor has started
receiving the messages with Repeating Groups also.
    Thanks for the help.

    Besides I have one more doubt and I hope you can help me out. The problem is that, I am now trying to use my initiator with the acceptor which uses SunGard FIXEngine
4.5. Here when I am trying to Logon, I am always receiving Logout message. That is because the authentication is failing or some other problem. But when I look at the Logs
of the SunGard program, it shows that it had received the Logon message from my initiator and it had also sent me the Logon message in response. But I am not receiving this
message. Besides this, the logs of the SunGard program says that there is some communication problem.
    What could be the possible area where I am erring? And what are the possible reasons for communication problem ? I have posted this query to SunGard  also. But if u
could help me out then it would be really great !!

Thanx and Rgds,
Pramod.

OM...@th... wrote:

> Ok, this is what is probably going on.  In order to parse messages with
> repeating groups, you must supply a data dictionary to your receiving
> application.  It is the data dictionary that tells your app how to properly
> parse these messages.  FIX has certain rules about which field is the
> delimiter, what order these fields need to be in etc.  What is probably
> happening is you don't have your data dictionary set to anything.  It is
> therefore considering the message garbled and the engine is ignoring it.
> I'd say try assigining the FIX42.xml as the data dictionary to your
> acceptor and see if you get better results.
>
> --oren
>

Re: [Quickfix-developers] Problem in Sending and Recieving messages usingQuickFIX

[<OM...@th...>]

Ok, this is what is probably going on.  In order to parse messages with
repeating groups, you must supply a data dictionary to your receiving
application.  It is the data dictionary that tells your app how to properly
parse these messages.  FIX has certain rules about which field is the
delimiter, what order these fields need to be in etc.  What is probably
happening is you don't have your data dictionary set to anything.  It is
therefore considering the message garbled and the engine is ignoring it.
I'd say try assigining the FIX42.xml as the data dictionary to your
acceptor and see if you get better results.

--oren



                                                                                                                                              
                      "Pramod.S.Warrier"                                                                                                      
                      @THOUGHTWORKS_COM               To:       OM...@th...                                                      
                      Sent by:                        cc:                                                                                     
                      pramod@THOUGHTWORKS_COM         Subject:  Re: [Quickfix-developers] Problem in Sending and Recieving messages           
                                                       usingQuickFIX                                                                          
                                                                                                                                              
                      08/06/2002 07:31 AM                                                                                                     
                                                                                                                                              
                                                                                                                                              




Hi,
    Thanks for the quick response.
    As for your query, the fromAdmin function of my initiator is also not
called and no reject message is received.
    Besides for your information, the message thats displayed in the log
file and the toApp function is as given below.

    The values i have entered is,
    SenderCompID = CLIENT1
    TargetCompID = TW
    NoRelatedSym = 2
    Symbol = IBM
    Symbol = INTEL
    QuoteReqID = QR1

    and the message i get is

8=FIX.4.2`9=78`35=R`34=8`49=CLIENT1`52=20020806-12:23:43`56=TW`131=QR1`146=2`55=IBM`55=INTEL`10=082


     What do you think are the possible areas where i could have erred ?
Besides i tried giving MassQuote and here too when theres a repeating group
then the message is not
recieved by the Acceptor. I hope theres no problems in the message that are
being generated.

Thanks,
Rgds,
Pramod.

OM...@th... wrote:

> Do you get anything in your fromAdmin on your initiator after sending the
> message?  Like maybe a reject message?
>
> --oren
>
> |---------+----------------------------------------------->
> |         |           "Pramod.S.Warrier"                  |
> |         |           <pwa...@in...>              |
> |         |           Sent by:                            |
> |         |           qui...@li...ur|
> |         |           ceforge.net                         |
> |         |                                               |
> |         |                                               |
> |         |           08/06/2002 04:13 AM                 |
> |         |                                               |
> |---------+----------------------------------------------->
>   >
----------------------------------------------------------------------------------------------|

>   |
|
>   |       To:       qui...@li...
|
>   |       cc:
|
>   |       Subject:  [Quickfix-developers] Problem in Sending and
Recieving messages using        |
>   |        QuickFIX
|
>   >
----------------------------------------------------------------------------------------------|

>
(See attached file: pwarrier.vcf)

Re: [Quickfix-developers] Problem in Sending and Recieving messages usingQuickFIX

[Pramod.S.Warrier <pwa...@in...>]

Hi,
    Thanks for the quick response.
    As for your query, the fromAdmin function of my initiator is also not called
and no reject message is received.
    Besides for your information, the message thats displayed in the log file and
the toApp function is as given below.

    The values i have entered is,
    SenderCompID = CLIENT1
    TargetCompID = TW
    NoRelatedSym = 2
    Symbol = IBM
    Symbol = INTEL
    QuoteReqID = QR1

    and the message i get is

8=FIX.4.2`9=78`35=R`34=8`49=CLIENT1`52=20020806-12:23:43`56=TW`131=QR1`146=2`55=IBM`55=INTEL`10=082

     What do you think are the possible areas where i could have erred ? Besides i
tried giving MassQuote and here too when theres a repeating group then the message
is not
recieved by the Acceptor. I hope theres no problems in the message that are being
generated.

Thanks,
Rgds,
Pramod.

OM...@th... wrote:

> Do you get anything in your fromAdmin on your initiator after sending the
> message?  Like maybe a reject message?
>
> --oren
>
> |---------+----------------------------------------------->
> |         |           "Pramod.S.Warrier"                  |
> |         |           <pwa...@in...>              |
> |         |           Sent by:                            |
> |         |           qui...@li...ur|
> |         |           ceforge.net                         |
> |         |                                               |
> |         |                                               |
> |         |           08/06/2002 04:13 AM                 |
> |         |                                               |
> |---------+----------------------------------------------->

Re: [Quickfix-developers] Problem in Sending and Recieving messages using QuickFIX

[<OM...@th...>]

Do you get anything in your fromAdmin on your initiator after sending the
message?  Like maybe a reject message?

--oren



|---------+----------------------------------------------->
|         |           "Pramod.S.Warrier"                  |
|         |           <pwa...@in...>              |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           08/06/2002 04:13 AM                 |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       qui...@li...                                    |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] Problem in Sending and Recieving messages using        |
  |        QuickFIX                                                                              |
  >----------------------------------------------------------------------------------------------|




Hi,
  I am using the quickfix engine and I am new to it. I am using the FIX 4.2
version.
  I am trying to implement an initiator which will send QuoteRequest
message to an acceptor. It works fine when I specific the NoRelatedSym=1.
i.e., The acceptor receives
the QuoteRequest message sent by my initiator program. But when I use
Repeating Groups (NoRelatedSym > 1), then the acceptor does not receive the
messages  send by the
initiator (fromApp function in Acceptor is not called). But in the
initiator program it shows that it has sent the message to the acceptor and
the message sent is also
logged in the Log File which is created.
   I don't know where I am going wrong. So it would be really great if
someone could please me help out.

Rgds,
Pramod.
(See attached file: pwarrier.vcf)

[Quickfix-developers] Problem in Sending and Recieving messages using QuickFIX

[Pramod.S.Warrier <pwa...@in...>]

Hi,
  I am using the quickfix engine and I am new to it. I am using the FIX 4.2 version.
  I am trying to implement an initiator which will send QuoteRequest message to an acceptor. It works fine when I specific the NoRelatedSym=1. i.e., The acceptor receives
the QuoteRequest message sent by my initiator program. But when I use Repeating Groups (NoRelatedSym > 1), then the acceptor does not receive the messages  send by the
initiator (fromApp function in Acceptor is not called). But in the initiator program it shows that it has sent the message to the acceptor and the message sent is also
logged in the Log File which is created.
   I don't know where I am going wrong. So it would be really great if someone could please me help out.

Rgds,
Pramod.

Re: [Quickfix-developers] compile problems with tradeclientgui

[<OM...@th...>]

Alex,

We did receive it however we have not had a change to try it out yet.  We
are finishing our effort for our next release, which primarily focuses on
the new .NET wrapper, making the current java API more consistent with the
C++ one, and improving our parsing of the FIX specs.  After we have
completed these tasks, we will probably focus on adding support for FIX 4.3
and get the JAVA API functional under linux/solaris.

--oren



                                                                                                                                       
                      Alex Hornby                                                                                                      
                      <al...@an...        To:       OM...@th...                                                      
                      >                        cc:       kd...@in..., quickfix-developers                                       
                                                <qui...@li...>,                                           
                      08/01/2002 06:39          qui...@li...                                        
                      AM                       Subject:  Re: [Quickfix-developers] compile problems with tradeclientgui                
                                                                                                                                       
                                                                                                                                       




On Tue, 2002-07-09 at 22:32, OM...@th... wrote:
>
> Well that's a tough call.  The reason we don't currently support JAVA for
> linux is that gcc (at least in our experience) has some issues throwing
> exceptions from shared objects (the JNI layer must be in a shared object
> for JAVA to access it). We are currently trying to isolate the problem to
> determine if there is something we can do.  The avenues we are currently
> exploring are 1) gettings exceptions to work correctly in shared objects,
> 2) representing the logic without exceptions, 3) using some piece in the
> middle to isolate the JNI layer from the exceptions.  We will keep
everyone
> updated when we have found a solution.  It would also be very helpful to
> get some assistance from anyone who has experience with exceptions in
> shared objects.
>
> --oren
>

Hi Oren,

Did the Linux JNI exception example I sent work for you?

Alex.

Re: [Quickfix-developers] compile problems with tradeclientgui

[Alex H. <al...@an...>]

On Tue, 2002-07-09 at 22:32, OM...@th... wrote:
> 
> Well that's a tough call.  The reason we don't currently support JAVA for
> linux is that gcc (at least in our experience) has some issues throwing
> exceptions from shared objects (the JNI layer must be in a shared object
> for JAVA to access it). We are currently trying to isolate the problem to
> determine if there is something we can do.  The avenues we are currently
> exploring are 1) gettings exceptions to work correctly in shared objects,
> 2) representing the logic without exceptions, 3) using some piece in the
> middle to isolate the JNI layer from the exceptions.  We will keep everyone
> updated when we have found a solution.  It would also be very helpful to
> get some assistance from anyone who has experience with exceptions in
> shared objects.
> 
> --oren
> 

Hi Oren,

Did the Linux JNI exception example I sent work for you?

Alex.

[Quickfix-developers] RE: ThreadedSocketInitiator sync problems in 1.1.1

[John C. <joh...@ho...>]

I have seen something which I believe may be similar.  On a 1 CPU =
system, all acceptance tests using SocketAcceptor (runat) succeed.  On a =
2 CPU system with an identical software configuration, same acceptance =
tests fail nondeterministically.  On the 2 CPU system, all acceptance =
tests succeed when ThreadedSocketAcceptor (runat_threaded) is used.

My configuration is: RH 7.2, gcc 3.0.2, quickfix 1.1.1

John Coppinger

[Quickfix-developers] Getting Limit Prices, MatureMonthYear, etc...

[Justin P. <jp...@Xw...>]

Before placing a trade I need to get the current limit price for a
stock, does anyone know a good unix solution to getting that solution
(without using the FIX quotes?)

Thanks,
Justin

Re: [Quickfix-developers] ThreadedSocketInitiator sync problems in 1.1.1

[<OM...@th...>]

Thanks for the information.  We will look into all of these.  We are also
looking at starting to use one of the framework libraries for threading and
sockets.  The one that looks most interesting to me right now is commonc++,
which is the GNU framework.

Do you or does anyone else on the list have any experiences they can share
about what frameworks they have used and how good they are?

--oren



|---------+----------------------------------------------->
|         |           Gene Gorokhovsky                    |
|         |           <mus...@ya...>                |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           07/23/2002 02:52 AM                 |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       qui...@li...                                    |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] ThreadedSocketInitiator sync problems in 1.1.1         |
  >----------------------------------------------------------------------------------------------|




I wrote a pair of buyer/exchange apps borrowing
liberally from the sample code and using quickfix
threaded acceptor/initiator classes. Buyer app
initiates connection and in the App::OnRun generates
SingleOrderRequests in a tight loop. Once a sufficient
number of requests have been generated onRun exits.

I have run into a few sync problem scenarios in the
buyer app:
Scenario 1:
once onRun returns, ThreadedSocketInitiator returns
control from OnStart to main app, which tries to clean
up, Virtual destructor chain is called, getting to
~Initiator. Initiator cleans up all the session
pointers, with guarding mutex wide open because while
ThreadedSocketInitiator is derived from Initiator,
both of them have their separate private m_mutex.

Meanwhile the connection queue and SocketThread both
need pointer to Initiator and its sessions on other
threads. readQueue thread makes a call Session->next
and calling a method of a deleted pointer leads to sad
consequences.

The above problem will probably go away once
ThreadedSocketInitiator uses Initiator's m_mutex
(which will have to be "protected" instead of
"private") or guards its own destructor with its own
m_mutex.


Another independent scenario which manifested itself
once I added code to post a logout message in my
buyer's onRun before exiting.


Two threads of the Threadedinitiator are  deadlocked.
One sits in OnStop. It has grabbed the mutex, and is
waiting to join the SocketThread. The SocketThread
however is also trying to get out. It wants to
unregister by calling removeThread, but the mutex has
been grabbed by onStop which is waiting for
SocketThread to return...
The problem is complicated because SocketThread is
attempting to close its own handle (by the way,
pthread_detach has to be called on pthread systems,
similarly to CloseHandle), which of course makes it
impossible to join from elsewhere(for instance from
OnStop).  The solution here is to not close handle and
erase the pair from the threads map during shutdown
processing (when m_stop is raised), and instead
relegate this to the thread that performes the join.

Here it would be helpful to use a robust Thread class,
which would make sure that handle is cleaned up both
after join and in destruction. Although not without a
fault,a decent portable implementation of such class
is  in the Boost Thread library
(http://www.boost.org/libs/thread/doc/index.html) That
implementation also includes a thread_group class
which is quite similar in functionality to
SocketToThread map with robust remove/add/join_all
methods.

The third and related to second problem is that m_stop
is not guarded between
ThreadedSocketInitiator::SocketThread and OnStop
methods.


Fourth problem is that at least in one place
(ThreadedSocketInitiator::removeThread), and perhaps
more, the mutex is locked explicitly, instead of via
Locker. If STL throws an exception (however unlikely,
it may happen!) between explicit lock/unlocks, mutex
will stay locked, with dire consequences. Explicit
locking/unlocking of mutex should carry a pretty big
comment next to it, as it is very easy to slip an
exception producing code between them, and is best
reserved for complicated syncing, as opposed to plain
guarding.

If finer grained then the method scope locking is
required, it can usually be achieved using an
anonymous C++ block
c::f()
{
unprotected code;
{
locker l(mutex);
protected code;
}
unprotected code;
}

Gene Gorokhovsky


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] quickfix library

[YT L. <yt...@db...>]

Hi all,
      Just want to know if I can obtain the compiled library instead of compiling it on my own....

      Thanks!

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973
----- Forwarded by YT Luk/HK/DBAsia/DeuBa on 24/07/2002 09:18 -----
                                                                                                                                            
                      YT Luk                                                                                                                
                                               To:      qui...@li...,                                          
                      24/07/2002 09:15         qui...@li...                                              
                                               cc:                                                                                          
                                               bcc:                                                                                         
                                               Subject: Compile error                                                                       
                                                                                                                                            
                                                                                                                                            



Hi all,

      I have been trying to compile the quickfix source but not successful. The problem is that the xml library quickfix needs for Solaris is on Solaris 8. When I run the command ./configure, it stops and has error at the point when it trys to link with a library with different version :

Error text :
==========================================================================
configure:2317: /mnt_gcc/solaris_local/bin/gcc -o conftest -g -O2 -I/opt/xml/usr/local/libxml/include/libxml2   -I/usr/lib conftest.c  -L/opt/xml/usr/local/libxml/sparc/lib -R/opt/xml/usr/local/libxml/sparc/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl 1>&5
ld: warning: file libz.so: required by /opt/xml/usr/local/libxml/sparc/lib/libxml2.so, not found
ld: fatal: file /usr/lib/libpthread.so: version `SUNW_1.2' does not exist:
        required by file /opt/xml/usr/local/libxml/sparc/lib/libxml2.so
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 2307 "configure"
#include "confdefs.h"

#include <xmlversion.h>
#include <stdio.h>

int main() {
 LIBXML_TEST_VERSION; return 0;
; return 0; }
==========================================================================

I have got a lib /usr/lib/libpthread.so with its version 1 only....

Question :
1. Do I really have to compile on my own...or I can simply obtain the compiled library somewhere else?
2. How can I obtain the new version of that library?


Thanks for your help!

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973
(Embedded image moved to file: pic18718.pcx)


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Quickfix-developers] Compile error

[YT L. <yt...@db...>]

Hi all,

      I have been trying to compile the quickfix source but not successful. The problem is that the xml library quickfix needs for Solaris is on Solaris 8. When I run the command ./configure, it stops and has error at the point when it trys to link with a library with different version :

Error text :
==========================================================================
configure:2317: /mnt_gcc/solaris_local/bin/gcc -o conftest -g -O2 -I/opt/xml/usr/local/libxml/include/libxml2   -I/usr/lib conftest.c  -L/opt/xml/usr/local/libxml/sparc/lib -R/opt/xml/usr/local/libxml/sparc/lib -lxml2 -lz -lpthread -lm -lsocket -lnsl 1>&5
ld: warning: file libz.so: required by /opt/xml/usr/local/libxml/sparc/lib/libxml2.so, not found
ld: fatal: file /usr/lib/libpthread.so: version `SUNW_1.2' does not exist:
        required by file /opt/xml/usr/local/libxml/sparc/lib/libxml2.so
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 2307 "configure"
#include "confdefs.h"

#include <xmlversion.h>
#include <stdio.h>

int main() {
 LIBXML_TEST_VERSION; return 0;
; return 0; }
==========================================================================

I have got a lib /usr/lib/libpthread.so with its version 1 only....

Question :
1. Do I really have to compile on my own...or I can simply obtain the compiled library somewhere else?
2. How can I obtain the new version of that library?


Thanks for your help!

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Quickfix-developers] ThreadedSocketInitiator sync problems in 1.1.1

[Gene G. <mus...@ya...>]

I wrote a pair of buyer/exchange apps borrowing
liberally from the sample code and using quickfix
threaded acceptor/initiator classes. Buyer app
initiates connection and in the App::OnRun generates
SingleOrderRequests in a tight loop. Once a sufficient
number of requests have been generated onRun exits.

I have run into a few sync problem scenarios in the
buyer app:
Scenario 1:
once onRun returns, ThreadedSocketInitiator returns
control from OnStart to main app, which tries to clean
up, Virtual destructor chain is called, getting to
~Initiator. Initiator cleans up all the session
pointers, with guarding mutex wide open because while
ThreadedSocketInitiator is derived from Initiator,
both of them have their separate private m_mutex.

Meanwhile the connection queue and SocketThread both
need pointer to Initiator and its sessions on other
threads. readQueue thread makes a call Session->next
and calling a method of a deleted pointer leads to sad
consequences.

The above problem will probably go away once
ThreadedSocketInitiator uses Initiator's m_mutex
(which will have to be "protected" instead of
"private") or guards its own destructor with its own
m_mutex.


Another independent scenario which manifested itself
once I added code to post a logout message in my
buyer's onRun before exiting.


Two threads of the Threadedinitiator are  deadlocked.
One sits in OnStop. It has grabbed the mutex, and is
waiting to join the SocketThread. The SocketThread
however is also trying to get out. It wants to
unregister by calling removeThread, but the mutex has
been grabbed by onStop which is waiting for
SocketThread to return...
The problem is complicated because SocketThread is
attempting to close its own handle (by the way,
pthread_detach has to be called on pthread systems,
similarly to CloseHandle), which of course makes it
impossible to join from elsewhere(for instance from
OnStop).  The solution here is to not close handle and
erase the pair from the threads map during shutdown
processing (when m_stop is raised), and instead
relegate this to the thread that performes the join.

Here it would be helpful to use a robust Thread class,
which would make sure that handle is cleaned up both
after join and in destruction. Although not without a
fault,a decent portable implementation of such class
is  in the Boost Thread library
(http://www.boost.org/libs/thread/doc/index.html) That
implementation also includes a thread_group class
which is quite similar in functionality to
SocketToThread map with robust remove/add/join_all
methods.

The third and related to second problem is that m_stop
is not guarded between
ThreadedSocketInitiator::SocketThread and OnStop
methods.


Fourth problem is that at least in one place
(ThreadedSocketInitiator::removeThread), and perhaps
more, the mutex is locked explicitly, instead of via
Locker. If STL throws an exception (however unlikely,
it may happen!) between explicit lock/unlocks, mutex
will stay locked, with dire consequences. Explicit
locking/unlocking of mutex should carry a pretty big
comment next to it, as it is very easy to slip an
exception producing code between them, and is best
reserved for complicated syncing, as opposed to plain
guarding.

If finer grained then the method scope locking is
required, it can usually be achieved using an
anonymous C++ block
c::f() 
{
unprotected code;
{
locker l(mutex);
protected code;
}
unprotected code;
}

Gene Gorokhovsky
 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Quickfix-developers] Anyway to parse a FIX message?

[YT L. <yt...@db...>]

Hi Oren,

      Yes....I am going to use the quickfix parsing function...i.e. I want to pass in a FIX message into it and would like to get back all the field values by using the tag numbers!

      Sounds that quickfix can do the thing I want....and I will give it a try !

      Thanks for your advice!

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973


                                                                                                                                                               
                      OM...@th...                                                                                                                 
                      Sent by:                                    To:       YT Luk/HK/DBAsia/DeuBa@DBAsia                                                      
                      qui...@li...ur        cc:       qui...@li...,                                         
                      ceforge.net                                  qui...@li...                                             
                                                                  Subject:  Re: [Quickfix-developers] Anyway to parse a FIX message?                           
                                                                                                                                                               
                      20/07/2002 07:07                                                                                                                         
                                                                                                                                                               
                                                                                                                                                               





Well I'm not sure what you are trying to do exactly, but the quickfix
FIX::Message class has a constructor that takes in a string.  This will
parse the FIX message and put it in a structure that will allow you to set
and get all of the values.

--oren



|---------+----------------------------------------------->
|         |           "YT Luk" <yt...@db...>            |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           07/18/2002 09:51 PM                 |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       qui...@li...                                    |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] Anyway to parse a FIX message?                         |
  >----------------------------------------------------------------------------------------------|




Hi all,

      I am new to FIX and quickfix...

      Just want to know if Quickfix can accept a FIX format string as input
and use function calls to get the values back in this FIX message....

      i.e. let Quickfix as a message parser...

      Thanks !

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973


--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers




--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Re: [Quickfix-developers] Anyway to parse a FIX message?

[<OM...@th...>]

Well I'm not sure what you are trying to do exactly, but the quickfix
FIX::Message class has a constructor that takes in a string.  This will
parse the FIX message and put it in a structure that will allow you to set
and get all of the values.

--oren



|---------+----------------------------------------------->
|         |           "YT Luk" <yt...@db...>            |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           07/18/2002 09:51 PM                 |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       qui...@li...                                    |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] Anyway to parse a FIX message?                         |
  >----------------------------------------------------------------------------------------------|




Hi all,

      I am new to FIX and quickfix...

      Just want to know if Quickfix can accept a FIX format string as input
and use function calls to get the values back in this FIX message....

      i.e. let Quickfix as a message parser...

      Thanks !

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973


--

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Anyway to parse a FIX message?

[YT L. <yt...@db...>]

Hi all,

      I am new to FIX and quickfix...

      Just want to know if Quickfix can accept a FIX format string as input and use function calls to get the values back in this FIX message....

      i.e. let Quickfix as a message parser...

      Thanks !

Regards,

Eric Luk

Tel : (852) 2203 6348
Fax : (852) 2203 6973


--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Re: [Quickfix-developers] Sequence number,HeartBeat and Message Gap Filling

[<OM...@th...>]

Hello Krishna,

Can you tell me where in the spec it says that admin messages should be
stopped.  The only thing I found that sounds kind of like you are talking
about is this:

"During the gap fill process, certain administrative messages should not be
retransmitted."

Which is just saying that admin messages should not be retransmitted, not
that they shouldn't be sent.  Is the current behavior causing any problems?

--oren



|---------+----------------------------------------------->
|         |           Krishna Dagli <kd...@in...>  |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           07/18/2002 07:46 PM                 |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       "qui...@li..."                                  |
  |        <qui...@li...>                                           |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] Sequence number,HeartBeat and Message Gap Filling      |
  >----------------------------------------------------------------------------------------------|




Hi,

My *.cfg setting has Heart Beat Integer set at 10 Seconds.
Both initiator and acceptor does not do anything other than
printing Admin messages.
I'm using FileStore implementation.

Question:
---------
I ran acceptor and initiator for a while. FIX.*.seqnum file,
now reads 5:5 which will be next sequence number.  I
modified initiators file and increased (by 10) the outgoing
sequence number. As expected acceptor sends a Resend request
message for the missed messages as per sequence number but
Heart Beat does not stop between initiator and acceptor. Am
I missing something. As per specs, message gap filling
should start and in this time no heatbeat/admin messages
should be sent. If initiator after receiving Resend message
does not do anything then heart beat should have been
stopped, but it does not.

What to do, if application, after receiving Msg Resend flag
takes more time to resend messages then Hear Beat int.
setting? Isn't QFEngine suppose to stop sending admin
message in this time?

========
Krishna


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Sequence number,HeartBeat and Message Gap Filling

[Krishna D. <kd...@in...>]

Hi,

My *.cfg setting has Heart Beat Integer set at 10 Seconds.
Both initiator and acceptor does not do anything other than
printing Admin messages.
I'm using FileStore implementation.

Question:
---------
I ran acceptor and initiator for a while. FIX.*.seqnum file,
now reads 5:5 which will be next sequence number.  I
modified initiators file and increased (by 10) the outgoing
sequence number. As expected acceptor sends a Resend request
message for the missed messages as per sequence number but
Heart Beat does not stop between initiator and acceptor. Am
I missing something. As per specs, message gap filling
should start and in this time no heatbeat/admin messages
should be sent. If initiator after receiving Resend message
does not do anything then heart beat should have been
stopped, but it does not.

What to do, if application, after receiving Msg Resend flag
takes more time to resend messages then Hear Beat int.
setting? Isn't QFEngine suppose to stop sending admin
message in this time?

========
Krishna

Re: [Quickfix-developers] PossDupFlag

[<OM...@th...>]

>> I have run into some confusion regarding the PossDupFlag:

>> The release notes for quickfix 1.1.0 say the application programmer is
>> responsible for handling messages with the PossDupFlag set.

>> I don't really understand the motivation for this. Isn't quickfix
>> responsible for handling the session level stuff, including guaranteed
>> delivery of messages in the correct order?

>> If I simply ignore the PossDupFlag in my fromApp method, does this mean
>> I can get the same message twice?

>> If I check for the PossDupFlag in fromApp, what is the "right thing" to
>> do with a message with PossDupFlag=Y?

I've gone and looked back at the spec and the FIX mailing list.  There is
disagreement on this, but I think the consensus is that you are right. I
also found this in the spec which backs your argument.

"Two  fields help with resending messages. The PossDupFlag is set to Y when
resending  a  message  as  the  result  of  a session level event (i.e. the
retransmission  of  a message reusing a sequence number). The PossResend is
set  to  Y  when  reissuing  a  message  with  a  new sequence number (e.g.
resending  an  order).  The  receiving  application  should  process  these
messages as follows:


PossDupFlag  -  if  a message with this sequence number has been previously
received, ignore message, if not, process normally."


So  the  answer  is  yes,  the QuickFIX session should be preventing resent
messages that have already been processed from being passed to you.


Realisticly  I  think  you  can safely skip checking for the PossDupFlag in
messages  because  QuickFIX will only submit resend request for messages it
hasn't  processed.   So  unless  there  is  a  serious error with the other
engine,  you  shouldn't  ever  see a resent message that you have processed
coming across the wire.



>> In the tradeclient example, there exists the following code in the toApp

>> method:

>>   try
>>   {
>>     FIX::PossDupFlag possDupFlag;
>>     message.getHeader().getField(possDupFlag);
>>     if(possDupFlag) throw FIX::DoNotSend();
>>   } catch(FIX::FieldNotFound&) {}

>> This code prevents all application level messages with PossDupFlag=Y
>> from being sent, right? Again, what is the motivation for this? Doesn't
>> this defeat the purpose of FIX (guaranteed delivery of messages)?

This actually has a useful purpose.  This is really targeted for
NewOrderSingle messages and should really be checking for that message
explicitly. Does this defeat the purpose of FIX guaranteed delivery?  Yes,
and that's the point.  If I send an order out that does not get processed
and a system then wants to process it say, I don't know, an hour later,
chances are the market doesn't look like it did when I wanted that order to
go out. At this point I don't want my order to go out into some random
market.  Now the exchange processing this message may very well have some
rules for out of date orders, but they may not, or they may process orders
up to 2 minuntes old and that's not good enough for me.

Realisticly this piece of code would also check for how many seconds old
this message is and determine if it wants to resend it. When a DoNotSend
exception is thrown, QuickFIX will replace the application message with a
harmless sequence gap fill, so the other side will happily get what they
want and not what you don't want them to have. It was originally written
just to simply demonstrate the functionality of DoNotSend, but a more
realistic example that explicitly checks for the message type and time of
the message would be clearer.

For other types of messages, like ExecutionReport, this code would makes no
sense because you always want to send those no matter how old.

--oren

[Quickfix-developers] PossDupFlag

[Rainer S. <ra...@aa...>]

Hi all,

I have run into some confusion regarding the PossDupFlag:

The release notes for quickfix 1.1.0 say the application programmer is 
responsible for handling messages with the PossDupFlag set.

I don't really understand the motivation for this. Isn't quickfix 
responsible for handling the session level stuff, including guaranteed 
delivery of messages in the correct order?

If I simply ignore the PossDupFlag in my fromApp method, does this mean 
I can get the same message twice?

If I check for the PossDupFlag in fromApp, what is the "right thing" to 
do with a message with PossDupFlag=Y?

Also confusing:

In the tradeclient example, there exists the following code in the toApp 
method:

   try
   {
     FIX::PossDupFlag possDupFlag;
     message.getHeader().getField(possDupFlag);
     if(possDupFlag) throw FIX::DoNotSend();
   } catch(FIX::FieldNotFound&) {}

This code prevents all application level messages with PossDupFlag=Y 
from being sent, right? Again, what is the motivation for this? Doesn't 
this defeat the purpose of FIX (guaranteed delivery of messages)?

Thanks!

Rainer Staringer
AAA+ Software

[Quickfix-developers] Version 1.1.1 is available!

[<OM...@th...>]

Version 1.1.1, is now available from http://quickfix.thoughtworks.com.

As always release notes are below.

RELEASE NOTES
________________

1.1.1
-----
Fixed memory leak caused by copying repeating groups.

Added acceptance tests for FIX 4.0 and 4.1

When new fields are added to the header or trailer portion of the XML data
dictionary,
QuickFIX will now handle them appropriately.

Header fields, not just body fields, can now be added to messages passing
through toApp
and toAdmin callbacks

New setting CheckLatency and MaxLatency are available for session
configuration. CheckLatency defaults
to Y and determines if a session will check if a message looks too old to
process. MaxLatency
defaults to 120 and is the maximum number of seconds a message can be out
of date and still
be considered good.

New setting ValidateFieldsOutOfOrder is available for session
configuration. Sets whether or not header
and body fields can be out of order. Useful for connecting to systems that
don't properly sort their
fields.

New setting LogonTimeout is availbale for session configuration. Number of
seconds QuickFIX
will wait to receive a logon response. Defaults to 10.

Another fix put in to allow string based enumeration to be properly
validated.

RefMsgType field no longer added to reject messages in versions earlier
thatn 4.2

SequenceReset messages are now appropriately send with OrigSendingTime
field.

RejectLogon, DoNotSend and UnsupportedMessageType exceptions added to JAVA
interface.

New settings ResetOnLogout and ResetOnDisconnect will reset sequence
numbers when a session
is respectively normally or abnormally terminated.

<string> is included from Exceptions.h, which makes QF compilable with
STLPort.

--oren