Menu
▾
▴
quickfixj-users
|
From: gu h. <hai...@ho...> - 2007-09-17 07:15:15
|
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, 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 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(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) _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/ |
|
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: Steve B. <st...@te...> - 2007-09-28 11:25:58
|
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#!
|
|
From: Robert B. <rbr...@me...> - 2007-09-17 17:27:33
|
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 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: Toli K. <to...@ma...> - 2007-09-17 17:43:35
|
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 > > Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single Strategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007 > > > > > -------------------------------------------------------- > > 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, distribution 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. > > Merlin Securities, LLC is a registered broker-dealer. Services offered through 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 solicitation or recommendation to buy or sell a particular security. > > > > ------------------------------------------------------------------------- > 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-17 18:02:42
|
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 S= trategy 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 > > Merlin Securities - #1 Prime Broker North America, #1 Prime Broker Single Strategy Funds, #1 Prime Broker Funds Under $100M - Global Custodian 2007 > > > > > -------------------------------------------------------- > > 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, distribution 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. > > Merlin Securities, LLC is a registered broker-dealer. Services offered through 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 solicitation or recommendation to buy or sell a particular security. > > > > ------------------------------------------------------------------------ - > 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 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 =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: 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. |
|
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: 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: dumitriu <dm...@co...> - 2008-08-21 17:22:32
|
Steve, Is there any way to get an indication that login failed because of this sending time problem? As far as I can tell, onLogout gets called, but there is no obvious way to retrieve the reason for the logout. Cheers, Dan Steve Bate 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? > > 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 > > > ------------------------------------------------------------------------- > 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 > > -- View this message in context: http://n2.nabble.com/Banzai-example-question--tp364931p740740.html Sent from the QuickFIX/J mailing list archive at Nabble.com. |
|
From: Toli K. <to...@ma...> - 2008-08-21 21:56:11
|
Dan, This problem is now on my "wishlist" as well - enough of our customers/users get confused why they are being logged out from the Marketcetera exchange simulator without any good reasons. I've created an RFE http://www.quickfixj.org/jira/browse/QFJ-342 and assigned it to myself, and i'll try to get through it fairly quickly. thanks for pushing! On Thu, Aug 21, 2008 at 10:22 AM, dumitriu <dm...@co...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > Steve, > > Is there any way to get an indication that login failed because of this > sending time problem? As far as I can tell, onLogout gets called, but there > is no obvious way to retrieve the reason for the logout. > > Cheers, > Dan > > > > > Steve Bate 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? >> >> 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 >> >> >> ------------------------------------------------------------------------- >> 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 >> >> > > -- > View this message in context: http://n2.nabble.com/Banzai-example-question--tp364931p740740.html > Sent from the QuickFIX/J mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > 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. |
Thanks for helping keep SourceForge clean.
X