Sorry guys, I've completely missed this thread, and the topic is very

First, a simple fix for the given example. Add the following on the first
line of Main:

And put the ThreadPoolSynchronizationContext class somewhere:
class ThreadPoolSynchronizationContext : SynchronizationContext
    // No-op.

Now, detailed explanation. The problem exists forever in Ignite and is
mentioned in the docs briefly [1].
Also mentioned in .NET docs (I've updated them a bit) [2].

* Ignite (Java side) runs async callbacks (continuations) on system
threads, and those threads have limitations (you should not call Ignite
APIs from them in general)
* Ignite.NET wraps async operations into native .NET Tasks
* Usually `await ...` call in .NET will continue execution on the original
Thread (simply put, actually it is more complex), so Ignite system thread
issue is avoided
* However, Console applications have no `SynchronizationContext`, so the
continuation can't be dispatched to original thread, and is executed on
current (Ignite) thread
* Setting custom SynchronizationContext fixes the issue: all async
continuations will be dispatched to .NET thread pool and never executed on
Ignite threads

However, dispatching callbacks to a different thread causes performance
hit, and Ignite favors performance over usability right now.
So it is up to the user to configure desired behavior.

Let me know if you need more details.



On Thu, Aug 1, 2019 at 3:41 PM Ilya Kasnacheev <>

> Hello!
> I have filed a ticket about this issue so it won't get lost.
> Regards,
> --
> Ilya Kasnacheev
> чт, 2 мая 2019 г. в 10:53, Barney Pippin <>:
>> Thanks for the response Ilya. Did you get a chance to look at this Pavel?
>> Thanks.
>> --
>> Sent from:

Reply via email to