Denis, > we don't try to solve the problem mentioned in the IEP
The problem: user code executes on striped pool (which causes issues) The solution: don't execute user code on striped pool I believe this solves the problem and removes any and all restrictions for async listeners/continuations. Am I missing something else? On Wed, Mar 17, 2021 at 10:16 AM Denis Garus <garus....@gmail.com> wrote: > Hello! > > As I understood, we don't try to solve the problem mentioned in the IEP: > there is unexpected behavior, > users should carefully read the docs to know about this, and so on. > A thread that executes an incorrect listener hung in any case, > and the suggested solution is to change the pool which owns this thread. > Did you consider an option to execute user-defined listeners with a > timeout? > I think that implicit using java pools to run a code that can be hung is a > questionable solution. > > вт, 16 мар. 2021 г. в 23:30, Alexey Kukushkin <kukushkinale...@gmail.com>: > > > Pavel, > > > > So what you are saying is submitting a continuation to .NET Thread Pool > > already respects current SynchronizationContext and ConfigureAwait. In > > this case the IEP looks complete (for some reason I thought that we > should > > take care about the SynchronizationContext inside the Ignite.NET > > implementation). > > > > -- > > Best regards, > > Alexey > > >
