Yes, this can be done purely on .NET side, which is an option that I
consider.
However, the root problem is on Java side, and I believe that we should fix
the root problem.
> violate some of Ignite assumptions: that we never run user code from
certain thread pools
We actually do run user code from Ignite thread pools:
cache.getAsync(1).listen(fut ->
System.out.println("Get operation completed [value=" + fut.get() + ']'));
`println` here is executed on the striped pool. This is stated in the
docs that I linked above.
Users have to be aware of this and they have to be very careful with
every future listener. IMO, this is a tricky gotcha and a bad
usability.
Thoughts?
On Wed, Aug 7, 2019 at 12:22 PM Ilya Kasnacheev <ilya.kasnach...@gmail.com>
wrote:
> Hello!
>
> + dev@
>
> I think the current behavior, where .Net callbacks may be run from striped
> pool, violate some of Ignite assumptions: that we never run user code from
> certain thread pools (like sys-stripe) and that we try to limit options of
> running user-supplied code from our internals.
>
> I think that future versions of .Net integration should remove the ability
> of async callbacks to be called from non-user threads, even if it can lead
> to performance degradation in some cases. I suggest removing this mode, if
> possible, while keeping only the safe one, where internal threads are not
> waiting upon completion of user code.
>
> In this case my issue IGNITE-12033 could be used to track this work.
>
> WDYT?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 7 авг. 2019 г. в 01:47, Pavel Tupitsyn <ptupit...@apache.org>:
>
>> Sorry guys, I've completely missed this thread, and the topic is very
>> important.
>>
>> First, a simple fix for the given example. Add the following on the first
>> line of Main:
>> SynchronizationContext.SetSynchronizationContext(new
>> ThreadPoolSynchronizationContext());
>>
>> 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].
>>
>> Breakdown:
>> * 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.
>>
>> Thanks
>>
>> [1] https://apacheignite.readme.io/docs/async-support
>> [2] https://apacheignite-net.readme.io/docs/asynchronous-support
>>
>> On Thu, Aug 1, 2019 at 3:41 PM Ilya Kasnacheev <ilya.kasnach...@gmail.com>
>> wrote:
>>
>>> Hello!
>>>
>>> I have filed a ticket about this issue so it won't get lost.
>>> https://issues.apache.org/jira/browse/IGNITE-12033
>>>
>>> Regards,
>>> --
>>> Ilya Kasnacheev
>>>
>>>
>>> чт, 2 мая 2019 г. в 10:53, Barney Pippin <james.pri...@uk.bnpparibas.com
>>> >:
>>>
>>>> Thanks for the response Ilya. Did you get a chance to look at this
>>>> Pavel?
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>>>>
>>>
