Igniters,
Bump this thread up. It seems the issue [1] is important but still
unassigned.
[1] https://issues.apache.org/jira/browse/IGNITE-12033
On Thu, 15 Aug 2019 at 15:01, Pavel Tupitsyn wrote:
> Hi Eduard,
>
> Yes, that is the same issue.
> The workaround above is not enough, because SetSy
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.
Upda
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 loo
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 ThreadPoolSynchronizationC
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.
>
>
>
> --
> Sent
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/
Hi,
Thanks for looking. You need to run two instances of the reproducer. Let the
first run until you can see "Wait" on the console then run the second. For me
the second instance won't get past the Replace call in either 2.6 or 2.7.
It's using the default config with nothing else set up over an
