Posted: Jan 27, 2012 @ 08:47 AM             Msg. 1 of 5

Hello,
I was working on Remoting feature support for my test and found following issue:
In some scenarios, when secondary application uses OECClient API from event callback, it may block both primary and secondary application.

Here is my scenario in details:

1. Primary application starts. It uses CreateInstance(true) but since this is first application, regular API instance is created. After that, primary application sets RemoteHostingEnabled to true.
2. After successful login, primary application calls to RequestContracts() from its OnLoginComplete handler
3. After application receives several OnContractsChanged() events, it discovers that Contracts["ESH2"] isn't null anymore and it calls to SubscribeTicks() from OnContractsChanged handler for this contract (ESH2)
4. After that, primary application starts to receive OnTicksReceived event calls.
5. Secondary application starts (actually, it's another instance of the same app with different parameters). It uses CreateInstance(true) and remoting instance is created.
6. Secondary app discovers that CompleteConnected is true so it does not call Connect()
7. Secondary app executes same RequestContracts() calls as in step 2
8. Same as in step 3, each time secondary app receives OnContractsChanged, it checks for Contracts["ESH2"]!=null.
But here is the problem: after secondary app receives FIRST OnContractsChanged event, it blocks on Contracts["ESH2"] call.
Moreover, primary app blocks at the same time and stops receiving OnTicksReceived events (and any other events since message loops in both apps are blocked)

I fixed the problem by using SynchronizationContext.Post() in event callbacks but it is not clear whether this is correct behavior of API

Is it expected behavior of API?
Is it allowed to use OECClient API from event callbacks? If it is not allowed in some cases only, is there any documentation with exact list of these cases?
Or is there any limitations to applications which use Remoting feature only?

---

Sergey Sokolov

Posted: Jan 27, 2012 @ 08:55 AM             Msg. 2 of 5

OECAPI enfoces blocking of "main" thread of primary application during calls of remote event handlers. And opposite: calls from remote applications are marshaled to the "main" thread of primary application.

---

Victor Vins
Lead Software Developer

Posted: Jan 27, 2012 @ 09:11 AM             Msg. 3 of 5

Thanks for response.
As I understood, that means, in order to support Remoting (secondary), it is not enough just to create API instance as it described in http://www.openecry.com/api/OECAPIRemoting.pdf, but it is also necessary to make sure that application is not calling API from event handlers, is it correct?

---

Sergey Sokolov

Posted: Jan 27, 2012 @ 09:20 AM             Msg. 4 of 5

No, it is not correct. Calls from event handler of remote applications will be executed even the thread of primary application will be suspended. This logic can be treated as synchronous sequential execution of local and remote event handlers.

---

Victor Vins
Lead Software Developer

Posted: Jan 27, 2012 @ 09:26 AM             Msg. 5 of 5

Ok, does this mean that *synchronous* calls from event handler of remote applications (in my case Contracts["ESH2"]) are disallowed?

---

Sergey Sokolov