quickfix-users Mailing List for QuickFIX (Page 91)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I have seen that the encryption values are defiedned,
is the encryption implmented in quick fix?

Specifically, I'd like to use PGP-MD5 encryption.
I this one implemented?

Jerry Westrick

It's possible that parser missed this.  This xml file is generated from the
FIX org's published HTML spec, which was done by hand.  Sometimes this
means that certain parts of it were done a little differently which
confuses the parser.  The parser just needs to be made aware of that
special case.  These show up pretty rarely, but are found once in a while.

--oren

                      "El-Abid, Bassam"                                                                                                              
                      <ba...@se...>                 To:       "'qui...@li...'"                                      
                      Sent by:                                <qui...@li...>                                                 
                      qui...@li...ur        cc:                                                                                     
                      ceforge.net                            Subject:  [Quickfix-users] RE: Quickfix-users digest, Vol 1 #22 - 1 msg                 

                      01/14/2003 04:41 PM                                                                                                            

Hello,

In the FIX42.xml, FIX41.xml, and FIX40.xml, "P = Market peg" for tag
"ExcecInst" is missing.
The value P was mentioned in fix-42-with_errata_20010501.html for New Order
- Single.
FIXimate for 4.0, 4.1, and 4.2 on www.fixprotocol.org has "P = Market peg"
as a value for "ExcecInst".

Did anyone notice this? Are there any other values missing in the xml file?

Bassam

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...]
Sent: Monday, January 13, 2003 12:35 PM
To: qui...@li...
Subject: Quickfix-users digest, Vol 1 #22 - 1 msg

Send Quickfix-users mailing list submissions to
             qui...@li...

To subscribe or unsubscribe via the World Wide Web, visit
             https://lists.sourceforge.net/lists/listinfo/quickfix-users
or, via email, send a message with subject or body 'help' to
             qui...@li...

You can reach the person managing the list at
             qui...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Quickfix-users digest..."

Today's Topics:

   1. EncryptMethod_PGPDESMD5 (Jerry Westrick)

--__--__--

Message: 1
From: Jerry Westrick <je...@we...>
To: qui...@li...
Date: 13 Jan 2003 16:18:59 +0100
Subject: [Quickfix-users] EncryptMethod_PGPDESMD5

Hello QuickFix users!

I see that the constant EncryptMethod_PGPDESMD5 is defined... Is the
encryption implemented?

Jerry

--__--__--

_______________________________________________
Quickfix-users mailing list Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

End of Quickfix-users Digest

_____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC

-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

Hello,

In the FIX42.xml, FIX41.xml, and FIX40.xml, "P = Market peg" for tag
"ExcecInst" is missing.
The value P was mentioned in fix-42-with_errata_20010501.html for New Order
- Single.
FIXimate for 4.0, 4.1, and 4.2 on www.fixprotocol.org has "P = Market peg"
as a value for "ExcecInst".

Did anyone notice this? Are there any other values missing in the xml file?

Bassam

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] 
Sent: Monday, January 13, 2003 12:35 PM
To: qui...@li...
Subject: Quickfix-users digest, Vol 1 #22 - 1 msg

Send Quickfix-users mailing list submissions to
	qui...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/quickfix-users
or, via email, send a message with subject or body 'help' to
	qui...@li...

You can reach the person managing the list at
	qui...@li...

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Quickfix-users digest..."

Today's Topics:

   1. EncryptMethod_PGPDESMD5 (Jerry Westrick)

--__--__--

Message: 1
From: Jerry Westrick <je...@we...>
To: qui...@li...
Date: 13 Jan 2003 16:18:59 +0100
Subject: [Quickfix-users] EncryptMethod_PGPDESMD5

Hello QuickFix users!

I see that the constant EncryptMethod_PGPDESMD5 is defined... Is the
encryption implemented?

Jerry

--__--__--

_______________________________________________
Quickfix-users mailing list Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

End of Quickfix-users Digest

_____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC

Hello QuickFix users!

I see that the constant EncryptMethod_PGPDESMD5 is defined...
Is the encryption implemented?

Jerry

A resource leak was discovered in 1.3.0 when using repeating groups.
Thanks to Rosenthal Collins for reporting this.  This leak will only
manifest itself if you send or receive messages with repeating groups.
1.3.0 has been taking down and this version is being put in its place.  You
can also patch your 1.3.0 version by simply calling the clear() method in
the FieldMap destructor.  If you do not use repeating groups and do not
intend to, you are o.k. with 1.3.0, but an upgrading or patching it is
recommended.

As always you can download here: http://quickfix.thoughtworks.com

and the relase notes are here:
http://sourceforge.net/project/shownotes.php?group_id=37535&release_id=119389

--oren

----- Forwarded by Oren Miller/Corporate/ThoughtWorks/US on 10/29/2002
08:41 PM -----

                      Oren Miller                                                                                                      
                                               To:       <qui...@li...>,                                  
                      10/28/2002 10:06          <qui...@li...>, <qui...@li...>      
                      PM                       cc:                                                                                     
                                               Subject:  Version 1.3.0 available                                                       

Version 1.3.0, is now available from http://quickfix.thoughtworks.com.
There is a lot of new stuff here, including such long awaited features as
built in database support (MySQL), JAVA support under linux AND solaris,
support for repeating groups in .NET and JAVA, and complete logging of
messages and events with the addition of the Log interface (Screen, File,
and MySQL loggers provided).

The stability problems being encountered on multi-processor machines have
been resolved.  Simply compile QuickFIX against STLport with older versions
of gcc, or upgrade to the latest 3.x.x release.  Compiling with STLport has
been made easy with the addition of the --with-stlport configure option.

Also keep in mind that the interface for MessageStore has changed.  So if
you are using a custom message store, it will need to support the new
interface to use this version.

Full release notes are available here:
http://sourceforge.net/project/shownotes.php?group_id=37535&release_id=118939

FIX 4.3 coming soon!

QuickFIX/ThoughtWorks is going to have a booth at the FIA Expo in Chicago:
http://www.fiafii.org/expo2002-2275.asp
If you would like a free ticket, please write to us at
tr...@th...

--oren

Version 1.3.0, is now available from http://quickfix.thoughtworks.com.
There is a lot of new stuff here, including such long awaited features as
built in database support (MySQL), JAVA support under linux AND solaris,
support for repeating groups in .NET and JAVA, and complete logging of
messages and events with the addition of the Log interface (Screen, File,
and MySQL loggers provided).

The stability problems being encountered on multi-processor machines have
been resolved.  Simply compile QuickFIX against STLport with older versions
of gcc, or upgrade to the latest 3.x.x release.  Compiling with STLport has
been made easy with the addition of the --with-stlport configure option.

Also keep in mind that the interface for MessageStore has changed.  So if
you are using a custom message store, it will need to support the new
interface to use this version.

Full release notes are available here:
http://sourceforge.net/project/shownotes.php?group_id=37535&release_id=118939

FIX 4.3 coming soon!

QuickFIX/ThoughtWorks is going to have a booth at the FIA Expo in Chicago:
http://www.fiafii.org/expo2002-2275.asp
If you would like a free ticket, please write to us at
tr...@th...

--oren

For users of QuickFIX that are in timezones affected by Daylight Savings, a
quick reminder.  Remember that your session times are set using UTC, which
is unaffected by daylight savings.  This means you may have to modify your
session times during the time change so that your sessions are active
during your local buisiness hours.

--oren

Joerg Thoennes wrote:

> 1. The libquickfix.a as a shared object library. The documentation says
>    that for Linux only a statically linked version is available. Please,
>    could anybody point out more details why this is the case? Perhaps
>    this problem could be solved with a newer compiler, e.g. GCC 3.0?

I think I have accomplished this task. The program libtool which is used to
generate shared libs in a platform-independent way always got the option
"-static" which forced it to omit the shared library. This was triggered by
the following line in Makefile.am:

      libquickfix_la_LDFLAGS = -static

In addition, there is a configure option "--enabled-shared". So I did the following:

1. Change all Makefile.am instance to comment out the above line.

2. Go to root directory and:

      ./bootstrap
      ./configure --enable-shared
      make

Then "make install" installs /usr/local/lib as follows:

-rwxr-xr-x    1 root     staff     2402221 Sep  4 17:04 libquickfix.so.0.0.0
lrwxrwxrwx    1 root     staff          20 Sep  4 17:04 libquickfix.so.0 -> libquickfix.so.0.0.0
lrwxrwxrwx    1 root     staff          20 Sep  4 17:04 libquickfix.so -> libquickfix.so.0.0.0
-rwxr-xr-x    1 root     staff         762 Sep  4 17:04 libquickfix.la
-rw-r--r--    1 root     staff    11412896 Sep  4 17:04 libquickfix.a

And
	ldd /usr/local/lib/libquickfix.so.0.0.0
         libxml2.so.2 => /usr/lib/libxml2.so.2 (0x401d5000)
         libc.so.6 => /lib/libc.so.6 (0x40274000)
         libz.so.1 => /usr/lib/libz.so.1 (0x40392000)
         libm.so.6 => /lib/libm.so.6 (0x403a1000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

Now I try to create libquickfix_jni.so using the Makefile.am from src/C++.

Oren, could you please send me your changes?

Thanks, Jörg

> I recently started working on the linux JNI port.  I put together a
> Makefile.am using a sample that was kindly supplied by Alex Hornby.  We
> originally thought that gcc had problems with exceptions within shared
> objects.  Alex's example showed that this is not necessarily the case.  I
> have so far compiled the JNI code under linux and have created a
> libquickfix_jni.so file, however I think there are still some linking
> issues that need to be resolved.

Sounds good.

> I would be happy to send out what I have so far (Alex, are you also
> interested?), and we can perhaps collaborate on completing the port.

That would be great. We are really eager to get that JNI code running.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Yeah, I was just thinking about that.  I think that a good argument to keep
them separate is if someone wants to make some sort of administrative tool
that uses the MessageStore interface to modify their databases/files.  In
this case I think that it would be useful to keep them separate.

Their are a couple of ways to handle making the change.  You can either
submit it as a request on the list (which you just did).  In which case you
can wait for it to appear in a future release.  OR, you can be more
proactive! You can make the change to your codebase and submit it to the
list.  That way you will have what you need immediately, anybody else who
wants that change can use it in the meantime, and we can incorporate the
change into a future release.

--oren

                      "Stancescu                                                                                                         
                      Constantin"                To:       <OM...@th...>                                                    
                      <Constantin.Stances        cc:       <qui...@li...>,                                       
                      cu...@sw...>                 <qui...@li...>                                           
                                                 Subject:  RE: [Quickfix-users] Crash scenarios in QuickFix                              
                      09/04/2002 07:50 AM                                                                                                

It is OK to get rid of the increment method for the sender as long
as we are sure that nobody, in the future will have the idea of separating
them !
About setting the Message into storage before sending, what and by whom
should be done
in order to have this change made ?

-- constantin

-----Original Message-----
From: OM...@th... [mailto:OM...@th...]
Sent: Mittwoch, 4. September 2002 14:37
To: Stancescu Constantin
Cc: Stancescu Constantin; qui...@li...;
qui...@li...
Subject: Re: [Quickfix-users] Crash scenarios in QuickFix

Stencescu,

I definately agree with your proposals.  The first one, setting the Message
into storage before sending, makes a lot of sense.   I also agree with your
second assesment about making the storage and incrementing of the sequence
number more easily transactional.  In fact, looking at the code, set and
incrNextSenderMsgSeqNum are only called once and they are together.  This
being the case, I would propose that instead of creating a new incrAndSet
method, just get rid of the incr method and make it the implied behavior of
the set call.  What do you think?

--oren

                      "Stancescu Constantin"

                      <Con...@sw...>         To:
<qui...@li...>

                      Sent by:                               cc:
"Stancescu Constantin" <Con...@sw...>

                      qui...@li...ur        Subject:
[Quickfix-users] Crash scenarios in QuickFix

                      ceforge.net

                      09/04/2002 05:12 AM

Hi,

I am Constantin Stancescu from SWX (Suisse Exchange) I am currently
implemented the FIX support for our trading system, based on QuickFix,
the Windows C++ version.
I have a couple of intersting subjects, this is the first of them:

As I understand the sender algorithm ( in Session.cpp Session::sendRaw)
is :

1. send()
2. m_pStore->set()                                                 //
includes disk flush
3. m_pStore->incrNextSenderMsgSeqNum()           // includes disk flush

If the application crashes after 1 (send) but before 3
(incrNextSenderMsgSeqNum)
we may have the following situation(I forced and tested it) :
- The receiver receives the message, so he will now expect n+1 as next
message.
- The sender, when restarting, will come with n < n + 1 and the logon
attempt is
rejected and we have to completely reset the session.

A couple of observations about coping with this situation:

- In this situation the send call from the user layer will never return.
Our application is written in such a way that in this case the business
message will be send again with possResend flag set, even if a new FIX
session is created with the same party. Is it reasonable to assume that
all(most) party applications will have this kind of behaviour ?

- A slight change may reduce the probability of trouble; the order
of action in Session::sendRaw should by:
             1.m_pStore->incrNextSenderMsgSeqNum()           // includes
disk flush
             2.m_pStore->set()
                                     // includes disk flush
             3.send()
             - If the application crashes after 2. but before 3., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender has all he needs
and we are OK.
             - If the application crashes after 1. but before 2., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender does not have the
message, we
             are in trouble. In our application we provide our own message
store implementation
             using an MSSQL database instead of FileStore.
             Step 1(incrNextSenderMsgSeqNum) and and 2(set) are part of the
same transaction
             so we can not crash between 1 and 2. In order to do this we
have to wait for the second
             call before commiting, it will be nicer to have just one
MessageStore call, say incrAndSet !!

What do you think about my proposal ?
Any others opininons or tips ?

Regards,
Constantin

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

It is OK to get rid of the increment method for the sender as long
as we are sure that nobody, in the future will have the idea of =
separating them !
About setting the Message into storage before sending, what and by whom =
should be done
in order to have this change made ?

-- constantin

-----Original Message-----
From: OM...@th... [mailto:OM...@th...]
Sent: Mittwoch, 4. September 2002 14:37
To: Stancescu Constantin
Cc: Stancescu Constantin; qui...@li...;
qui...@li...
Subject: Re: [Quickfix-users] Crash scenarios in QuickFix

Stencescu,

I definately agree with your proposals.  The first one, setting the =
Message
into storage before sending, makes a lot of sense.   I also agree with =
your
second assesment about making the storage and incrementing of the =
sequence
number more easily transactional.  In fact, looking at the code, set and
incrNextSenderMsgSeqNum are only called once and they are together.  =
This
being the case, I would propose that instead of creating a new =
incrAndSet
method, just get rid of the incr method and make it the implied behavior =
of
the set call.  What do you think?

--oren

                                                                         =
                                                                         =
  =20
                      "Stancescu Constantin"                             =
                                                                         =
  =20
                      <Con...@sw...>         To:       =
<qui...@li...>                                   =
    =20
                      Sent by:                               cc:       =
"Stancescu Constantin" <Con...@sw...>                    =
    =20
                      qui...@li...ur        Subject:  =
[Quickfix-users] Crash scenarios in QuickFix                             =
    =20
                      ceforge.net                                        =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                      09/04/2002 05:12 AM                                =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20

Hi,

I am Constantin Stancescu from SWX (Suisse Exchange) I am currently
implemented the FIX support for our trading system, based on QuickFix,
the Windows C++ version.
I have a couple of intersting subjects, this is the first of them:

As I understand the sender algorithm ( in Session.cpp Session::sendRaw)
is :

1. send()
2. m_pStore->set()                                                 //
includes disk flush
3. m_pStore->incrNextSenderMsgSeqNum()           // includes disk flush

If the application crashes after 1 (send) but before 3
(incrNextSenderMsgSeqNum)
we may have the following situation(I forced and tested it) :
- The receiver receives the message, so he will now expect n+1 as next
message.
- The sender, when restarting, will come with n < n + 1 and the logon
attempt is
rejected and we have to completely reset the session.

A couple of observations about coping with this situation:

- In this situation the send call from the user layer will never return.
Our application is written in such a way that in this case the business
message will be send again with possResend flag set, even if a new FIX
session is created with the same party. Is it reasonable to assume that
all(most) party applications will have this kind of behaviour ?

- A slight change may reduce the probability of trouble; the order
of action in Session::sendRaw should by:
             1.m_pStore->incrNextSenderMsgSeqNum()           // includes
disk flush
             2.m_pStore->set()
                                     // includes disk flush
             3.send()
             - If the application crashes after 2. but before 3., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender has all he =
needs
and we are OK.
             - If the application crashes after 1. but before 2., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender does not have =
the
message, we
             are in trouble. In our application we provide our own =
message
store implementation
             using an MSSQL database instead of FileStore.
             Step 1(incrNextSenderMsgSeqNum) and and 2(set) are part of =
the
same transaction
             so we can not crash between 1 and 2. In order to do this we
have to wait for the second
             call before commiting, it will be nicer to have just one
MessageStore call, say incrAndSet !!

What do you think about my proposal ?
Any others opininons or tips ?

Regards,
Constantin

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

Stencescu,

I definately agree with your proposals.  The first one, setting the Message
into storage before sending, makes a lot of sense.   I also agree with your
second assesment about making the storage and incrementing of the sequence
number more easily transactional.  In fact, looking at the code, set and
incrNextSenderMsgSeqNum are only called once and they are together.  This
being the case, I would propose that instead of creating a new incrAndSet
method, just get rid of the incr method and make it the implied behavior of
the set call.  What do you think?

--oren

                      "Stancescu Constantin"                                                                                                         
                      <Con...@sw...>         To:       <qui...@li...>                                        
                      Sent by:                               cc:       "Stancescu Constantin" <Con...@sw...>                         
                      qui...@li...ur        Subject:  [Quickfix-users] Crash scenarios in QuickFix                                  
                      ceforge.net                                                                                                                    

                      09/04/2002 05:12 AM                                                                                                            

Hi,

I am Constantin Stancescu from SWX (Suisse Exchange) I am currently
implemented the FIX support for our trading system, based on QuickFix,
the Windows C++ version.
I have a couple of intersting subjects, this is the first of them:

As I understand the sender algorithm ( in Session.cpp Session::sendRaw)
is :

1. send()
2. m_pStore->set()                                                 //
includes disk flush
3. m_pStore->incrNextSenderMsgSeqNum()           // includes disk flush

If the application crashes after 1 (send) but before 3
(incrNextSenderMsgSeqNum)
we may have the following situation(I forced and tested it) :
- The receiver receives the message, so he will now expect n+1 as next
message.
- The sender, when restarting, will come with n < n + 1 and the logon
attempt is
rejected and we have to completely reset the session.

A couple of observations about coping with this situation:

- In this situation the send call from the user layer will never return.
Our application is written in such a way that in this case the business
message will be send again with possResend flag set, even if a new FIX
session is created with the same party. Is it reasonable to assume that
all(most) party applications will have this kind of behaviour ?

- A slight change may reduce the probability of trouble; the order
of action in Session::sendRaw should by:
             1.m_pStore->incrNextSenderMsgSeqNum()           // includes
disk flush
             2.m_pStore->set()
                                     // includes disk flush
             3.send()
             - If the application crashes after 2. but before 3., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender has all he needs
and we are OK.
             - If the application crashes after 1. but before 2., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender does not have the
message, we
             are in trouble. In our application we provide our own message
store implementation
             using an MSSQL database instead of FileStore.
             Step 1(incrNextSenderMsgSeqNum) and and 2(set) are part of the
same transaction
             so we can not crash between 1 and 2. In order to do this we
have to wait for the second
             call before commiting, it will be nicer to have just one
MessageStore call, say incrAndSet !!

What do you think about my proposal ?
Any others opininons or tips ?

Regards,
Constantin

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

Joerg,

I recently started working on the linux JNI port.  I put together a
Makefile.am using a sample that was kindly supplied by Alex Hornby.  We
originally thought that gcc had problems with exceptions within shared
objects.  Alex's example showed that this is not necessarily the case.  I
have so far compiled the JNI code under linux and have created a
libquickfix_jni.so file, however I think there are still some linking
issues that need to be resolved.

I would be happy to send out what I have so far (Alex, are you also
interested?), and we can perhaps collaborate on completing the port.

--oren

|---------+----------------------------------------------->
|         |           Joerg Thoennes                      |
|         |           <Joe...@ma...>           |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           09/04/2002 03:29 AM                 |
|         |           Please respond to Joerg.Thoennes    |
|         |                                               |
|---------+----------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       qui...@li...,                                   |
  |        qui...@li...                                                  |
  |       cc:                                                                                    |
  |       Subject:  [Quickfix-developers] JNI library for Linux                                  |
  >----------------------------------------------------------------------------------------------|

Hello,

we are developing exchange connectivity software running on linux server
machines. The next interface to incorporate is a FIX interface.

Now we are evaluating the QuickFIX engine and it seems to meet our needs
very closely except for one point: the Linux integration.

We would like to use QuickFIX on Linux from a Java application. The Java
interface for QuickFIX is currently available only for Windows.

To get the Java interface running on Linux, we need

1. The libquickfix.a as a shared object library. The documentation says
    that for Linux only a statically linked version is available. Please,
    could anybody point out more details why this is the case? Perhaps
    this problem could be solved with a newer compiler, e.g. GCC 3.0?

2. There is no appropriate Makefile.am to build the libquickfix_jni.so
    for Linux. Could anybody tell us how to change the Makefile.am (and
    the C++ sources for the JNI interface)?

If we can resolve these points with the help from this list, we could
get a working Java FIX application for Linux.

Can anyone help?

Thanks in advance.

--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Hi,

I am Constantin Stancescu from SWX (Suisse Exchange) I am currently
implemented the FIX support for our trading system, based on QuickFix,
the Windows C++ version.
I have a couple of intersting subjects, this is the first of them:

As I understand the sender algorithm ( in Session.cpp Session::sendRaw)
is :

1. send()
2. m_pStore->set()				// includes disk flush=20
3. m_pStore->incrNextSenderMsgSeqNum()	// includes disk flush=20

If the application crashes after 1 (send) but before 3 =
(incrNextSenderMsgSeqNum)=20
we may have the following situation(I forced and tested it) :
- The receiver receives the message, so he will now expect n+1 as next =
message.
- The sender, when restarting, will come with n < n + 1 and the logon =
attempt is=20
rejected and we have to completely reset the session.

A couple of observations about coping with this situation:

- In this situation the send call from the user layer will never return.
Our application is written in such a way that in this case the business
message will be send again with possResend flag set, even if a new FIX=20
session is created with the same party. Is it reasonable to assume that
all(most) party applications will have this kind of behaviour ?

- A slight change may reduce the probability of trouble; the order
of action in Session::sendRaw should by:
	1.m_pStore->incrNextSenderMsgSeqNum()	// includes disk flush
	2.m_pStore->set()							// includes disk flush=20
	3.send()
	- If the application crashes after 2. but before 3., at restart
	the sender will present a sequence number n+1 when the receiver expects =
n.
	The receiver will ask for resend, the sender has all he needs and we =
are OK.
	- If the application crashes after 1. but before 2., at restart
	the sender will present a sequence number n+1 when the receiver expects =
n.
	The receiver will ask for resend, the sender does not have the message, =
we
	are in trouble. In our application we provide our own message store =
implementation
	using an MSSQL database instead of FileStore.
	Step 1(incrNextSenderMsgSeqNum) and and 2(set) are part of the same =
transaction=20
	so we can not crash between 1 and 2. In order to do this we have to =
wait for the second
	call before commiting, it will be nicer to have just one MessageStore =
call, say incrAndSet !!

What do you think about my proposal ?
Any others opininons or tips ?

Regards,
Constantin

  =20

Hello,

we are developing exchange connectivity software running on linux server
machines. The next interface to incorporate is a FIX interface.

Now we are evaluating the QuickFIX engine and it seems to meet our needs 
very closely except for one point: the Linux integration.

We would like to use QuickFIX on Linux from a Java application. The Java
interface for QuickFIX is currently available only for Windows.

To get the Java interface running on Linux, we need

1. The libquickfix.a as a shared object library. The documentation says
    that for Linux only a statically linked version is available. Please,
    could anybody point out more details why this is the case? Perhaps
    this problem could be solved with a newer compiler, e.g. GCC 3.0?

2. There is no appropriate Makefile.am to build the libquickfix_jni.so
    for Linux. Could anybody tell us how to change the Makefile.am (and
    the C++ sources for the JNI interface)?

If we can resolve these points with the help from this list, we could 
get a working Java FIX application for Linux.

Can anyone help?

Thanks in advance.

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

OM...@th... wrote:
> It appears that the Message::validate() method is always returning true on
> your system.  These tests are basically saying that the engine is
> processing messages even if they have a bad checksum or an invalid length.
> Can you also post the results of the unit tests?  Do they all pass?

  $ ./runut 12345
.....................................................................................................................

117 out of 117 tests passing (100%)

Obviously all unit tests pass.

Joerg

It appears that the Message::validate() method is always returning true=
 on
your system.  These tests are basically saying that the engine is
processing messages even if they have a bad checksum or an invalid leng=
th.
Can you also post the results of the unit tests?  Do they all pass?

--oren

                                                                       =
                                                                       =
      =20
                      Joerg Thoennes                                   =
                                                                       =
      =20
                      <Joe...@ma...>              To:       =
qui...@li...                                   =
      =20
                      Sent by:                               cc:       =
                                                                       =
      =20
                      qui...@li...ur        Subject:  =
[Quickfix-users] Acceptance Test errors                                =
      =20
                      ceforge.net                                      =
                                                                       =
      =20
                                                                       =
                                                                       =
      =20
                                                                       =
                                                                       =
      =20
                      09/03/2002 09:05 AM                              =
                                                                       =
      =20
                      Please respond to                                =
                                                                       =
      =20
                      Joerg.Thoennes                                   =
                                                                       =
      =20
                                                                       =
                                                                       =
      =20
                                                                       =
                                                                       =
      =20

Hello,

after compiling on Linux (Debian 3.0 woody), we get the following
failures during the acceptance test:

$ ./runat 12345
<at>
   <test name=3D'definitions/server/fix40/10_MsgSeqNumEqual.def'
result=3D'success'/>

   [...success...]

   <test name=3D'definitions/server/fix40/2c_MsgSeqNumTooLow.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix40/2d_GarbledMessage.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.0*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D3*16=3D3*10=3D0*</E>

<A>8=3DFIX.4.0*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:55:24*56=
=3DTW*10=3D223*</A></message>

     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name=3D'definitions/server/fix40/2e_PossDupAlreadyReceived.def=
'
result=3D'success'/>

             [...success...]

<test name=3D'definitions/server/fix40/2t_FirstThreeFieldsOutOfOrder.de=
f'
result=3D'success'/>
   <test name=3D'definitions/server/fix40/3b_InvalidChecksum.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.0*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D3*16=3D3*10=3D0*</E>

<A>8=3DFIX.4.0*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:55:57*56=
=3DTW*10=3D229*</A></message>

     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name=3D'definitions/server/fix40/3c_GarbledMessage.def'
result=3D'success'/>

   [...success...]

   <test
name=3D'definitions/server/fix41/2k_CompIDDoesNotMatchProfile.def'
result=3D'success'/>
   <test
name=3D'definitions/server/fix41/2m_BodyLengthValueNotCorrect.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.1*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D2*16=3D2*10=3D0*</E>

<A>8=3DFIX.4.1*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:56:57*56=
=3DTW*10=3D231*</A></message>

     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test
name=3D'definitions/server/fix41/2o_SendingTimeValueOutOfRange.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix41/2q_MsgTypeNotValid.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix41/2r_UnregisteredMsgType.def'
result=3D'success'/>
   <test
name=3D'definitions/server/fix41/2t_FirstThreeFieldsOutOfOrder.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix41/3b_InvalidChecksum.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.1*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D3*16=3D3*10=3D0*</E>

<A>8=3DFIX.4.1*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:57:28*56=
=3DTW*10=3D230*</A></message>

     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name=3D'definitions/server/fix41/3c_GarbledMessage.def'
result=3D'success'/>

    [...success...]

   <test
name=3D'definitions/server/fix42/2t_FirstThreeFieldsOutOfOrder.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/3b_InvalidChecksum.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.2*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D3*16=3D3*10=3D0*</E>

<A>8=3DFIX.4.2*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:58:27*56=
=3DTW*10=3D231*</A></message>

     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name=3D'definitions/server/fix42/3c_GarbledMessage.def'
result=3D'failure' >
     <message>
<E>8=3DFIX.4.2*9=3D54*35=3D2*34=3D2*49=3DISLD*52=3D00000000-00:00:00*56=
=3DTW*7=3D3*16=3D3*10=3D0*</E>

<A>8=3DFIX.4.2*9=3D45*35=3D0*34=3D2*49=3DISLD*52=3D20020903-13:58:57*56=
=3DTW*10=3D234*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in
`expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test
name=3D'definitions/server/fix42/4a_NoDataSentDuringHeartBtInt.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/4b_ReceivedTestRequest.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/6_SendTestRequest.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/7_ReceiveRejectMessage.def'
result=3D'success'/>
   <test
name=3D'definitions/server/fix42/8_AdminAndApplicationMessages.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/8_OnlyAdminMessages.def'
result=3D'success'/>
   <test name=3D'definitions/server/fix42/8_OnlyApplicationMessages.def=
'
result=3D'success'/>
</at>

I would expect all acceptance tests running fine. Could anybody explain=

this to me?

Thanks, J=F6rg

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

=

Hello,

after compiling on Linux (Debian 3.0 woody), we get the following 
failures during the acceptance test:

$ ./runat 12345
<at>
   <test name='definitions/server/fix40/10_MsgSeqNumEqual.def' 
result='success'/>

   [...success...]

   <test name='definitions/server/fix40/2c_MsgSeqNumTooLow.def' 
result='success'/>
   <test name='definitions/server/fix40/2d_GarbledMessage.def' 
result='failure' >
     <message>
<E>8=FIX.4.0*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=3*16=3*10=0*</E>
<A>8=FIX.4.0*9=45*35=0*34=2*49=ISLD*52=20020903-13:55:24*56=TW*10=223*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name='definitions/server/fix40/2e_PossDupAlreadyReceived.def' 
result='success'/>

	[...success...]

<test name='definitions/server/fix40/2t_FirstThreeFieldsOutOfOrder.def' 
result='success'/>
   <test name='definitions/server/fix40/3b_InvalidChecksum.def' 
result='failure' >
     <message>
<E>8=FIX.4.0*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=3*16=3*10=0*</E>
<A>8=FIX.4.0*9=45*35=0*34=2*49=ISLD*52=20020903-13:55:57*56=TW*10=229*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name='definitions/server/fix40/3c_GarbledMessage.def' 
result='success'/>

   [...success...]

   <test 
name='definitions/server/fix41/2k_CompIDDoesNotMatchProfile.def' 
result='success'/>
   <test 
name='definitions/server/fix41/2m_BodyLengthValueNotCorrect.def' 
result='failure' >
     <message>
<E>8=FIX.4.1*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=2*16=2*10=0*</E>
<A>8=FIX.4.1*9=45*35=0*34=2*49=ISLD*52=20020903-13:56:57*56=TW*10=231*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test 
name='definitions/server/fix41/2o_SendingTimeValueOutOfRange.def' 
result='success'/>
   <test name='definitions/server/fix41/2q_MsgTypeNotValid.def' 
result='success'/>
   <test name='definitions/server/fix41/2r_UnregisteredMsgType.def' 
result='success'/>
   <test 
name='definitions/server/fix41/2t_FirstThreeFieldsOutOfOrder.def' 
result='success'/>
   <test name='definitions/server/fix41/3b_InvalidChecksum.def' 
result='failure' >
     <message>
<E>8=FIX.4.1*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=3*16=3*10=0*</E>
<A>8=FIX.4.1*9=45*35=0*34=2*49=ISLD*52=20020903-13:57:28*56=TW*10=230*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name='definitions/server/fix41/3c_GarbledMessage.def' 
result='success'/>

    [...success...]

   <test 
name='definitions/server/fix42/2t_FirstThreeFieldsOutOfOrder.def' 
result='success'/>
   <test name='definitions/server/fix42/3b_InvalidChecksum.def' 
result='failure' >
     <message>
<E>8=FIX.4.2*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=3*16=3*10=0*</E>
<A>8=FIX.4.2*9=45*35=0*34=2*49=ISLD*52=20020903-13:58:27*56=TW*10=231*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test name='definitions/server/fix42/3c_GarbledMessage.def' 
result='failure' >
     <message>
<E>8=FIX.4.2*9=54*35=2*34=2*49=ISLD*52=00000000-00:00:00*56=TW*7=3*16=3*10=0*</E>
<A>8=FIX.4.2*9=45*35=0*34=2*49=ISLD*52=20020903-13:58:57*56=TW*10=234*</A></message>
     <trace><![CDATA[Runner.rb:64:in `compareAction']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:116:in `expectedAction']]></trace>
     <trace><![CDATA[./Reflector.rb:79:in `processFile']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `each_line']]></trace>
     <trace><![CDATA[./Reflector.rb:61:in `processFile']]></trace>
     <trace><![CDATA[./ReflectorClient.rb:132:in `start']]></trace>
     <trace><![CDATA[Runner.rb:124]]></trace>
     <trace><![CDATA[Runner.rb:107:in `each']]></trace>
     <trace><![CDATA[Runner.rb:107]]></trace>
   </test>
   <test 
name='definitions/server/fix42/4a_NoDataSentDuringHeartBtInt.def' 
result='success'/>
   <test name='definitions/server/fix42/4b_ReceivedTestRequest.def' 
result='success'/>
   <test name='definitions/server/fix42/6_SendTestRequest.def' 
result='success'/>
   <test name='definitions/server/fix42/7_ReceiveRejectMessage.def' 
result='success'/>
   <test 
name='definitions/server/fix42/8_AdminAndApplicationMessages.def' 
result='success'/>
   <test name='definitions/server/fix42/8_OnlyAdminMessages.def' 
result='success'/>
   <test name='definitions/server/fix42/8_OnlyApplicationMessages.def' 
result='success'/>
</at>

I would expect all acceptance tests running fine. Could anybody explain 
this to me?

Thanks, Jörg

Version 1.2.1, is now available from http://quickfix.thoughtworks.com.
This is a minor release.  Notes are below.

1.2.1
-----
config.h no longer included from Utility.h.  This was causing problems when
people wanted
to build quickfix application without autotools.

More robust detection of dropped/bad sockets. One of our users ran into a
problem with this
during certification with the CME. He has confirmed that it works correctly
now.

Closing acceptors now works in all situations.

Mutex locking in session is a little smarter, making it easier to
syncrhonize applications.

code is now auto formatted with astyle. This makes it easier for people to
contribute code
without having to worry as much about conforming to coding standards.

--oren

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

The biggest addition to this version is that we now have a .NET API.  Also
the documentation now covers how to write applications in java and .NET
(using C# for examples). Release notes are below.

1.2.0
-----
First release of .NET API for QuickFIX. The API is mostly a direct port of
the JAVA API,
future versions well attempt to refine this API to use more .NET specific
constructs. QuickFIX
applications can now be written in C# or VB.NET or any other CLR language.

Documentation covers all API's, C++, Java, and .NET

New example application executor. Executor example is implemented in C++,
Java and C#
for side by side comparison.

Fixed bug where the session time range was not calculated correctly when
minutes or
seconds were involved. (.i.e., is that start time was set to 12:30:00, the
30 would
cause problems, wheras 12:00:00 would be fine).

Resend requests with EndSeqNo set to 0 (>=FIX 4.2) or 999999 (<=FIX 4.1)
are now supported.

Possible duplicate messages with a sequence number that is too low will no
longer be forwarded
to the application callback.

FIX Specification parser modified so it will now capture some fields that
it was missing. The FIX42.xml
file in particular is more complete.

Made Java API more consistant with C++ API.

--oren

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

This announcement was already made on quickfix-developers, this is a
forward for the quickfix-users and quickfix-announce lists.

Version 1.1.0, our first really major release since 1.0.0, is now available
from http://quickfix.thoughtworks.com.

Thank you to everyone who provided feedback, and submitted patches. This
version has major new functionality, bug fixes, more compliance fixes, and
performance enhancements. The release notes are posted below, but first a
couple words for people planning on upgrading.

First of all, this release is most important for people who plan on doing a
lot of throughput and maintain many sessions. The new filestore is much
more efficient memory wise, and the addition of the ThreadedSocketInitiator
and ThreadedSocketAcceptor provide much better performance and scalability.

When upgrading, please keep in mind the following:

- QuickFIX now uses libxml2.  The folks at libxml has requested all new
projects stop using libxml1 and we are complying with this. You will need
libxml2 installed to build newer versions.

- The signitures for toApp and toAdmin in the Application interface has
changed.  Your applications will need to reflect this change to compile.
The message class is no longer const, this allows you to add fields to a
message before it is sent out.  Ideal for adding additional fields to
messages like Logons and such.

- FileStore has been rewritten.  As a result, the file format has changed.
You should not mix QuickFIX logs from earlier versions with 1.1.0.

- PosDup message are now passed to the application callbacks.  You will now
need to have your application verify whether it wants to process a
particular message that may be a duplicate.

Other than that, here are the release notes.  Please provide everyone with
feedback about this version on this list.

RELEASE NOTES
________________

1.1.0
-----
Added support for messages with repeating groups.

Added ThreadedSocketInitiator and ThreadedSocketAcceptor. Each session has
it own thread
for listening on a socket and one for processing messages.

The signature for toApp and toAdmin have changed from ( const Message&,
const SessionID& )
to ( Message&, const SessionID& ). This allows applications to add fields
to messages before
they are sent out. Particularly useful for administrative messages that
need fields that arn't
added by default.

Filestore is much more memory efficient. Only file offsets are stored in
memory
and messages are retreived on in as needed basis. This keeps memory use way
down and also is a little faster for normal operations.

On Linux and Solaris upgraded from libxml to libxml2. It is recomended by
the libxml guys that all new applications use libxml2. configure will
verify
that libxml is installed on a system and automatically add the necessary
command line parameters.

Possible duplicate messages are now passed to the fromAdmin and fromApp
application
callbacks. Applications must now check for this field and determine how
possible
duplicate messages should be handled.

Values.h correctly generated enumerations for fields of type INT.

Validation works with STRING enumerations, not just CHAR and INT.

Sockets are now properly closed if a connection fails. This fixes a leak in
socket
resources that appeared after a large number of reconnect attempts.

RefTagID, RefMsgType are no longer added to reject message in versions of
FIX 4.1
and earlier. BusinessMessageReject no longer used in FIX versions 4.1 and
earlier.

Improved DataDictionary generation. More enumerations are listed.

--oren

Hello, I am having a problem getting started using the example programs

I have tradeclient and ordermatch compiled, however after I send in an
order ordermatch does nothing and there is nothing in its log files. Do
I have something misconfigured? There doesn't seem to be much
documentation on setting these up.

I assume that I just place an order via tradeclient and ordermatch would
do something that would confirm it?

Thanks,
Justin Pauley

Here is the config file for tradeclient:

DEFAULT]
ConnectionType=initiator
ReconnectInterval=20
FileStorePath=logs
SenderCompID=<removed>
SocketAcceptPort=15207

[SESSION]
ConnectionType=initiator
TargetCompID=IB
HeartBtInt=30
BeginString=FIX.4.1
DataDictionary=spec/FIX41.xml
SocketConnectPort=15207
SocketConnectHost=208.245.107.4
StartTime=01:00:00
EndTime=23:00:00

Here is my config file for ordermatch:
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=20
FileStorePath=logs2
SenderCompID=direct57
SocketAcceptPort=15207

[SESSION]
TargetCompID=IB
HeartBtInt=30
BeginString=FIX.4.1
DataDictionary=spec/FIX41.xml
StartTime=01:00:00
EndTime=23:00:00

What am I doing wrong? :( 

Hello, I am having a problem getting started using the example programs

I have tradeclient and ordermatch compiled, however after I send in an
order ordermatch does nothing and there is nothing in its log files. Do
I have something misconfigured? There doesn't seem to be much
documentation on setting these up.

I assume that I just place an order via tradeclient and ordermatch would
do something that would confirm it?

Thanks,
Justin Pauley

Here is the config file for tradeclient:

DEFAULT]
ConnectionType=initiator
ReconnectInterval=20
FileStorePath=logs
SenderCompID=<removed>
SocketAcceptPort=15207

[SESSION]
ConnectionType=initiator
TargetCompID=IB
HeartBtInt=30
BeginString=FIX.4.1
DataDictionary=spec/FIX41.xml
SocketConnectPort=15207
SocketConnectHost=208.245.107.4
StartTime=01:00:00
EndTime=23:00:00

Here is my config file for ordermatch:
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=20
FileStorePath=logs2
SenderCompID=direct57
SocketAcceptPort=15207

[SESSION]
TargetCompID=IB
HeartBtInt=30
BeginString=FIX.4.1
DataDictionary=spec/FIX41.xml
StartTime=01:00:00
EndTime=23:00:00

What am I doing wrong? :( 

Hey guys,

im trying to compile current cvs snapshot on solaris.
as i dont have any clue about c++ (im working with C and perl)
i decided to write down some experiences for the list. im currently
trying to compile on sparcv9 platform with gcc version 3.1 20020423

first of all i get lots of "warning: no newline at end of file" which
seems 
to be just a cosmetic issue.
a more serious thing is the following :

In file included from AcceptorTestCase.cpp:57:
AcceptorTestCase.h:61: looser throw specifier for `virtual void 
   FIX::TestApplication::fromApp(const FIX::Message&, const
FIX::SessionID&)'
../Application.h:111:   overriding `virtual void 
   FIX::NullApplication::fromApp(const FIX::Message&, const
FIX::SessionID&) 
   throw (FIX::IncorrectTagValue&, FIX::UnsupportedMessageType&, 
   FIX::FieldNotFound&)'
gmake[4]: *** [AcceptorTestCase.lo] Error 1
gmake[4]: Leaving directory `/export/home/admin/quickfix/src/C++/test'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory `/export/home/admin/quickfix/src/C++'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/export/home/admin/quickfix/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/export/home/admin/quickfix'
gmake: *** [all] Error 2

this seems to me like the function called fromApp() doesnt match its
prototype.
at least its how i fixed this problem by adding the throw() after the
function call.
as i mentioned that im not a c++ programmer i hope that was something
useful - but as code
is provided like this i assume there must be another solution. i was
reading something about missing
throw() stuff and that the application has to catch errors and stuff.
but didnt help me further.

regards,

Heribert Steuer

2002	Jan	Feb (4)	Mar (6)	Apr (2)	May (4)	Jun (1)	Jul (1)	Aug (2)	Sep (11)	Oct (3)	Nov	Dec
2003	Jan (7)	Feb (3)	Mar (10)	Apr (40)	May (63)	Jun (12)	Jul (26)	Aug (13)	Sep (6)	Oct (13)	Nov (17)	Dec (28)
2004	Jan (13)	Feb (6)	Mar (9)	Apr (20)	May (15)	Jun (29)	Jul (22)	Aug (11)	Sep (32)	Oct (34)	Nov (22)	Dec (33)
2005	Jan (17)	Feb (8)	Mar (3)	Apr (20)	May (19)	Jun (29)	Jul (30)	Aug (10)	Sep (24)	Oct	Nov (17)	Dec (11)
2006	Jan (32)	Feb (54)	Mar (34)	Apr (43)	May (14)	Jun (11)	Jul (10)	Aug (43)	Sep (37)	Oct (44)	Nov (16)	Dec (11)
2007	Jan (26)	Feb (5)	Mar (23)	Apr (3)	May (22)	Jun (17)	Jul (22)	Aug (34)	Sep (17)	Oct (18)	Nov (4)	Dec (8)
2008	Jan (28)	Feb (28)	Mar (23)	Apr (37)	May (53)	Jun (20)	Jul (30)	Aug (12)	Sep (19)	Oct (16)	Nov (15)	Dec (10)
2009	Jan (19)	Feb (8)	Mar (21)	Apr (8)	May (15)	Jun (22)	Jul (34)	Aug (18)	Sep (23)	Oct (26)	Nov (16)	Dec (13)
2010	Jan (38)	Feb (17)	Mar (39)	Apr (34)	May (5)	Jun (15)	Jul (7)	Aug (18)	Sep (4)	Oct (16)	Nov (3)	Dec (17)
2011	Jan (28)	Feb (12)	Mar (36)	Apr (9)	May (26)	Jun (27)	Jul (6)	Aug (10)	Sep (6)	Oct (1)	Nov (1)	Dec
2012	Jan (3)	Feb (4)	Mar	Apr (7)	May (9)	Jun (4)	Jul (2)	Aug (1)	Sep	Oct (9)	Nov (10)	Dec (8)
2013	Jan (3)	Feb (2)	Mar (7)	Apr (2)	May	Jun (7)	Jul (22)	Aug (5)	Sep (3)	Oct (3)	Nov (3)	Dec (2)
2014	Jan (4)	Feb	Mar (7)	Apr	May	Jun	Jul (1)	Aug (7)	Sep (1)	Oct	Nov	Dec (1)
2015	Jan	Feb	Mar (3)	Apr	May	Jun (3)	Jul	Aug	Sep	Oct (4)	Nov (4)	Dec
2016	Jan (1)	Feb	Mar (3)	Apr	May	Jun	Jul (5)	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun (2)	Jul (1)	Aug	Sep (1)	Oct (5)	Nov (1)	Dec
2019	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar (3)	Apr	May	Jun	Jul (1)	Aug (1)	Sep (1)	Oct	Nov	Dec
2023	Jan	Feb	Mar (4)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

quickfix-users Mailing List for QuickFIX (Page 91)

quickfix-users — QuickFIX user support