quickfixj-users — General mailing list for QuickFIX/J topics.

[Quickfixj-users] SecurityTradingStatus valid values VS. incorrect tag value

[Matyas B. <ma...@ba...>]

Hi All,

We found a strange problem, when we made a FIX.4.4. testing application. 
When we send a SecurityStatusRequest (35=e), the server sends the 
SecurityStatus (35=f) message with SecurityTradingStatus (Tag #326) = 17 
("Ready to trade!")!

But the quickfix throws an incorrect tag value exception
(<20060719-09:42:51, FIX.4.4:A81->XXXXX, event> (Message 371 Rejected: 
Value is incorrect (out of range) for this tag:326) 
FixTester.toAdmin: 
8=FIX.4.4
9=131
35=3
34=103
49=A81
52=20060719-09:42:51.591
56=BAXTER
45=371
58=Value 
is incorrect (out of range) for this tag
371=326
372=f
373=5
10=253
)

We checked the constants on the quickfix javadoc  file:

*quickfix.field.SecurityTradingStatus 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html>* 

|public static final int| 	|FIELD 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#FIELD>| 
	|326|
|public static final int| 	|MARKET_IMBALANCE_BUY 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#MARKET_IMBALANCE_BUY>| 
	|7|
|public static final int| 	|MARKET_IMBALANCE_SELL 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#MARKET_IMBALANCE_SELL>| 
	|8|
|public static final int| 	|MARKET_ON_CLOSE_IMBALANCE_BUY 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#MARKET_ON_CLOSE_IMBALANCE_BUY>| 
	|9|
|public static final int| 	|NO_OPEN_NO_RESUME 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#NO_OPEN_NO_RESUME>| 
	|4|
|public static final int| 	|OPENING_DELAY 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#OPENING_DELAY>| 
	|1|
|public static final int| 	|PRICE_INDICATION 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#PRICE_INDICATION>| 
	|5|
|public static final int| 	|RESUME 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#RESUME>| 
	|3|
|public static final int| 	|TRADING_HALT 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#TRADING_HALT>| 
	|2|
|public static final int| 	|TRADING_RANGE_INDICATION 
<http://www.quickfixj.org/quickfixj/javadoc/quickfix/field/SecurityTradingStatus.html#TRADING_RANGE_INDICATION>| 
	|6|

But, in the FIX.4.4 documentation contains this:

  Valid values:
  1 = Opening Delay
  2 = Trading Halt
  3 = Resume
  4 = No Open/No Resume
  5 = Price Indication
  6 = Trading Range Indication
  7 = Market Imbalance Buy
  8 = Market Imbalance Sell
  9 = Market On Close Imbalance Buy
  10 = Market On Close Imbalance Sell
  11 = (not assigned)
  12 = No Market Imbalance
  13 = No Market On Close Imbalance
  14 = ITS Pre-Opening
  15 = New Price Indication
  16 = Trade Dissemination Time
  17 = Ready to trade (start of session)
  18 = Not Available for trading (end of session)
  19 = Not Traded on this Market
  20 = Unknown or Invalid
  21 = Pre-Open
  22 = Opening Rotation
  23 = Fast Market


Why hasn't the quickfix constants for every valid values of the 
SecurityTradingStatus?
How can I solve this problem? (Catch the exception after the 
MessageCracker, or extend the constants wit the possible values...)

Thank you,

                             Matyi

[Quickfixj-users] ClassCastException in MessageCracker

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

Hi Guys,

I've been using QuickFIX/J for a couple of weeks now and for the most
part I'm very happy with the result. Thanks to Steve and the rest for
finally making QuickFIX a pure Java application!

However, yesterday when I had to restart our application I had some
issues when QuickFIX didn't respond correctly to a ResendRequest from
our counterparty.

Normally this is what happens when I have to restart during the day:

XXX =3D Me
YYY =3D Counterparty

8=3DFIX.4.2=019=3D53=0135=3DA=0134=3D7200=0149=3DXXX=0152=3D20060718-08:07:=
30.231=0156=3DYYY=0110=3D108=01
8=3DFIX.4.2=019=3D66=0135=3DA=0134=3D7201=0149=3DXXX=0152=3D20060718-08:07:=
30.261=0156=3DYYY=0198=3D0=01108=3D180=0110=3D195=01
8=3DFIX.4.2=019=3D66=0135=3DA=0134=3D14225=0149=3DYYY=0152=3D20060718-08:07=
:29.596=0156=3DXXX=0198=3D0=01108=3D30=0110=3D212=01
8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D7202=0149=3DXXX=0152=3D20060718-08:07:=
32.134=0156=3DYYY=017=3D1=0116=3D0=0110=3D222=01
8=3DFIX.4.2=019=3D75=0135=3D1=0134=3D7203=0149=3DXXX=0152=3D20060718-08:07:=
32.134=0156=3DYYY=01112=3DResendHasFinished=0110=3D224=01

ResendRequest from YYY:
8=3DFIX.4.2=019=3D66=0135=3D2=0134=3D14226=0149=3DYYY=0152=3D20060718-08:07=
:29.600=0156=3DXXX=017=3D7150=0116=3D0=0110=3D182=01

Correct respons from QuickFIX/J:
8=3DFIX.4.2=019=3D94=0135=3D4=0134=3D7150=0143=3DY=0149=3DXXX=0152=3D200607=
18-08:07:32.184=0156=3DYYY=01122=3D20060718-08:07:32=0136=3D7204=01123=3DY=
=0110=3D080=01
8=3DFIX.4.2=019=3D75=0135=3D1=0134=3D7204=0149=3DXXX=0152=3D20060718-08:07:=
38.143=0156=3DYYY=01112=3DTest
OS, 10:07:38=0110=3D149=01
8=3DFIX.4.2=019=3D75=0135=3D1=0134=3D7205=0149=3DXXX=0152=3D20060718-08:07:=
41.147=0156=3DYYY=01112=3DTest
OS, 10:07:41=0110=3D142=01

Yesterday's scenario:

8=3DFIX.4.2=019=3D67=0135=3DA=0134=3D30499=0149=3DXXX=0152=3D20060718-11:29=
:33.504=0156=3DYYY=0198=3D0=01108=3D180=0110=3D004=01
8=3DFIX.4.2=019=3D67=0135=3DA=0134=3D61254=0149=3DYYY=0152=3D20060718-11:29=
:34.083=0156=3DXXX=0198=3D0=01108=3D180=0110=3D000=01
8=3DFIX.4.2=019=3D63=0135=3D2=0134=3D30500=0149=3DXXX=0152=3D20060718-11:29=
:36.728=0156=3DYYY=017=3D1=0116=3D0=0110=3D023=01
8=3DFIX.4.2=019=3D76=0135=3D1=0134=3D30501=0149=3DXXX=0152=3D20060718-11:29=
:36.738=0156=3DYYY=01112=3DResendHasFinished=0110=3D026=01

ResendRequest from YYY:
8=3DFIX.4.2=019=3D67=0135=3D2=0134=3D61255=0149=3DYYY=0152=3D20060718-11:29=
:34.087=0156=3DXXX=017=3D30498=0116=3D0=0110=3D249=01

The correct Sequence Reset message is missing from QuickFIX/J...

8=3DFIX.4.2=019=3D76=0135=3D1=0134=3D30502=0149=3DXXX=0152=3D20060718-11:29=
:42.757=0156=3DYYY=01112=3DTest
OS, 13:29:42=0110=3D201=01
8=3DFIX.4.2=019=3D76=0135=3D1=0134=3D30503=0149=3DXXX=0152=3D20060718-11:29=
:45.761=0156=3DYYY=01112=3DTest
OS, 13:29:45=0110=3D203=01

When checking the Event log I found the following:

20060718-11:29:31.220: Session FIX.4.2:XXX->YYY schedule is daily,
00:00:00 UTC - 00:00:00 UTC
20060718-11:29:31.241: Created session: FIX.4.2:XXX->YYY
20060718-11:29:33.554: Initiated logon request
20060718-11:29:36.728: Received logon response
20060718-11:29:36.728: MsgSeqNum too high, expecting 1 but received 61254
20060718-11:29:36.738: Sent ResendRequest FROM: 1 TO: 0
20060718-11:29:36.788: Received ResendRequest FROM: 30498 TO: 0
20060718-11:29:36.819: Error during message processing
java.lang.ClassCastException: quickfix.Message
=09at quickfix.MessageCracker.crack(MessageCracker.java:48)
=09at trader.quickfix.QuickFIXApplication.toApp(QuickFIXApplication.java:37=
3)
=09at quickfix.Session.resend(Session.java:757)
=09at quickfix.Session.nextResendRequest(Session.java:698)
=09at quickfix.Session.next(Session.java:585)
=09at quickfix.mina.ThreadPerSessionEventHandlingStrategy$MessageDispatchin=
gThread.run(ThreadPerSessionEventHandlingStrategy.java:75)

I'm sure that this ClassCastException is the problem but I have no
idea what might be the cause. Anyone experienced the same thing?
I'll check if I can recreate the problem and add some debug code to
check what object type is passed when problem occurs.

Thanks,
/Eddie

Re: [Quickfixj-users] [Quickfix-developers] Timestamp in FileLog

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

> Well, the presence of OrigSendingTime indicates that the message has
> been resent.  Is there any indication that the message was not
> successfully sent the first time?

Ooops, sorry. I thought Tag 52 was OrigSendingTime but it's called
SendingTime which is a required field and the one I'm using.

Cheers,
/Eddie

>
> --oren
>
> On Jul 5, 2006, at 5:35 AM, Edde wrote:
>
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> > html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi Guys,
> >
> > We've been experiencing some delay problems with our FIX application
> > and are currently investigating our FIX logs and comparing these with
> > our counterparty.
> >
> > I'm currently using QuickFIX/J but we had the same problems before
> > when using the _jni version and QuickFIX 1.11.1.
> >
> > To try and narrow down the problem I've been comparing the timestamp
> > added to the FileLogs (incl. millisecs) with the OrigSendTime (Tag 52)
> > added by our counterparty. Since our server (running QuickFIX) is
> > located within the same network as our counterparties FIX gateway I'd
> > expect these times to be almost identical (the clocks are synchronized
> > on the two servers).
> >
> > After comparing about 30 random messages from the FileLog I was
> > surprized to see that there was a mean time difference of about 0.750s
> > with a max diff reaching 1.8s. Since both servers are running on the
> > same network this seems a bit strange to me. However, I'm not really
> > sure what exact time in the pricessing chain the timestamp in the
> > FileLog represents?
> > Is this time created as soon as possible when the message arrives on
> > the socket or is there significant processing involved before the
> > message is written to the log?
> >
> > The same goes for the counterparty and Tag 52. Is this time added to
> > the message just before it's being sent or is there any processing
> > involved after Tag 52 has been added to the message?
> >
> > Any suggestions would be helpful and if anyone has other suggestions
> > on how to track down these delays feel free to share them with me.
> >
> > Using Tomcat but need to do more? Need to support web services,
> > security?
> > Get stuff done quickly with pre-integrated technology to make your
> > job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>

Re: [Quickfixj-users] [Quickfix-developers] Timestamp in FileLog

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

Well, the presence of OrigSendingTime indicates that the message has  
been resent.  Is there any indication that the message was not  
successfully sent the first time?

--oren

On Jul 5, 2006, at 5:35 AM, Edde wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Guys,
>
> We've been experiencing some delay problems with our FIX application
> and are currently investigating our FIX logs and comparing these with
> our counterparty.
>
> I'm currently using QuickFIX/J but we had the same problems before
> when using the _jni version and QuickFIX 1.11.1.
>
> To try and narrow down the problem I've been comparing the timestamp
> added to the FileLogs (incl. millisecs) with the OrigSendTime (Tag 52)
> added by our counterparty. Since our server (running QuickFIX) is
> located within the same network as our counterparties FIX gateway I'd
> expect these times to be almost identical (the clocks are synchronized
> on the two servers).
>
> After comparing about 30 random messages from the FileLog I was
> surprized to see that there was a mean time difference of about 0.750s
> with a max diff reaching 1.8s. Since both servers are running on the
> same network this seems a bit strange to me. However, I'm not really
> sure what exact time in the pricessing chain the timestamp in the
> FileLog represents?
> Is this time created as soon as possible when the message arrives on
> the socket or is there significant processing involved before the
> message is written to the log?
>
> The same goes for the counterparty and Tag 52. Is this time added to
> the message just before it's being sent or is there any processing
> involved after Tag 52 has been added to the message?
>
> Any suggestions would be helpful and if anyone has other suggestions
> on how to track down these delays feel free to share them with me.
>
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfixj-users] Timestamp in FileLog

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

Hi Guys,

We've been experiencing some delay problems with our FIX application
and are currently investigating our FIX logs and comparing these with
our counterparty.

I'm currently using QuickFIX/J but we had the same problems before
when using the _jni version and QuickFIX 1.11.1.

To try and narrow down the problem I've been comparing the timestamp
added to the FileLogs (incl. millisecs) with the OrigSendTime (Tag 52)
added by our counterparty. Since our server (running QuickFIX) is
located within the same network as our counterparties FIX gateway I'd
expect these times to be almost identical (the clocks are synchronized
on the two servers).

After comparing about 30 random messages from the FileLog I was
surprized to see that there was a mean time difference of about 0.750s
with a max diff reaching 1.8s. Since both servers are running on the
same network this seems a bit strange to me. However, I'm not really
sure what exact time in the pricessing chain the timestamp in the
FileLog represents?
Is this time created as soon as possible when the message arrives on
the socket or is there significant processing involved before the
message is written to the log?

The same goes for the counterparty and Tag 52. Is this time added to
the message just before it's being sent or is there any processing
involved after Tag 52 has been added to the message?

Any suggestions would be helpful and if anyone has other suggestions
on how to track down these delays feel free to share them with me.

[Quickfixj-users] Resend: Trap error when MsgSeqNum is too low

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

Hi all,

Sorry if this message has been recieved on this list before but I
never saw it on the list so I thought it might have disappeared on the
way...
-------------------------------------------------
Is it possible to trap the error that occurs when you try to logon
with a too low MsgSeqNum?

We've previously been using the QuickFix_jni solution and in this
version I've been using a customized version of quickfix.jar. Here I
was able to trap the above situation in the onEvent(...) callback by
scanning the message for the "Logon state is not valid for message"
String. It wasn't the best solution but at least it worked.
With QuickFixJ there no longer is a callback to onEvent(...) at all
and QuickFix simply disconnects without any message. Is there a way to
trap this situation?

I'm not very familiar with the actual implementation of QuickFixJ but
I tried to trace the source of the disconnect() call but it seems to
originate inside the MINA library for which I don't have the source
code so I'm sort of stuck.

Any help would be appreciated.
Cheers,
/Eddie

Re: [Quickfixj-users] adding new tags/fields

[Steve B. <st...@te...>]

Hi Sankalp,
 
For validation purposes, you can add enumerated values for fields in the
data dictionary. The same is true for fields (tags) but you won't have
typesafe accessors for those fields without regenerating the message code.
However, you can still set the custom fields without code regeneration. Are
you having problems with modifying the data dictionary?
 
Steve


  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of Nayak,
Sankalp (IT)
Sent: Wednesday, June 28, 2006 11:41 PM
To: qui...@li...
Subject: [Quickfixj-users] adding new tags/fields


Hi all
 
Is it possible to add new tags and fields ? If I want to add more values for
a specific field , is there a way to do that without rebuilding the entire
application ?
Any help will be appreciated.
 
regards
Sankalp
 
  _____  


NOTICE: If received in error, please destroy and notify sender.  Sender does
not waive confidentiality or privilege, and use is prohibited.

[Quickfixj-users] adding new tags/fields

[Nayak, S. \(IT\) <San...@mo...>]

Hi all
=20
Is it possible to add new tags and fields ? If I want to add more values
for a specific field , is there a way to do that without rebuilding the
entire application ?
Any help will be appreciated.
=20
regards
Sankalp
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender.  Sender =
does not waive confidentiality or privilege, and use is prohibited.

[Quickfixj-users] Trap error when MsgSeqNum is too low

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

Hi all,

Is it possible to trap the error that occurs when you try to logon
with a too low MsgSeqNum?

We've previously been using the QuickFix_jni solution and in this
version I've been using a customized version of quickfix.jar. Here I
was able to trap the above situation in the onEvent(...) callback by
scanning the message for the "Logon state is not valid for message"
String. It wasn't the best solution but at least it worked.
With QuickFixJ there no longer is a callback to onEvent(...) at all
and QuickFix simply disconnects without any message. Is there a way to
trap this situation?

I'm not very familiar with the actual implementation of QuickFixJ but
I tried to trace the source of the disconnect() call but it seems to
originate inside the MINA library for which I don't have the source
code so I'm sort of stuck.

Any help would be appreciated.
Cheers,
/Eddie

Re: [Quickfixj-users] [Quickfix-developers] Setting the logger timezone

[Parhami, F. <Far...@gs...>]

Thanks Steve. Will do.=20

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Friday, June 23, 2006 9:04 AM
To: qui...@li...
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Setting the logger timezone

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Currently there is no way to change it but it wouldn't be
a difficult feature to add. Feel free to add a Jira feature
request at http://www.quickfixj.org/jira/secure/Dashboard.jspa
and I can try to get it into the next release. Alternately,
you could develop the feature and submit a patch. It  would
be good to be able to control both the time zone and the
date format.

Regards,

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Parhami, Faraz
> Sent: Friday, June 23, 2006 2:55 PM
> To: John Hensley; qui...@li...
> Subject: Re: [Quickfix-developers] Setting the logger timezone
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Thanks. Is there a way to change the logging TimeZone?=20
>=20
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On=20
> Behalf Of John Hensley
> Sent: Thursday, June 22, 2006 8:58 PM
> To: qui...@li...
> Subject: Re: [Quickfix-developers] Setting the logger timezone
>=20
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> The TimeZone setting just lets you specify the session=20
> schedule in something other than UTC. It doesn't affect the logging.
>=20
> John

Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfixj-users] [Quickfix-developers] Setting the logger timezone

[Steve B. <sb...@sm...>]

Currently there is no way to change it but it wouldn't be
a difficult feature to add. Feel free to add a Jira feature
request at http://www.quickfixj.org/jira/secure/Dashboard.jspa
and I can try to get it into the next release. Alternately,
you could develop the feature and submit a patch. It  would
be good to be able to control both the time zone and the
date format.

Regards,

Steve

> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On=20
> Behalf Of Parhami, Faraz
> Sent: Friday, June 23, 2006 2:55 PM
> To: John Hensley; qui...@li...
> Subject: Re: [Quickfix-developers] Setting the logger timezone
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Thanks. Is there a way to change the logging TimeZone?=20
>=20
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On=20
> Behalf Of John Hensley
> Sent: Thursday, June 22, 2006 8:58 PM
> To: qui...@li...
> Subject: Re: [Quickfix-developers] Setting the logger timezone
>=20
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> The TimeZone setting just lets you specify the session=20
> schedule in something other than UTC. It doesn't affect the logging.
>=20
> John

Re: [Quickfixj-users] Problems migrating to QuickFIX/J

[Steve B. <st...@te...>]

Hi Eddie,

Yes, this is a known issue and the files are different
by design. I agree that the error message should 
be more descriptive with a suggestion about how to
correct the problem.

I'm glad it's working for you now.

Steve

> -----Original Message-----
> From: qui...@li... 
> [mailto:qui...@li...] On 
> Behalf Of Edde
> Sent: Thursday, June 22, 2006 2:04 PM
> To: qui...@li...
> Subject: Re: [Quickfixj-users] Problems migrating to QuickFIX/J
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/ Hi,
> 
> > Are you running "Generate FIX Messages" from Eclipse's 
> external tool 
> > menu? If not, it should be run from there for an Eclipse build. I 
> > assume you are using a relatively recent version of Eclipse 
> if you're 
> > using Java 5. The Ant version needs to be 1.6+ but that's what is 
> > installed in newer versions of Eclipse.
> 
> Well, I thought I had the latest version since used the 
> Software Update feature. But I guess I should have known that 
> it didn't pick up major releases so I've now upgraded and 
> moved my projects to Eclipse 3.1.2.
> 
> "Generate FIX Messages" worked just fine with the new version 
> of Eclipse so I've now managed to build my own quickfixj.
> 
> > I haven't received any reports of the 
> ThreadedSocketInitiator hanging 
> > during construction. The only guess I have is that maybe 
> you are doing 
> > something in the onCreate method that is causing a thread 
> deadlock in 
> > QFJ although it didn't cause it in the JNI version. Again, just a 
> > guess. If it is something like that, please tell me and 
> I'll look into 
> > it from the QFJ side.
> 
> It turned out that the ThreadedSocketInitiator actually threw 
> an exception in the constructor that I managed to throw away 
> without feedback in my application. I've modified my code to 
> trap the exception and this is what I got:
> 
> quickfix.ConfigError: error during session initialization
> 	at 
> quickfix.mina.initiator.AbstractSocketInitiator.createSessions
> (AbstractSocketInitiator.java:113)
> 	at 
> quickfix.mina.initiator.AbstractSocketInitiator.<init>(Abstrac
> tSocketInitiator.java:67)
> 	at 
> quickfix.mina.initiator.AbstractSocketInitiator.<init>(Abstrac
> tSocketInitiator.java:60)
> 	at 
> quickfix.ThreadedSocketInitiator.<init>(ThreadedSocketInitiato
> r.java:32)
> 	at 
> trader.fix.QuickFIXCommunicator.initializeConnection(QuickFIXC
> ommunicator.java:749)
> 	... 4 more
> Caused by: java.lang.RuntimeException: java.io.EOFException
> 	at quickfix.FileStoreFactory.create(FileStoreFactory.java:65)
> 	at quickfix.Session.<init>(Session.java:212)
> 	at 
> quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:125)
> 	at 
> quickfix.mina.SessionConnector.createSession(SessionConnector.
> java:109)
> 	at 
> quickfix.mina.initiator.AbstractSocketInitiator.createSessions
> (AbstractSocketInitiator.java:106)
> 	... 8 more
> Caused by: java.io.EOFException
> 	at java.io.DataInputStream.readInt(DataInputStream.java:358)
> 	at quickfix.FileStore.initializeMessageIndex(FileStore.java:172)
> 	at quickfix.FileStore.initializeCache(FileStore.java:107)
> 	at quickfix.FileStore.initialize(FileStore.java:102)
> 	at quickfix.FileStore.<init>(FileStore.java:89)
> 	at quickfix.FileStoreFactory.create(FileStoreFactory.java:63)
> 	... 12 more
> 
> The problem occured when creating the FileStoreFactory. The 
> directory I specified had some old files in it from a 
> previous run with the _jni version. My guess is that the _jni 
> version of the files used different EOF delimiters or 
> something. I haven't looked into the problem in more detail 
> since the solution was very simple, just remove the old files 
> from the directory and everything works just fine.
> 
> Not sure if this is a bug but it might be a good idea to add 
> in the documentation somewhere.
> 
> Thanks for your help!
> /Eddie
> 
> 
> >
> > As far as I know, using Java 5 should not be a problem.
> >
> > Regards,
> >
> > Steve
> >
> > > -----Original Message-----
> > > From: qui...@li...
> > > [mailto:qui...@li...] On 
> Behalf Of 
> > > Edde
> > > Sent: Wednesday, June 21, 2006 3:51 PM
> > > To: qui...@li...
> > > Subject: [Quickfixj-users] Problems migrating to QuickFIX/J
> > >
> > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Guys,
> > >
> > > We've been using QuickFix in our trading application and 
> since our 
> > > application is built in Java I've been using the _jni 
> library. Now 
> > > that QuickFIX/J 1.0 has been released I thought it was time to 
> > > migrate to the pure Java version.
> > > >From what I understand QuickFIX/J is backwards 
> compatible with the
> > > _jni interface which should mean that the only thing needed is to 
> > > replace my old quickfix.jar file with the new 
> quickfixj.jar and add 
> > > the extra dependencies (e.g 
> backport-util-concurrent-2.1.jar). Am I 
> > > missing something here or is that all I need to do?
> > >
> > > Anyway this is what I tried to do and my application runs smothly 
> > > until it tries to create the ThreadedSocketInitiator when the 
> > > application just hangs when calling the constructor. Any ideas?
> > > I've just upgraded to Java 1.5.0_7 if that could be a problem...
> > >
> > > Before posting to this list I thought I'd download the source and 
> > > try to compile the quickfixj.jar with some debug to give you some 
> > > more info on exactly where it hangs but I didn't succeed in this 
> > > either ;-(.
> > > I'm using Eclipse for development so it was great that the source 
> > > came as an Eclipse project. I added the project to Eclipse which 
> > > seems to work just fine but it won't compile since all the 
> > > quickfix.field.* classes are missing. I checked out the 
> webpage and 
> > > saw that these can easily be creating using the "Generate 
> FIX Messages" ant script.
> > > Unfortunately this doesn't seem to work because I get the 
> following
> > > error:
> > >
> > > "BUILD FAILED:
> > > file:C:/Projects/Trading/FIX/QuickFix/quickfixj/build.xml:86:
> > > Unexpected element "macrodef""
> > >
> > > My experience using Ant scripts unfortunately limits to 
> generating 
> > > Javadoc so I'm not sure what's going on here...
> > >
> > > Any help would be highly appreciated.
> > > Cheers,
> > > /Eddie
> > >
> > >
> > > _______________________________________________
> > > Quickfixj-users mailing list
> > > Qui...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> > >
> >
> >
> >
> > All the advantages of Linux Managed Hosting--Without the 
> Cost and Risk!
> > Fully trained technicians. The highest number of Red Hat 
> > certifications in the hosting industry. Fanatical Support. Click to 
> > learn more
> > 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=1216
> > 42 _______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >
> 
> All the advantages of Linux Managed Hosting--Without the Cost 
> and Risk!
> Fully trained technicians. The highest number of Red Hat 
> certifications in the hosting industry. Fanatical Support. 
> Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&
> dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

Re: [Quickfixj-users] Problems migrating to QuickFIX/J

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

Hi,

> Are you running "Generate FIX Messages" from Eclipse's external
> tool menu? If not, it should be run from there for an Eclipse
> build. I assume you are using a relatively recent version of
> Eclipse if you're using Java 5. The Ant version needs to be
> 1.6+ but that's what is installed in newer versions of Eclipse.

Well, I thought I had the latest version since used the Software
Update feature. But I guess I should have known that it didn't pick up
major releases so I've now upgraded and moved my projects to Eclipse
3.1.2.

"Generate FIX Messages" worked just fine with the new version of
Eclipse so I've now managed to build my own quickfixj.

> I haven't received any reports of the ThreadedSocketInitiator
> hanging during construction. The only guess I have is that
> maybe you are doing something in the onCreate method that is
> causing a thread deadlock in QFJ although it didn't cause it in
> the JNI version. Again, just a guess. If it is something like
> that, please tell me and I'll look into it from the QFJ side.

It turned out that the ThreadedSocketInitiator actually threw an
exception in the constructor that I managed to throw away without
feedback in my application. I've modified my code to trap the
exception and this is what I got:

quickfix.ConfigError: error during session initialization
	at quickfix.mina.initiator.AbstractSocketInitiator.createSessions(AbstractSocketInitiator.java:113)
	at quickfix.mina.initiator.AbstractSocketInitiator.<init>(AbstractSocketInitiator.java:67)
	at quickfix.mina.initiator.AbstractSocketInitiator.<init>(AbstractSocketInitiator.java:60)
	at quickfix.ThreadedSocketInitiator.<init>(ThreadedSocketInitiator.java:32)
	at trader.fix.QuickFIXCommunicator.initializeConnection(QuickFIXCommunicator.java:749)
	... 4 more
Caused by: java.lang.RuntimeException: java.io.EOFException
	at quickfix.FileStoreFactory.create(FileStoreFactory.java:65)
	at quickfix.Session.<init>(Session.java:212)
	at quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:125)
	at quickfix.mina.SessionConnector.createSession(SessionConnector.java:109)
	at quickfix.mina.initiator.AbstractSocketInitiator.createSessions(AbstractSocketInitiator.java:106)
	... 8 more
Caused by: java.io.EOFException
	at java.io.DataInputStream.readInt(DataInputStream.java:358)
	at quickfix.FileStore.initializeMessageIndex(FileStore.java:172)
	at quickfix.FileStore.initializeCache(FileStore.java:107)
	at quickfix.FileStore.initialize(FileStore.java:102)
	at quickfix.FileStore.<init>(FileStore.java:89)
	at quickfix.FileStoreFactory.create(FileStoreFactory.java:63)
	... 12 more

The problem occured when creating the FileStoreFactory. The directory
I specified had some old files in it from a previous run with the _jni
version. My guess is that the _jni version of the files used different
EOF delimiters or something. I haven't looked into the problem in more
detail since the solution was very simple, just remove the old files
from the directory and everything works just fine.

Not sure if this is a bug but it might be a good idea to add in the
documentation somewhere.

Thanks for your help!
/Eddie


>
> As far as I know, using Java 5 should not be a problem.
>
> Regards,
>
> Steve
>
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On
> > Behalf Of Edde
> > Sent: Wednesday, June 21, 2006 3:51 PM
> > To: qui...@li...
> > Subject: [Quickfixj-users] Problems migrating to QuickFIX/J
> >
> > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> > QuickFIX/J Support: http://www.quickfixj.org/support/
> > Hi Guys,
> >
> > We've been using QuickFix in our trading application and since our
> > application is built in Java I've been using the _jni library. Now
> > that QuickFIX/J 1.0 has been released I thought it was time to migrate
> > to the pure Java version.
> > >From what I understand QuickFIX/J is backwards compatible with the
> > _jni interface which should mean that the only thing needed is to
> > replace my old quickfix.jar file with the new quickfixj.jar and add
> > the extra dependencies (e.g backport-util-concurrent-2.1.jar). Am I
> > missing something here or is that all I need to do?
> >
> > Anyway this is what I tried to do and my application runs smothly
> > until it tries to create the ThreadedSocketInitiator when the
> > application just hangs when calling the constructor. Any ideas?
> > I've just upgraded to Java 1.5.0_7 if that could be a problem...
> >
> > Before posting to this list I thought I'd download the source and try
> > to compile the quickfixj.jar with some debug to give you some more
> > info on exactly where it hangs but I didn't succeed in this either
> > ;-(.
> > I'm using Eclipse for development so it was great that the source came
> > as an Eclipse project. I added the project to Eclipse which seems to
> > work just fine but it won't compile since all the quickfix.field.*
> > classes are missing. I checked out the webpage and saw that these can
> > easily be creating using the "Generate FIX Messages" ant script.
> > Unfortunately this doesn't seem to work because I get the following
> > error:
> >
> > "BUILD FAILED:
> > file:C:/Projects/Trading/FIX/QuickFix/quickfixj/build.xml:86:
> > Unexpected element "macrodef""
> >
> > My experience using Ant scripts unfortunately limits to generating
> > Javadoc so I'm not sure what's going on here...
> >
> > Any help would be highly appreciated.
> > Cheers,
> > /Eddie
> >
> >
> > _______________________________________________
> > Quickfixj-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> >
>
>
>
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

Re: [Quickfixj-users] Problems migrating to QuickFIX/J

[Steve B. <st...@te...>]

Hi Eddie,

Are you running "Generate FIX Messages" from Eclipse's external
tool menu? If not, it should be run from there for an Eclipse
build. I assume you are using a relatively recent version of
Eclipse if you're using Java 5. The Ant version needs to be
1.6+ but that's what is installed in newer versions of Eclipse.

I haven't received any reports of the ThreadedSocketInitiator
hanging during construction. The only guess I have is that
maybe you are doing something in the onCreate method that is
causing a thread deadlock in QFJ although it didn't cause it in
the JNI version. Again, just a guess. If it is something like
that, please tell me and I'll look into it from the QFJ side.

As far as I know, using Java 5 should not be a problem.

Regards,

Steve

> -----Original Message-----
> From: qui...@li... 
> [mailto:qui...@li...] On 
> Behalf Of Edde
> Sent: Wednesday, June 21, 2006 3:51 PM
> To: qui...@li...
> Subject: [Quickfixj-users] Problems migrating to QuickFIX/J
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi Guys,
> 
> We've been using QuickFix in our trading application and since our
> application is built in Java I've been using the _jni library. Now
> that QuickFIX/J 1.0 has been released I thought it was time to migrate
> to the pure Java version.
> >From what I understand QuickFIX/J is backwards compatible with the
> _jni interface which should mean that the only thing needed is to
> replace my old quickfix.jar file with the new quickfixj.jar and add
> the extra dependencies (e.g backport-util-concurrent-2.1.jar). Am I
> missing something here or is that all I need to do?
> 
> Anyway this is what I tried to do and my application runs smothly
> until it tries to create the ThreadedSocketInitiator when the
> application just hangs when calling the constructor. Any ideas?
> I've just upgraded to Java 1.5.0_7 if that could be a problem...
> 
> Before posting to this list I thought I'd download the source and try
> to compile the quickfixj.jar with some debug to give you some more
> info on exactly where it hangs but I didn't succeed in this either
> ;-(.
> I'm using Eclipse for development so it was great that the source came
> as an Eclipse project. I added the project to Eclipse which seems to
> work just fine but it won't compile since all the quickfix.field.*
> classes are missing. I checked out the webpage and saw that these can
> easily be creating using the "Generate FIX Messages" ant script.
> Unfortunately this doesn't seem to work because I get the following
> error:
> 
> "BUILD FAILED: 
> file:C:/Projects/Trading/FIX/QuickFix/quickfixj/build.xml:86:
> Unexpected element "macrodef""
> 
> My experience using Ant scripts unfortunately limits to generating
> Javadoc so I'm not sure what's going on here...
> 
> Any help would be highly appreciated.
> Cheers,
> /Eddie
> 
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

Re: [Quickfixj-users] Problems migrating to QuickFIX/J

[Nick F. <Nic...@ve...>]

Sounds like you need the latest version of ant. Can you try upgrading
ant, and see if that works - it solved the problem for me.

Nick

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Edde
Sent: 21 June 2006 14:51
To: qui...@li...
Subject: [Quickfixj-users] Problems migrating to QuickFIX/J

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Hi Guys,

We've been using QuickFix in our trading application and since our
application is built in Java I've been using the _jni library. Now
that QuickFIX/J 1.0 has been released I thought it was time to migrate
to the pure Java version.
>From what I understand QuickFIX/J is backwards compatible with the
_jni interface which should mean that the only thing needed is to
replace my old quickfix.jar file with the new quickfixj.jar and add
the extra dependencies (e.g backport-util-concurrent-2.1.jar). Am I
missing something here or is that all I need to do?

Anyway this is what I tried to do and my application runs smothly
until it tries to create the ThreadedSocketInitiator when the
application just hangs when calling the constructor. Any ideas?
I've just upgraded to Java 1.5.0_7 if that could be a problem...

Before posting to this list I thought I'd download the source and try
to compile the quickfixj.jar with some debug to give you some more
info on exactly where it hangs but I didn't succeed in this either
;-(.
I'm using Eclipse for development so it was great that the source came
as an Eclipse project. I added the project to Eclipse which seems to
work just fine but it won't compile since all the quickfix.field.*
classes are missing. I checked out the webpage and saw that these can
easily be creating using the "Generate FIX Messages" ant script.
Unfortunately this doesn't seem to work because I get the following
error:

"BUILD FAILED:
file:C:/Projects/Trading/FIX/QuickFix/quickfixj/build.xml:86:
Unexpected element "macrodef""

My experience using Ant scripts unfortunately limits to generating
Javadoc so I'm not sure what's going on here...

Any help would be highly appreciated.
Cheers,
/Eddie


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

[Quickfixj-users] Problems migrating to QuickFIX/J

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

Hi Guys,

We've been using QuickFix in our trading application and since our
application is built in Java I've been using the _jni library. Now
that QuickFIX/J 1.0 has been released I thought it was time to migrate
to the pure Java version.
>From what I understand QuickFIX/J is backwards compatible with the
_jni interface which should mean that the only thing needed is to
replace my old quickfix.jar file with the new quickfixj.jar and add
the extra dependencies (e.g backport-util-concurrent-2.1.jar). Am I
missing something here or is that all I need to do?

Anyway this is what I tried to do and my application runs smothly
until it tries to create the ThreadedSocketInitiator when the
application just hangs when calling the constructor. Any ideas?
I've just upgraded to Java 1.5.0_7 if that could be a problem...

Before posting to this list I thought I'd download the source and try
to compile the quickfixj.jar with some debug to give you some more
info on exactly where it hangs but I didn't succeed in this either
;-(.
I'm using Eclipse for development so it was great that the source came
as an Eclipse project. I added the project to Eclipse which seems to
work just fine but it won't compile since all the quickfix.field.*
classes are missing. I checked out the webpage and saw that these can
easily be creating using the "Generate FIX Messages" ant script.
Unfortunately this doesn't seem to work because I get the following
error:

"BUILD FAILED: file:C:/Projects/Trading/FIX/QuickFix/quickfixj/build.xml:86:
Unexpected element "macrodef""

My experience using Ant scripts unfortunately limits to generating
Javadoc so I'm not sure what's going on here...

Any help would be highly appreciated.
Cheers,
/Eddie

Re: [Quickfixj-users] SSL tunnelling

[Steve B. <st...@te...>]

Hi Nick,

This sounds good. One suggestion is to investigate how to support adding
/any/ MINA filter. There's a Jira issue (feature request) for this
capability. We could still have special support for SSL to make it
easier to configure. I'd played with MINA SSL a little but we just
recently upgraded to 0.9.x and I haven't much time to do much with
it.

I added a placeholder page to the wiki's wish list for integrated
SSL support. Could you start writing your thoughts there? For
the stunnel, it would be great if you could write a short (even
a 1/2 page would be good) description/tutorial, it would be a good
addition to the list of "tips and tricks" articles on the wiki. One
thing to note on the SSL support is that Java 5 or newer is required.
AFAIK, there is not problem running QFJ with Java 5.

For the conventions related to configuration properties, look at
the existing configuration documentation and it should be mostly
clear.

Steve

> -----Original Message-----
> From: qui...@li... 
> [mailto:qui...@li...] On 
> Behalf Of Nick Fortescue
> Sent: Wednesday, June 14, 2006 5:27 PM
> To: qui...@li...
> Subject: Re: [Quickfixj-users] SSL tunnelling
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/ OK, 
> I've done some experimenting in the absence of a reply. I 
> thought I'd summarize here for the benefit of the archive, 
> and also make a suggestion.
> 
> Firstly stunnel works fine. With the help of the instructions 
> at http://faq.gotomyvnc.com/fom-serve/cache/33.html setting 
> it up was very easy, and the Executor/Banzai pair tunnelled 
> fine and worked perfectly.
> 
> As far as using the abilities of Mina, it seems a shame not 
> to, as this would save setting up a port just for tunnelling, 
> and also make it easy to turn on and off via the config file. 
> The process seems fairly
> straightforward:
> 
> 1) Adapt the settings config file so it had an SSL option. 
> For example SocketUseSSL=Y. Maybe some options for choosing a 
> key file would be needed.
> 2) Add the Mina-Filter SSL to the optional/test jars.
> 3) Add acceptance tests that this was being used and did 
> connect using SSL
> 4) Modify AbstractSocketAcceptor.getIoAcceptor(...) to use 
> the SSL filter if specified in the settings.
> 5) Modify AbstractSocketInitiator.getIoAcceptor(...) to use 
> the SSL filter if specified in the settings.
> 
> Some questions:
> 1) Does this seem architecturally like the right thing to do 
> and the right way to do it?
> 2) If I did it would it be a useful thing to contribute?
> 3) Are there any conventions for things like config settings 
> names, coding style etc, that I ought to be aware of?
> 
> Nick
> 
> 
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On 
> Behalf Of Nick Fortescue
> Sent: 14 June 2006 14:44
> To: qui...@li...
> Subject: [Quickfixj-users] SSL tunnelling
> 
> Forgive me if this is an FAQ, I couldn't find it.
> 
> There seem to be two obvious ways to do SSL tunnelling with 
> quickfixj. 
> 
> - I could use stunnel (http://www.stunnel.org/) 
> 
> - I could use SSL tunnelling from MINA, for example, like this example
> code:
> http://svn.apache.org/viewvc/directory/trunks/mina/examples/sr
> c/main/jav
> a/org/apache/mina/examples/echoserver/Main.java?revision=40006
> 8&view=mar
> kup
> 
> I wondered if anyone had any experience with either of these, 
> and whether one or the other was particularly recommended. Or 
> whether there was a third option I was missing.
> 
> Thanks,
> 
> Nick
> 
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

Re: [Quickfixj-users] SSL tunnelling

[Nick F. <Nic...@ve...>]

OK, I've done some experimenting in the absence of a reply. I thought
I'd summarize here for the benefit of the archive, and also make a
suggestion.

Firstly stunnel works fine. With the help of the instructions at
http://faq.gotomyvnc.com/fom-serve/cache/33.html setting it up was very
easy, and the Executor/Banzai pair tunnelled fine and worked perfectly.

As far as using the abilities of Mina, it seems a shame not to, as this
would save setting up a port just for tunnelling, and also make it easy
to turn on and off via the config file. The process seems fairly
straightforward:

1) Adapt the settings config file so it had an SSL option. For example
SocketUseSSL=3DY. Maybe some options for choosing a key file would be
needed.
2) Add the Mina-Filter SSL to the optional/test jars.
3) Add acceptance tests that this was being used and did connect using
SSL
4) Modify AbstractSocketAcceptor.getIoAcceptor(...) to use the SSL
filter if specified in the settings.
5) Modify AbstractSocketInitiator.getIoAcceptor(...) to use the SSL
filter if specified in the settings.

Some questions:
1) Does this seem architecturally like the right thing to do and the
right way to do it?
2) If I did it would it be a useful thing to contribute?
3) Are there any conventions for things like config settings names,
coding style etc, that I ought to be aware of?

Nick


-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Nick
Fortescue
Sent: 14 June 2006 14:44
To: qui...@li...
Subject: [Quickfixj-users] SSL tunnelling

Forgive me if this is an FAQ, I couldn't find it.

There seem to be two obvious ways to do SSL tunnelling with quickfixj.=20

- I could use stunnel (http://www.stunnel.org/)=20

- I could use SSL tunnelling from MINA, for example, like this example
code:
http://svn.apache.org/viewvc/directory/trunks/mina/examples/src/main/jav
a/org/apache/mina/examples/echoserver/Main.java?revision=3D400068&view=3D=
mar
kup

I wondered if anyone had any experience with either of these, and
whether one or the other was particularly recommended. Or whether there
was a third option I was missing.

Thanks,

Nick

[Quickfixj-users] SSL tunnelling

[Nick F. <Nic...@ve...>]

Forgive me if this is an FAQ, I couldn't find it.

=20

There seem to be two obvious ways to do SSL tunnelling with quickfixj.=20

=20

- I could use stunnel (http://www.stunnel.org/)=20

- I could use SSL tunnelling from MINA (for example, like this example
code:
http://svn.apache.org/viewvc/directory/trunks/mina/examples/src/main/jav
a/org/apache/mina/examples/echoserver/Main.java?revision=3D400068&view=3D=
mar
kup

=20

I wondered if anyone had any experience with either of these, and
whether one or the other was particularly recommended. Or whether there
was a third option I was missing.

=20

Thanks,

=20

Nick

Re: [Quickfixj-users] Best way to report bugs/submit patches

[Steve B. <st...@te...>]

Hi Nick,

Thanks for the patches. Yes, that was the best way to do it for these
types of changes. Larger modifications to the software or major new
features should be discussed here first. I'll include your patches
in the next release.

Thanks again,

Steve

> -----Original Message-----
> From: qui...@li... 
> [mailto:qui...@li...] On 
> Behalf Of Nick Fortescue
> Sent: Wednesday, June 14, 2006 11:27 AM
> To: qui...@li...
> Subject: [Quickfixj-users] Best way to report bugs/submit patches
> 
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/ Hi,
> 
> I've just added a bug report to JIRA, and attached some 
> patches for some fairly minor script issues with the 
> examples. I just wanted to check whether the best way of 
> suggesting changes to fix bugs was via JIRA, or whether it 
> was good to discuss them on this list too.
> 
> I assume that quickfixj works like other open source projects 
> - I can't submit changes via subversion directly without 
> becoming a committer.
> 
> Nick
> 
> 
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> 

[Quickfixj-users] Best way to report bugs/submit patches

[Nick F. <Nic...@ve...>]

Hi,

I've just added a bug report to JIRA, and attached some patches for some
fairly minor script issues with the examples. I just wanted to check
whether the best way of suggesting changes to fix bugs was via JIRA, or
whether it was good to discuss them on this list too.

I assume that quickfixj works like other open source projects - I can't
submit changes via subversion directly without becoming a committer.

Nick

Re: [Quickfixj-users] [Quickfix-users] Quickfix/J How do I suppress MINA messages?

[Chris v. O <chr...@gn...>]

Steve,

   Sorry to be so stupid, but I cant figure out how to do this. Could 
someone provide a small example?

Thanks, Chris


Steve Bate wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Hi Chris,
> 
> The MINA message is logged using the QuickFIX session-oriented logging
> mechanism. What this means is that all session events are logged 
> to the same log category since the QF API provides no way to specify a 
> category when logging the event. Unfortunately, this makes filtering a 
> little more difficult.
> 
> It appears you are using the default JDK 1.4 logging as the underyling
> logging framework. You can write a java.util.logging.Filter and
> attach it to whatever logging handler you are using. 
> 
> http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/Filter.html
> 
> You can also use this technique to filter FIX messages before they
> saved to log (somebody else asked about that capability recently).
> 
> Regards,
> 
> Steve

Re: [Quickfixj-users] Possible workingDirectory/path bug in quickfix.FileStore class

[Toli K. <to...@ma...>]

Ok, my apologies for sending an incomplete email earlier. Had an
"enter key" malfunction.

I'm working on a multi-module project driven by Maven (instead of
ant), where couple of the modules use QuickfixJ.

The directory layout is as follows:
parentModule
    - childModule
       - src
           - test
              - java
                     *.java files are here

I'm noticing a very strange situation: i have a unit test that runs
just fine if you run it directly from the <childModule> directory, it
initializes the Session correctly which creates the appropriate
output/ and store/ directories for FIX.4.2-xxx files.

However, if i run the same test from a parent directory (ie one level
up) then it fails in to create/locate the output/ directory:
java.io.FileNotFoundException:
output/data/server/FIX.4.2-test-exchange-test-sender.body (No such
file or directory)
java.lang.RuntimeException: java.io.FileNotFoundException:
output/data/server/FIX.4.2-test-exchange-test-sender.body (No such
file or directory)
        at quickfix.FileStoreFactory.create(FileStoreFactory.java:65)
        at quickfix.Session.<init>(Session.java:191)
        at quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:125)
        at quickfix.mina.acceptor.AbstractSocketAcceptor.createSessions(AbstractSocketAcceptor.java:129)

with the real error coming from here:
Caused by: java.io.FileNotFoundException:
output/data/server/FIX.4.2-test-exchange-test-sender.body (No such
file or directory)
        at java.io.RandomAccessFile.open(Native Method)
        at java.io.RandomAccessFile.<init>(Unknown Source)
        at java.io.RandomAccessFile.<init>(Unknown Source)
        at quickfix.FileStore.initialize(FileStore.java:97)
        at quickfix.FileStore.<init>(FileStore.java:87)
        at quickfix.FileStoreFactory.create(FileStoreFactory.java:63)

I've traced the cause of the error itself to a Maven bug (incorrect
working dir setup) which i've filed with them:
http://jira.codehaus.org/browse/MSUREFIRE-133

In QuickFixJ it gets manifested in quickfix.FileStore class
constructor. If the incoming "path" is changed to be an absolute path
(instead of relative) the rest of initialization works fine.

I understand this a maven bug and not Quickfix, but i was hoping you
would incorporate the workaround for it anyway b/c it makes sense
regardless: it's just to take the incoming path and to always treat it
as an absolute path. That makes the code more defensive.

It's a one-line change. all the unit tests pass.

I"m attaching a patch for the changes (it's just one line).

toli

[Quickfixj-users] Possible workingDirectory/path bug in quickfix.FileStore class

[Toli K. <to...@ma...>]

Hi,

I'm working on a multi-module project driven by Maven (instead of
ant), where couple of the modules use QuickfixJ.

The directory layout is as follows:



I'm noticing a very strange situation: i have a unit test that runs
just fine if you

[Quickfixj-users] Log4FIX (Beta Release)

[Brian C. <co...@oc...>]

I am pleased to announce the beta release of Log4FIX. Log4FIX is an  
open source FIX logger/ message viewer, written in Java 5, and based  
on QuickFIX/J. Log4FIX provides a "pretty" view for FIX messages by  
utilizing the QuickFIX data dictionary.

Log4FIX works in two main modes:
- tightly integrated with your QuickFIX/J application (real time  
logging)
- standalone application capable of parsing any file with valid FIX  
messages (replay a session)

Log4FIX is still in beta. However, you should find it useful today.  
You can find out more information at: http:// 
www.opentradingsolutions.org/.

Thanks,
Brian Coyner
Object Computing, Inc.
http://www.ociweb.com/
http://www.opentradingsolutions.org/