Don't place an IOrder return from IEngine.submit
into some collection. You don't need to. Just
use the String order label as a key, and then you
can query it later using IEngine.getOrders()
or getOrder(orderlLabelKey).
When using a double-submit as you are doing,
it may be useful (not required) to use waitForUpdate
which will enable you to check the status of the
submit. Ordinarily that will be delivered asynchronously
but you can wait for the small amount of time it will
take for status update using waitForUpdate.
I'm just writing this off the top of my head, but
you will need to submit a complete piece of code,
with parameters, so that somebody can replicate
your problem.
When you are in an onTick or onBar callback, then
you *are* on the proper thread (serialized) for
performing Order operations. That is correct.
But I can't debug your code
Only when you have asynch events which require access
to Order processing, then that is when you *must*
use IContext.executeTask(Callable) to do that;
otherwise you violate Threading requirements.
Most "naive"/"newbie" coders, coding simple things, just use
an onTick or onBar type of callback event to "drive"
their logic forward. That ensures they are automatically
on the Order callback thread, which will not result
in Thread violation exceptions. (Most of them will
not really understand threading, so this is a good
thing.)
Remember that if you are on the executeTask queue
thread, that waiting or blocking in that thread can
cause a Deadlock situation. You can get this same
problem when using the Swing event queue, and
using a blocking call which queues further events
on the same queue, which will never execute,
resulting in a Deadlock condition.
HyperScalper