Re: [Quickfixj-users] SendingTime accuracy problem?!?

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

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.