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

[Quickfixj-users] Conditionally Required Field Missing

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

Hi,

=20

I am getting a response "Conditionally Required Field Missing". How do I
establish what field is missing?

=20

Regards,

John


Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20

Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited.  If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20

Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase =
International Group; registered in England and Wales as company number =
02251162; registered address: Essex House, 2 County Place, Chelmsford, =
Essex CM2 0RE, UK.

[Quickfixj-users] Third Party Message Routing

[<th...@co...>]

I would like to utilize the QFJ engine to act as a router between FIX  
engines in a one-to-many and many-to-one fashion.  I have read the  
"Message Routing Details - Third Party Message Routing" section of  
the FIX protocol documentation on the Standard Message Header.  It  
seems to be straight-forward on the surface, but very involved if I  
have to code to handle every message and ensure all the relevant IDs  
are unique.

Is there some simpler "quick fix" magic like a "router mode" or  
something I can configure or will I need override the onMessage  
method for every message I want to route and manipulate the unique  
IDs accordingly?  Any other suggestions are appreciated as well.

Thanks in advance.

Re: [Quickfixj-users] invalid tag54

[Bruno <bru...@jd...>]

Hi John,

 

Did you check your config files? I you have UseDataDictionary=N, I think
validation is disable altogether.

 

Cheers,

 

Bruno

 

From: qui...@li...
[mailto:qui...@li...] On Behalf Of John
Coleman
Sent: Tuesday, October 09, 2007 1:22 PM
To: qui...@li...
Subject: [Quickfixj-users] invalid tag54

 

Hi,

 

I am surprised that QFJ does not reject a quote request when tag 54=Z, a
value not in the FIX 4.4 dictionary I am using.

 

Anyone understand what is wrong? I don't want to validate the value in my
code when the dictionary looks good. I have hacked the dictionary before to
allow irregular values, so I am sure it works.

 

TIA

John

Eurobase International Limited and its subsidiaries (Eurobase) are unable to
exercise control over the content of information in E-Mails. Any views and
opinions expressed may be personal to the sender and are not necessarily
those of Eurobase. Eurobase will not enter into any contractual obligations
in respect of any part of its business in any E-mail. 

Privileged / confidential information may be contained in this message and
/or any attachments. This E-mail is intended for the use of the addressee(s)
only and may contain confidential information. If you are not the / an
intended recipient, you are hereby notified that any use or dissemination of
this communication is strictly prohibited.  If you receive this transmission
in error, please notify us immediately, and then delete this E-mail. 

Neither the sender nor Eurobase accepts any liability whatsoever for any
defects of any kind either in or arising from this E-mail transmission.
E-Mail transmission cannot be guaranteed to be secure or error-free, as
messages can be intercepted, lost, corrupted, destroyed, contain viruses, or
arrive late or incomplete. Eurobase does not accept any responsibility for
viruses and it is your responsibility to scan any attachments.

Eurobase Systems Limited is the main trading company in the Eurobase
International Group; registered in England and Wales as company number
02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex
CM2 0RE, UK.

[Quickfixj-users] invalid tag54

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

Hi,

=20

I am surprised that QFJ does not reject a quote request when tag 54=3DZ, =
a
value not in the FIX 4.4 dictionary I am using.

=20

Anyone understand what is wrong? I don't want to validate the value in
my code when the dictionary looks good. I have hacked the dictionary
before to allow irregular values, so I am sure it works.

=20

TIA

John


Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20

Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited.  If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20

Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase =
International Group; registered in England and Wales as company number =
02251162; registered address: Essex House, 2 County Place, Chelmsford, =
Essex CM2 0RE, UK.

[Quickfixj-users] Echo Messages

[<th...@co...>]

What is the best way using the least lines of code to echo the  
incoming message back to the sender when in the onMessage(...) method?

Thanks in advance.

Re: [Quickfixj-users] Latency to respond to messages?

[Ted G. <tg...@Co...>]

Good question, I'm sorry I didn't mention that in my original mail.  Yes, I
have set:
SocketTcpNoDelay=Y

Thanks,
Ted

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Steve
Bate
Sent: Monday, October 08, 2007 11:37 AM
To: qui...@li...
Subject: Re: [Quickfixj-users] Latency to respond to messages?

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Have you disabled the Nagle Algorithm at the TCP level (using TCP_NO_DELAY)?

> I'm building an arbitrage system, so responding to FIX messages quickly is
> essential.  I don't need to process hundreds of messages a second, but I
> need to respond to the messages that arrive very quickly.
>
>
>
> I'm new to QuickFix, so my first test was to write a QFJ application that
> just logs into the exchange with my credentials and lets QFJ handle the
> heartbeat messages.  Once heartbeats are established, I used WireShark to
> capture the network traffic so I could see how long it takes to respond to
> a
> heartbeat from the exchange.  The network capture data shows that QFJ's
> best
> time to respond to a heartbeat is about 1.5 ms, and some of the times are
> much higher (seconds).
>
>
>
> I need to respond to all messages in sub-millisecond times, so I'm curious
> how to improve these times.  I've done the following:
>
> + Log level is WARN, so nothing is being logged
>
> + Using the MemoryStore for messages
>
> + Using the SocketInitiator
>
>
>
> Any suggestions on improving these times would be appreciated.  Or if QFJ
> is
> not designed to handle these requirements, I'd be interested in knowing
> that
> as well.
>
>
>
> Thanks,
>
> Ted
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>
> http://get.splunk.com/_______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] Latency to respond to messages?

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

Have you disabled the Nagle Algorithm at the TCP level (using TCP_NO_DELAY)?

> I'm building an arbitrage system, so responding to FIX messages quickly is
> essential.  I don't need to process hundreds of messages a second, but I
> need to respond to the messages that arrive very quickly.
>
>
>
> I'm new to QuickFix, so my first test was to write a QFJ application that
> just logs into the exchange with my credentials and lets QFJ handle the
> heartbeat messages.  Once heartbeats are established, I used WireShark to
> capture the network traffic so I could see how long it takes to respond to
> a
> heartbeat from the exchange.  The network capture data shows that QFJ's
> best
> time to respond to a heartbeat is about 1.5 ms, and some of the times are
> much higher (seconds).
>
>
>
> I need to respond to all messages in sub-millisecond times, so I'm curious
> how to improve these times.  I've done the following:
>
> + Log level is WARN, so nothing is being logged
>
> + Using the MemoryStore for messages
>
> + Using the SocketInitiator
>
>
>
> Any suggestions on improving these times would be appreciated.  Or if QFJ
> is
> not designed to handle these requirements, I'd be interested in knowing
> that
> as well.
>
>
>
> Thanks,
>
> Ted
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>
> http://get.splunk.com/_______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

[Quickfixj-users] Latency to respond to messages?

[Ted G. <tg...@Co...>]

 

I'm building an arbitrage system, so responding to FIX messages quickly is
essential.  I don't need to process hundreds of messages a second, but I
need to respond to the messages that arrive very quickly.  

 

I'm new to QuickFix, so my first test was to write a QFJ application that
just logs into the exchange with my credentials and lets QFJ handle the
heartbeat messages.  Once heartbeats are established, I used WireShark to
capture the network traffic so I could see how long it takes to respond to a
heartbeat from the exchange.  The network capture data shows that QFJ's best
time to respond to a heartbeat is about 1.5 ms, and some of the times are
much higher (seconds).  

 

I need to respond to all messages in sub-millisecond times, so I'm curious
how to improve these times.  I've done the following:

+ Log level is WARN, so nothing is being logged

+ Using the MemoryStore for messages

+ Using the SocketInitiator

 

Any suggestions on improving these times would be appreciated.  Or if QFJ is
not designed to handle these requirements, I'd be interested in knowing that
as well.

 

Thanks,

Ted

[Quickfixj-users] No-arg constructor for DateFields

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

Hey,

I have a question about no-arg constructors of DateField subclasses,
such as SendingTime and TransactTime.

It seems that if you use no-arg constructors for these fields, you
always get a field with some constant arbitrary time in it. For
example:

Message msg = new Message();
msg.setField(new TransactTime());
sleep(20 seconds)
msg.setField(new SendingTime());

You get the same exact time in both TransactTime and SendingTime
fields. This is b/c the no-arg constructors are implemented to get the
time from a static Calendar that's part of the DateField superclass,
and the Calendar class is implemented to have a static 'current time'
value that's initialized once and kept.

Is there any particular reason why the no-arg constructor for
DateField subclasses has this behaviour? I'd expect that it'd be the
equivalent of new SendingTime(new Date()), ie it'd always create a
field with the latest time.

i'm not sure if this is a bug or a C++ QF compatibility issue, but i
can't think of a use case where you'd want this behaviour. It's not
even returning the time the FIX engine started - it's just some
arbitrary time when the very first DateField was created.

thoughts?

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

Re: [Quickfixj-users] Confusion about why SLF4JLog changes aren't in the latest archive

[Ted G. <tg...@Co...>]

Isn't it always the case, you send a question and immediately find the
answer.  It turns out that quickfixj is still using slf4j1.3.0, while I am
using the 1.4.3 version.  The value of the INFO_INT constant was 1 in 1.3
and is 20 in 1.4.3.

So it appears that compiling the quickfixj jar against the slf4j1.3.0
version resulted in INFO_INT being set to 1, rather than reading the value
at runtime.

My apologies for any confusion,

Ted


-----Original Message-----
From: Ted Graham [mailto:tg...@Co...] 
Sent: Friday, October 05, 2007 9:09 AM
To: 'qui...@li...'
Subject: Confusion about why SLF4JLog changes aren't in the latest archive

I downloaded the latest (Sept 23rd ) release of quickfixj-core.jar.  When I
open it up and decompile the SLF4JLog.class, I find the following line
inside the log method:

	la.log(null, callerFQCN, 1, message, null);

Notice that it is passing 1 as the log level.  However, in the src download,
and in the subversion repository, it is passing
LocationAwareLogger.INFO_INT.  Now if I check this file's history in
Subversion, I see this file was changed on April 6, 2007.  

So why isn't the change to pass LocationAwareLogger.INFO_INT included in
quickfixj-core.jar?

I'm somewhat new to java and very new to quickfixj, so if I have
misunderstood, I'd appreciate an explanation.

Thanks,
Ted

[Quickfixj-users] Confusion about why SLF4JLog changes aren't in the latest archive

[Ted G. <tg...@Co...>]

I downloaded the latest (Sept 23rd ) release of quickfixj-core.jar.  When I
open it up and decompile the SLF4JLog.class, I find the following line
inside the log method:

	la.log(null, callerFQCN, 1, message, null);

Notice that it is passing 1 as the log level.  However, in the src download,
and in the subversion repository, it is passing
LocationAwareLogger.INFO_INT.  Now if I check this file's history in
Subversion, I see this file was changed on April 6, 2007.  

So why isn't the change to pass LocationAwareLogger.INFO_INT included in
quickfixj-core.jar?

I'm somewhat new to java and very new to quickfixj, so if I have
misunderstood, I'd appreciate an explanation.

Thanks,
Ted

[Quickfixj-users] Level number 1 is not recognized

[Danilo T. <tu...@po...>]

Hi,

I had to migrate to SLF4J 1.4.3 because of MDC support.
Now I'm getting this exception:

Caused by: java.lang.IllegalStateException: Level number 1 is not
recognized.
	at
org.slf4j.impl.Log4jLoggerAdapter.log(Log4jLoggerAdapter.java:507)
	at quickfix.SLF4JLog.log(SLF4JLog.java:100)
	at quickfix.SLF4JLog.onEvent(SLF4JLog.java:83)
	at quickfix.Session.<init>(Session.java:293)
	at
quickfix.DefaultSessionFactory.create(DefaultSessionFactory.java:159)
	at
quickfix.mina.SessionConnector.createSession(SessionConnector.java:112)
	at
quickfix.mina.initiator.AbstractSocketInitiator.createSessions(AbstractSocke
tInitiator.java:132)
	... 32 more

I guess it's because quickfixj 1.3.0 is compiled against SLF4J 1.3.1.
Is there any plan to migrate to SLF4J 1.4.3?

Thanks,
Danilo

Re: [Quickfixj-users] tag1

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

John,

The Account tag is part of a repeating group. Apparently, it was not
included in that group in the first message and it's an invalid tag =
outside
the group. In the second message, the field is within the repeating =
group
so it parses correctly. However, you must retrieve it by retrieving the
groups and then obtaining the Account field from each group.

Regards,

Steve

> -----Original Message-----
> From: qui...@li... [mailto:quickfixj-
> use...@li...] On Behalf Of John Coleman
> Sent: Wednesday, October 03, 2007 6:53 AM
> To: qui...@li...
> Subject: Re: [Quickfixj-users] tag1
> Importance: High
>=20
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi,
>=20
> We use Quickfix at both sides.
>=20
> I have now moved the tag 1 element to the end of the message and it is =
now
> accepted on the server - I didn't think ordering in the message body =
was
> significant, but it appears so?
>=20
> But the problems goes on. When I try to retrieve the account from the
> message, it throws field not found.
>=20
> My code is: quoteRequest.getString(Account.FIELD)
>=20
> The quote request is:
> =
8=3DFIX.4.4=019=3D191=0135=3DR=0134=3D229=0149=3Dtestinitiator1=0152=3D20=
071003-
> =
10:21:13.932=0156=3DFxFIXService=01131=3DSIMRFQ00044702=01146=3D1=0155=3D=
EUR/USD=01461=3DRCSXX
> =
X=0180303=3D1=01537=3D1=0154=3D1=0138=3D100000=0163=3D0=0164=3D20070926=01=
15=3DEUR=011=3Dtestinitiator1=0110
> =3D075=01
>=20
> It's like QFJ can't see what is in the message?
>=20
> TIA
> John
>=20
> -----Original Message-----
> From: qui...@li... [mailto:quickfixj-
> use...@li...] On Behalf Of Bruno
> Sent: 03 October 2007 10:13
> To: qui...@li...
> Subject: Re: [Quickfixj-users] tag1
>=20
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>=20
> Hi John,
>=20
> Are you using Quickfix to send the message or the server uses =
Quickfix?
>=20
> This is a response from the server, so in case you are using Quickfix =
to
> send the message it is probably related to how the server implements =
FIX
> and not to Quickfix itself. In this case, you should check the rules =
of
> engagement from the server.
>=20
> Cheers,
>=20
> Bruno
>=20
> -----Original Message-----
> From: qui...@li... [mailto:quickfixj-
> use...@li...] On Behalf Of John Coleman
> Sent: Wednesday, October 03, 2007 10:52 AM
> To: qui...@li...
> Subject: [Quickfixj-users] tag1
> Importance: High
>=20
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> Hi,
>=20
> I'm supplying a tag 1 value on a quote request, but the Quickfix =
engine
> seems to not like this, and responds:-
>=20
> fromAdmin:  message:
> =
8=3DFIX.4.4?9=3D138?35=3D3?34=3D22?49=3DFxFIXService?52=3D20071003-08:42:=
32.2
> 77?56=3Dtestinitiator1?45=3D22?58=3DTag not defined for this message
> type?371=3D1?372=3DR?373=3D2?10=3D235?
>=20
> According to FIXionary we can have tag 1 optionally for a 35=3DR, so =
why do
> we get a rejection?
>=20
> TIA
> John
>=20
> Eurobase International Limited and its subsidiaries (Eurobase) are =
unable
> to exercise control over the content of information in E-Mails. Any =
views
> and opinions expressed may be personal to the sender and are not
> necessarily those of Eurobase. Eurobase will not enter into any
> contractual obligations in respect of any part of its business in any =
E-
> mail.
>=20
> Privileged / confidential information may be contained in this message =
and
> /or any attachments. This E-mail is intended for the use of the
> addressee(s) only and may contain confidential information. If you are =
not
> the / an intended recipient, you are hereby notified that any use or
> dissemination of this communication is strictly prohibited.  If you
> receive this transmission in error, please notify us immediately, and =
then
> delete this E-mail.
>=20
> Neither the sender nor Eurobase accepts any liability whatsoever for =
any
> defects of any kind either in or arising from this E-mail =
transmission. E-
> Mail transmission cannot be guaranteed to be secure or error-free, as
> messages can be intercepted, lost, corrupted, destroyed, contain =
viruses,
> or arrive late or incomplete. Eurobase does not accept any =
responsibility
> for viruses and it is your responsibility to scan any attachments.
>=20
> Eurobase Systems Limited is the main trading company in the Eurobase
> International Group; registered in England and Wales as company number
> 02251162; registered address: Essex House, 2 County Place, Chelmsford,
> Essex CM2 0RE, UK.
>=20
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>=20
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Re: [Quickfixj-users] tag1

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

SGksDQoNCldlIHVzZSBRdWlja2ZpeCBhdCBib3RoIHNpZGVzLg0KDQpJIGhhdmUgbm93IG1vdmVk
IHRoZSB0YWcgMSBlbGVtZW50IHRvIHRoZSBlbmQgb2YgdGhlIG1lc3NhZ2UgYW5kIGl0IGlzIG5v
dyBhY2NlcHRlZCBvbiB0aGUgc2VydmVyIC0gSSBkaWRuJ3QgdGhpbmsgb3JkZXJpbmcgaW4gdGhl
IG1lc3NhZ2UgYm9keSB3YXMgc2lnbmlmaWNhbnQsIGJ1dCBpdCBhcHBlYXJzIHNvPw0KDQpCdXQg
dGhlIHByb2JsZW1zIGdvZXMgb24uIFdoZW4gSSB0cnkgdG8gcmV0cmlldmUgdGhlIGFjY291bnQg
ZnJvbSB0aGUgbWVzc2FnZSwgaXQgdGhyb3dzIGZpZWxkIG5vdCBmb3VuZC4NCg0KTXkgY29kZSBp
czogcXVvdGVSZXF1ZXN0LmdldFN0cmluZyhBY2NvdW50LkZJRUxEKQ0KDQpUaGUgcXVvdGUgcmVx
dWVzdCBpczogOD1GSVguNC40ATk9MTkxATM1PVIBMzQ9MjI5ATQ5PXRlc3Rpbml0aWF0b3IxATUy
PTIwMDcxMDAzLTEwOjIxOjEzLjkzMgE1Nj1GeEZJWFNlcnZpY2UBMTMxPVNJTVJGUTAwMDQ0NzAy
ATE0Nj0xATU1PUVVUi9VU0QBNDYxPVJDU1hYWAE4MDMwMz0xATUzNz0xATU0PTEBMzg9MTAwMDAw
ATYzPTABNjQ9MjAwNzA5MjYBMTU9RVVSATE9dGVzdGluaXRpYXRvcjEBMTA9MDc1AQ0KDQpJdCdz
IGxpa2UgUUZKIGNhbid0IHNlZSB3aGF0IGlzIGluIHRoZSBtZXNzYWdlPw0KDQpUSUENCkpvaG4N
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHF1aWNrZml4ai11c2Vycy1ib3Vu
Y2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnF1aWNrZml4ai11c2Vycy1ib3VuY2Vz
QGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIEJydW5vDQpTZW50OiAwMyBPY3Rv
YmVyIDIwMDcgMTA6MTMNClRvOiBxdWlja2ZpeGotdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0
DQpTdWJqZWN0OiBSZTogW1F1aWNrZml4ai11c2Vyc10gdGFnMQ0KDQpRdWlja0ZJWC9KIERvY3Vt
ZW50YXRpb246IGh0dHA6Ly93d3cucXVpY2tmaXhqLm9yZy9kb2N1bWVudGF0aW9uLw0KUXVpY2tG
SVgvSiBTdXBwb3J0OiBodHRwOi8vd3d3LnF1aWNrZml4ai5vcmcvc3VwcG9ydC8NCg0KSGkgSm9o
biwNCg0KQXJlIHlvdSB1c2luZyBRdWlja2ZpeCB0byBzZW5kIHRoZSBtZXNzYWdlIG9yIHRoZSBz
ZXJ2ZXIgdXNlcyBRdWlja2ZpeD8gDQoNClRoaXMgaXMgYSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2
ZXIsIHNvIGluIGNhc2UgeW91IGFyZSB1c2luZyBRdWlja2ZpeCB0byBzZW5kIHRoZSBtZXNzYWdl
IGl0IGlzIHByb2JhYmx5IHJlbGF0ZWQgdG8gaG93IHRoZSBzZXJ2ZXIgaW1wbGVtZW50cyBGSVgg
YW5kIG5vdCB0byBRdWlja2ZpeCBpdHNlbGYuIEluIHRoaXMgY2FzZSwgeW91IHNob3VsZCBjaGVj
ayB0aGUgcnVsZXMgb2YgZW5nYWdlbWVudCBmcm9tIHRoZSBzZXJ2ZXIuDQoNCkNoZWVycywNCg0K
QnJ1bm8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHF1aWNrZml4ai11c2Vy
cy1ib3VuY2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCBbbWFpbHRvOnF1aWNrZml4ai11c2Vycy1i
b3VuY2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIEpvaG4gQ29sZW1hbg0K
U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAzLCAyMDA3IDEwOjUyIEFNDQpUbzogcXVpY2tmaXhq
LXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KU3ViamVjdDogW1F1aWNrZml4ai11c2Vyc10g
dGFnMQ0KSW1wb3J0YW5jZTogSGlnaA0KDQpRdWlja0ZJWC9KIERvY3VtZW50YXRpb246IGh0dHA6
Ly93d3cucXVpY2tmaXhqLm9yZy9kb2N1bWVudGF0aW9uLw0KUXVpY2tGSVgvSiBTdXBwb3J0OiBo
dHRwOi8vd3d3LnF1aWNrZml4ai5vcmcvc3VwcG9ydC8NCkhpLA0KDQpJJ20gc3VwcGx5aW5nIGEg
dGFnIDEgdmFsdWUgb24gYSBxdW90ZSByZXF1ZXN0LCBidXQgdGhlIFF1aWNrZml4IGVuZ2luZSBz
ZWVtcyB0byBub3QgbGlrZSB0aGlzLCBhbmQgcmVzcG9uZHM6LQ0KDQpmcm9tQWRtaW46ICBtZXNz
YWdlOiA4PUZJWC40LjTimLo5PTEzOOKYujM1PTPimLozND0yMuKYujQ5PUZ4RklYU2VydmljZeKY
ujUyPTIwMDcxMDAzLTA4OjQyOjMyLjINCjc34pi6NTY9dGVzdGluaXRpYXRvcjHimLo0NT0yMuKY
ujU4PVRhZyBub3QgZGVmaW5lZCBmb3IgdGhpcyBtZXNzYWdlIHR5cGXimLozNzE9MeKYujM3Mj1S
4pi6MzczPTLimLoxMD0yMzXimLoNCg0KQWNjb3JkaW5nIHRvIEZJWGlvbmFyeSB3ZSBjYW4gaGF2
ZSB0YWcgMSBvcHRpb25hbGx5IGZvciBhIDM1PVIsIHNvIHdoeSBkbyB3ZSBnZXQgYSByZWplY3Rp
b24/DQoNClRJQQ0KSm9obg0KDQpFdXJvYmFzZSBJbnRlcm5hdGlvbmFsIExpbWl0ZWQgYW5kIGl0
cyBzdWJzaWRpYXJpZXMgKEV1cm9iYXNlKSBhcmUgdW5hYmxlIHRvIGV4ZXJjaXNlIGNvbnRyb2wg
b3ZlciB0aGUgY29udGVudCBvZiBpbmZvcm1hdGlvbiBpbiBFLU1haWxzLiBBbnkgdmlld3MgYW5k
IG9waW5pb25zIGV4cHJlc3NlZCBtYXkgYmUgcGVyc29uYWwgdG8gdGhlIHNlbmRlciBhbmQgYXJl
IG5vdCBuZWNlc3NhcmlseSB0aG9zZSBvZiBFdXJvYmFzZS4gRXVyb2Jhc2Ugd2lsbCBub3QgZW50
ZXIgaW50byBhbnkgY29udHJhY3R1YWwgb2JsaWdhdGlvbnMgaW4gcmVzcGVjdCBvZiBhbnkgcGFy
dCBvZiBpdHMgYnVzaW5lc3MgaW4gYW55IEUtbWFpbC4gDQoNClByaXZpbGVnZWQgLyBjb25maWRl
bnRpYWwgaW5mb3JtYXRpb24gbWF5IGJlIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3NhZ2UgYW5kIC9v
ciBhbnkgYXR0YWNobWVudHMuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIGZvciB0aGUgdXNlIG9m
IHRoZSBhZGRyZXNzZWUocykgb25seSBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9y
bWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgLyBhbiBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBh
cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSBvciBkaXNzZW1pbmF0aW9uIG9mIHRoaXMg
Y29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IHJlY2VpdmUgdGhp
cyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHksIGFu
ZCB0aGVuIGRlbGV0ZSB0aGlzIEUtbWFpbC4gDQoNCk5laXRoZXIgdGhlIHNlbmRlciBub3IgRXVy
b2Jhc2UgYWNjZXB0cyBhbnkgbGlhYmlsaXR5IHdoYXRzb2V2ZXIgZm9yIGFueSBkZWZlY3RzIG9m
IGFueSBraW5kIGVpdGhlciBpbiBvciBhcmlzaW5nIGZyb20gdGhpcyBFLW1haWwgdHJhbnNtaXNz
aW9uLiBFLU1haWwgdHJhbnNtaXNzaW9uIGNhbm5vdCBiZSBndWFyYW50ZWVkIHRvIGJlIHNlY3Vy
ZSBvciBlcnJvci1mcmVlLCBhcyBtZXNzYWdlcyBjYW4gYmUgaW50ZXJjZXB0ZWQsIGxvc3QsIGNv
cnJ1cHRlZCwgZGVzdHJveWVkLCBjb250YWluIHZpcnVzZXMsIG9yIGFycml2ZSBsYXRlIG9yIGlu
Y29tcGxldGUuIEV1cm9iYXNlIGRvZXMgbm90IGFjY2VwdCBhbnkgcmVzcG9uc2liaWxpdHkgZm9y
IHZpcnVzZXMgYW5kIGl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gc2NhbiBhbnkgYXR0YWNo
bWVudHMuDQoNCkV1cm9iYXNlIFN5c3RlbXMgTGltaXRlZCBpcyB0aGUgbWFpbiB0cmFkaW5nIGNv
bXBhbnkgaW4gdGhlIEV1cm9iYXNlIEludGVybmF0aW9uYWwgR3JvdXA7IHJlZ2lzdGVyZWQgaW4g
RW5nbGFuZCBhbmQgV2FsZXMgYXMgY29tcGFueSBudW1iZXIgMDIyNTExNjI7IHJlZ2lzdGVyZWQg
YWRkcmVzczogRXNzZXggSG91c2UsIDIgQ291bnR5IFBsYWNlLCBDaGVsbXNmb3JkLCBFc3NleCBD
TTIgMFJFLCBVSy4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIFNGLm5ldCBlbWFpbCBpcyBz
cG9uc29yZWQgYnk6IE1pY3Jvc29mdA0KRGVmeSBhbGwgY2hhbGxlbmdlcy4gTWljcm9zb2Z0KFIp
IFZpc3VhbCBTdHVkaW8gMjAwNS4NCmh0dHA6Ly9jbGsuYXRkbXQuY29tL01SVC9nby92c2UwMTIw
MDAwMDcwbXJ0L2RpcmVjdC8wMS8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpRdWlja2ZpeGotdXNlcnMgbWFpbGluZyBsaXN0DQpRdWlja2ZpeGotdXNl
cnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s
aXN0cy9saXN0aW5mby9xdWlja2ZpeGotdXNlcnMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlz
IFNGLm5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnk6IE1pY3Jvc29mdA0KRGVmeSBhbGwgY2hhbGxl
bmdlcy4gTWljcm9zb2Z0KFIpIFZpc3VhbCBTdHVkaW8gMjAwNS4NCmh0dHA6Ly9jbGsuYXRkbXQu
Y29tL01SVC9nby92c2UwMTIwMDAwMDcwbXJ0L2RpcmVjdC8wMS8NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpRdWlja2ZpeGotdXNlcnMgbWFpbGluZyBs
aXN0DQpRdWlja2ZpeGotdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0DQpodHRwczovL2xpc3Rz
LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9xdWlja2ZpeGotdXNlcnMNCg==

Re: [Quickfixj-users] tag1

[Bruno <bru...@jd...>]

Hi John,

Are you using Quickfix to send the message or the server uses Quickfix?=20

This is a response from the server, so in case you are using Quickfix to =
send the message it is probably related to how the server implements FIX =
and not to Quickfix itself. In this case, you should check the rules of =
engagement from the server.

Cheers,

Bruno

-----Original Message-----
From: qui...@li... =
[mailto:qui...@li...] On Behalf Of John =
Coleman
Sent: Wednesday, October 03, 2007 10:52 AM
To: qui...@li...
Subject: [Quickfixj-users] tag1
Importance: High

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

I'm supplying a tag 1 value on a quote request, but the Quickfix engine =
seems to not like this, and responds:-

fromAdmin:  message: =
8=3DFIX.4.4=E2=98=BA9=3D138=E2=98=BA35=3D3=E2=98=BA34=3D22=E2=98=BA49=3DF=
xFIXService=E2=98=BA52=3D20071003-08:42:32.2
77=E2=98=BA56=3Dtestinitiator1=E2=98=BA45=3D22=E2=98=BA58=3DTag not =
defined for this message =
type=E2=98=BA371=3D1=E2=98=BA372=3DR=E2=98=BA373=3D2=E2=98=BA10=3D235=E2=98=
=BA

According to FIXionary we can have tag 1 optionally for a 35=3DR, so why =
do we get a rejection?

TIA
John

Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20

Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited.  If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20

Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase =
International Group; registered in England and Wales as company number =
02251162; registered address: Essex House, 2 County Place, Chelmsford, =
Essex CM2 0RE, UK.


-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

[Quickfixj-users] tag1

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

Hi,

I'm supplying a tag 1 value on a quote request, but the Quickfix engine =
seems to not like this, and responds:-

fromAdmin:  message: =
8=3DFIX.4.4=E2=98=BA9=3D138=E2=98=BA35=3D3=E2=98=BA34=3D22=E2=98=BA49=3DF=
xFIXService=E2=98=BA52=3D20071003-08:42:32.2
77=E2=98=BA56=3Dtestinitiator1=E2=98=BA45=3D22=E2=98=BA58=3DTag not =
defined for this message =
type=E2=98=BA371=3D1=E2=98=BA372=3DR=E2=98=BA373=3D2=E2=98=BA10=3D235=E2=98=
=BA

According to FIXionary we can have tag 1 optionally for a 35=3DR, so why =
do we get a rejection?

TIA
John

Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20

Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited.  If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20

Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase =
International Group; registered in England and Wales as company number =
02251162; registered address: Essex House, 2 County Place, Chelmsford, =
Essex CM2 0RE, UK.

Re: [Quickfixj-users] neater getField?

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

John,

You can try using a getString(field) instead:
         holder.setAccount(new Account(quoteRequest.getString(Account.FIELD)));

This way is a little cleaner

On 10/2/07, John Coleman <joh...@eu...> wrote:
> QuickFIX/J Documentation:
> In my application I receive a message. The getAccount method does not exist
> for this message so I am using getField and then want to do a
> setAccount(Account a) method on my own value object class.
>
>
>
>             holder.setAccount(new Account(quoteRequest.getField(new
> Account()).getValue()));
>
-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

[Quickfixj-users] neater getField?

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

In my application I receive a message. The getAccount method does not
exist for this message so I am using getField and then want to do a
setAccount(Account a) method on my own value object class.

=20

            holder.setAccount(new Account(quoteRequest.getField(new
Account()).getValue()));

=20

I have coded the above, but this seems very cumbersome - any neat tips
please?

=20

Regards,

John

=20


Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20

Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited.  If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20

Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.

Eurobase Systems Limited is the main trading company in the Eurobase =
International Group; registered in England and Wales as company number =
02251162; registered address: Essex House, 2 County Place, Chelmsford, =
Essex CM2 0RE, UK.

Re: [Quickfixj-users] 100% Java vs the QuickFIX C++ JNI Wrapper

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

Ted,

the Quickfix/J itself is 100% Java. There's a separate C++ project that's
also an implementation of FIX called QuickFIX (
http://www.quickfixengine.org/) which is the original open-source FIX
implementation. It has a JNI wrapper, and QFJ is compatible with that.  It
is meant as a way for people to transition from their existing QuickFIX JNI
implementations.

The QuickFIX project was the initial "inspiration" for QFJ, but QFJ has
obviously been written in Java from scratch.

so if you are writing Java code, then just use QFJ directly.

On 9/28/07, Ted Graham <tg...@co...> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
> I'm confused about something on the main website.   It says that
> QuickFIX/J
> is 100% Java, but it also talks about "Compatibility with QuickFIX C++
> Java
> Native Wrapper API".  The section on QuickFIXJ logging says, "QuickFIX/J
> is
> based on the QuickFIX C++ JNI API"
>
> What does the JNI API provide, and when should I use it?
>
> Any explanation or pointers to resources appreciated.
>
> Thanks,
> Ted
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>



-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

[Quickfixj-users] 100% Java vs the QuickFIX C++ JNI Wrapper

[Ted G. <tg...@Co...>]

I'm confused about something on the main website.   It says that QuickFIX/J
is 100% Java, but it also talks about "Compatibility with QuickFIX C++ Java
Native Wrapper API".  The section on QuickFIXJ logging says, "QuickFIX/J is
based on the QuickFIX C++ JNI API"

What does the JNI API provide, and when should I use it?

Any explanation or pointers to resources appreciated.

Thanks,
Ted

Re: [Quickfixj-users] Banzai example question?

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

Hi Mike,

 

I haven't seen this on Windows XP or Solaris. I don't have access to a
Windows 2000 computer. It appears to be

a low level networking issue (below the MINA layer), but I don't have any
idea what would cause it. It might be

helpful to search the MINA archives to see if anyone else has reported a
similar problem.

 

Regards,

 

Steve

 

  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of
guhaiquan
Sent: Thursday, September 27, 2007 2:33 AM
To: qui...@li...
Subject: [Quickfixj-users] Banzai example question?

 

hi, all


 


When I run the Banzai examples, I find a phenomena: If I just start the
Banzai,not run the Executor. I got the following output in the console: it
seems an Iosession is built without the Executor. My environment is Windows
2000, eclipse 3.2. JDK1.5. Any one have any ideas?


Thanks a lot.


 


Regards,


Mike


The part output in the console:


<20070917-07:08:26, FIX.4.2:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:27, FIX.4.3:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:28, FIX.4.1:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:29, FIX.4.4:BANZAI->EXEC, event> (Connection refused: no
further information)


2007-9-17 15:08:30 quickfix.mina.initiator.InitiatorIoHandler sessionCreated


info: MINA session created: null


<20070917-07:08:30, FIX.4.0:BANZAI->EXEC, out
 going>
(8=FIX.4.09=6135=A34=149=BANZAI52=20070917-07:08:3056=EXEC98=0108=3010=017)


<20070917-07:08:30, FIX.4.0:BANZAI->EXEC, event> (Initiated logon request)


2007-9-17 15:08:30 org.apache.mina.common.support.DefaultExceptionMonitor
exceptionCaught


warning: Unexpected exception.


java.nio.channels.NotYetConnectedException


       at
sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:129)


       at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:294)


       at
org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProce
ssor.java:477)


       at
org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProce
ssor.java:409)


       at
org.apache.mina.transport.socket.nio.SocketIoProcessor.access$600(SocketIoPr
ocessor.java:44)


       at
org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoPr
ocessor.java:562)


       at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:
43)
 


       at java.lang.Thread.run(Thread.java:595)


<20070917-07:08:31, FIX.4.2:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:33, FIX.4.3:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:34, FIX.4.1:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:35, FIX.4.4:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:37, FIX.4.2:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:38, FIX.4.3:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:39, FIX.4.1:BANZAI->EXEC, event> (Connection refused: no
further information)


<20070917-07:08:40, FIX.4.4:BANZAI->EXEC, event> (Connection refused: no
further information)

 

  _____  

J9SCPBR;4z Hotmail#,8|G?4s!"8|02H+!"8|6`4f4"?U
<http://www.hot%0d%0a%20mail.com> A"?LLeQi#!

Re: [Quickfixj-users] acceptor restart issue

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

Hi Robert,

 

I don't have any ideas why this would be happening. I have heard any reports
of it from other users.

If you find more information, please let me know.

 

Regards,

 

Steve

 

  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of Robert
Brueckmann
Sent: Thursday, September 27, 2007 8:40 AM
To: qui...@li...
Subject: [Quickfixj-users] acceptor restart issue

 

We're noticing a pretty regular issue with one of our vendors who require us
to be an acceptor for their message flow:  If we fire up the
acceptor...their first attempt to connect to us results is our acceptor
sending them a logout message.  Their second attempt succeeds and message
flow commences...if we leave this instance up and running for any length of
time, the session ends at 8 pm, logs out and then the session starts up
again the next day at 7:30 am without a hitch on either end.  

 

If for some reason after 8 pm, whether it be database or log maintenance or
something and the DBA has to stop the acceptor instance (last night he shut
it down at 1:35 am as shown below), the log shows the following:

 

----

 

2007-09-26 20:05:05,062 DEBUG [QF/J Session dispatcher: FIX.4.2:US->THEM]
fix.Application (?:?) - logging off...

 

Terminated by runtime system.  Shutting down FIX server.

 

Sep 27, 2007 1:35:37 AM quickfix.mina.acceptor.AbstractSocketAcceptor
stopAcceptingConnections

 

INFO: No longer accepting connections on /x.x.x.x:4321

 

Sep 27, 2007 1:35:37 AM quickfix.mina.SessionConnector logoutAllSessions

 

INFO: Logging out all sessions

 

 

Re: [Quickfixj-users] Difference in TransactionTime format between new and older version of QFJ

[Serg V. G. <ri...@ze...>]

Hello!

Small correction:

UtcTimeStampField timeF =3D new UtcTimeStampField(TransactTime.FIELD,
false);
java.util.Date date =3D dateFormat.parse("2007/10/10 12:15:33");
timeF.setValue(date);
OrderCancelRequest req =3D new OrderCancelRequest();
req.setField(timeF);

But your idea help a lot, thanks!


=D0=92 =D0=A7=D1=82=D0=B2, 27/09/2007 =D0=B2 04:48 -0700, Toli Kuznets =D0=
=BF=D0=B8=D1=88=D0=B5=D1=82:

> Serg,=20
>=20
> I think what you are seeing are the effects of fixing bug QFJ-146
> (http://www.quickfixj.org/jira/browse/QFJ-146), where the milliseconds
> in UtcTimeStampField and its subclasses where not being preserved.=20
>=20
> You can go back to ignoring milliseconds with by creating a
> UtcTimeStampeField explicitly:
>=20
> Field time =3D new UtcTimeStampField(TransactTime.FIELD, false);
>          java.util.Date date =3D dateFormat.parse("2007/10/10
> 12:15:33");
>          time.setValue(date);
>          OrderCancelRequest req =3D new OrderCancelRequest();
>          req.set(time);
>=20
> that should revert to the old behaviour
>=20
>=20
>=20
> On 9/27/07, Serg V. Gulko <ri...@ze...> wrote:
>=20
>         QuickFIX/J Documentation:
>         http://www.quickfixj.org/documentation/
>         QuickFIX/J Support: http://www.quickfixj.org/support/
>        =20
>        =20
>        =20
>        =20
>         Hello!
>        =20
>         >From the beginning we are used version of 1.1.0 of QFJ, few
>         monthes ago I have decided to try 1.2.1.
>         Look in the source code:
>        =20
>                 SimpleDateFormat dateFormat =3D new
>         SimpleDateFormat("yyyy/MM/dd k:mm:ss");
>                 TransactTime time =3D new TransactTime();
>                  java.util.Date date =3D dateFormat.parse("2007/10/10
>         12:15:33");
>                  time.setValue(date);
>                  OrderCancelRequest req =3D new OrderCancelRequest();
>                  req.set(time);
>        =20
>                  System.out.println("CancelRequest: "+req.toXML());
>        =20
>         Lib 1.2.1 give me
>        =20
>         <message>
>         <header>
>         <field tag=3D"8"><![CDATA[FIX.4.2]]></field>
>         <field tag=3D"35"><![CDATA[F]]></field>
>         </header>
>         <body>
>         <field tag=3D"60"><![CDATA[20071010-09:15:33.000]]></field>
>         </body>
>         <trailer/>
>         </message>
>        =20
>         1.1.0
>        =20
>         <message>
>         <header>
>         <field number=3D"8"><![CDATA[FIX.4.2]]></field>
>         <field number=3D"35"><![CDATA[F]]></field>
>         </header>
>         <body>
>         <field number=3D"60"><![CDATA[20071010-09:15:33]]></field>
>         </body>
>         <trailer/>
>         </message>
>        =20
>         This .000 are demaged all my communications with exchanger.
>         How I can remove it and use old TT format wihtout zeros?
>        =20
>         Serg Gulko
>        =20
>        =20
>        =20
>        =20
>        =20
>         -----------------------------------------------------------------=
--------
>         This SF.net email is sponsored by: Microsoft
>         Defy all challenges. Microsoft(R) Visual Studio 2005.
>         http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>         _______________________________________________
>         Quickfixj-users mailing list
>         Qui...@li...
>         https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>        =20
>=20
>=20
>=20
>=20
> --=20
> Toli Kuznets
> http://www.marketcetera.com: Open-Source Trading Platform
> download.run.trade.

[Quickfixj-users] acceptor restart issue

[Robert B. <rbr...@me...>]

We're noticing a pretty regular issue with one of our vendors who
require us to be an acceptor for their message flow:  If we fire up the
acceptor...their first attempt to connect to us results is our acceptor
sending them a logout message.  Their second attempt succeeds and
message flow commences...if we leave this instance up and running for
any length of time, the session ends at 8 pm, logs out and then the
session starts up again the next day at 7:30 am without a hitch on
either end.=20=20

=20

If for some reason after 8 pm, whether it be database or log maintenance
or something and the DBA has to stop the acceptor instance (last night
he shut it down at 1:35 am as shown below), the log shows the following:

=20

----

=20

2007-09-26 20:05:05,062 DEBUG [QF/J Session dispatcher:
FIX.4.2:US->THEM] fix.Application (?:?) - logging off...

=20

Terminated by runtime system.  Shutting down FIX server.

=20

Sep 27, 2007 1:35:37 AM quickfix.mina.acceptor.AbstractSocketAcceptor
stopAcceptingConnections

=20

INFO: No longer accepting connections on /x.x.x.x:4321

=20

Sep 27, 2007 1:35:37 AM quickfix.mina.SessionConnector logoutAllSessions

=20

INFO: Logging out all sessions

=20

----

=20

So by all appearances, we're validly logging out with the vendor at 8 pm
and then I have a shutdown hook that captures any os-level process
termination that in turn double-checks and validly logs out of all
sessions still active before completely killing the process.

=20

We fired it back up at 4:35 am this morning...and 7:30 am rolls
around...the log shows the following:

=20

----

=20

Sep 27, 2007 4:28:39 AM quickfix.mina.acceptor.AbstractSocketAcceptor
startAcceptingConnections

=20

INFO: Listening for connections at /x.x.x.x:4321

=20

Sep 27, 2007 7:30:05 AM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated

=20

INFO: MINA session created: /x.x.x.x:15071

=20

Sep 27, 2007 7:30:15 AM quickfix.mina.acceptor.AcceptorIoHandler
sessionCreated

=20

INFO: MINA session created: /x.x.x.x:15071

=20

2007-09-27 07:30:20,042 DEBUG [SocketAcceptorIoProcessor-0.0]
fix.Application (?:?) - logging off...

=20

----

=20

It almost looks like they try to connect twice in a row at 7:30:05 and
7:30:15 but regardless of how many times they attempt to connect, it
always results in us logging off and sending them a logout message in
response to the login message they send to us.

=20

But like I said, if we hadn't restarted the instance, and just left it
up and running, when they attempt to establish the session the next day,
there are no problems at all.

=20

Does anyone see anything by looking at these bare-bones log messages?
Does anyone have any ideas what could be causing this ONLY when we
restart the instance?  I mean it's not the end of the world since I send
the vendor an email and they attempt to reconnect again and the message
flow starts up again...but I would like not to have to involve anyone
and be able to gracefully restart the acceptor without impacting the
production system at all.

=20

Any help would be greatly appreciated.

=20

Thanks,

Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single S=
trategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007


=20

--------------------------------------------------------

This message contains information from Merlin Securities, LLC, or from one =
of its affiliates, that may be confidential and privileged. If you are not =
an intended recipient, please refrain from any disclosure, copying, distrib=
ution or use of this information and note that such actions are prohibited.=
 If you have received this transmission in error, please notify the sender =
immediately by telephone or by replying to this transmission.
=20
Merlin Securities, LLC is a registered broker-dealer. Services offered thro=
ugh Merlin Securities, LLC are not insured by the FDIC or any other Federal=
 Government Agency, are not deposits of or guaranteed by Merlin Securities,=
 LLC and may lose value. Nothing in this communication shall constitute a s=
olicitation or recommendation to buy or sell a particular security.

Re: [Quickfixj-users] Difference in TransactionTime format between new and older version of QFJ

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

Serg,

I think what you are seeing are the effects of fixing bug QFJ-146 (
http://www.quickfixj.org/jira/browse/QFJ-146), where the milliseconds in
UtcTimeStampField and its subclasses where not being preserved.

You can go back to ignoring milliseconds with by creating a
UtcTimeStampeField explicitly:

Field time = new UtcTimeStampField(TransactTime.FIELD, false);
         java.util.Date date = dateFormat.parse("2007/10/10 12:15:33");
         time.setValue(date);
         OrderCancelRequest req = new OrderCancelRequest();
         req.set(time);

that should revert to the old behaviour


On 9/27/07, Serg V. Gulko <ri...@ze...> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>  Hello!
>
> >From the beginning we are used version of 1.1.0 of QFJ, few monthes ago I
> have decided to try 1.2.1.
> Look in the source code:
>
>         SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd
> k:mm:ss");
>         TransactTime time = new TransactTime();
>          java.util.Date date = dateFormat.parse("2007/10/10 12:15:33");
>          time.setValue(date);
>          OrderCancelRequest req = new OrderCancelRequest();
>          req.set(time);
>
>          System.out.println("CancelRequest: "+req.toXML());
>
> Lib 1.2.1 give me
>
> <message>
> <header>
> <field tag="8"><![CDATA[FIX.4.2]]></field>
> <field tag="35"><![CDATA[F]]></field>
> </header>
> <body>
> <field tag="60"><![CDATA[20071010-09:15:33*.000*]]></field>
> </body>
> <trailer/>
> </message>
>
> 1.1.0
>
> <message>
> <header>
> <field number="8"><![CDATA[FIX.4.2]]></field>
> <field number="35"><![CDATA[F]]></field>
> </header>
> <body>
> <field number="60"><![CDATA[20071010-09:15:33]]></field>
> </body>
> <trailer/>
> </message>
>
> This .000 are demaged all my communications with exchanger. How I can
> remove it and use old TT format wihtout zeros?
>
> Serg Gulko
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>


-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.