Upgraded my linux server from 2.8.0 --> 2.9.5.1 this weekend
and now I have problems with IEngine.broadcast... pacing.

So I believe this exception should not be happening, since
I didn't change my codebase. I am running many individual
Strategy modules, each of which may use IEngine.broadcast...

My software runs perfectly under API 2.8.0, so something has
change in API 2.9.5.1 which results in my software violating
the minimum delay between successive messages, even though
each Strategy waits the required period of time >1000 msecs
between successive broadcast messages.

I may have to revert to 2.8.0 until this can be clarified.

HyperScalper

Could you please provide a launch scenario and an example strategy?

I don't think I can, as it's very complex. But each Strategy
independently "paces" itself so that it does NOT violate the
minimum delay requirement, on a per-Strategy basis.

As this works perfectly in 2.8.0, I can only assume that the
exception is being incorrectly thrown, or the delay criterion
has been changed since 2.8.0 .

In the unlikely event that the minimum delay period has now
become a "global" account-wide restriction, this could explain
why I am seeing problems. Each Strategy paces correctly,
but they are running concurrently so another Strategy happens
to send its own message just a few milliseconds after different
Strategy has executed a broadcast.

If this were the case that would easily explain the problem, and
hope the implementation hasn't been changed in that way
<speculation> You could reassure me that this is not the
requirement, that would help...

I'll quickly implement a global delay timestamp at the level of
the IClient, which all Strategies must observe, and see whether
the problem disappears.

HyperScalper

We don't ask you for your complex system, we ask if you can provide an example strategy or 2 strategies which show the idea + the launch scenario (i.e. local run/remote run; Historical Tester or work with live data; JForex-SDK or platform).

(Amazon EC2 linux, Oracle JDK 1.7 update 45 server vm)

I put in a global pacing restriction and the exception is still
thrown. I realize you want a test scenario but I can't provide one
at this time. I have to revert to the 2.8.0 API for right now.

I've been respecting these min delay pacing restrictions for
many months, so I'm pretty sure the code enforces the minimum
delay of 1000+ msecs per broadcast message per Strategy.
I delay about 1200 msecs just to be on the safe side.

For now, it appears that the
API's internal timestamp for the "last broadcast message"
is incorrect. So these min delay violation exceptions appear
to be thrown when they should not be thrown.

HyperScalper

I've seen a few of these also in 2.8.0 API so I'll review my minimum
delay code. Just saw a lot more of them in 2.9.1.5 so I panicked

Could be I have missed something.

I'll post some more when I get some further results. Could be
my problem so I'll check carefully. If I've queued up several
IContext.broadcast calls within a Callable, and IContext.executeTask
has these queued up, it could be that I violate the minimum
delay, so I'll make sure I measure time from the actual
call to IEngine.broadcast, rather than the IContext.executeTask
so that could be my problem... Sorry for the trouble

Thanks,
HyperScalper