[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265836#comment-17265836
]
Yaroslav Molochkov commented on IGNITE-13949:
---------------------------------------------
[~alex_pl], no, unfortunately I don't have the reproducer because I don't have
the context of the problem, yet the error in IGNITE-12854 is exactly the same
as I saw it.
Of course, the synchronisation will incur performance penalty, yet I find some
strange operations like incrementing value without lock, while some operations
with that same value are under the native lock. It very well could be the case
where we can get away without proper sync, of course, and there's a great
chance that I'm mistaken in my assumptions since I don't have a viable
reproduces or details of the situations where we can see that error.
But in any case, I think it's strange that we care for these little unsafe
optimisations yet we use native monitors, instead maybe we should use stamped
lock idioms for attempted non-blocking value change, etc, etc.
Furthermore, the PartitionUpdateCounterTrackingImpl's inheritance is not
prohibited while it is clearly is not designed for that purpose. And the way
the inheritance is implemented is it's subclass is kinda weird. In essence,
what I want to say is that client code might suffer because of said quirks.
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> ------------------------------------------------------------------
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.9.1
> Reporter: Yaroslav Molochkov
> Assignee: Yaroslav Molochkov
> Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
