quickfix-developers — QuickFIX developers forum

[Quickfix-developers] Field order in repeating groups?

[Edde <edd...@gm...>]

Hi,

I'm trying to build a trading application using repeating groups and
I'm running into some trouble with field order (at least that's what I
think is wrong).

I start off by sending a MarketDataRequest as follows:

(8=3DFIX.4.2=019=3D170=0135=3DV=0134=3D2=0149=3DEDDE_MD=0152=3D20050131-16:=
07:41.425=0156=3DFIP=01146=3D1=0155=3DEric
B=0148=3D101=0122=3D8=01207=3DST=01262=3DFR-SE0000108656-0=01263=3D0=01264=
=3D1=01267=3D7=01269=3D0=01269=3D1=01269=3D2=01269=3D4=01269=3D5=01269=3D8=
=01269=3D7=0110=3D103=01)

My counterpart application is answering this message by sending two
separate MarketDataSnapshotFullRefresh messages back. The first one
looks like this and I have no problems parsing this message containing
the first two entries in the repeating group:

(8=3DFIX.4.2=019=3D131=0135=3DW=0134=3D2=0149=3DFIP=0152=3D20050131-16:06:5=
7.510=0156=3DEDDE_MD=01262=3DFR-SE0000108656-0=01268=3D2=01269=3D0=01270=3D=
20.8=01271=3D10000=01269=3D1=01270=3D20.9=01271=3D13000=0110=3D146=01)

The problem occurrs when I try to parse the second message which
contains the last five entries in the repeating group. This message
look like this:

(8=3DFIX.4.2=019=3D196=0135=3DW=0134=3D3=0149=3DFIP=0152=3D20050131-16:06:5=
7.512=0156=3DEDDE_MD=01262=3DFR-SE0000108656-0=01268=3D5=01381=3D28185455.4=
=01387=3D1354717=01561=3D1000=01269=3D2=01270=3D20.9=01271=3D1000=01269=3D4=
=01270=3D0=01269=3D5=01270=3D22.2=01269=3D7=01270=3D20.9=01269=3D8=01270=3D=
20=0110=3D146=01)

I never get a chance to parse this message since the QuickFix engine
traps the message and sends the following message back.

(8=3DFIX.4.2=019=3D122=0135=3D3=0134=3D3=0149=3DEDDE_MD=0152=3D20050131-16:=
07:43.928=0156=3DFIP=0145=3D3=0158=3DIncorrect
NumInGroup count for repeating group=01371=3D268=01372=3DW=0110=3D177=01)

Now, based on the reject message this seems to be a problem with the
number of entries in the group but that seems ok to me (268=3D5 and
there are five 269 tags in the message).
However, when I double checked the FIX spec for the MDEntryType field
it says "Must be the first field in the repeating group". In the
message I receive the 268=3D5 tag isn't immediately followed by the
first 269 tag so I suspect this is the problem but I want to make sure
this is the case before I go to my counterparty and tells them there
is a bug in their application.
Is this indeed the reason why QuickFix is rejecting the message?
If this is the reason then is there a way to make QuickFix ignore this
error so I can test the application before my counterparty fixes the
bug?

Thanks,
/Eddie

[Quickfix-developers] toString method

[Michael H. <mh...@li...>]

V2hlbiB5b3UgY2FsbCB0aGUgdG9TdHJpbmcgbWV0aG9kIGluIHRoZSBtZXNzYWdlIGNsYXNzIHRo
ZSBzdHJpbmcgcmV0dXJuZWQgaXMgbm90IGd1YXJhbnRlZWQgdG8gYmUgb2YgdGhlIHNhbWUgZXhh
Y3QgZm9ybWF0IG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLiBTaW5jZSBJIG5lZWQgdG8gYmUgYWJs
ZSB0byByZXRyaWV2ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZSBpbiB0aGUgb3JpZ2luYWwgZm9ybWF0
IEkgYWRkZWQgYW5vdGhlciBtZW1iZXIgdmFyaWFibGUgYW5kIG1ldGhvZCB0byByZXR1cm4gdGhp
cyBpbmZvcm1hdGlvbi4gSSBoYXZlIHNlZW4gb3RoZXIgcG9zdHMgY29tbWVudGluZyBhYm91dCB0
aGlzLiBJIG5lZWQgdGhpcyB3aGVuIHJlY2VpdmluZyB1c2VyIGRlZmluZWQgbWVzc2FnZXMgc28g
SSBjYW4gcHJvY2VzcyB0aGVtIGNvcnJlY3RseS4gVGhpcyBwcm9iYWJseSBzaG91bGQgYmUgYWRk
ZWQgcGVybWFuZW50bHkuIEkgY2FuIHBvc3QgdGhlIGNvZGUgaWYgeW91IHdhbnQgdG8gYWRkIHRo
aXMgdG8gdGhlIGxpYnJhcnkuDQogDQpUaGFua3MNCk1pY2hhZWwNCg==

[Quickfix-developers] Week long session bug.

[Michael H. <mh...@li...>]

SSBhbSB1c2luZyBRdWlja0ZpeCAxLjYgdG8gY29ubmVjdCB0byBTRkUuIEkgYW0gcGxhbm5pbmcg
b24gdXNpbmcgdGhlIG5ld2VzdCB2ZXJzaW9uIDEuOTQgYW5kIGhhdmUgZm91bmQgYSB3ZWlyZCBi
dWcgd2l0aCB3ZWVrIGxvbmcgc2Vzc2lvbnMuIEkgc2V0IHRoZSBzZXNzaW9uIHRvIHJ1biBmcm9t
IE1vbmRheSAtIEZyaWRheS4gVGhpcyB3b3JrcyBmaW5lIGZvciB0aGUgZmlyc3Qgd2VlayBidXQg
d2hlbiBpdCBzaG91bGQgc3RhcnQgb24gdGhlIGZvbGxvd2luZyBNb25kYXkgdGhlIG9ubHkgdGhp
bmcgdGhhdCBoYXBwZW5zIGlzIHRoYXQgaXQgY3JlYXRlcyBhIHNlZXNpb24gYW5kIHRoZW4gaGFu
Z3MuIEhhcyBhbnlvbmUgc2VlbiB0aGlzIGJlZm9yZT8gSWYgSSBnZXQgcmlkIG9mIHdlZWsgbG9u
ZyBzZXNzaW9ucyBldmVyeXRoaW5nIHJ1bnMgZmluZS4NCiANClRoYW5rcw0KTWljaGFlbA0K

Re: [Quickfix-developers] Message Reject when receiving Repeating Groups in MarketDataSnapshot/Full Refresh

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

You probably haven't assigned a data dictionary to your session.  This =20=

is required if you intend on using repeating groups.  Without a =20
dictionary, QuickFIX has no way of identifying what tags belong to =20
repeating groups in your message, and must therefore assume any =20
repeated tag is a duplicate which must be rejected.

--oren

On Jan 28, 2005, at 10:08 AM, Edde wrote:

> QuickFIX Documentation: =20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: =20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi all,
>
> My name is Eddie Robertsson and I'm very new to QuickFix (started
> ud=D8=F3sing it about 2 weeks ago...). I'm using version 1.9.4 of the =
Java
> API in QuickFix and this far things have been going really well.
> However, I ran into a problem today when I tried to get MarketData
> from our broker.
>
> I start off by sending a MarketDataRequest message for full market
> data snapshot of one instrument using 7 repeating groups (Bid, Offer,
> Trade, Opening Price, Closing Price, Trading Session High Price and
> Trading Session Low Price). This is the FIX message being sent:
>
> (8=3DFIX.4.2=019=3D157=0135=3DV=0134=3D2=0149=3DEDDE_MD=0152=3D20050128-=
16:00:=20
> 53.164=0156=3DFIP=01146=3D1=0155=3DEric
> =
B=0148=3D101=0122=3D8=01207=3DST=01262=3DFROW=01263=3D0=01264=3D1=01267=3D=
7=01269=3D0=01269=3D1=01269=3D2=01269=3D4=20
> =01269=3D5=01269=3D8=01269=3D7=0110=3D248=01)
>
> The problem occurrs when I receive the answer to this message which is
> a MarketData Snapshot/Full Refresh message with repeating groups. The
> message looks like this:
>
> (8=3DFIX.4.2=019=3D118=0135=3DW=0134=3D2=0149=3DFIP=0152=3D20050128-16:0=
0:=20
> =
16.812=0156=3DEDDE_MD=01262=3DFROW=01268=3D2=01269=3D0=01270=3D21.3=01271=3D=
1000=01269=3D1=01270=3D22.2=20
> =01271=3D144000=0110=3D029=01)
>
> The problem is that my application never receives this message since
> it is rejected by QuickFix at an earlier stage with the following
> reason:
> (Message 2 Rejected: Tag appears more than once:269)
>
> QuickFix then rejects the message by sending the following back to my
> counterpart:
>
> (8=3DFIX.4.2=019=3D102=0135=3D3=0134=3D3=0149=3DEDDE_MD=0152=3D20050128-=
16:00:=20
> 55.427=0156=3DFIP=0145=3D2=0158=3DTag
> appears more than once=01371=3D269=01372=3DW=0110=3D157=01)
>
> It seems to me that what I'm receiving is a valid response to my
> request but for some reason QuickFix rejects the message. Any ideas?
> The only thing I can think of is that the response is missing the
> required tag 55 but it seems to be a very strange error message if
> this is indeed the problem.
>
> Any help is much appreciated.
> Cheers,
> /Eddie
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive =
Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] Message Reject when receiving Repeating Groups in MarketDataSnapshot/Full Refresh

[Edde <edd...@gm...>]

Hi all,

My name is Eddie Robertsson and I'm very new to QuickFix (started
using it about 2 weeks ago...). I'm using version 1.9.4 of the Java
API in QuickFix and this far things have been going really well.
However, I ran into a problem today when I tried to get MarketData
from our broker.

I start off by sending a MarketDataRequest message for full market
data snapshot of one instrument using 7 repeating groups (Bid, Offer,
Trade, Opening Price, Closing Price, Trading Session High Price and
Trading Session Low Price). This is the FIX message being sent:

(8=3DFIX.4.2=019=3D157=0135=3DV=0134=3D2=0149=3DEDDE_MD=0152=3D20050128-16:=
00:53.164=0156=3DFIP=01146=3D1=0155=3DEric
B=0148=3D101=0122=3D8=01207=3DST=01262=3DFROW=01263=3D0=01264=3D1=01267=3D7=
=01269=3D0=01269=3D1=01269=3D2=01269=3D4=01269=3D5=01269=3D8=01269=3D7=0110=
=3D248=01)

The problem occurrs when I receive the answer to this message which is
a MarketData Snapshot/Full Refresh message with repeating groups. The
message looks like this:

(8=3DFIX.4.2=019=3D118=0135=3DW=0134=3D2=0149=3DFIP=0152=3D20050128-16:00:1=
6.812=0156=3DEDDE_MD=01262=3DFROW=01268=3D2=01269=3D0=01270=3D21.3=01271=3D=
1000=01269=3D1=01270=3D22.2=01271=3D144000=0110=3D029=01)

The problem is that my application never receives this message since
it is rejected by QuickFix at an earlier stage with the following
reason:
(Message 2 Rejected: Tag appears more than once:269)

QuickFix then rejects the message by sending the following back to my
counterpart:

(8=3DFIX.4.2=019=3D102=0135=3D3=0134=3D3=0149=3DEDDE_MD=0152=3D20050128-16:=
00:55.427=0156=3DFIP=0145=3D2=0158=3DTag
appears more than once=01371=3D269=01372=3DW=0110=3D157=01)

It seems to me that what I'm receiving is a valid response to my
request but for some reason QuickFix rejects the message. Any ideas?
The only thing I can think of is that the response is missing the
required tag 55 but it seems to be a very strange error message if
this is indeed the problem.

Any help is much appreciated.
Cheers,
/Eddie

[Quickfix-developers] Bug #55 - bug in seqnum storing file

[Joerg T. <Joe...@ma...>]

Hi all,

as reported by Alexey Zubko, I added the following bug:

<http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=55>

My first though was to append new-line instead of space, but new-line is different on 
Windows, Mac and UNIX. Since the space is also a separator in the header file, I would do 
the following changes in FileStore.cpp:

  147 if ( fscanf( seqNumFile, "%d : %d ", &sender, &target ) == 2 )
                                       ^

and

288 fprintf( m_seqNumsFile, "%d : %d ",
                                     ^
289          getNextSenderMsgSeqNum(), getNextTargetMsgSeqNum() );

Thanks, Alexey  for reporting that.

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

Re: [Quickfix-developers] Rejected messages and resend requests

[<fra...@fr...>]

Selon Caleb Epstein <cal...@gm...>:

> On Wed, 26 Jan 2005 11:18:26 +0100, fra...@fr...
> <fra...@fr...> wrote:
>
> > It seems to me that Quickfix incorrectly resends rejected messages (a=
t
> session
> > level).
>
> I don't think that this is possible.  Session-level reject messages
> are sent with MsgType=3D3 which should be caught and filtered out in
> Session::nextResendRequest at the check for Message::isAdminMsgType.
>
> Do you have a session log that illustrates this behavior?
>

I did not say that Quickfix resends Reject message, which it does not.
I said that the engine resends messages that have been previously rejecte=
d at
session level (incriminated message is pointed by refSeqNum).

Fran=E7ois

Re: [Quickfix-developers] Rejected messages and resend requests

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

On Wed, 26 Jan 2005 11:18:26 +0100, fra...@fr...
<fra...@fr...> wrote:

> It seems to me that Quickfix incorrectly resends rejected messages (at session
> level).

I don't think that this is possible.  Session-level reject messages
are sent with MsgType=3 which should be caught and filtered out in
Session::nextResendRequest at the check for Message::isAdminMsgType.

Do you have a session log that illustrates this behavior?

-- 
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] VMS port of QF

[John G. <joh...@wa...>]

Hi and thanks for the answer,

> Having not worked with VMS for years now, I guess there is a decent C++ compiler now. 
Should be ok as far as c++ is concerned.

> Since the UNIX build system of QuickFIX is based on the GNU autotools (automake, autoconf) 
> I wonder whether they can also cope with VMS. Perhaps you should check www.gnu.org for 
> this; it would make the life much easier. In addition, check if there is a UNIX/POSIX etc. 
> compatibility layer on VMS. I am sure, there some stuff of this kind.

It seems it depends on the considered tool. The gnu build system is nice
for a gnu OS but is a real pain to cope with if not. If you want to fully
compile PHP or QF on a Solaris machine, you'll need to install M4,
autoconf, automake, libtool at least. On a VMS machine, may be add perl to
that. I had a look at the GVN project, which basically looks like a "vms
cygwin" that does not build necessarily build native vms libs, and anyway
the VMS version requirements are not met (still in 7.1, need 7.3).

> Looking forward to hear news from the VMS port...
Well, so far, I am slowly tracking all the G++ includes needed and 
wondering why one of them (streambuf.h) does not compile, so it looks like 
a looooong night coming along ;-)

Thanks for feedback on fixml too.

Sincerely,
John GALLET

Re: [Quickfix-developers] Rejected messages and resend requests

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

No, we don't do anything like this currently.  We'll add this to our=20
implementation schedule.

--oren

On Jan 26, 2005, at 4:18 AM, fra...@fr... wrote:

> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:=20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
> Hello,
>
> It seems to me that Quickfix incorrectly resends rejected messages (at=20=

> session
> level).
>
> Quoting the Fix protocol:
> "If the sending application chooses to retransmit the rejected=20
> message, it
> should be assigned a new sequence number and sent with PossResend=3DY."
>
> In my understanding, when responding to a resend request, Quickfix=20
> should not
> resend a previously rejected message but generate a Sequence Request=20=

> to skip to
> the next valid message.
>
> Correct me if I am wrong, I see no mechanism currently implemented in=20=

> the engine
> doing this. Unfortunately this does not look very easy. Since the=20
> engine should
> remember rejected messages, this has to be stored in persistence.
>
> Best regards,
>
> Fran=E7ois
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive =
Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] VMS port of QF

[Joerg T. <Joe...@ma...>]

Hi John,

> I did not find anything relevent in the archives, so I am askng on the 
> list : has anyone tried to port / compile QuickFix to VMS operating system 
> ?
> The company I am working at runs an in-house fix client that is very badly 
> written, but runs on windows, all unixes, and VMS. We are thinking of 
> moving to QuickFix, but we need to port it to VMS. If anyone has had any 
> experience with that kind of sport, I'd be happy to have some feedback. I 
> already compiled libxml2 (had to disable a few functions new to 2.6.17 and 
> some const pointers that the C vms compiler considered not const) but I do 
> have a libxml lib. I am now in the process of rewriting a config.h and 
> makefiles. 

Having not worked with VMS for years now, I guess there is a decent C++ compiler now. 
Since the UNIX build system of QuickFIX is based on the GNU autotools (automake, autoconf) 
I wonder whether they can also cope with VMS. Perhaps you should check www.gnu.org for 
this; it would make the life much easier. In addition, check if there is a UNIX/POSIX etc. 
compatibility layer on VMS. I am sure, there some stuff of this kind.

> Second, non technical question I have, is about Fixml : how often is it 
> found in real life production applications ? If I want to developp a fix 
> server to collect orders in Fix format, should I really develop this 
> part, which seems right now pretty unused to me, at least in Europe. I 
> found some opinions in this direction in the archives, but that was nearly 
> a year ago.

We are Europe based and doing (Quick)FIX consulting. But up to now I did not hear about 
any production usage of FIXML in Europe. But the best way to find out is probably to post 
the question in the FPL forums at http://www.fixprotocol.org

Looking forward to hear news from the VMS port...

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

[Quickfix-developers] VMS port of QF

[John G. <joh...@wa...>]

Hi there,

I did not find anything relevent in the archives, so I am askng on the 
list : has anyone tried to port / compile QuickFix to VMS operating system 
?
The company I am working at runs an in-house fix client that is very badly 
written, but runs on windows, all unixes, and VMS. We are thinking of 
moving to QuickFix, but we need to port it to VMS. If anyone has had any 
experience with that kind of sport, I'd be happy to have some feedback. I 
already compiled libxml2 (had to disable a few functions new to 2.6.17 and 
some const pointers that the C vms compiler considered not const) but I do 
have a libxml lib. I am now in the process of rewriting a config.h and 
makefiles. 

Second, non technical question I have, is about Fixml : how often is it 
found in real life production applications ? If I want to developp a fix 
server to collect orders in Fix format, should I really develop this 
part, which seems right now pretty unused to me, at least in Europe. I 
found some opinions in this direction in the archives, but that was nearly 
a year ago.

TIA for any hints.

Sincerely,
John GALLET

[Quickfix-developers] Rejected messages and resend requests

[<fra...@fr...>]

Hello,

It seems to me that Quickfix incorrectly resends rejected messages (at se=
ssion
level).

Quoting the Fix protocol:
"If the sending application chooses to retransmit the rejected message, i=
t
should be assigned a new sequence number and sent with PossResend=3DY."

In my understanding, when responding to a resend request, Quickfix should=
 not
resend a previously rejected message but generate a Sequence Request to s=
kip to
the next valid message.

Correct me if I am wrong, I see no mechanism currently implemented in the=
 engine
doing this. Unfortunately this does not look very easy. Since the engine =
should
remember rejected messages, this has to be stored in persistence.

Best regards,

Fran=E7ois

[Quickfix-developers] bug in seqnum storing file

[Alexey Z. <ale...@in...>]

Hello,
=20
There is a pretty interesting bug (my system is Win2k, VC6).
FileStore::setSeqNum() doesn=92t save target sequence number correctly =
=96
If the number was big and you reset it during run, fprintf overrides not
all numbers:
=20
For example (the number is 301599):
87 : 301599
After reset (the number is 1 -> it writes =931 : 1=94):
1 : 101599
=20
When I restart my application QF expect the seqnum 101599, not 1.
=20
I think you have to change format =96 add a space:
=20
void FileStore::setSeqNum()
{ QF_STACK_PUSH(FileStore::setSeqNum)
=20
  rewind( m_seqNumsFile );
// old  fprintf( m_seqNumsFile, "%d : %d",
  fprintf( m_seqNumsFile, "%d : %d ",
           getNextSenderMsgSeqNum(), getNextTargetMsgSeqNum() );
  if ( ferror( m_seqNumsFile ) ) throw IOException();
  if ( fflush( m_seqNumsFile ) ) throw IOException();
=20
  QF_STACK_POP
}
=20
=20
=20
Regards,
Alexey.

Re: [Quickfix-developers] rejection due to duplicate tag in NoParties repeating group?

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

It would be more helpful if you would post the message in its entirety.

--oren

----- Original Message ----- 
From: "Xizhen Wang" <wan...@ya...>
To: <qui...@li...>
Sent: Monday, January 24, 2005 10:26 AM
Subject: [Quickfix-developers] rejection due to duplicate tag in NoParties 
repeating group?


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi, when I use QuickFix to process an Execution Report
> msg, QF rejected the msg due to duplicate tag (tag 447
> PartyIDSource) in NoParties repeating group, as below:
>
> 8=FIX.4.4
9=114
35=3
34=2
49=ABC
52=20050124-15:41:12.334
56=DEF
45=2
58=Tag
> appears more than once
371=447
372=8
373=13
10=064

>
>
> Below is relevant part of the Execution Report msg:
> 453=3
448=XXXXX
447=C
452=3
448=xx...@xx...
447=C
452=11
448=XXXXXXX
447=B
452=1
>
> Could anyone help? Thanks!
> Alvin
>
>
> =====
> /)_/)
> ( ._.)
> c(")(")
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

[Quickfix-developers] rejection due to duplicate tag in NoParties repeating group?

[Xizhen W. <wan...@ya...>]

Hi, when I use QuickFix to process an Execution Report
msg, QF rejected the msg due to duplicate tag (tag 447
PartyIDSource) in NoParties repeating group, as below:

8=FIX.4.4
9=114
35=3
34=2
49=ABC
52=20050124-15:41:12.334
56=DEF
45=2
58=Tag
appears more than once
371=447
372=8
373=13
10=064



Below is relevant part of the Execution Report msg:
453=3
448=XXXXX
447=C
452=3
448=xx...@xx...
447=C
452=11
448=XXXXXXX
447=B
452=1

Could anyone help? Thanks!
Alvin


=====
/)_/)
( ._.)
c(")(")

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Quickfix-developers] CFG file documentation error

[Scott H. <sco...@fo...>]

The file doc/html/configuration.html (which I would wager is a frequently 
bookmarked page on the website) has the ConnectionType parameter 
misspelled as "initator".

Might seem like a minor problem, but the src/C++/Initiator.cpp 
initialize() loop silently ignores anything but "initiator" and results in 
the user getting a mysterious "No sessions defined for initiator" message.

I have added a feature request (#54) for a sanity check when loading the 
SessionSettings from a .cfg file.  Can someone please correct the 
configuration.html file in CVS (and on the current website) also?  I 
didn't report that as a separate bug.

[Quickfix-developers] Bug #53 - Possible deadlock if sendToTarget is called in Java fromApp() callbacks

[Joerg T. <Joe...@ma...>]

Hi all,

in some rare situations Java application using QuickFIX may deadlock rendering the FIX 
connection dead:

http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=53

All Java objects implementing the Application interface are protected by a C++ level mutex.

In some rare situations, two thread may lock the mutex of the C++ Session object and the 
JavaApplication mutex in different order, causing a deadlock.

Typical scenario:

Thread 1: started by QuickFIX, locks JavaApplication.m_mutex in fromApp(), locks 
Session.m_mutex in sendToTarget()

Thread 2: started by Java application, locks Session.m_mutex in sendToTarget(), locks 
JavaApplication.m_mutex in toApp()

Then the thread processing incoming FIX message is deadlocked.

This is fixed in the CVS repository:

http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/java/JavaApplication.cpp?r1=1.16&r2=1.17
http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/java/JavaApplication.h?r1=1.11&r2=1.12

You may also patch the current 1.9.4 with these two files.

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

[Quickfix-developers] Bug #52 - bootstrapping autoconf with new libxml2 breaks build process

[Joerg T. <Joe...@ma...>]

Hi all,

this bug may be interesting for all people calling ./bootstrap themselves:

http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=52

Newer libxml2 version since June 2004 define the include directory in another make 
variable (XML_CPPFLAGS instead of XML_CFLAGS). This breaks Makefile generation since 
./configure.in relies on XML_CFLAGS.

Fixed in the repository.

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

Re: [Quickfix-developers] SessionQualifier not copied properly for Java

[Joerg T. <Joe...@ma...>]

Scott Harrington wrote:
> I started using the new SessionQualifier feature today (using JNI) and had
> failures at first.  I tracked it down to the src/java/Conversions.h file, 
> and the problem was pretty easy to fix.  Here is the patch:

Thanks, Scott, for the patch. The bug has been fixed:

http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=50

See CVS repository:

http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/java/Conversions.h?r1=1.16&r2=1.17

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

Re: [Quickfix-developers] Session::next/nextQueued deep recursion

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

Yeah, next is a recursive call (which in turn calls nextQueued, which 
can in turn call next again) so I can see how this could happen.  We 
may need to redesign this in a non-recursive way so it can better 
handle arbitrarily large queues.

--oren

On Jan 19, 2005, at 2:04 PM, Caleb Epstein wrote:

> We had a crash in production today that I believe was caused by a
> stack overflow due to deep recursion by the Session::next and
> ::nextQueued methods.
>
> Basically, a session was disconnected (possibly due to a networking
> outage - still investigating that).  Re-establishing the connection
> took long enough that a large backlog of messages built up on both
> sides of the connection.  When the connection was re-established, we
> ended up with a large queue of messages, and our process crashed.
>
> I'm attaching the stack trace, which is over 2,600 levels deep!  I'm
> pretty sure the stack overflowed.
>
> The process is compiled with optimized code on the Sun C++ compiler,
> so there are function names but no symbols etc in the output.  Let me
> know if more info is needed to debug this.
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com
> <stacktrace.txt.gz>

[Quickfix-developers] SessionQualifier not copied properly for Java

[Scott H. <sco...@fo...>]

I started using the new SessionQualifier feature today (using JNI) and had
failures at first.  I tracked it down to the src/java/Conversions.h file, 
and the problem was pretty easy to fix.  Here is the patch:

diff -u -r1.16 Conversions.h
--- Conversions.h       3 Nov 2004 16:31:54 -0000       1.16
+++ Conversions.h       20 Jan 2005 19:44:02 -0000
@@ -69,16 +69,18 @@
 {
   JNIEnv * pEnv = ENV::get();
   JVMClass type( "Lquickfix/SessionID;" );
-  jmethodID method = pEnv->GetMethodID( type, "<init>", "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V" );
+  jmethodID method = pEnv->GetMethodID( type, "<init>", "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V" 
);
   
   jstring beginString = newString( sessionID.getBeginString().getValue() );
   jstring senderCompID = newString( sessionID.getSenderCompID().getValue() );
   jstring targetCompID = newString( sessionID.getTargetCompID().getValue() );
-  jobject result = pEnv->NewObject( type, method, beginString, senderCompID, targetCompID );
+  jstring qualifier = newString( sessionID.getSessionQualifier() );
+  jobject result = pEnv->NewObject( type, method, beginString, senderCompID, targetCompID, qualifier );
 
   pEnv->DeleteLocalRef( beginString );
   pEnv->DeleteLocalRef( senderCompID );
   pEnv->DeleteLocalRef( targetCompID );
+  pEnv->DeleteLocalRef( qualifier );
   return result;
 }
 

[Quickfix-developers] Session::next/nextQueued deep recursion

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

We had a crash in production today that I believe was caused by a
stack overflow due to deep recursion by the Session::next and
::nextQueued methods.

Basically, a session was disconnected (possibly due to a networking
outage - still investigating that).  Re-establishing the connection
took long enough that a large backlog of messages built up on both
sides of the connection.  When the connection was re-established, we
ended up with a large queue of messages, and our process crashed.

I'm attaching the stack trace, which is over 2,600 levels deep!  I'm
pretty sure the stack overflowed.

The process is compiled with optimized code on the Sun C++ compiler,
so there are function names but no symbols etc in the output.  Let me
know if more info is needed to debug this.

-- 
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] QF (acceptor) crash

[Alexey Z. <ale...@in...>]

Hello All,
=20
I=92ve got a crash (unhandled exception) in a server application.
Here is the scenario:
=20
I added a non required field (tag 50) to logon message and sent it by
mistake without value:
8=3DFIX.4.29=3D9635=3DA34=3D149=3DXXXX50=3D52=3D20050119-19:37:3=85..
=20
And I=92ve got a crash in the server =96 m_sessionID is not valid.
=20
=20
void Session::generateReject( const Message& message, int err, int field
)
{ QF_STACK_PUSH(Session::generateReject)
=20
  if ( !m_state.receivedLogon() )
    throw std::logic_error( "Tried to send a reject while not logged on"
);
=20
/***/// here is the crash
  std::string beginString =3D m_sessionID.getBeginString();
=20
=20
=20
Regards, Alexey.

RE: [Quickfix-developers] initiator still trying to connect after EndTime..?

[Gururaj K. <gkr...@ba...>]

Most of us use fixed session times per QF process. Hence this bug was
not noted.

The issue is in ThreadedSocketInitiator code - code that creates the
socket was not aware of session times after the session ended..

These are your steps. This is a fix if you are using
ThreadedSocketInitiator. This is also a fix for an older QF version -
the StartDay,EndDay parameters are not included in this calculation.

In ThreadedSocketInitiator::socketThread() method, after the "delete
pConnection;" statement in line 202, add the following code. This will
sleep till session start time.
	if (!sessp->isSessionTime())
	 {
		long numsecs = sessp->getSecondsToStart();
		process_sleep(abs(numsecs));
	 }

In Session.cpp (src/C++) define this function to be:
long Session::getSecondsToStart()
{
	UtcTimeOnly tnow;
	tnow.setCurrent();

	long rnum = m_startTime - tnow;	
	// if we are already past startTime for today, 
	// get startTime for next calendar day.
	if (rnum < 0) return rnum + UTC_DAY;
}

Also, add a declaration in Session.h file.

Regards,
Guru.

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Xizhen Wang
Sent: Tuesday, January 18, 2005 2:18 PM
To: Oren Miller; qui...@li...
Subject: Re: [Quickfix-developers] initiator still trying to connect
after EndTime..?


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ:
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Can anyone answer this question? I wonder how others
can put QuickFix in production with this problem
unsolved...

Thanks

2005-01-12 08:08  
 Hi,
 
 At the endtime, my initiator dropped the connection.
 This is right. However, it keeps trying to reconnect
 after that. After Connection succeeds, it drops the
 connection again, and then connct again.... This is
 odd.
 
 Can anyone help?
 
 Thanks!
 Alvin

 

--- Oren Miller <or...@qu...> wrote:

> This may be a bug, I'll investigate it.
> 
> --oren
> 
> ----- Original Message -----
> From: "Xizhen Wang" <wan...@ya...>
> To: <qui...@li...>
> Sent: Wednesday, January 12, 2005 11:16 AM
> Subject: [Quickfix-developers] When is Logout Msg
> sent out?
> 
> 
> > QuickFIX Documentation:
> >
>
http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
>
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support:
> http://www.quickfixengine.org/services.html
> >
> > Hi, I just wonder on what condition QF sends out
> the
> > Logout message from Initiator? It seems it does
> not
> > send out the Logout msg at EndTime. It simply
> drops
> > the connection.
> >
> > Could anyone clarify? Thanks
> > Alvin
> >
> > =====
> > /)_/)
> > ( ._.)
> > c(")(")
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Take Yahoo! Mail with you! Get it on your mobile
> phone.
> > http://mobile.yahoo.com/maildemo
> >
> >
> >
>
-------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the
> post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt
> from ThinkGeek.
> > It's fun and FREE -- well,
> almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Quickfix-developers mailing list 
> > Qui...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > 
> 
> 


=====
/)_/)
( ._.)
c(")(")


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE
limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and
FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers