Hi Eduard, Yes, that is the same issue. The workaround above is not enough, because SetSynchronizationContext affects only the current thread. After the first async operation completes, the continuation is dispatched to some ThreadPool thread, which may not have a SynchronizationContext set.
Hi guys, We are also facing a similar problem, if not the same. Our main difference with the initial reproducer is that we are using the Thick Client. We applied the suggested fix of setting the SynchronizationContext, but we also perform a GetAsync after the initial PutAsync. Also, I added a
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
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 : > Thanks for the response Ilya. Did you get a chance to look at this Pavel? > Thanks. > > > > -- >
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/
Hello! Yes, I can reproduce this scenario. I attribute it to async/await, where there is a .Net callback which is invoked from cache operation and which calls cache operations, and this leads to attempts of scheduling striped pool operations to same stripe as cuirrently occupied. Pavel, what do
Hi, is anyone else seeing this or able to reproduce? Thanks! -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
et up over and above the code you can see on the first post. Thanks -Original Message- From: Alexandr Shapkin Sent: 15 April 2019 11:46 To: email@example.com Subject: [EXTERNAL] Re: Replace or Put after PutAsync causes Ignite to hang Hi, I took a look at the reproducer and it works