Hi Pavel, Thanks for the quick response.
We have trialled the ContinueWith() suggestion which has resolved the issue in testing so far. I suspect this will have only a very minor performance impact. Thanks, Raymond. On Wed, Mar 10, 2021 at 10:33 PM Pavel Tupitsyn <[email protected]> wrote: > Raymond, > > You are right, there is no efficient AND easy way to solve this. > > Basically, user code has to append ContinueWith to every async Ignite API > call manually: > > await cache.GetAsync(1).ContinueWith( > t => t.Result, > CancellationToken.None, > TaskContinuationOptions.None, > TaskScheduler.Default); > > This will move the continuation to the thread pool only for Ignite calls, > where it is necessary. > An extension method can be cleaner, but this is still error-prone and > verbose. > > > There should be a global Ignite setting to move all async continuations > away from the striped pool. > I'm taking the ticket [1] ASAP, it is a shame that we let it sit for so > long. > > [1] https://issues.apache.org/jira/browse/IGNITE-12033 > > On Wed, Mar 10, 2021 at 8:09 AM Raymond Wilson <[email protected]> > wrote: > >> Title correction: Async operations in IA C# client appear dangerous >> >> >> On Wed, Mar 10, 2021 at 6:05 PM Raymond Wilson < >> [email protected]> wrote: >> >>> We are using IA 2.8.1 with the C# client. >>> >>> After triaging intermittent critical thread blockages we determined we >>> have run into this problem reported back in 2019. >>> >>> >>> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html >>> >>> This thread contains suggestions about using SetSynchronizationContext() >>> in a single threaded context, and overriding a method within it to direct >>> all thread continuations into the .Net managed thread pool to resolve the >>> issue. >>> >>> WIthin that thread, this Jira ticket is created: >>> https://issues.apache.org/jira/browse/IGNITE-12033 >>> >>> Reading into the ticket there does not seem to be a good approach >>> suggested to resolve this other than to use the public thread pool rather >>> than the striped thread pool for task continuations. >>> >>> None of the possible paths to solve this issue seem attractive for us: >>> >>> - We use a lot of concurrency (as I suspect every Ignite system would) >>> so the simple SynchronizationContext approach wont work. >>> >>> - Overriding all callbacks via the SynchronizationContext into the >>> managed thread pool not only imposes a performance penalty across the >>> application, but also may direct non-thread pool based threads executing >>> Ignite async operations into the managed thread pool after the async >>> operation has completed, which would have difficult to predict consequences. >>> >>> - Using .ConfigureAwait(true) [which may not be supported in .Net Core] >>> forces synchronization with the call thread, which may be a .Net managed >>> thread pool thread and so may not be available for some time. >>> >>> Initial experiments suggest the SynchronizationContext approach may not >>> work at all in our case with the override solution appearing to make the >>> problem worse. >>> >>> Given the current issues with async Cache operation should this be >>> deprecated in the C# client until the underlying issues are resolved? It is >>> hard to see how any non-trivial C# client based Ignite application can >>> safely use them. >>> >>> Regards, >>> Raymond. >>> >>> -- >>> <http://www.trimble.com/> >>> Raymond Wilson >>> Solution Architect, Civil Construction Software Systems (CCSS) >>> 11 Birmingham Drive | Christchurch, New Zealand >>> [email protected] >>> >>> >>> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >>> >> >> >> -- >> <http://www.trimble.com/> >> Raymond Wilson >> Solution Architect, Civil Construction Software Systems (CCSS) >> 11 Birmingham Drive | Christchurch, New Zealand >> [email protected] >> >> >> <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >> > -- <http://www.trimble.com/> Raymond Wilson Solution Architect, Civil Construction Software Systems (CCSS) 11 Birmingham Drive | Christchurch, New Zealand [email protected] <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
