Menu
▾
▴
Re: [Quickfixj-users] SendingTime accuracy problem?!?
|
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. |
