Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Serg V. G. <ri...@ze...> - 2007-09-27 10:55:29
|
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
|
|
From: <ily...@bn...> - 2007-09-27 07:08:52
|
Je serai absent(e) =E0 partir du 09/27/2007 de retour le 09/28/2007.
Je r=E9pondrai =E0 votre message d=E8s mon retour.
I'll be out of office from September 27th till September 28th. I'll reply
to your email as soon as I get back. In the meantime, you can contact
Damien Delvall=E9e (dam...@bn...) or
FIB...@bn....
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.=20
If you receive this message in error, please delete it and=20
immediately notify the sender. Any use not in accord with=20
its purpose, any dissemination or disclosure, either whole=20
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.=20
BNP PARIBAS (and its subsidiaries) shall (will) not=20
therefore be liable for the message if modified.=20
---------------------------------------------
Ce message et toutes les pieces jointes (ci-apres le=20
"message") sont etablis a l'intention exclusive de ses=20
destinataires et sont confidentiels. Si vous recevez ce=20
message par erreur, merci de le detruire et d'en avertir=20
immediatement l'expediteur. Toute utilisation de ce=20
message non conforme a sa destination, toute diffusion=20
ou toute publication, totale ou partielle, est interdite, sauf=20
autorisation expresse. L'internet ne permettant pas=20
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce=20
message, dans l'hypothese ou il aurait ete modifie.
|
|
From: guhaiquan <hai...@ho...> - 2007-09-27 06:32:54
|
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,MikeThe 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 sessionCreatedinfo: MINA session created: null<20070917-07:08:30, FIX.4.0:BANZAI->EXEC, outgoing> (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 exceptionCaughtwarning: 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(SocketIoProcessor.java:477) at org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:409) at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$600(SocketIoProcessor.java:44) at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.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) _________________________________________________________________ 用 Live Search 搜尽天下资讯！ http://www.live.com/?searchOnly=true |
|
From: Toli K. <to...@ma...> - 2007-09-24 18:20:35
|
UWkgQ2FpLAoKSSdtIG5vdCBzdXJlIGkgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIGNvbXBsZXRl bHksIGJ1dCBsZXQgbWUgdHJ5IHRvCnNoZWQgc29tZSBsaWdodCBvbiBncm91cHMuCklmIHlvdSBh cmUganVzdCByZWFkaW5nIGdyb3VwcyBmcm9tIGluY29taW5nIG1lc3NhZ2UsIHlvdSBjYW4gdXNl Cmdyb3VwID0gbmV3IEdyb3VwKGdyb3VwQ291bmRGaWVsZCwgMCksIGFuZCB0aGVuIHVzZQptc2cu Z2V0R3JvdXAoZ3JvdXAsIGluZGV4KSB0byByZXRyaWV2ZSBhIHBhcnRpY3VsYXIgZ3JvdXAuCgpJ ZiB5b3UgbmVlZCB0byBjcmVhdGUgYSBncm91cCBmcm9tIHNjcmF0Y2ggKHdpdGhvdXQgcmVhZGlu ZyBpdCBmcm9tCmluY29taW5nIG1lc3NhZ2UpLCB5b3UgY2FuIGRvIHRoaXMgKHNlZSBNZXNzYWdl VGVzdC5qYXZhIGZvciBleGFtbGVzKToKR3JvdXAgcGFydHlHcm91cCA9IG5ldyBHcm91cChxdWlj a2ZpeC5maWVsZC5Ob1BhcnR5SURzLkZJRUxELCBQYXJ0eUlELkZJRUxEKTsKCnRoYXQgb25seSBn aXZlcyB5b3UgYSByZWd1bGFyIEdyb3VwIGFuZCBub3QgdmVyc2lvbi1zcGVjaWZpYyBncm91cC4K ClRoZSBiZXN0IHdheSBpcyB0byB1c2UgTWVzc2FnZUZhY3RvcnkgdG8gY3JlYXRlIG5ldyBncm91 cHMuIFNlZQpEZWZhdWx0TWVzc2FnZUZhY3RvcnlUZXN0LmphdmEgZm9yIGV4YW1wbGVzOgogICAg ICAgIGFzc2VydEVxdWFscyhxdWlja2ZpeC5maXg0MC5OZXdzLkxpbmVzT2ZUZXh0LmNsYXNzLApm YWN0b3J5LmNyZWF0ZSgiRklYLjQuMCIsIE1zZ1R5cGUuTkVXUywKTGluZXNPZlRleHQuRklFTEQp LmdldENsYXNzKCkpOwoKaWYgeW91IG5lZWQgbW9yZSByZWFsLXdvcmxkIGV4YW1wbGVzLCB5b3Ug YXJlIHdlbGNvbWUgdG8gbG9vayBhdCBob3cKd2UgdXNlIGdyb3VwIGNyZWF0aW9uIGluIHRoZSBN YXJrZXRjZXRlcmEgUGxhdGZvcm06CiAgICAgICAgICAgIEdyb3VwIHN5bWJvbEdyb3VwID0KbXNn RmFjdG9yeS5jcmVhdGVHcm91cChNc2dUeXBlLk1BUktFVF9EQVRBX1JFUVVFU1QsCk5vUmVsYXRl ZFN5bS5GSUVMRCk7CldlIHVzZSBhIHdyYXBwZXIgdGhhdCBzZW5kcyB0aGUgQmVnaW5TdHJpbmcg aW4sIGJ1dCBvdGhlcndpc2UgaXQncyB0aGUKc2FtZSBjb2RlOgpodHRwOi8vdHJhYy5tYXJrZXRj ZXRlcmEub3JnL3RyYWMuZmNnaS9icm93c2VyL3BsYXRmb3JtL3RydW5rL2NvcmUvc3JjL3Rlc3Qv amF2YS9vcmcvbWFya2V0Y2V0ZXJhL3F1aWNrZml4L0ZJWE1lc3NhZ2VVdGlsVGVzdC5qYXZhI0wz ODEKCmhvcGUgdGhpcyBoZWxwcy4KCgpPbiA5LzI0LzA3LCBDYWlRaSA8Y2FpcWkwNDIxQGhvdG1h aWwuY29tPiB3cm90ZToKPiBRdWlja0ZJWC9KIERvY3VtZW50YXRpb246Cj4gaHR0cDovL3d3dy5x dWlja2ZpeGoub3JnL2RvY3VtZW50YXRpb24vCj4gUXVpY2tGSVgvSiBTdXBwb3J0OiBodHRwOi8v d3d3LnF1aWNrZml4ai5vcmcvc3VwcG9ydC8KPgo+Cj4gSGVsbG8sIHN0ZXZlLAo+Cj4gIFRoYW5r IHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgYW5zd2VyIQo+Cj4gIEJ1dCBJIHN0aWxsIGRvbid0IGtu b3c6IHdoeSBhbmQgd2hlbiB3ZSBjYW4gc2V0ICIwIiB0byB0aGUgZGVsaW1ldGVyIGZpZWxkCj4g bnVtYmVyPwo+Cj4gIFN1Y2ggYXM6Cj4gICAgICAgICAgICAgICAgR3JvdXAgZyA9IG5ldyBHcm91 cChncm91cENvdW50VGFnLCAwKTsKPgo+ICB3aGljaCBpcyB1c2VkIGluIGEgYXJ0aWNsZSBvZiAi VXNpbmcgTWVzc2FnZSBNZXRhZGF0YSIgYXQKPiBodHRwOi8vd3d3LnF1aWNrZml4ai5vcmcvY29u Zmx1ZW5jZS9kaXNwbGF5L3Fmai9Vc2luZytNZXNzYWdlK01ldGFkYXRhCj4gLgo+Cj4gIEFzIHdl IGtub3duLCBkb24ndCBoYXZlIGZpZWxkICIwIiwgYW5kIGl0IGlzbid0IGEgZGVsaW1ldGVyIGZp ZWxkIG51bWJlci4gSQo+IHdhbnQgdG8ga25vdyBtb3JlIGFib3V0IHRoaXMgdXNhZ2UuIENhbiB5 b3UgaGVscCBtZT8gVGhhbmsgeW91IQo+Cj4KPiAgUmVnYXJkcywKPiAgUWkgQ2FpCj4KPgo+Cj4g IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gIEZyb206IHN0ZXZlQHRlY2hub2V0 aWMuY29tCj4gVG86IHF1aWNrZml4ai11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBEYXRl OiBNb24sIDI0IFNlcCAyMDA3IDA4OjQ0OjQxIC0wNDAwCj4gU3ViamVjdDogUmU6IFtRdWlja2Zp eGotdXNlcnNdIFF1ZXN0aW9uIGFib3V0OiBDcmVhdGUgYSBuZXcgR3JvdXAKPgo+Cj4KPgo+IEhl bGxvIFFpIENhaSwKPgo+Cj4KPiBJJ20gbm90IHN1cmUgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIHF1 ZXN0aW9uLiBUaGUgZGVsaW1ldGVyIGZpZWxkIG51bWJlciBtdXN0Cj4gYmUgc2V0IHRvIHRoZSBm aXJzdCBmaWVsZCBudW1iZXIgd2l0aGluIHRoZSBncm91cC4gVGhpcyBpcyBob3cgdGhlIG1lc3Nh Z2UKPiBwYXJzZXIgZGV0ZXJtaW5lcyB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIHJlcGVhdGluZyBn cm91cCBpbnN0YW5jZXMuIFRoYXQncwo+IHdoeSB0aGUgY29uc3RydWN0b3IgeW91IG1lbnRpb24g YWxzbyBzcGVjaWZpZXMgdGhlIGRlbGltZXRlciBhcyBhbiBvcmRlcmVkCj4gZmllbGQsIHNvIGl0 IHdpbGwgYmUgdGhlIGZpcnN0IGZpZWxkLgo+Cj4KPgo+IFJlZ2FyZHMsCj4KPgo+Cj4gU3RldmUK Pgo+Cj4KPgo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Cj4KPiBGcm9tOiBx dWlja2ZpeGotdXNlcnMtYm91bmNlc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBbbWFpbHRvOnF1 aWNrZml4ai11c2Vycy1ib3VuY2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24KPiBCZWhhbGYg T2YgPz8KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNCwgMjAwNyA3OjQ0IEFNCj4gVG86IHF1 aWNrZml4ai11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiBTdWJqZWN0OiBbUXVpY2tmaXhq LXVzZXJzXSBRdWVzdGlvbiBhYm91dDogQ3JlYXRlIGEgbmV3IEdyb3VwCj4KPgo+Cj4gSGksIEFs bAo+Cj4gUmVjZW50bHksIEkgbm90aWNlIHRoYXQsIGEgYXJ0aWNsZSBvZiAiVXNpbmcgTWVzc2Fn ZSBNZXRhZGF0YSIgYXQKPiBodHRwOi8vd3d3LnF1aWNrZml4ai5vcmcvY29uZmx1ZW5jZS9kaXNw bGF5L3Fmai9Vc2luZytNZXNzYWdlK01ldGFkYXRhCj4gLkluIHRoaXMgYXJ0aWNsZSwgSSBoYXZl IGEgcXVlc3Rpb24gYWJvdXQgaG93IHRvIGNyZWF0ZSBhIG5ldyBHcm91cC4KPgo+IEF0IHRoZSBm aW5hbCBjb2RlLCBpdCB1c2VzOiBHcm91cCBnID0gbmV3IEdyb3VwKGdyb3VwQ291bnRUYWcsIDAp OyB0byBjcmVhdGUKPiBhIG5ldyBncm91cC4gQnV0IGF0IEdyb3VwLmphdmEsIHdlIG9ubHkgaGF2 ZSBhIGNvbnN0cnVjdG9yOiBwdWJsaWMgR3JvdXAoaW50Cj4gZmllbGQsIGludCBkZWxpbSl7dGhp cyhmaWVsZCwgZGVsaW0sIG5ldyBpbnRbXSB7IGRlbGltIH0pO30gdG8gY3JlYXRlIGEKPiBncm91 cCB3aXRoIHRoZSBzcGVjaWZpZWQgY291bnQgYW5kIGRlbGltZXRlciBmaWVsZHMuIEBwYXJhbSBm aWVsZCBpcyB0aGUKPiBjb3VudCB0YWcgbnVtYmVyOyBAcGFyYW0gZGVsaW0gaXMgdGhlIGRlbGlt ZXRlciB0YWcgbnVtYmVyIChmaXJzdCBncm91cAo+IGZpZWxkKS4KPgo+IE15IHF1ZXN0aW9uIGlz OiB3aGVuIHJlY2VpdmVkIHJlcGVhdGluZyBncm91cCwgd2UgbmVlZCB0byBjcmVhdGUgYSBuZXcg Z3JvdXAKPiBhbmQgd2UgZG9uJ3Qga25vdyB3aGljayB0eXBlIGdyb3VwIGl0IGlzLCBzbyB3ZSBj YSBuJ3QgdXNlIGNvbnN0cnVjdG9yIGxpa2U6Cj4gbmV3IE5ld09yZGVyQ3Jvc3MuTm9TaWRlcygp OyAgQnV0IGlzIGl0IGFkdmlzYWJsZSB0byBsZXQgQHBhcmFtIGRlbGltID0gMD8KPiBUaG91Z2gs IEkga25vdyBpdCBtYWtlIGZldyBkaWZmZXJlbmNlLGV2ZW4gd2UgY2FuIGxldCBkZWxpbSA9IDEs MiwzLCEtIS0gYW5kCj4gdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0OiBmaWVsZCBvcmRlcmlu ZyBtYXkgYmUgbm9uZW50aXR5IG9yIGRpZmZlcmVudC4KPiBCdXQgaXQgaXMgaW4gYnJlYWNoIG9m IHRoZSBkZXNjcmlwdGlvbiBvZiAiQHBhcmFtIGRlbGltIGlzIHRoZSBkZWxpbWV0ZXIgdGFnCj4g bnVtYmVyIChmaXJzdCBncm91cCBmaWVsZCkuIj8gIERvIHlvdSB0aGluayBzbz8KPgo+IFNvLCBJ IHRoaW5rLCBoZXJlLCB3ZSBjYW4gdXNlIHRoZSBtZXRob2QgIkdyb3VwIGNyZWF0ZShTdHJpbmcg YmVnaW5TdHJpbmcsCj4gU3RyaW5nIG1zZ1R5cGUsIGludCBjb3JyZXNwb25kaW5nRmllbGRJRCki IGF0IE1lc3NhZ2VGYWN0b3J5LmphdmEuIE9yIHdlIGNhbgo+IGhhdmUgYSBuZXcgY29uc3RydWN0 b3I6R3JvdXAoKSAvIEdyb3VwKGNvcnJlc3BvbmRpbmdGaWVsZElEKSB3aXRob3V0IGZpZWxkCj4g b3JkZXJpbmcgLCBsaWtlIHRoZSBjb25zdHJ1Y3RvcjogbWVzc2FnZSgpOy4KPgo+IEhvdyBkbyB5 b3UgdGhpbmsgdGhpcyBxdWVzdGlvbj8gQW0gSSB1bmRlcnN0b29kPyAgQW55IHF1ZXN0aW9ucyBw bGVhc2UgbGV0Cj4gbWUga25vdzopICBUaGFuayB5b3UgdmVyeSBtdWNoIQo+Cj4gUmVnYXJkcywK PiBRaSBDYWkKPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPgo+Cj4gSjlTQ1BC Ujs0eiBIb3RtYWlsIyw4fEc/NHMhIjh8MDJIKyEiOHw2YDRmNCI/VUEiP0xMZVFpIyEKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IMq508PQwtK7tPogV2luZG93cyBMaXZlIE1l c3NlbmdlciDH4cvJvbvB97rNubLP7aOhIMGivLTM5dHpo6EKPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4g VGhpcyBTRi5uZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5OiBNaWNyb3NvZnQKPiBEZWZ5IGFsbCBj aGFsbGVuZ2VzLiBNaWNyb3NvZnQoUikgVmlzdWFsIFN0dWRpbyAyMDA1Lgo+IGh0dHA6Ly9jbGsu YXRkbXQuY29tL01SVC9nby92c2UwMTIwMDAwMDcwbXJ0L2RpcmVjdC8wMS8KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFF1aWNrZml4ai11c2VycyBt YWlsaW5nIGxpc3QKPiBRdWlja2ZpeGotdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0 cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXhqLXVzZXJz Cj4KPgoKCi0tIApUb2xpIEt1em5ldHMKaHR0cDovL3d3dy5tYXJrZXRjZXRlcmEuY29tOiBPcGVu LVNvdXJjZSBUcmFkaW5nIFBsYXRmb3JtCmRvd25sb2FkLnJ1bi50cmFkZS4K |
|
From: CaiQi <cai...@ho...> - 2007-09-24 17:33:48
|
Hello, steve,
Thank you very much for your answer!
But I still don't know: why and when we can set "0" to the delimeter field number?
Such as:
Group g = new Group(groupCountTag, 0);
which is used in a article of "Using Message Metadata" at http://www.quickfixj.org/confluence/display/qfj/Using+Message+Metadata .
As we known, don't have field "0", and it isn't a delimeter field number. I want to know more about this usage. Can you help me? Thank you!
Regards,
Qi Cai
From: st...@te...: qui...@li...: Mon, 24 Sep 2007 08:44:41 -0400Subject: Re: [Quickfixj-users] Question about: Create a new Group
Hello Qi Cai,
I’m not sure fully understand your question. The delimeter field number must be set to the first field number within the group. This is how the message parser determines the boundaries between repeating group instances. That’s why the constructor you mention also specifies the delimeter as an ordered field, so it will be the first field.
Regards,
Steve
From: qui...@li... [mailto:qui...@li...] On Behalf Of ??Sent: Monday, September 24, 2007 7:44 AMTo: qui...@li...: [Quickfixj-users] Question about: Create a new Group
Hi, All Recently, I notice that, a article of "Using Message Metadata" at http://www.quickfixj.org/confluence/display/qfj/Using+Message+Metadata .In this article, I have a question about how to create a new Group. At the final code, it uses: Group g = new Group(groupCountTag, 0); to create a new group. But at Group.java, we only have a constructor: public Group(int field, int delim){this(field, delim, new int[] { delim });} to create a group with the specified count and delimeter fields. @param field is the count tag number; @param delim is the delimeter tag number (first group field). My question is: when received repeating group, we need to create a new group and we don't know whick type group it is, so we can't use constructor like: new NewOrderCross.NoSides(); But is it advisable to let @param delim = 0? Though, I know it make few difference,even we can let delim = 1,2,3,!-!- and the only difference is that: field ordering may be nonentity or different. But it is in breach of the description of "@param delim is the delimeter tag number (first group field)."? Do you think so? So, I think, here, we can use the method "Group create(String beginString, String msgType, int correspondingFieldID)" at MessageFactory.java. Or we can have a new constructor:Group() / Group(correspondingFieldID) without field ordering , like the constructor: message();. How do you think this question? Am I understood? Any questions please let me know:) Thank you very much! Regards,Qi Cai
J9SCPBR;4z Hotmail#,8|G?4s!"8|02H+!"8|6`4f4"?UA"?LLeQi#!
_________________________________________________________________
Windows Live Custom Domain，您的免费电子邮局。
https://domains.live.com/default.aspx |
|
From: Steve B. <st...@te...> - 2007-09-24 12:47:00
|
Hello,
This looks like a bug in the data dictionary parsing that's been there for
quite some time. Can you post an bug report
on the QFJ Jira bug tracking site? We'll get this fixed in the next release.
Thanks.
Steve
_____
From: qui...@li...
[mailto:qui...@li...] On Behalf Of ??
Sent: Monday, September 24, 2007 8:23 AM
To: qui...@li...
Subject: [Quickfixj-users] Question about "NoHops" at messageHeader
Hi,All
Recently, I find that, in QFJ_1.2.1, I can't use the repeating group
"NoHops"and the fiels 628,629,630. I only can use field 627.
Because repeating group "NoHops" is the only group at messageHeader, so in
many places, we may ignore it! For example, at DataDictionary.java,
private void load(InputStream inputStream) throws ConfigError {
!-!-
// HEADER
NodeList headerNode =
documentElement.getElementsByTagName("header");
if (headerNode.getLength() == 0) {
throw new ConfigError("<header> section not found in data
dictionary");
}
NodeList headerFieldNodes = headerNode.item(0).getChildNodes();
if (headerFieldNodes.getLength() == 0) {
throw new ConfigError("No header fields defined");
}
for (int i = 0; i < headerFieldNodes.getLength(); i++) {
Node headerFieldNode = headerFieldNodes.item(i);
String nodeName = headerFieldNode.getNodeName();
if (nodeName.equals("field") || nodeName.equals("group")) {
String name = getAttribute(headerFieldNode, "name");
if (name == null) {
throw new ConfigError("<" + nodeName + "> does not have
a name attribute");
}
String required = getAttribute(headerFieldNode, "required",
NO);
if (required == null) {
throw new ConfigError("<" +
headerFieldNode.getNodeName()
+ "> does not have a 'required' attribute");
}
addHeaderField(lookupXMLFieldNumber(document, name),
required.equalsIgnoreCase("Y"));
}
!-!-
}
It only load <group name="NoHops" required="N"> from fix44.xml, but can't
load <field name="HopCompID" required="N"/>!"<field name="HopSendingTime"
required="N"/>!"<field name="HopRefID" required="N"/> which are in the
group.
So, maybe, we should add:
if (nodeName.equals("group")) {
String required = getAttribute(headerFieldNode, "required");
if (required == null) {
throw new ConfigError("<group> does not have a 'required'
attribute");
}
addHeaderXMLGroup(document, headerFieldNode, this, required
.equalsIgnoreCase("Y"));
}
}
there, I used a new function:addHeaderXMLGroup(),coming from addXMLGroup().
This question may relate to
addXMLComponentFields()!"addXMLGroup()!"addGroup()!"isGroup()!"getGroup()!"c
heckGroupCount()!"iterate() at DataDictionary.java; and
parseGroup()!"parseHeader() at Message.java; where ignore the only group at
messageHeader "NoHops". And after messageCodeGenerate, I can't "public
static class NoHops extends Group";
How do you think this question? Am I understood? Any questions please let
me know:) Thank you very much!
Regards,
Qi Cai
_____
Windows Live Writer HCDz8f1p9jKYMxBg#,GaKIP4HUV>#! A
<http://writer.live.com/> "<4J9SC#!
|
|
From: Steve B. <st...@te...> - 2007-09-24 12:44:55
|
Hello Qi Cai, I'm not sure fully understand your question. The delimeter field number must be set to the first field number within the group. This is how the message parser determines the boundaries between repeating group instances. That's why the constructor you mention also specifies the delimeter as an ordered field, so it will be the first field. Regards, Steve _____ From: qui...@li... [mailto:qui...@li...] On Behalf Of ?? Sent: Monday, September 24, 2007 7:44 AM To: qui...@li... Subject: [Quickfixj-users] Question about: Create a new Group Hi, All Recently, I notice that, a article of "Using Message Metadata" at http://www.quickfixj.org/confluence/display/qfj/Using+Message+Metadata .In this article, I have a question about how to create a new Group. At the final code, it uses: Group g = new Group(groupCountTag, 0); to create a new group. But at Group.java, we only have a constructor: public Group(int field, int delim){this(field, delim, new int[] { delim });} to create a group with the specified count and delimeter fields. @param field is the count tag number; @param delim is the delimeter tag number (first group field). My question is: when received repeating group, we need to create a new group and we don't know whick type group it is, so we can't use constructor like: new NewOrderCross.NoSides(); But is it advisable to let @param delim = 0? Though, I know it make few difference,even we can let delim = 1,2,3,!-!- and the only difference is that: field ordering may be nonentity or different. But it is in breach of the description of "@param delim is the delimeter tag number (first group field)."? Do you think so? So, I think, here, we can use the method "Group create(String beginString, String msgType, int correspondingFieldID)" at MessageFactory.java. Or we can have a new constructor:Group() / Group(correspondingFieldID) without field ordering , like the constructor: message();. How do you think this question? Am I understood? Any questions please let me know:) Thank you very much! Regards, Qi Cai _____ J9SCPBR;4z Hotmail#,8|G?4s!"8|02H+!"8|6`4f4"?U <http://www.hotmail.com> A"?LLeQi#! |
|
From: Steve B. <st...@te...> - 2007-09-24 12:30:29
|
Serg and Bruno, QuickFIX/J (and QuickFIX) support a single daily or weekly schedule per session. For daily sessions, you specify the start/end times. For a weekly session, you specify starting day/time and ending day/time. QFJ doesn't support multiple daily schedules per session, including schedules that vary from day to day. It also doesn't support daily schedules, but only for specific days of the week. If you need these types of schedules, there are several possible ways to implement it. You could use an external scheduler (e.g., cron on Unix) to start/stop the FIX process or use JMX to enable, reset and disable the session. You could also use an embedded scheduling engine like Quartz (open source) or Flux (commercial) to do something similar. Regards, Steve > -----Original Message----- > From: qui...@li... [mailto:quickfixj- > use...@li...] On Behalf Of Serg V. Gulko > Sent: Monday, September 24, 2007 4:29 AM > To: qui...@li... > Subject: [Quickfixj-users] Weekly session configuration > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Dear All! > > How I can configure session schedule using next rules: > > Monday: from 07:00:00 to 10:00:00 > Friday: from 11:00:00 to 12:00:00 > > Now I tried to create several separate [session] entries but > QFJ(1.2.1) uses only last one. > > Serg > > > > ------------------------------------------------------------------------- > 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 |
|
From: <cai...@ho...> - 2007-09-24 12:23:39
|
Hi,All
Recently, I find that, in QFJ_1.2.1, I can't use the repeating group "NoHops"and the fiels 628,629,630. I only can use field 627.
Because repeating group "NoHops" is the only group at messageHeader, so in many places, we may ignore it! For example, at DataDictionary.java,
private void load(InputStream inputStream) throws ConfigError {
……
// HEADER NodeList headerNode = documentElement.getElementsByTagName("header"); if (headerNode.getLength() == 0) { throw new ConfigError("<header> section not found in data dictionary"); }
NodeList headerFieldNodes = headerNode.item(0).getChildNodes(); if (headerFieldNodes.getLength() == 0) { throw new ConfigError("No header fields defined"); }
for (int i = 0; i < headerFieldNodes.getLength(); i++) { Node headerFieldNode = headerFieldNodes.item(i);
String nodeName = headerFieldNode.getNodeName(); if (nodeName.equals("field") || nodeName.equals("group")) { String name = getAttribute(headerFieldNode, "name"); if (name == null) { throw new ConfigError("<" + nodeName + "> does not have a name attribute"); } String required = getAttribute(headerFieldNode, "required", NO); if (required == null) { throw new ConfigError("<" + headerFieldNode.getNodeName() + "> does not have a 'required' attribute"); } addHeaderField(lookupXMLFieldNumber(document, name), required.equalsIgnoreCase("Y")); }
……
}
It only load <group name="NoHops" required="N"> from fix44.xml, but can't load <field name="HopCompID" required="N"/>、<field name="HopSendingTime" required="N"/>、<field name="HopRefID" required="N"/> which are in the group.
So, maybe, we should add:
if (nodeName.equals("group")) { String required = getAttribute(headerFieldNode, "required"); if (required == null) { throw new ConfigError("<group> does not have a 'required' attribute"); } addHeaderXMLGroup(document, headerFieldNode, this, required .equalsIgnoreCase("Y")); } }
there, I used a new function:addHeaderXMLGroup(),coming from addXMLGroup().
This question may relate to addXMLComponentFields()、addXMLGroup()、addGroup()、isGroup()、getGroup()、checkGroupCount()、iterate() at DataDictionary.java; and parseGroup()、parseHeader() at Message.java; where ignore the only group at messageHeader "NoHops". And after messageCodeGenerate, I can't "public static class NoHops extends Group";
How do you think this question? Am I understood? Any questions please let me know:) Thank you very much!
Regards,Qi Cai
_________________________________________________________________
手机也能上 MSN 聊天了，快来试试吧！
http://mobile.msn.com.cn/ |
|
From: <cai...@ho...> - 2007-09-24 11:54:17
|
Hi, All Recently, I notice that, a article of "Using Message Metadata" at http://www.quickfixj.org/confluence/display/qfj/Using+Message+Metadata .In this article, I have a question about how to create a new Group. At the final code, it uses: Group g = new Group(groupCountTag, 0); to create a new group. But at Group.java, we only have a constructor: public Group(int field, int delim){this(field, delim, new int[] { delim });} to create a group with the specified count and delimeter fields. @param field is the count tag number; @param delim is the delimeter tag number (first group field). My question is: when received repeating group, we need to create a new group and we don't know whick type group it is, so we can't use constructor like: new NewOrderCross.NoSides(); But is it advisable to let @param delim = 0? Though, I know it make few difference,even we can let delim = 1,2,3,…… and the only difference is that: field ordering may be nonentity or different. But it is in breach of the description of "@param delim is the delimeter tag number (first group field)."? Do you think so? So, I think, here, we can use the method "Group create(String beginString, String msgType, int correspondingFieldID)" at MessageFactory.java. Or we can have a new constructor:Group() / Group(correspondingFieldID) without field ordering , like the constructor: message();. How do you think this question? Am I understood? Any questions please let me know:) Thank you very much! Regards,Qi Cai _________________________________________________________________ 用 Live Search 搜尽天下资讯！ http://www.live.com/?searchOnly=true |
|
From: Bruno <bru...@jd...> - 2007-09-24 08:53:35
|
Hi guys, I have a similar question. I need to have daily and weekly sessions configured at the same time. It would look like that: Mon-Fri: from 09:00:00 to 20:00:00 In other words, the session should be up every day from 9am from 8pm, except on weekends. Can that be done? Thanks, Bruno -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Serg V. Gulko Sent: Monday, September 24, 2007 10:29 AM To: qui...@li... Subject: [Quickfixj-users] Weekly session configuration QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Dear All! How I can configure session schedule using next rules: Monday: from 07:00:00 to 10:00:00 Friday: from 11:00:00 to 12:00:00 Now I tried to create several separate [session] entries but QFJ(1.2.1) uses only last one. Serg ------------------------------------------------------------------------- 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 |
|
From: Serg V. G. <ri...@ze...> - 2007-09-24 08:29:07
|
Dear All! How I can configure session schedule using next rules: Monday: from 07:00:00 to 10:00:00 Friday: from 11:00:00 to 12:00:00 Now I tried to create several separate [session] entries but QFJ(1.2.1) uses only last one. Serg |
|
From: Steve B. <st...@te...> - 2007-09-24 01:36:09
|
The primary change in this release is that QFJ is now compiled using Java (a Java 4 version, created using Retrotranslator, is also included as a binary only release). Other new features include extensions to the JMX support (notifications for session state events) and support for dynamic definition of acceptor sessions. There are also several other new features, improvements and bugs fixes (see release notes below). I give special thanks to Toli Kuznets from Marketcetera (http://www.marketcetera.com/) for several bug fixes and new features. I also greatly appreciate the contributions of David Vincent and Laurent Danesi from Smart Trade Technologies (http://www.smart-trade.net/). Smart Trade did the initial Java 5 and retrotranslator conversion and provide the server that supports the QuickFIX/J web site, wiki, bug tracker and continuous integration server. Downloads: https://sourceforge.net/project/showfiles.php?group_id=163099 Release Notes: Version 1.3.0 ** New Features and Improvements * [QFJ-75] - Make table names for JdbcLog configurable * [QFJ-165, QFJ-221] - Support dynamic definition of acceptor sessions * [QFJ-204] - Support variable interpolation during parsing of default session settings * [QFJ-209, QFJ-210, QFJ-217, QFJ-230] - QFJ ported to Java 5 * [QFJ-222] - Made SessionJmxExporter.createSessionName public * [QFJ-225] - Enhance JMX support to include notifications of session state events * [QFJ-236] - Make heartbeat test request delay configurable * [QFJ-237] - Support sending a sequence request message using JMX ** Bug Fixes * [QFJ-206] - Some XSLT templates weren't handling custom packaging correctly * [QFJ-208] - Example scripts had wrong classpath * [QFJ-211] - Race condition/NPE on Session.disconnect() * [QFJ-215] - QFJ deadlocks in Session.disconnect() * [QFJ-218] - Session time not checked while session is disconnected * [QFJ-220] - QFJ hangs in IoSessionResponder.disconnect() while waiting for scheduled messages to be written * [QFJ-223] - IoSessionInitiator sometimes tries to log null messages in case of IOExceptions * [QFJ-228] - Weekly session schedule calculates wrong day for non-GMT timezone * [QFJ-231] - Fixed synchronization of responder during logout * [QFJ-233] - Removed unused SendResetSeqNumFlag from documentation ---- Steve Bate |
|
From: Ashley W. <ash...@db...> - 2007-09-19 17:09:14
|
Hi, I have another newbie question, this time about the generated quickfix.field package. I'm trying to run the generator against the fix xml files I've inherited from the previous developer and I get another quickfix.field package similar to the one in the quickfix-core, but obviously customized due to the spec changes I'm putting through. But one puzzle is that.the SecurityTradingStatus class in the generated code contains a constant called NO_OPENNO_RESUME whereas the one that comes with the latest quickfix-core jar file contains a constant called NO_OPEN_NO_RESUME - note the extra underscore. So it appears I'll have to pay careful attention to the order of the jar files in the classpaths for compilation and runtime. Maybe my approach of shipping the quickfix-core along with a second jar file that contains all of the code that came out of the generator (including the quickfix.field package) is wrong. I could possibly modify the quickfix-core to remove its version of quickfix.field but this feels a little clunky to me. Any pointers greatly appreciated. Thanks - Ashley --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. |
|
From: Ashley W. <ash...@db...> - 2007-09-19 12:01:41
|
Just to conclude this one, the upgrade sorted the problem. Ran the system overnight and doing a threaddump revealed just a handful of mina threads rather than the enormous number I was seeing before Many thanks. - Ashley qui...@li... wrote on 12/09/2007 08:36:32: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > Thanks for the info, I'll do an upgrade and confirm. > > qui...@li... wrote on 11/09/2007 22:37:23: > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > In that case you should find upgrading to a later version will help - > > this was a bug fixed in 1.0.2. > > > > http://www.quickfixj.org/jira/browse/QFJ-34 > > > > Cheers, > > Brad. > > > > > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of > > Ashley Williams > > Sent: Tuesday, 11 September 2007 5:43 PM > > To: qui...@li... > > Subject: Re: [Quickfixj-users] OutOfMemoryErrors with many Mina threads > > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > I believe it's quickfix version 1.0 and mina version 0.9.3 > > > > ------------------------------------------------------------------------- > > 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 e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail > in error) please notify the sender immediately and delete this e- > mail. Any unauthorized copying, disclosure or distribution of the > material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. > ------------------------------------------------------------------------- > 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 e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. |
|
From: Toli K. <to...@ma...> - 2007-09-19 01:16:54
|
Steve, I changed this into an RFE and added a patch that fixes it. let me know what you think: http://www.quickfixj.org/jira/browse/QFJ-236 We've been trying to get Marketcetera OpenFIX certified, so Graham filed a few other bugs/RFEs for that, and i'll try to go through and fix them all. Let me know if you have any thoughts on how to approach it best, so that i don't step on any assumptions during my implementation. Also, do you want me to just send you patches for all of these for review first, in case there are better approaches instead? Also, i've noticed that you are getting ready to release 1.3.0 - it'd be great if we can get these fixes in, but it's quite all right if we don't, we can just ship Marketcetera with a custom build of QFJ if needed. We are doing a dot release with bug-fixes only anyway, so it's not that big of a deal. thanks On 9/17/07, Steve Bate <st...@te...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hi Toli, > > This is a vague area of the spec. The specification says the test request > should be sent after the missed heartbeat plus "some reasonable > transmission time". The definition of reasonable is left to the > implementer. QF and QFJ consider 50% of the heart beat interval to be > reasonable. Apparently TransactTools uses 30%. If you want to submit > a patch to make this configurable, I'll add it although it will > probably only be used for OpenFix certification. IIRC, there are several > other tests that fail because of differing interpretation of ambiguous > areas of the specification. > > Regards, > > Steve > > > -----Original Message----- > > From: qui...@li... [mailto:quickfixj- > > use...@li...] On Behalf Of Toli Kuznets > > Sent: Monday, September 17, 2007 3:41 PM > > To: qui...@li... > > Subject: [Quickfixj-users] Question about calculating time to send a > > TestRequest message > > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > Hey, > > > > I also posted this as a JIRA question 236: > > http://www.quickfixj.org/jira/browse/QFJ-236 > > > > We've been going through a certification process with TransactTools > > (http://www.openfix.net/), and encountered a different expected > > behaviour with sending Test Requests. > > > > In the TransactTools test, they skip a heartbeat message and expect > > our quickfix engine (Ie QFJ) to send a test request: > > "We suppressed our last heartbeat message. > > In response we expected to receive a test request message from you > > within 9 seconds (30% of the HeartBeatInt field) but did not." > > > > Seems like they expect it to be sent within HeartBeatInt+9secs. > > Looking at the code in SessionState.isTestRequestNeeded(), it > > calculates the Test Request delay as 1.5 * (HeartBeatInt + > > numTestRequestsSent + 1), which translates into HeartBeatInt * 1.5 > > (for first request) = 30 + 15secs, which is over the +9 seconds that's > > expected. > > > > Is there a known spec for this formula or was it something > > "reasonable" but not necessarily standard? Maybe it's something we > > need to make configurable to satisfy different expectations form > > counterparties? > > > > thoughts? > > > > -- > > Toli Kuznets > > http://www.marketcetera.com: Open-Source Trading Platform > > download.run.trade. > > > > ------------------------------------------------------------------------- > > 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 > -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Robert B. <rbr...@me...> - 2007-09-18 15:17:57
|
Thanks for all your help guys! 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. |
|
From: Steve B. <st...@te...> - 2007-09-17 23:35:53
|
Hi Toli, This is a vague area of the spec. The specification says the test request should be sent after the missed heartbeat plus "some reasonable transmission time". The definition of reasonable is left to the implementer. QF and QFJ consider 50% of the heart beat interval to be reasonable. Apparently TransactTools uses 30%. If you want to submit a patch to make this configurable, I'll add it although it will probably only be used for OpenFix certification. IIRC, there are several other tests that fail because of differing interpretation of ambiguous areas of the specification. Regards, Steve > -----Original Message----- > From: qui...@li... [mailto:quickfixj- > use...@li...] On Behalf Of Toli Kuznets > Sent: Monday, September 17, 2007 3:41 PM > To: qui...@li... > Subject: [Quickfixj-users] Question about calculating time to send a > TestRequest message > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hey, > > I also posted this as a JIRA question 236: > http://www.quickfixj.org/jira/browse/QFJ-236 > > We've been going through a certification process with TransactTools > (http://www.openfix.net/), and encountered a different expected > behaviour with sending Test Requests. > > In the TransactTools test, they skip a heartbeat message and expect > our quickfix engine (Ie QFJ) to send a test request: > "We suppressed our last heartbeat message. > In response we expected to receive a test request message from you > within 9 seconds (30% of the HeartBeatInt field) but did not." > > Seems like they expect it to be sent within HeartBeatInt+9secs. > Looking at the code in SessionState.isTestRequestNeeded(), it > calculates the Test Request delay as 1.5 * (HeartBeatInt + > numTestRequestsSent + 1), which translates into HeartBeatInt * 1.5 > (for first request) = 30 + 15secs, which is over the +9 seconds that's > expected. > > Is there a known spec for this formula or was it something > "reasonable" but not necessarily standard? Maybe it's something we > need to make configurable to satisfy different expectations form > counterparties? > > thoughts? > > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform > download.run.trade. > > ------------------------------------------------------------------------- > 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 |
|
From: Toli K. <to...@ma...> - 2007-09-17 21:29:36
|
Yes it does. The btobits.com site seems to have a broken link to their legend diagram, so i'm attaching it to the message. The FIX 4.4 spec says the NoQuoteEntires is not required when you are canceling all quotes: "The number of securities (instruments) whose quotes are to be canceled. Not required when canceling all quotes.". If that's the case, you shouldn't be sending any Symbol (tag 55) fields. But if you are sending any 55=xxx fields, you need to wrap it in a repeating group so you'll need to specify the NoQuoteEntires as well. If you look at the FIX44.xml dictionary file in QFJ, you'll also see that the Quote Request has Instrument block as a group: <message name="QuoteCancel" msgtype="Z" msgcat="app"> .... <field name="TradingSessionSubID" required="N"/> <group name="NoQuoteEntries" required="N"> <component name="Instrument" required="N"/> ..... -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Tommy H. <th...@bo...> - 2007-09-17 21:16:58
|
Toli, Does the '=>' symbol in the dictionary mean repeating group? If so, I see your point. However, does that necessarily mean that NoQuoteEntries (295) is required? (I will need to be able to make the case to our business partner to have them correct their code and I don't want to say it is required if I can not substantiate my claim) Thanks - Tommy On Sep 17, 2007, at 3:53 PM, Toli Kuznets wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Tommy, > > According to the spec, it looks like the Instrument block (and Symbol > inside of it) is only present in a NoQuoteEntries Group (295 > NoQuoteEntries). > > Your outgoing message doesn't seem to have a group in it (there's > no tag 295). > > Could that be the reason? > > On 9/17/07, Tommy Hannon <th...@bo...> wrote: >> QuickFIX/J Documentation: >> http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> I am using version 1.1.0 of QFJ and receiving a QuoteCancel >> message from a >> business partner... >> >> FIX.4.4:Us->Them: >> 8=FIX. >> 4.49=10135=Z49=Them56=Us34=42999852=20070913-23:00:11116=TraderX117=8 >> 4542955298=455=[N/A]10=104 >> >> To which our engine replies... >> >> FIX.4.4:Us->Them: >> 8=FIX. >> 4.49=14435=334=66549=Us52=20070913-23:00:11.60656=Them129=TraderX45=4 >> 2999858=Tag >> not defined for this message type371=55372=Z373=210=123 >> >> It appears this message is being sent by the QFJ engine as I am not >> explicitly sending it in the code. Although the QuoteCancelType >> (298) = 4 >> (Cancel All Quotes) does not apply to any particular quote, the >> FIX 4.4 >> specification does allow for the optional "Component Block - >> <Instrument>" >> in Quote Cancel (Z) message which contains Symbol (55) tag. What >> is the >> problem? >> >> Thanks in advance. >> --------------------------------------------------------------------- >> ---- >> 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. > > ---------------------------------------------------------------------- > --- > 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 > |
|
From: Toli K. <to...@ma...> - 2007-09-17 20:53:23
|
Tommy, According to the spec, it looks like the Instrument block (and Symbol inside of it) is only present in a NoQuoteEntries Group (295 NoQuoteEntries). Your outgoing message doesn't seem to have a group in it (there's no tag 295). Could that be the reason? On 9/17/07, Tommy Hannon <th...@bo...> wrote: > QuickFIX/J Documentation: > http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I am using version 1.1.0 of QFJ and receiving a QuoteCancel message from a > business partner... > > FIX.4.4:Us->Them: > 8=FIX.4.49=10135=Z49=Them56=Us34=42999852=20070913-23:00:11116=TraderX117=84542955298=455=[N/A]10=104 > > To which our engine replies... > > FIX.4.4:Us->Them: > 8=FIX.4.49=14435=334=66549=Us52=20070913-23:00:11.60656=Them129=TraderX45=42999858=Tag > not defined for this message type371=55372=Z373=210=123 > > It appears this message is being sent by the QFJ engine as I am not > explicitly sending it in the code. Although the QuoteCancelType (298) = 4 > (Cancel All Quotes) does not apply to any particular quote, the FIX 4.4 > specification does allow for the optional "Component Block - <Instrument>" > in Quote Cancel (Z) message which contains Symbol (55) tag. What is the > problem? > > Thanks in advance. > ------------------------------------------------------------------------- > 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. |
|
From: Tommy H. <th...@bo...> - 2007-09-17 20:42:56
|
I am using version 1.1.0 of QFJ and receiving a QuoteCancel message from a business partner... FIX.4.4:Us->Them: 8=FIX. 4.49=10135=Z49=Them56=Us34=42999852=20070913-23:00:11116=TraderX117=8454 2955298=455=[N/A]10=104 To which our engine replies... FIX.4.4:Us->Them: 8=FIX. 4.49=14435=334=66549=Us52=20070913-23:00:11.60656=Them129=TraderX45=4299 9858=Tag not defined for this message type371=55372=Z373=210=123 It appears this message is being sent by the QFJ engine as I am not explicitly sending it in the code. Although the QuoteCancelType (298) = 4 (Cancel All Quotes) does not apply to any particular quote, the FIX 4.4 specification does allow for the optional "Component Block - <Instrument>" in Quote Cancel (Z) message which contains Symbol (55) tag. What is the problem? Thanks in advance. |
|
From: Toli K. <to...@ma...> - 2007-09-17 19:40:51
|
Hey, I also posted this as a JIRA question 236: http://www.quickfixj.org/jira/browse/QFJ-236 We've been going through a certification process with TransactTools (http://www.openfix.net/), and encountered a different expected behaviour with sending Test Requests. In the TransactTools test, they skip a heartbeat message and expect our quickfix engine (Ie QFJ) to send a test request: "We suppressed our last heartbeat message. In response we expected to receive a test request message from you within 9 seconds (30% of the HeartBeatInt field) but did not." Seems like they expect it to be sent within HeartBeatInt+9secs. Looking at the code in SessionState.isTestRequestNeeded(), it calculates the Test Request delay as 1.5 * (HeartBeatInt + numTestRequestsSent + 1), which translates into HeartBeatInt * 1.5 (for first request) = 30 + 15secs, which is over the +9 seconds that's expected. Is there a known spec for this formula or was it something "reasonable" but not necessarily standard? Maybe it's something we need to make configurable to satisfy different expectations form counterparties? thoughts? -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Steve B. <st...@te...> - 2007-09-17 18:53:07
|
> Does anyone know of a way to increase the amount of time a SendingTime > value is allowed to deviate from? Toli says 2 minutes below...I would > like to increase this window...what is the point of this validation > anyway? To add to what Toli has already written, the FIX specification requires the latency checks. I assume this is to avoid erroneous processing of old messages. In some cases, there may even be regulatory issues with executing excessively old order (for example). To get a more detailed answer, you could try posting your question on the FPL forums. The two minute default is what is recommended in the specification. If you are logging incoming messages, then you still have the raw messages that were sent. I'd recommend checking the log record timestamp (which is based on your local time) with the SendingTime field value in the messages. It's possible there is a problem with your counterparty's recovery implementation. Regards, Steve |
|
From: Toli K. <to...@ma...> - 2007-09-17 18:14:34
|
Robert, You have two options: you can turn off checking for latency altogether, or you can increase the maxLatency from the default of 2 minutes. the flags for this are 'checkLatency' and 'maxLatency' in your session settings: http://www.quickfixj.org/quickfixj/usermanual/usage/configuration.html Hope this helps. On 9/17/07, Robert Brueckmann <rbr...@me...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Does anyone know of a way to increase the amount of time a SendingTime > value is allowed to deviate from? Toli says 2 minutes below...I would > like to increase this window...what is the point of this validation > anyway? There's not way to override this or capture it in the code and > handle these messages differently? > > In the meantime, I'm working with the vendor to ensure our clocks are > synchronized. Very bizarre though that the 2 hours worth of messages > that came through, you would have thought that ALL of them would have > been rejected...nope...it's like the first 25% of them were rejected, > them something repaired itself or something synched up or something > happened and the remainder of the messages have all been flowing through > without a hitch. > > robert l. brueckmann > merlin securities > 712 fifth avenue > new york, ny 10019 > p: 212.822.4821 > f: 212.822.4820 > > > > Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single Strategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007 > > > From: qui...@li... > [mailto:qui...@li...] On Behalf Of Toli > Kuznets > Sent: Monday, September 17, 2007 1:43 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] SendingTime accuracy problem?!? > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Robert, > > The one time i've seen "Sending time accuracy problem" error was when > the sender/receiver machines had their clock out of sequence for over > 2 minutes. > > For example, if your acceptor machine was 2 minutes ahead/behind the > initiator, the QFJ engine refuses to accept messages in that case. > > Check to make sure that your machine has its clock synchronized - that > fixed the problem for us. > > hope this helps > > > On 9/17/07, Robert Brueckmann <rbr...@me...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > We had an issue with one of our vendors this morning. Our engine > fires > > up at 7:15 am EST and waits as an acceptor for the vendor to connect > and > > push messages over to us starting at 7:30 am on their end. > > > > I'm not constantly monitoring the engine and for all intents and > > purposes, according the logs, the engine was up and listening at the > > appropriate time, so even if I was, it wouldn't have looked like > > anything was wrong. 2 hours had gone by before one of our traders > > called the IT desk to say they aren't seeing any of the trades they > > place with the vendor flow over to the FIX Monitor utility we provide > to > > them. > > > > I contacted the vendor, they said they couldn't connect this morning > to > > us for some unspecified reason and never retried. They fired it back > up > > after we called them and we got bombarded with 2 hours worth of > > messages. Looking at the EVENT_LOG table, I'm seeing hundreds of > > entries for messages being rejected due to this ambiguous 'SendingTime > > accuracy problem.' > > > > What the heck is this? Why would this happen? Why would 75% of their > > messages flow through without a hitch and this other 25% get rejected? > > Is there any way to avoid this from happening again? Is there any way > > to get notified of these rejects (like some method I could put in > place > > somewhere in the application code to capture this rejection?) or to > > ignore this issue so the engine does process them so they can at least > > get into our database? We luckily have an end-of-day reconciliation > > with this vendor in place to find out which ones we're missing but > this > > is going to be a huge pain today. > > > > Anyone have any experience with this error? Anyone have a better way > to > > handle them, than simply let the engine reject the message entirely > with > > no way to recover the message and reprocess it? > > > > Any help would be greatly appreciated! > > > > Thanks, > > rlb -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
103 messages has been excluded from this view by a project administrator.
