Just as a followup query: Are async Compute methods susceptible to a similar issue, and should have the same treatment using a ContinueWith()?
Thanks, Raymond. On Thu, Mar 11, 2021 at 8:45 PM Raymond Wilson <raymond_wil...@trimble.com> wrote: > 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 <ptupit...@apache.org> > 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 < >> raymond_wil...@trimble.com> wrote: >> >>> Title correction: Async operations in IA C# client appear dangerous >>> >>> >>> On Wed, Mar 10, 2021 at 6:05 PM Raymond Wilson < >>> raymond_wil...@trimble.com> 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 >>>> raymond_wil...@trimble.com >>>> >>>> >>>> <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 >>> raymond_wil...@trimble.com >>> >>> >>> <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 > raymond_wil...@trimble.com > > > <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 raymond_wil...@trimble.com <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch>
