Hello!
I think that you need to start a new isolated transaction from callback
(possibly in another thread) to get proper isolation.
Regards,
--
Ilya Kasnacheev
пт, 21 авг. 2020 г. в 18:34, ssansoy :
> Still seeing the same issue in 2.8.1 unfortunately.
>
> I have a related question however.
Still seeing the same issue in 2.8.1 unfortunately.
I have a related question however.
Assuming I perform the following operation on node 1 of my 3 node cluster
(All caches use CacheRebalanceMode.SYNC,
CacheWriteSynchronizationMode.FULL_SYNC, CacheAtomicityMode.TRANSACTIONAL):
t
Hello!
It is supposed to be fixed in 2.8. Did you check that?
Thanks.
--
Ilya Kasnacheev
ср, 22 июл. 2020 г. в 12:24, ssansoy :
> Hi, could the behaviour I have observed be captured by this bug:
>
> https://issues.apache.org/jira/browse/IGNITE-9841
>
> "Note, ScanQuery exhibits the same behav
Hi, could the behaviour I have observed be captured by this bug:
https://issues.apache.org/jira/browse/IGNITE-9841
"Note, ScanQuery exhibits the same behavior - returns partial results when
some partitions are lost. Not sure if solution would be related or needs to
be tracked and fixed under a s
Hello!
I'm not actually sure. Do you have a reproducer where you see decreased
count() result? What is PartitionLossPolicy, have you tried tweaking it?
I can see a method in our tests for doing that, and it is very raw: it
checks every cache to make sure that all partitions are OWNING. This
is
o
By the way, just referring back to the original question - is there such a
callback that can be used to wait for the partition exchange to complete, in
any version of ignite? We are using ignite 2.7.6 (which I acknowledge is
slightly behind - but we planning to upgrade)
--
Sent from: http://apa
Hi, the following setup should reproduce the issue:
A server class starts up a server node with the config in my original mail
(eg 3 servers, partitioned with 1 backup). In that class, at the end do
something like:
ignite.events(ignite.cluster().forServers()).localListen(ignitePredicate,
Hello!
Can you throw together a reproducer project which shows this behavior? I
would check.
Regards,
--
Ilya Kasnacheev
пт, 3 июл. 2020 г. в 13:14, ssansoy :
> Thanks - the issue I have now is how can I confirm that the local listen
> has
> returned before executing my code?
> e.g. in the lo
Thanks - the issue I have now is how can I confirm that the local listen has
returned before executing my code?
e.g. in the local listen I can set a flag, and then the local listen returns
- but the thread that detects this flag and runs the task could still be
scheduled to run before the local lis
Hello!
Yes, you need to return from event listener as soon as you can.
Regards,
--
Ilya Kasnacheev
пт, 3 июл. 2020 г. в 12:03, ssansoy :
> Hi Ilya, thanks for the quick help!
> Within the local listen, I am adding a task to an executor - so the cache
> operations happen in a different thread.
Hi Ilya, thanks for the quick help!
Within the local listen, I am adding a task to an executor - so the cache
operations happen in a different thread. However, is the key thing here that
the local listen handler metho needs to have returned?
E.g. the local listen may not have fully completed by the
Hello!
Do you issue your cache operations from event listener thread? This might
be unsafe and also not return the expected results. Event listeners are
invoked from internal threads.
Consider issuing a task to public pool from event listener, and then
returning. I would expect that task will run
Hi Ignite users,
I have 3 nodes running, with a cache with the following configuration:
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setBackups(1);
cacheConfiguration.setRebalanceMode(CacheRebalanceMode.SYNC);
cacheConfiguration.setWriteSynchronizationMode(CacheWrite
13 matches
Mail list logo
