quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Repeating groups?

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

You need to use the specific group class.  If you just use the generic =
base
Group class, QF will not know how to properly sort the fields.  Instead=
 of
this:

Group Qset =3D new Group(296, 0x1);
Qset.setField(...);

Group Quotes =3D new Group(295, 0x1);
Quotes.setField(...);

you should have

QuickFix42.MassQuote.NoQuoteSets Qset =3D
  new QuickFix42.MassQuote.NoQuoteSets Qset();
Qset.set(...);

QuickFix42.MassQuote.NoQuoteSets.NoQuoteEntries Quotes =3D
  new QuickFix42.MassQuote.NoQuoteSets.NoQuoteEntries();
Quotes.set(...);

Here is a link to the C# example for creating messages with repeating
groups:
http://quickfix.thoughtworks.com/documentation/csharp/repeating_groups_=
1.html

--oren


|---------+----------------------------------------------->
|         |           "Rob Kulseth" <ro...@ri...>   |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           04/10/2003 02:07 PM                 |
|         |                                               |
|---------+----------------------------------------------->
  >--------------------------------------------------------------------=
--------------------------|
  |                                                                    =
                          |
  |       To:       <qui...@li...>        =
                          |
  |       cc:                                                          =
                          |
  |       Subject:  [Quickfix-developers] Repeating groups?            =
                          |
  >--------------------------------------------------------------------=
--------------------------|




I have attached the result of creating a quickfix MassQuote message wit=
h
three quotes for some RBK options.  it is presented in the order in whi=
ch
the string was generated, I have added tabs and linebreaks to show the
repeating groups.  When ever I send a message like this to my counterpa=
rty
it breaks their fix server.  They are telling me that the tags are out =
of
order.  tag 302 304 and 311 have to precede 209 and tag 301 has to prec=
ede
tag 296.  my question is this: Is this FIX standard?  If it is, what is=

wrong with generation of the message.  I have attached psudocode of my
message generation after the message.

8=3DFIX.4.2=019=3D433=0135=3Di=0134=3D30=0149=3DSENDER=0150=3DSUB=0152=3D=
20030410-18:09:08=0156=3DTARGET=01
57=3DTEST=01
117=3DQUOTEID=01
             296=3D1=01
                         295=3D3=01

                         55=3DRBK=01
                         60=3D20030410-13:09:08=01
                         132=3D0=01
                         133=3D0.05=01
                         134=3D1=01
                         135=3D1=01
                         167=3DOPT=01
                         200=3D200304=01
                         201=3D1=01
                         202=3D30=01
                         299=3D0=01
                         336=3DW_AM1=01

                         55=3DRBK=01
                         60=3D20030410-13:09:08=01
                         132=3D10.2=01
                         133=3D10.7=01
                         134=3D1=01
                         135=3D1=01
                         167=3DOPT=01
                         200=3D200304=01
                         201=3D0=01
                         202=3D32.5=01
                         299=3D1=01
                         336=3DW_AM1=01

                         55=3DRBK=01
                         60=3D20030410-13:09:08=01
                         132=3D0=01
                         133=3D0.05=01
                         134=3D1=01
                         135=3D1=01
                         167=3DOPT=01
                         200=3D200304=01
                         201=3D1=01
                         202=3D32.5=01
                         299=3D2=01
                         336=3DW_AM1=01

             302=3D1=01
             304=3D0=01
             311=3DRBK=01
301=3D1=01
10=3D063=01


private void Tick()
{
             QuickFix42.MassQuote m =3D new QuickFix42.MassQuote();
             m.setField(new QuoteID(mClient.mUserID));
             m.setField(new QuoteResponseLevel(1)); //tell me only abou=
t
bad quotes
             foreach(group of quotes I am quoting known as the variable=
 p)
             {
                         Group Qset =3D new Group(296, 0x1);
                         Qset.setField(new
QuoteSetID(mQuoteSetID.ToString()));
                         Qset.setField(new UnderlyingSymbol(p.Series));=

                         Qset.setField(new TotQuoteEntries(0));
                         foreach(quote in my quote group p known as Q)
                         {
                                     Group Quotes =3D new Group(295, 0x=
1);
                                     //set all the quote fields
                                     Quotes.setField(new
QuoteEntryID(i.ToString()));
                                     Quotes.setField(new Symbol(q.Symbo=
l));
                                     Quotes.setField(new
SecurityType(q.SecurityType));
                                     Quotes.setField(new
MaturityMonthYear(q.strMaturityMonthYear));
                                     Quotes.setField(new
SecurityType(q.SecurityType));
                                     Quotes.setField(new
StrikePrice(q.StrikePrice));
                                     Quotes.setField(new PutOrCall(q.Is=
Call
? PutOrCall.CALL : PutOrCall.PUT ));
                                     Quotes.setField(new BidPx(q.BidPX)=
);
                                     Quotes.setField(new
OfferPx(q.OfferPX));
                                     Quotes.setField(new
BidSize(q.BidSize));
                                     Quotes.setField(new
OfferSize(q.OfferSize));
                                     Quotes.setField(new
TransactTime(DateTime.Now));
                                     Quotes.setField(new
TradingSessionID(mClient.Parent.Key));
                                     i++;
                                     Qset.addGroup(Quotes);
                         }
                         m.addGroup(Qset);
                         mQuoteSetID++;
             }
             send m
}


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger

for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd
disoriented. TotalView can help you find your way. Available on major U=
NIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



=

[Quickfix-developers] Repeating groups?

[Rob K. <ro...@ri...>]

I have attached the result of creating a quickfix MassQuote message with =
three quotes for some RBK options.  it is presented in the order in =
which the string was generated, I have added tabs and linebreaks to show =
the repeating groups.  When ever I send a message like this to my =
counterparty it breaks their fix server.  They are telling me that the =
tags are out of order.  tag 302 304 and 311 have to precede 209 and tag =
301 has to precede tag 296.  my question is this: Is this FIX standard?  =
If it is, what is wrong with generation of the message.  I have attached =
psudocode of my message generation after the message.

8=3DFIX.4.2=019=3D433=0135=3Di=0134=3D30=0149=3DSENDER=0150=3DSUB=0152=3D=
20030410-18:09:08=0156=3DTARGET=0157=3DTEST=01
117=3DQUOTEID=01
	296=3D1=01
		295=3D3=01

		55=3DRBK=01
		60=3D20030410-13:09:08=01
		132=3D0=01
		133=3D0.05=01
		134=3D1=01
		135=3D1=01
		167=3DOPT=01
		200=3D200304=01
		201=3D1=01
		202=3D30=01
		299=3D0=01
		336=3DW_AM1=01

		55=3DRBK=01
		60=3D20030410-13:09:08=01
		132=3D10.2=01
		133=3D10.7=01
		134=3D1=01
		135=3D1=01
		167=3DOPT=01
		200=3D200304=01
		201=3D0=01
		202=3D32.5=01
		299=3D1=01
		336=3DW_AM1=01

		55=3DRBK=01
		60=3D20030410-13:09:08=01
		132=3D0=01
		133=3D0.05=01
		134=3D1=01
		135=3D1=01
		167=3DOPT=01
		200=3D200304=01
		201=3D1=01
		202=3D32.5=01
		299=3D2=01
		336=3DW_AM1=01

	302=3D1=01
	304=3D0=01
	311=3DRBK=01
301=3D1=01
10=3D063=01


private void Tick()
{
	QuickFix42.MassQuote m =3D new QuickFix42.MassQuote();
	m.setField(new QuoteID(mClient.mUserID));
	m.setField(new QuoteResponseLevel(1)); //tell me only about bad quotes
	foreach(group of quotes I am quoting known as the variable p)
	{
		Group Qset =3D new Group(296, 0x1);
		Qset.setField(new QuoteSetID(mQuoteSetID.ToString()));
		Qset.setField(new UnderlyingSymbol(p.Series));
		Qset.setField(new TotQuoteEntries(0));
		foreach(quote in my quote group p known as Q)
		{
			Group Quotes =3D new Group(295, 0x1);
			//set all the quote fields
			Quotes.setField(new QuoteEntryID(i.ToString()));
			Quotes.setField(new Symbol(q.Symbol));
			Quotes.setField(new SecurityType(q.SecurityType));
			Quotes.setField(new MaturityMonthYear(q.strMaturityMonthYear));
			Quotes.setField(new SecurityType(q.SecurityType));
			Quotes.setField(new StrikePrice(q.StrikePrice));
			Quotes.setField(new PutOrCall(q.IsCall ? PutOrCall.CALL : =
PutOrCall.PUT ));
			Quotes.setField(new BidPx(q.BidPX));
			Quotes.setField(new OfferPx(q.OfferPX));
			Quotes.setField(new BidSize(q.BidSize));
			Quotes.setField(new OfferSize(q.OfferSize));
			Quotes.setField(new TransactTime(DateTime.Now));
			Quotes.setField(new TradingSessionID(mClient.Parent.Key));
			i++;
			Qset.addGroup(Quotes);
		}
		m.addGroup(Qset);
		mQuoteSetID++;
	}
	send m
}

Re: [Quickfix-developers] problems with quickfix-1.4.1 - Java code

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

OM...@th... wrote:
> Yeah, this is a tradeoff I'm still struggling with.  The problem is that
> there are three different API's, and each language has its own set of
> standards.  So the question is, it it more important to follow the
> conventions each language, or to keep all the API's consistent among
> themselves.  If I am maintaining C++ and Java applications that use QF, I'd
> like those two API's to be as similar as possible.  This is certainly an
> important issue for consultants who may need to implement FIX applications
> for different clients with different language requirements.  Unfortunately,
> C++/Java/.NET have different conventions.

Actually, I do not now anything about .NET (and Windows) and the related conventions.
Finally you have to decide since you have best oversight.

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] problems with quickfix-1.4.1 - Java code

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

Yeah, this is a tradeoff I'm still struggling with.  The problem is tha=
t
there are three different API's, and each language has its own set of
standards.  So the question is, it it more important to follow the
conventions each language, or to keep all the API's consistent among
themselves.  If I am maintaining C++ and Java applications that use QF,=
 I'd
like those two API's to be as similar as possible.  This is certainly a=
n
important issue for consultants who may need to implement FIX applicati=
ons
for different clients with different language requirements.  Unfortunat=
ely,
C++/Java/.NET have different conventions.

It's an odd situation, because in C++ you don't really throw exceptions=
,
you throw types (int, string, std::exception, whatever the hell you wan=
t).
Since java has the strictest requirements, it may make sense to use tho=
se
and adopt them in the other API's.

--oren



|---------+----------------------------------------------->
|         |           Joerg Thoennes                      |
|         |           <Joe...@ma...>           |
|         |           Sent by:                            |
|         |           qui...@li...ur|
|         |           ceforge.net                         |
|         |                                               |
|         |                                               |
|         |           04/10/2003 12:42 PM                 |
|         |           Please respond to Joerg.Thoennes    |
|         |                                               |
|---------+----------------------------------------------->
  >--------------------------------------------------------------------=
--------------------------|
  |                                                                    =
                          |
  |       To:       Mike Hepburn <mi...@an...>                      =
                          |
  |       cc:       quickfix <qui...@li...=
>                         |
  |       Subject:  Re: [Quickfix-developers] problems with quickfix-1.=
4.1 - Java code           |
  >--------------------------------------------------------------------=
--------------------------|




> (1) trying to (java) compile an application that cracks FIX4.3 messag=
es
> (in Java) with quickfix 1.4.1 is slightly broken due to some missing
> throw specifiers in the socket initiator/acceptor classes (see Socket=

> Acceptor, Initiator diff's below)

Regarding exception names: Java has a naming standard here, and it woul=
d be
nice if
QuickFIX could also adhere to this standard:

- Checked exceptions extend java.lang.Exception and must be specified i=
n
the throws clause.
   They are named XyzException. They should be used in all cases where =
the
programmer could
   deal with the problem indicated, eg just retry or try some other way=
.

- Unchecked exceptions extend java.lang.RuntimeException and can be lef=
t
out of the throws
   clause. They normally indicate programming errors
(ArrayOutOfBoundsException etc.) and
   the programmer is not expected to do any useful recovery. The progra=
m
should terminate.

- Errors extend java.lang.Error and indicate fatal runtime errors:
   "An Error is a subclass of Throwable that indicates serious problems=

    that a reasonable application should not try to catch. Most such er=
rors
are abnormal conditions."
   Examples are OutOfMemoryError, StackOverFlowError etc.

It would be good if the exception naming of QuickFIX could reflect this=
,
e.g. the ConfigError
should be changed to the ConfigException, the UnsupportedMessageType to=

UnsupportedMessageTypeException.

OK, this is a major change, but would make the API more consistent.

Cheers, J=F6rg

--
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: Etnus, makers of TotalView, The debu=
gger

for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd
disoriented. TotalView can help you find your way. Available on major U=
NIX
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



=

Re: [Quickfix-developers] Exceptions thrown in Dictionary.getLong causes banzai to abort

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

Stacy Curl wrote:
> I'm having trouble getting the java example app banzai to work. I'm
> using QuickFIX version 1.4.1, gcc 2.95.3, binutils-2.11.92, SuSe 8.0,

I suggest to try at least GCC 3.0 and the related libraries:

Package: gcc-3.0
Status: install ok installed
Priority: standard
Section: devel
Installed-Size: 3032
Maintainer: Debian GCC maintainers <deb...@li...>
Source: gcc-3.0 (1:3.0.4ds3-7)
Version: 1:3.0.4-7
Replaces: egcc
Provides: c-compiler
Depends: gcc-3.0-base, libgcc1 (>= 1:3.0.4-7), libc6 (>= 2.2.4-4), cpp-3.0 (>= 1:3.0.4-7), cpp-3.0 (<< 1:3.0.5), binutils (>= 2.11.93.0.2-2)
Recommends: libc-dev
Suggests: gcc-3.0-doc (>= 1:3.0.4-7)
Conflicts: libc5-dev, egcc
Description: The GNU C compiler.
  This is the GNU C compiler, a fairly portable optimizing compiler for C.

> I believe my problem is the same as David Monheit's
> (http://sourceforge.net/mailarchive/message.php?msg_id=4254678).

This sounds like problems with non-matching exceptions from different C++ objects.
> 
> I'd like to try to build QuickFIX with different linking options, even
> using static linking would be prefereable to having programs
> abort when exceptions are thrown.
> 
> Q: Does Banzai work on any platform ? I can find no unit tests for Java.

Yes, works for me (Debian 3.0, GCC 3.0, J2SDK 1.4_01)

> Q: How do I change the linking options to use static linking ?

The default is static linking for the libquickfix.so library, but you need
a dynamically linked libquickfix_jni.so. Otherwise, Java could not load the library
at runtime. Of course, you do not want to link the code into the JVM...

Please ask me if you have further questions related to the compilation with GCC 3.0.

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] problems with quickfix-1.4.1 - Java code

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

> (1) trying to (java) compile an application that cracks FIX4.3 messages
> (in Java) with quickfix 1.4.1 is slightly broken due to some missing
> throw specifiers in the socket initiator/acceptor classes (see Socket
> Acceptor, Initiator diff's below)

Regarding exception names: Java has a naming standard here, and it would be nice if
QuickFIX could also adhere to this standard:

- Checked exceptions extend java.lang.Exception and must be specified in the throws clause.
   They are named XyzException. They should be used in all cases where the programmer could
   deal with the problem indicated, eg just retry or try some other way.

- Unchecked exceptions extend java.lang.RuntimeException and can be left out of the throws
   clause. They normally indicate programming errors (ArrayOutOfBoundsException etc.) and
   the programmer is not expected to do any useful recovery. The program should terminate.

- Errors extend java.lang.Error and indicate fatal runtime errors:
   "An Error is a subclass of Throwable that indicates serious problems
    that a reasonable application should not try to catch. Most such errors are abnormal conditions."
   Examples are OutOfMemoryError, StackOverFlowError etc.

It would be good if the exception naming of QuickFIX could reflect this, e.g. the ConfigError
should be changed to the ConfigException, the UnsupportedMessageType to UnsupportedMessageTypeException.

OK, this is a major change, but would make the API more consistent.

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] Exceptions thrown in Dictionary.getLong causes banzai to abort

[Stacy C. <st...@br...>]

I'm having trouble getting the java example app banzai to work. I'm
using QuickFIX version 1.4.1, gcc 2.95.3, binutils-2.11.92, SuSe 8.0,
...

I believe my problem is the same as David Monheit's
(http://sourceforge.net/mailarchive/message.php?msg_id=3D4254678).

I'd like to try to build QuickFIX with different linking options, even
using static linking would be prefereable to having programs
abort when exceptions are thrown.

Q: Does Banzai work on any platform ? I can find no unit tests for Java.

Q: How do I change the linking options to use static linking ?


Thanks,
Stacy.

[Quickfix-developers] Minor documentation bug: import org.quickfix.fields -> ...field

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

Hi,

just found a minor documentation bug:

./doc/html/java/receiving_messages_2.html:3:import org.quickfix.fields.*;
./doc/html/java/receiving_messages_3.html:3:import org.quickfix.fields.*;

shall be "field" instead of "fields"

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] ResendRequest and quickfix 1.4.1

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

Bishop, Barry wrote:
> I have just built quickfix 1.4.1 with GCC 2.95 and STLport on solaris.
> 
> All my previous problems have been fixed, except I now have a new one.
> 
> My java application aborts with a core when processing a ResendRequest
> message. It didn't do this with quickfix 1.3.2 and my java code hasn't
> changed.

OK, just a quick shot before I am leaving for today (it's 5 p.pm. in Germany now):

It seems to have to do with exceptions ( EH = exception handler? ), exceptions and
shared libs do not work together well until you have a shared libgcc. And a shared
libgcc you have starting with GCC 3.0. I cite the GCC 3.0 info docs:

      There are several situations in which an application should use the
      shared `libgcc' instead of the static version.  The most common of
      these is when the application wishes to throw and catch exceptions
      across different shared libraries.  In that case, each of the
      libraries as well as the application itself should use the shared
      `libgcc'.

So I strongly encourage you to switch to GCC 3.2. (GCC 3.0 has probably other problems.)
Note to use libtool 1.5 for this.

Good luck

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] problems with quickfix-1.4.1 - Java code

[Mike H. <mi...@an...>]

Hi All,

we've found a couple of 'features' with the new release:

(1) trying to (java) compile an application that cracks FIX4.3 messages
(in Java) with quickfix 1.4.1 is slightly broken due to some missing
throw specifiers in the socket initiator/acceptor classes (see Socket
Acceptor, Initiator diff's below)

(2) when calling the onRun() method, we get a crash in the native code
due to some Exceptions not being initialised correctly. we've disabled
the exception catching in this method to get things working again (see
JavaApplication.ccp diffs below).

The crash occurs when creating an Exception on the stack - the stack
trace shows a class not found type of error - however jar -tvf on
quickfix.jar shows the Exception class DoNotSend is there and available.

Any ideas ??

Cheers
Mike

heres the stack trace:
#0  0x40092851 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x40092851 in kill () from /lib/libc.so.6
#1  0x4001ee8d in raise () from /lib/libpthread.so.0
#2  0x40092504 in raise () from /lib/libc.so.6
#3  0x40093b3b in abort () from /lib/libc.so.6
#4  0x4d80bfb7 in __cxxabiv1::__terminate(void (*)()) (
    handler=3D0x400939b0 <abort>)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#5  0x4d80c004 in std::terminate() ()
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#6  0x4d80c176 in __cxa_throw ()
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:77
#7  0x4d6a6e3a in JVMClass (this=3D0xb91ffa9c,=20
    name=3D0x4d73ef33 "DoNotSend;") at JVM.h:119
#8  0x4d6aa5e0 in Exceptions (this=3D0xb91ffa9c) at JavaApplication.h:92
#9  0x4d6a84b0 in JavaApplication::onRun() (this=3D0x8706af0)
    at JavaApplication.cpp:190
#10 0x4d6ff2b6 in __static_initialization_and_destruction_0 (
    __initialize_p=3D142517072, __priority=3D-1189086092) at
SessionSettings.h:66
#11 0x4001bf30 in pthread_detach () from /lib/libpthread.so.0


--- SocketAcceptor.java.bak	2003-04-09 13:51:36.000000000 +0100
+++ SocketAcceptor.java	2003-04-09 13:51:58.000000000 +0100
@@ -90,7 +90,7 @@
     private native void create();
     private native void destroy();
=20
-    public void start() throws RuntimeError {
+    public void start() throws RuntimeError, ConfigError {
         doStart();
     }
=20
@@ -98,7 +98,7 @@
         doStop();
     }
=20
-    private native void doStart() throws RuntimeError;
+    private native void doStart() throws RuntimeError, ConfigError;
=20
     private native void doStop();
 }
--- SocketInitiator.java.bak	2003-04-09 13:54:48.000000000 +0100
+++ SocketInitiator.java	2003-04-09 13:52:33.000000000 +0100
@@ -90,15 +90,15 @@
     private native void create();
     private native void destroy();
=20
-    public void start() throws RuntimeError {
+    public void start() throws RuntimeError, ConfigError {
         doStart();
     }
-   =20
+
     public void stop() {
         doStop();
     }
=20
-    private native void doStart() throws RuntimeError;
+    private native void doStart() throws RuntimeError, ConfigError;
=20
     private native void doStop();
 }

--- JavaApplication.cpp	2003-04-09 18:11:33.000000000 +0100
+++ /home/mike/src/quickfix.back/src/java/JavaApplication.cpp	2003-03-20
15:16:13.000000000 +0000
@@ -186,9 +178,7 @@
 void JavaApplication::onRun()
 {
   JNIEnv * pEnv =3D ENV::get();
-  // Exceptions e;
   pEnv->CallVoidMethod( m_object, onRunId );
-  // handleException( pEnv, e );
   JVM::get() ->DetachCurrentThread();
 };

Re: [Quickfix-developers] QuickFIX 1.4.1

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

Oren Miller wrote:

> I havn't seen this before, but I can see how some systems might need 
> it.  I guess it depends on how your mkdir works.

UNIX mkdir cannot make multiple path elements at once unless you specify -p. In this
case, it could not make ".../include/quickfix" because "../include" did not exist.

>  >> /opt2/QuickFIX/linux/1.4.0/include/quickfix/include
>  >> which looks at little bit strange (double include).
> 
> Yeah, this is sort of a result of windows having no standard for 
> installing header and library files, so they are generally put in a 
> local directory.  I didn't want to muddle the root quickfix directory, 
> hence the include directory which then had to be carried over to *nix 
> for portability.  I would like it to work like you suggest, but will 
> need to reorganize how headers are installed in windows.  I'm thinking 
> of creating an "output" directory under the root quickfix directory.  
> There would then be another "quickfix" directory under output which 
> would contain the include files (and a directory for the lib and bin 
> files).  That way under windows people can put quickfix\output in the 
> include path, and we can then do things more normally under *nix. 
> 
> Any input on how this problem is normally handled would be helpful.

Since I do not work on Windows, I cannot contribute here. According to the
automake docs, the are two prefixes for installing include files:

	include_HEADERS
	pkginclude_HEADERS

If you use the first one, all headers are installed in

	$(prefix)/include

and in the second case in

	$(prefix)/include/quickfix
#inclu
(Quickfix is here the package name.) Together with '#include <quickfix/...' this
would be the best solution if you could make it fit for Windows. To make this work,
all includes of the kind "#include "quickfix/include/..." should be changed to
the <quickfix/...> style. If you say in Windows "-I<somedir>\include", it should also
find '#include <quickfix/...>' if the compiler translates the file separators.

>  >> In addition, it would be nice to install the generated quickfix.jar 
> into the lib directory.
>  >> Change src/java/Makefile.am:
> 
> Yeah, I didn't really know what standard procedure there was for 
> installing jar files.  Sounds like a good place to me.

Yes, there wasn't a standard one. I invented it ;-) See "info automake", Generalities::Uniform:

 >     Sometimes the standard directories--even as augmented by Automake--
 > are not enough.  In particular it is sometimes useful, for clarity, to
 > install objects in a subdirectory of some predefined directory.  To this
 > end, Automake allows you to extend the list of possible installation
 > directories.  A given prefix (e.g. `zar') is valid if a variable of the
 > same name with `dir' appended is defined (e.g. `zardir').

 >   For instance, until HTML support is part of Automake, you could use
 > this to install raw HTML documentation:

 >     htmldir = $(prefix)/html
 >     html_DATA = automake.html

Writing portable build scripts is a tedious work, I hope I helped you a little bit.

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] QF 1.4.1: failing acceptance tests

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

Oren Miller wrote:
> Configure it in the test itself.  Open up the failing test file.  The 
> first message that is sent in is the logon message which sets the 108 
> (HeartBtInt) value.  Increasing this value will increase the interval 
> for the test.

Can you think of way to make the test more insensitive to timing constraints, e.g.
by a special action 'eDROP_HEARTBEAT'? Or adjust the timing values in general?

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] FW: ResendRequest and quickfix 1.4.1

[Oren M. <ore...@ya...>]

Looks like you can fix this by doing the following to the JavaApplication::toApp method in src/java/JavaApplication.cpp
The abort is being caused by the line:
msg = *((FIX::Message*)jmsg.getInt( "cppPointer" ));
add the check if( !pEnv->ExceptionOccurred() ) before that line and see if you get better results.
 "Bishop, Barry" <Bar...@gs...> wrote:Hi,

Further investigation leads me to believe that the processing of an inbound
ResendRequest message has the following behaviour with quickfix 1.4.1 JNI
layer:

1) Appropriate messages are always resent
2) Processing continues normally afterwards unless any message was not sent
by throwing DoNotSend from Application.toApp(), in which case the library
cores.

I'm looking at the JNI code now to try and work this out.

A work-around would very much be appreciated!

Thanks,
barry


-----Original Message-----
From: Bishop, Barry 
Sent: 09 April 2003 15:10
To: developers QuickFIX
Subject: ResendRequest and quickfix 1.4.1


Hi,

I have just built quickfix 1.4.1 with GCC 2.95 and STLport on solaris.

All my previous problems have been fixed, except I now have a new one.

My java application aborts with a core when processing a ResendRequest
message. It didn't do this with quickfix 1.3.2 and my java code hasn't
changed.

The resend is fulfilled, as I see the messages being resent. However, after
the last one, the application dies. I have a stack trace (see below) that
seems to suggest something is going wrong in the JNI layer, specifically
JavaApplication.toApp(). I think '__check_eh_spec' must be something to do
with C++ exception handling. I have attached my (java) implementation of
Application.toApp() that gets called.

Thanks for any help guys,
barry bishop




############################################################################
######
ATTACHMENTS
############################################################################
######

Implementation of 'org.quickfix.Application.toApp'
==================================================

public void toApp(Message message, SessionID sessionId)
throws DoNotSend
{
// throwing a DoNotSend from here stops the message being
sent.
boolean send = true;

org.quickfix.field.PossDupFlag possDup = new
org.quickfix.field.PossDupFlag();

try
{
message.getHeader().getField( possDup );

// Is this field a duplicate?
if ( possDup.getValue() ==
org.quickfix.field.PossDupFlag.POSSIBLE_DUPLICATE )
{
// Yes. Is it a quote?
if ( message instanceof
org.quickfix.fix42.Quote )
{
send = false;
}
}
}
catch ( FieldNotFound fnf )
{
// Definitely not a duplicate
}

if ( ! send )
throw new DoNotSend();

// Everything we send comes via this callback.
audit( "toApp", message, sessionId );
}


STACK
=====

----------------- lwp# 25 / thread# 25 --------------------
ff31acfc _lwp_kill (6, 0, 0, ffffffff, ff33c3ec, ff3c2474) + 8
ff2b563c abort (ff338000, f3c2c31c, 11, 1, ff3e260c, fdc10290) + 100
f40de394 __default_terminate (14c, f46cf564, f40de390, ff3e260c, 2979c,
ff3c2474)
+ 4
f40df214 terminate__Fv (f40df280, f3c29dcc, 18, 1, ff3e260c, fdc10290) + 20
f40df220 __default_unexpected__Fv (48, f46cf590, f40df21c, 2a0f48, 0, 0) +
4
f40df2a0 unexpected__Fv (0, 4, 2a0f48, f4af3000, 81010100, ff00) + 20
f40df564 __check_eh_spec (1, f587ecb4, f49eb9d0, f49eb800, 1097c0, 8f2a4) +
60
f410abe0 toApp__15JavaApplicationRQ23FIX7MessageRCQ23FIX9SessionID (1128e0,
f587e
e78, 354974, f410a93c, 0, 53) + 2a4
f413c2f4 resend__Q23FIX7SessionRQ23FIX7Message (354970, f587ee78, 354b20,
f587efb
8, f587f0f4, f587f330) + 174
f413b1e4 nextResendRequest__Q23FIX7SessionRCQ23FIX7Message (354970,
f587f330, f46
95c00, 354b20, 0, 0) + 4d8
f41417d4 next__Q23FIX7SessionRCQ23FIX7Message (354970, f587f330, 354b20, 0,
0, 0)
+ 394
f41413c0
next__Q23FIX7SessionRCQ24_STLt12basic_string3ZcZQ24_STLt11char_traits1Zc
ZQ24_STLt9allocator1Zc (354970, f587f450, 0, 3b5118, 6f0, 0) + 3c
f41528d8 read__Q23FIX16SocketConnectionRQ23FIX15SocketConnector (2e0e70,
10d0a4,
f587f4e0, 5000, ff33b1bc, ffffffff) + 8c
f4155028 onData__Q23FIX15SocketInitiatorRQ23FIX15SocketConnectori (10cfd8,
10d0a4
, 15, f4154f9c, 160, f587d4f0) + 8c
f464a58c onEvent__Q23FIX16ConnectorWrapperRQ23FIX13SocketMonitori
(f587f6e8, 10d0
a4, 15, f464a510, 10d0a8, 0) + 7c
f4156bd4 block__Q23FIX13SocketMonitorRQ33FIX13SocketMonitor8Strategy
(10d0a4, f58
7f6e8, 10d05c, f4154974, 1, f587f6fc) + 2d0
f4153ef8 block__Q23FIX15SocketConnectorRQ33FIX15SocketConnector8Strategy
(10d0a4,
10d05c, 0, 0, ff382000, 0) + 2c
f4154944 onStart__Q23FIX15SocketInitiator (10cfd8, 10cfd8, f4154910,
f4686c00, ec
, 0) + 34
f4108c20 start__Q23FIX9Initiator (10cfd8, 6, 269d8, f587f970, ff1fe2a0,
ff209990)
+ 1a8
f41343d8 Java_org_quickfix_SocketInitiator_doStart (8f2a4, f587fa64,
f587fc48, 0,
1, 0) + 2c
0007a8f0 ???????? (f64689a0, f587fc48, 8f220, ff1fe2a0, b7, f9d59260)
00077a74 ???????? (f64689a0, 79abc, 8f220, 80bc8, f9a86030, 0)
00077d1c ???????? (f6f7e7d0, 79abc, f587fbdc, 80d68, ff1fe2a0, 0)
00077d1c ???????? (0, 1, ff20a500, 82ebc, 1e, e)
ff232454 __1cMStubRoutinesG_code1_ (f587fc68, f587fea0, a, f9816050, 79abc,
f587f
dec) + 410
fefcd23c
__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArgu
ments_pnGThread__v_ (f587fe98, ff1fe2a0, f587fde4, 8f220, 79abc, f587fea0) +
308
fefcc8d4
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4
pnRJavaCallArguments_pnGThread__v_ (f9816cc8, f587fdd0, f587fdd4, ff1fe2a0,
f587fe
98, f587fde4) + 150
fefcc944
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbo
lHandle_5pnGThread__v_ (f587fe98, f587fe94, f587fe90, f587fe84, f587fe7c,
8f220) +
60
feffd7d8 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (f9816cc8, 8f220,
ff1fe2a
0, ff1fe2a0, 3, 8f220) + 17c
ff0d5078 __1cKJavaThreadDrun6M_v_ (f5800000, ff207d18, ff1fe2a0, 80000,
8f220, 80
000) + 36c
ff070918 _start (ff1fe2a0, 0, 0, 0, 0, 0) + 20
ff370694 _lwp_start (0, 0, 0, 0, 0, 0)


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

[Quickfix-developers] FW: ResendRequest and quickfix 1.4.1

[Bishop, B. <Bar...@gs...>]

Hi,

Further investigation leads me to believe that the processing of an inbound
ResendRequest message has the following behaviour with quickfix 1.4.1 JNI
layer:

1) Appropriate messages are always resent
2) Processing continues normally afterwards unless any message was not sent
by throwing DoNotSend from Application.toApp(), in which case the library
cores.

I'm looking at the JNI code now to try and work this out.

A work-around would very much be appreciated!

Thanks,
barry


-----Original Message-----
From: Bishop, Barry 
Sent: 09 April 2003 15:10
To: developers QuickFIX
Subject: ResendRequest and quickfix 1.4.1


Hi,

I have just built quickfix 1.4.1 with GCC 2.95 and STLport on solaris.

All my previous problems have been fixed, except I now have a new one.

My java application aborts with a core when processing a ResendRequest
message. It didn't do this with quickfix 1.3.2 and my java code hasn't
changed.

The resend is fulfilled, as I see the messages being resent. However, after
the last one, the application dies. I have a stack trace (see below) that
seems to suggest something is going wrong in the JNI layer, specifically
JavaApplication.toApp(). I think '__check_eh_spec' must be something to do
with C++ exception handling. I have attached my (java) implementation of
Application.toApp() that gets called.

Thanks for any help guys,
barry bishop




############################################################################
######
	ATTACHMENTS
############################################################################
######

Implementation of 'org.quickfix.Application.toApp'
==================================================

    public void toApp(Message message, SessionID sessionId)
        throws DoNotSend
    {
		// throwing a DoNotSend from here stops the message being
sent.
		boolean send = true;
		
		org.quickfix.field.PossDupFlag possDup = new
org.quickfix.field.PossDupFlag();
		
		try
		{
			message.getHeader().getField( possDup );
			
			// Is this field a duplicate?
			if ( possDup.getValue() ==
org.quickfix.field.PossDupFlag.POSSIBLE_DUPLICATE )
			{
				// Yes. Is it a quote?
				if ( message instanceof
org.quickfix.fix42.Quote )
				{
					send = false;
				}
			}
		}
		catch ( FieldNotFound fnf )
		{
			// Definitely not a duplicate
		}
		
		if ( ! send )
			throw new DoNotSend();
		
		// Everything we send comes via this callback.
    		audit( "toApp", message, sessionId );
    }


STACK
=====

-----------------  lwp# 25 / thread# 25  --------------------
 ff31acfc _lwp_kill (6, 0, 0, ffffffff, ff33c3ec, ff3c2474) + 8
 ff2b563c abort    (ff338000, f3c2c31c, 11, 1, ff3e260c, fdc10290) + 100
 f40de394 __default_terminate (14c, f46cf564, f40de390, ff3e260c, 2979c,
ff3c2474)
 + 4
 f40df214 terminate__Fv (f40df280, f3c29dcc, 18, 1, ff3e260c, fdc10290) + 20
 f40df220 __default_unexpected__Fv (48, f46cf590, f40df21c, 2a0f48, 0, 0) +
4
 f40df2a0 unexpected__Fv (0, 4, 2a0f48, f4af3000, 81010100, ff00) + 20
 f40df564 __check_eh_spec (1, f587ecb4, f49eb9d0, f49eb800, 1097c0, 8f2a4) +
60
 f410abe0 toApp__15JavaApplicationRQ23FIX7MessageRCQ23FIX9SessionID (1128e0,
f587e
e78, 354974, f410a93c, 0, 53) + 2a4
 f413c2f4 resend__Q23FIX7SessionRQ23FIX7Message (354970, f587ee78, 354b20,
f587efb
8, f587f0f4, f587f330) + 174
 f413b1e4 nextResendRequest__Q23FIX7SessionRCQ23FIX7Message (354970,
f587f330, f46
95c00, 354b20, 0, 0) + 4d8
 f41417d4 next__Q23FIX7SessionRCQ23FIX7Message (354970, f587f330, 354b20, 0,
0, 0)
 + 394
 f41413c0
next__Q23FIX7SessionRCQ24_STLt12basic_string3ZcZQ24_STLt11char_traits1Zc
ZQ24_STLt9allocator1Zc (354970, f587f450, 0, 3b5118, 6f0, 0) + 3c
 f41528d8 read__Q23FIX16SocketConnectionRQ23FIX15SocketConnector (2e0e70,
10d0a4,
f587f4e0, 5000, ff33b1bc, ffffffff) + 8c
 f4155028 onData__Q23FIX15SocketInitiatorRQ23FIX15SocketConnectori (10cfd8,
10d0a4
, 15, f4154f9c, 160, f587d4f0) + 8c
 f464a58c onEvent__Q23FIX16ConnectorWrapperRQ23FIX13SocketMonitori
(f587f6e8, 10d0
a4, 15, f464a510, 10d0a8, 0) + 7c
 f4156bd4 block__Q23FIX13SocketMonitorRQ33FIX13SocketMonitor8Strategy
(10d0a4, f58
7f6e8, 10d05c, f4154974, 1, f587f6fc) + 2d0
 f4153ef8 block__Q23FIX15SocketConnectorRQ33FIX15SocketConnector8Strategy
(10d0a4,
 10d05c, 0, 0, ff382000, 0) + 2c
 f4154944 onStart__Q23FIX15SocketInitiator (10cfd8, 10cfd8, f4154910,
f4686c00, ec
, 0) + 34
 f4108c20 start__Q23FIX9Initiator (10cfd8, 6, 269d8, f587f970, ff1fe2a0,
ff209990)
 + 1a8
 f41343d8 Java_org_quickfix_SocketInitiator_doStart (8f2a4, f587fa64,
f587fc48, 0,
 1, 0) + 2c
 0007a8f0 ???????? (f64689a0, f587fc48, 8f220, ff1fe2a0, b7, f9d59260)
 00077a74 ???????? (f64689a0, 79abc, 8f220, 80bc8, f9a86030, 0)
 00077d1c ???????? (f6f7e7d0, 79abc, f587fbdc, 80d68, ff1fe2a0, 0)
 00077d1c ???????? (0, 1, ff20a500, 82ebc, 1e, e)
 ff232454 __1cMStubRoutinesG_code1_ (f587fc68, f587fea0, a, f9816050, 79abc,
f587f
dec) + 410
 fefcd23c
__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArgu
ments_pnGThread__v_ (f587fe98, ff1fe2a0, f587fde4, 8f220, 79abc, f587fea0) +
308
 fefcc8d4
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4
pnRJavaCallArguments_pnGThread__v_ (f9816cc8, f587fdd0, f587fdd4, ff1fe2a0,
f587fe
98, f587fde4) + 150
 fefcc944
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbo
lHandle_5pnGThread__v_ (f587fe98, f587fe94, f587fe90, f587fe84, f587fe7c,
8f220) +
 60
 feffd7d8 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (f9816cc8, 8f220,
ff1fe2a
0, ff1fe2a0, 3, 8f220) + 17c
 ff0d5078 __1cKJavaThreadDrun6M_v_ (f5800000, ff207d18, ff1fe2a0, 80000,
8f220, 80
000) + 36c
 ff070918 _start   (ff1fe2a0, 0, 0, 0, 0, 0) + 20
 ff370694 _lwp_start (0, 0, 0, 0, 0, 0)

[Quickfix-developers] ResendRequest and quickfix 1.4.1

[Bishop, B. <Bar...@gs...>]

Hi,

I have just built quickfix 1.4.1 with GCC 2.95 and STLport on solaris.

All my previous problems have been fixed, except I now have a new one.

My java application aborts with a core when processing a ResendRequest
message. It didn't do this with quickfix 1.3.2 and my java code hasn't
changed.

The resend is fulfilled, as I see the messages being resent. However, after
the last one, the application dies. I have a stack trace (see below) that
seems to suggest something is going wrong in the JNI layer, specifically
JavaApplication.toApp(). I think '__check_eh_spec' must be something to do
with C++ exception handling. I have attached my (java) implementation of
Application.toApp() that gets called.

Thanks for any help guys,
barry bishop




############################################################################
######
	ATTACHMENTS
############################################################################
######

Implementation of 'org.quickfix.Application.toApp'
==================================================

    public void toApp(Message message, SessionID sessionId)
        throws DoNotSend
    {
		// throwing a DoNotSend from here stops the message being
sent.
		boolean send = true;
		
		org.quickfix.field.PossDupFlag possDup = new
org.quickfix.field.PossDupFlag();
		
		try
		{
			message.getHeader().getField( possDup );
			
			// Is this field a duplicate?
			if ( possDup.getValue() ==
org.quickfix.field.PossDupFlag.POSSIBLE_DUPLICATE )
			{
				// Yes. Is it a quote?
				if ( message instanceof
org.quickfix.fix42.Quote )
				{
					send = false;
				}
			}
		}
		catch ( FieldNotFound fnf )
		{
			// Definitely not a duplicate
		}
		
		if ( ! send )
			throw new DoNotSend();
		
		// Everything we send comes via this callback.
    		audit( "toApp", message, sessionId );
    }


STACK
=====

-----------------  lwp# 25 / thread# 25  --------------------
 ff31acfc _lwp_kill (6, 0, 0, ffffffff, ff33c3ec, ff3c2474) + 8
 ff2b563c abort    (ff338000, f3c2c31c, 11, 1, ff3e260c, fdc10290) + 100
 f40de394 __default_terminate (14c, f46cf564, f40de390, ff3e260c, 2979c,
ff3c2474)
 + 4
 f40df214 terminate__Fv (f40df280, f3c29dcc, 18, 1, ff3e260c, fdc10290) + 20
 f40df220 __default_unexpected__Fv (48, f46cf590, f40df21c, 2a0f48, 0, 0) +
4
 f40df2a0 unexpected__Fv (0, 4, 2a0f48, f4af3000, 81010100, ff00) + 20
 f40df564 __check_eh_spec (1, f587ecb4, f49eb9d0, f49eb800, 1097c0, 8f2a4) +
60
 f410abe0 toApp__15JavaApplicationRQ23FIX7MessageRCQ23FIX9SessionID (1128e0,
f587e
e78, 354974, f410a93c, 0, 53) + 2a4
 f413c2f4 resend__Q23FIX7SessionRQ23FIX7Message (354970, f587ee78, 354b20,
f587efb
8, f587f0f4, f587f330) + 174
 f413b1e4 nextResendRequest__Q23FIX7SessionRCQ23FIX7Message (354970,
f587f330, f46
95c00, 354b20, 0, 0) + 4d8
 f41417d4 next__Q23FIX7SessionRCQ23FIX7Message (354970, f587f330, 354b20, 0,
0, 0)
 + 394
 f41413c0
next__Q23FIX7SessionRCQ24_STLt12basic_string3ZcZQ24_STLt11char_traits1Zc
ZQ24_STLt9allocator1Zc (354970, f587f450, 0, 3b5118, 6f0, 0) + 3c
 f41528d8 read__Q23FIX16SocketConnectionRQ23FIX15SocketConnector (2e0e70,
10d0a4,
f587f4e0, 5000, ff33b1bc, ffffffff) + 8c
 f4155028 onData__Q23FIX15SocketInitiatorRQ23FIX15SocketConnectori (10cfd8,
10d0a4
, 15, f4154f9c, 160, f587d4f0) + 8c
 f464a58c onEvent__Q23FIX16ConnectorWrapperRQ23FIX13SocketMonitori
(f587f6e8, 10d0
a4, 15, f464a510, 10d0a8, 0) + 7c
 f4156bd4 block__Q23FIX13SocketMonitorRQ33FIX13SocketMonitor8Strategy
(10d0a4, f58
7f6e8, 10d05c, f4154974, 1, f587f6fc) + 2d0
 f4153ef8 block__Q23FIX15SocketConnectorRQ33FIX15SocketConnector8Strategy
(10d0a4,
 10d05c, 0, 0, ff382000, 0) + 2c
 f4154944 onStart__Q23FIX15SocketInitiator (10cfd8, 10cfd8, f4154910,
f4686c00, ec
, 0) + 34
 f4108c20 start__Q23FIX9Initiator (10cfd8, 6, 269d8, f587f970, ff1fe2a0,
ff209990)
 + 1a8
 f41343d8 Java_org_quickfix_SocketInitiator_doStart (8f2a4, f587fa64,
f587fc48, 0,
 1, 0) + 2c
 0007a8f0 ???????? (f64689a0, f587fc48, 8f220, ff1fe2a0, b7, f9d59260)
 00077a74 ???????? (f64689a0, 79abc, 8f220, 80bc8, f9a86030, 0)
 00077d1c ???????? (f6f7e7d0, 79abc, f587fbdc, 80d68, ff1fe2a0, 0)
 00077d1c ???????? (0, 1, ff20a500, 82ebc, 1e, e)
 ff232454 __1cMStubRoutinesG_code1_ (f587fc68, f587fea0, a, f9816050, 79abc,
f587f
dec) + 410
 fefcd23c
__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArgu
ments_pnGThread__v_ (f587fe98, ff1fe2a0, f587fde4, 8f220, 79abc, f587fea0) +
308
 fefcc8d4
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4
pnRJavaCallArguments_pnGThread__v_ (f9816cc8, f587fdd0, f587fdd4, ff1fe2a0,
f587fe
98, f587fde4) + 150
 fefcc944
__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbo
lHandle_5pnGThread__v_ (f587fe98, f587fe94, f587fe90, f587fe84, f587fe7c,
8f220) +
 60
 feffd7d8 __1cMthread_entry6FpnKJavaThread_pnGThread__v_ (f9816cc8, 8f220,
ff1fe2a
0, ff1fe2a0, 3, 8f220) + 17c
 ff0d5078 __1cKJavaThreadDrun6M_v_ (f5800000, ff207d18, ff1fe2a0, 80000,
8f220, 80
000) + 36c
 ff070918 _start   (ff1fe2a0, 0, 0, 0, 0, 0) + 20
 ff370694 _lwp_start (0, 0, 0, 0, 0, 0)

Re: [Quickfix-developers] QuickFIX 1.4.1

[Oren M. <ore...@ya...>]

>> ../Utility.h:118: warning: `const char*FIX::EOL' defined but not used

>> This is seen at several places. IMHO, the std::endl could be used if
>> the flush done by this construct does not matter.
>> (See stdc++ doc:

Agreed.  I believe this is only used in the toXML method, and I'm not sure why.  Looks like a lapse.

>> org_quickfix_MySQLLog.cpp:127:19: warning: no newline at end of file
>> org_quickfix_MySQLLogFactory.cpp:125:19: warning: no newline at end of file
>> These probably slipped through to the release.

Yeah, these will be fixed.

$ make install

>> rm -rf /opt2/QuickFIX/linux/1.4.0/include/quickfix
>> mkdir /opt2/QuickFIX/linux/1.4.0/include/quickfix
>> mkdir: cannot create directory `/opt2/QuickFIX/linux/1.4.1/include/quickfix': No >> such file or directory
>> To fix this I added in src/C++/Makefile.am the line 116 below:

I havn't seen this before, but I can see how some systems might need it.  I guess it depends on how your mkdir works.


>> /opt2/QuickFIX/linux/1.4.0/include/quickfix/include
>> which looks at little bit strange (double include).

Yeah, this is sort of a result of windows having no standard for installing header and library files, so they are generally put in a local directory.  I didn't want to muddle the root quickfix directory, hence the include directory which then had to be carried over to *nix for portability.  I would like it to work like you suggest, but will need to reorganize how headers are installed in windows.  I'm thinking of creating an "output" directory under the root quickfix directory.  There would then be another "quickfix" directory under output which would contain the include files (and a directory for the lib and bin files).  That way under windows people can put quickfix\output in the include path, and we can then do things more normally under *nix.  

Any input on how this problem is normally handled would be helpful.

>> In addition, it would be nice to install the generated quickfix.jar into the lib directory.
>> Change src/java/Makefile.am:

Yeah, I didn't really know what standard procedure there was for installing jar files.  Sounds like a good place to me.





---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

Re: [Quickfix-developers] QF 1.4.1: failing acceptance tests

[Oren M. <ore...@ya...>]

Configure it in the test itself.  Open up the failing test file.  The first message that is sent in is the logon message which sets the 108 (HeartBtInt) value.  Increasing this value will increase the interval for the test.
 Joerg Thoennes <Joe...@ma...> wrote:Hi,

some acceptance test in QF 1.4.1 are failed, see the attached log.

The pattern is always the same: a ResendRequest is expected, but a HeartBeat is got.
I suppose some processing is too slow and to heartbeat comes automatically before the
ResendRequest could be issued. Therefore, a good try would to increase the heartbeat
interval. But I only see

test/cfg/at_server.cfg

and the heartbeat interval can only set in Initiators, not Acceptors. Where I can configure
the Initiator for the acceptance test?

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



Number of fields do no match



18




Number of fields do no match



16




Number of fields do no match



18




Number of fields do no match



18




Number of fields do no match



16




Number of fields do no match



18








---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

[Quickfix-developers] QF 1.4.1: failing acceptance tests

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

Hi,

some acceptance test in QF 1.4.1 are failed, see the attached log.

The pattern is always the same: a ResendRequest is expected, but a HeartBeat is got.
I suppose some processing is too slow and to heartbeat comes automatically before the
ResendRequest could be issued. Therefore, a good try would to increase the heartbeat
interval. But I only see

	test/cfg/at_server.cfg

and the heartbeat interval can only set in Initiators, not Acceptors. Where I can configure
the Initiator for the acceptance test?

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] SocketReuseAddress default value

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

Hi,

in the documentation there is no default value for SocketReuseAddress given.
According to the source (examples from SocketAcceptor.h / .cpp)


       68 class SocketAcceptor : public Acceptor, SocketServer::Strategy
...
      100   bool m_reuseAddress;
...
       88   if( s.get().has( SOCKET_REUSE_ADDRESS ) )
       89   m_reuseAddress = ( bool ) s.get().getBool( SOCKET_REUSE_ADDRESS );

the m_reuseAddress is not initialized if the SocketReuseAddress is not used. It would be better
to set

      100   bool m_reuseAddress = false;

and document it.

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] QuickFIX 1.4.1

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

Oren Miller wrote:
> QuickFIX 1.4.1 is now available here:
> http://quickfix.thoughtworks.com/download.html

Thanks Oren for building this release. Now I can compile without errors. And more important:
The runtime problems (SIGRTMIN and SIGABRT) with 1.3.2 have gone. Now my Java process starts
and I can continue to develop the prototype applications. Many thanks again!!


Below there are some minor issues for purists ;-)

$ make

../Utility.h:118: warning: `const char*FIX::EOL' defined but not used

	This is seen at several places. IMHO, the std::endl could be used if
	the flush done by this construct does not matter.
	(See stdc++ doc:

>> Some people also believe that sending endl down an output stream only writes a newline. This is incorrect; after a newline is written, the buffer is also flushed. Perhaps this is the effect you want when writing to a screen -- get the text out as soon as possible, etc -- but the buffering is largely wasted when doing this to a file:

>>   output << "a line of text" << endl;
>>   output << some_data_variable << endl;
>>   output << "another line of text" << endl;
	
	The std::endl should also send '\r\n' on Windows, but I am not sure.)

	

org_quickfix_MySQLLog.cpp:127:19: warning: no newline at end of file
org_quickfix_MySQLLogFactory.cpp:125:19: warning: no newline at end of file

	These probably slipped through to the release.


$ make install

rm -rf /opt2/QuickFIX/linux/1.4.0/include/quickfix
mkdir /opt2/QuickFIX/linux/1.4.0/include/quickfix
mkdir: cannot create directory `/opt2/QuickFIX/linux/1.4.1/include/quickfix': No such file or directory

To fix this I added in src/C++/Makefile.am the line 116 below:

     114 install-exec-local: *.h
     115     rm -rf $(includedir)/quickfix
     116     -mkdir $(includedir)
     117     mkdir $(includedir)/quickfix
     118     mkdir $(includedir)/quickfix/include
     119     cp *.h $(includedir)/quickfix/include

The include files then install into

	/opt2/QuickFIX/linux/1.4.0/include/quickfix/include

which looks at little bit strange (double include).

IMHO, the src/C++/Makefile.am should be changed in the following way

- Move all *.h files from
	
	libquickfix_la_SOURCES = ...

   to

	pkginclude_HEADERS = ...

- Drop the install-local / uninstall-local target altogether.

This install the include file into

	/opt2/QuickFIX/linux/1.4.0/include/quickfix

and they can be accessed using

	#include <quickfix/...>

which seems to more standard than using

	#include "quickfix/include/..."

as in the examples. Of course, after doing that, QuickFIX probably has to be installed to be used by the
examples (and the tests).

In addition, it would be nice to install the generated quickfix.jar into the lib directory.
Change src/java/Makefile.am:

- Add

javadir = $(libdir)
java_DATA = ../../lib/quickfix.jar

- Drop the install-local / uninstall-local targets.


Anyway, I just start to understand autotool so my suggestions are just starting points.

Oren, could you please comment on these issues?

Thanks, 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] QuickFIX 1.4.1 .NET API

[Oren M. <ore...@ya...>]

Carlos Yee just informed me that the 1.4.1 release package is missing the .NET code.  I did the release this time using the Windows XP zip tool instead of winzip.  Shame on me, I did not validate the package.  It looks like the XP tool ignores directories that start with a "."

I've re-released the zip package using winzip.  It may take a little time for the new file to propogate to all the mirrors.  If you are not using .NET, you need not concern yourself with this.

--oren



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more

[Quickfix-developers] QuickFIX 1.4.1

[Oren M. <ore...@ya...>]

QuickFIX 1.4.1 is now available here:
http://quickfix.thoughtworks.com/download.html

release notes are here:
http://sourceforge.net/project/shownotes.php?release_id=151463

Mostly bug fixes and compilation fixes.  If you has
trouble getting 1.4.0 working, this one probably
addresses your problem.  Also a fix for repeating
groups is in this version.

Experimental feature for displaying C++ call stack
after a crash can also be optionally enabled.  This
adds overhead and should be enabled if you are
experiencing a strange crash and need to know where it
is happening.  If your system provides you with a
coredump, you should compile with -g instead of using
this feature.

Most of the patches for this version came from various
contributors.  CONTRIBUTORS and THANKS files have been
added to the repository, acknowleding people who have
helped the project.  It isn't complete yet and I know
I'm missing several of you.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

Re: [Quickfix-developers] QuickFIX bug.

[Oren M. <ore...@ya...>]

> I have discovered a bug in QuickFIX when dealing
> with the 355 tag in the 
> Email message. I am working with a vendor who has
> chosen to embed Custom 
> FIX tags within the 355 block of an email message.
> QuickFIX does not 
> parse this message correctly at all.

QuickFIX does not yet fully support DATA fields (it
treats them like normal strings, as you have
observed).  So this is new functionality that needs to
be added.

> The other bug I have found has to do with the way
> the BodyLength is 
> calculated. The message I receive from this vendor
> has a tag that is 
> repeated, once outside of a repeating group, and
> once within. QuickFIX 
> incorrectly calculates the body length by only
> counting this repeated 
> tag once, and thus rejects the message outright.

Can you provide the message (or a similar one, with
the data changed), so we can add it to our test suite?

> Finally, a question on QuickFIX internals. I have
> noticed that there is 
> a distinct lack of logging within the various
> components that make up 
> QuickFIX. For example, when a message is rejected
> due to a bad 
> BodyLength or Checksum QuickFIX prints no error
> messages at all? Another 
> example would be in parsing the XML file for
> validation, if there is an 
> error in the XML it prints an error, but not the tag
> that caused it, 
> making diagnosis of the problem much more difficult.
> Is there any reason 
> for this? Is there a canonical way to log from
> within other QuickFIX 
> modules that I could use to log these errors?

This depends on what version you are using.  Earlier
versions had no significant logging at all.  In the
newer releases it has gotten pretty good.  You should
look at the Log and LogFactory interface. 
Implementations that come with QF are the
ScreenLogFactory, FileLogFactory, and MySQLLogFactory.
 The LogFactory is an optional interface that is
passed in to the initiator and acceptor.  If you do
not pass one in, you will get no logging.

There is no reason that messages are at their current
detail level.  Patches that improve on error messages
are welcome.

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

[Quickfix-developers] QuickFIX bug.

[Nicholas P. <nic...@sl...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have discovered a bug in QuickFIX when dealing with the 355 tag in the 
Email message. I am working with a vendor who has chosen to embed Custom 
FIX tags within the 355 block of an email message. QuickFIX does not 
parse this message correctly at all.

Instead of looking at the 354 tag and determining the length of the 355 
tag from that, it instead assumes that the next <eos> after the start of 
the 355 tag indicates it's end. While the embedding of FIX within a tag 
like the 355 tag is a dubious choice, I have to receive these message. I 
will endeavor to make a patch for this bug.

The other bug I have found has to do with the way the BodyLength is 
calculated. The message I receive from this vendor has a tag that is 
repeated, once outside of a repeating group, and once within. QuickFIX 
incorrectly calculates the body length by only counting this repeated 
tag once, and thus rejects the message outright.

Finally, a question on QuickFIX internals. I have noticed that there is 
a distinct lack of logging within the various components that make up 
QuickFIX. For example, when a message is rejected due to a bad 
BodyLength or Checksum QuickFIX prints no error messages at all? Another 
example would be in parsing the XML file for validation, if there is an 
error in the XML it prints an error, but not the tag that caused it, 
making diagnosis of the problem much more difficult. Is there any reason 
for this? Is there a canonical way to log from within other QuickFIX 
modules that I could use to log these errors?

Thanks,
- -Nick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+kbgDR42/Somtp0QRAsCPAJ90HWqJmF5TcJ38tCkNUT+bHlNpOgCeJroN
U2qGT1VcZIE/+nKuNvwKQJQ=
=Kcgv
-----END PGP SIGNATURE-----

RE: [Quickfix-developers] OnRun Function?

[Vamsi K. <Vam...@ib...>]

I guess I  was  not clear.
I am developing a FIX  Client which maintains  a session as  well as
polls  for an external source for  pre-built FIX formatted messages (
only  body) and add header and  send  them to the  FIX Server.

Can somebody  tell me how to do that?

Vamsi

/-----Original Message-----
/From: qui...@li... [mailto:quickfix-
/dev...@li...] On Behalf Of Vamsi Krishna
/Sent: Monday, April 07, 2003 10:09 AM
/To: qui...@li...
/Cc: OM...@th...
/Subject: [Quickfix-developers] OnRun Function?
/
/HI
/I was trying to poll on external source ( pre-composed FIX messages
/residing either in Database or MQSeries or some proprietory command
/messages which start or start FIXClient component).
/
/Can somebody tell me how? I was trying to use onRun function. It seems
/that it will get invoked only once.
/
/Thanks in advance
/Vamsi
/
/
/
/-------------------------------------------------------
/This SF.net email is sponsored by: ValueWeb:
/Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
/No other company gives more support or power for your dedicated server
/http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
/_______________________________________________
/Quickfix-developers mailing list
/Qui...@li...
/https://lists.sourceforge.net/lists/listinfo/quickfix-developers