[jira] [Commented] (IGNITE-9742) Illegal change of DiscoveryCustomEvent in GridDhtPartitionsExchangeFuture#onDone
[
https://issues.apache.org/jira/browse/IGNITE-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633122#comment-16633122
]
ASF GitHub Bot commented on IGNITE-9742:
GitHub user daradurvs opened a pull request:
https://github.com/apache/ignite/pull/4875
IGNITE-9742 Illegal change of DiscoveryCustomEvent in
GridDhtPartitionsExchangeFuture#onDone
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daradurvs/ignite ignite-9742
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4875.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4875
commit eabe386acef14647e92ff36d2ffeb0b1ad642df2
Author: Vyacheslav Daradur
Date: 2018-09-29T21:07:04Z
fixed
> Illegal change of DiscoveryCustomEvent in
> GridDhtPartitionsExchangeFuture#onDone
>
>
> Key: IGNITE-9742
> URL: https://issues.apache.org/jira/browse/IGNITE-9742
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
> Labels: discovery
> Fix For: 2.8
>
>
> The following code is called in {{GridDhtPartitionsExchangeFuture#onDone}}:
> {code}
> ((DiscoveryCustomEvent)firstDiscoEvt).customMessage(null);
> {code}
> That means a global instance of 'DiscoveryCustomEvent' is being
> mutated outside discovery-spi infrastructure. It also means that
> discovery listeners receive 'DiscoveryCustomEvent' with 'null' field
> instead of 'CustomMessage' which they may rely on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9742) Illegal change of DiscoveryCustomEvent in GridDhtPartitionsExchangeFuture#onDone
Vyacheslav Daradur created IGNITE-9742:
--
Summary: Illegal change of DiscoveryCustomEvent in
GridDhtPartitionsExchangeFuture#onDone
Key: IGNITE-9742
URL: https://issues.apache.org/jira/browse/IGNITE-9742
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
The following code is called in {{GridDhtPartitionsExchangeFuture#onDone}}:
{code}
((DiscoveryCustomEvent)firstDiscoEvt).customMessage(null);
{code}
That means a global instance of 'DiscoveryCustomEvent' is being
mutated outside discovery-spi infrastructure. It also means that
discovery listeners receive 'DiscoveryCustomEvent' with 'null' field
instead of 'CustomMessage' which they may rely on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9741) SegmentArchivedStorage and SegmentCompressStorage remain `iterrupted` after de-activation occurs before activation
Maxim Muzafarov created IGNITE-9741:
---
Summary: SegmentArchivedStorage and SegmentCompressStorage remain
`iterrupted` after de-activation occurs before activation
Key: IGNITE-9741
URL: https://issues.apache.org/jira/browse/IGNITE-9741
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Maxim Muzafarov
Fix For: 2.7
The {{FileWriteAheadLogManager}} now contains:
{{private final SegmentAware segmentAware;}}
The SegmentAware have the `interrupt()` method:
{code:java|title=SegmentAware:216}
/**
* Interrupt waiting on related objects.
*/
public void interrupt() {
segmentArchivedStorage.interrupt();
segmentCompressStorage.interrupt();
segmentCurrStateStorage.interrupt();
}
{code}
Method at the {{FileWriteAheadLogManager}} de-activation sets (e.g. for
SegmentArchivedStorage) `interrupted` filed to `true` value but never revert it
to `false` after activation.
{code:java|title=SegmentArchivedStorage:114}
/**
* Interrupt waiting on this object.
*/
synchronized void interrupt() {
interrupted = true;
notifyAll();
}
{code}
So, the SegmentArchivedStorage after de-activation always remain interrupted.
This can lead to undefined behaviour e.g. exchange worker hangs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8788) Getting NullPointerException during commit into cassandra, after reconnecting to ignite server
[ https://issues.apache.org/jira/browse/IGNITE-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632961#comment-16632961 ] Igor Kamyshnikov commented on IGNITE-8788: -- There is one other aspect of this issue. Let's assume that ignite server config has Cassandra caches A and B. And ignite client config has A, B and C. If such ignite client joins the cluster it infects it: no other clients would be able to join this cluster even if they have just A and B caches defined in their configs (their Ignition.start threads will hang). New Ignite server nodes would not be able to join the cluster as well (dying with the exception mentioned in the ticket). And even if that "bad" client leaves the cluster, the cluster cannot be joined by new correct clients and servers. > Getting NullPointerException during commit into cassandra, after reconnecting > to ignite server > -- > > Key: IGNITE-8788 > URL: https://issues.apache.org/jira/browse/IGNITE-8788 > Project: Ignite > Issue Type: Bug > Components: cassandra >Reporter: Yashasvi Kotamraju >Assignee: Igor Rudyak >Priority: Major > > When ignite client reconnects to restarted ignite server, while commiting > data into cassandra NullPointerException is observed for random runs. > caused by: java.lang.NullPointerException > at > org.apache.ignite.cache.store.cassandra.persistence.PojoField.getValueFromObject(PojoField.java:167) > > at > org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:450) > > at > org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:202) > > at > org.apache.ignite.cache.store.cassandra.session.transaction.WriteMutation.bindStatement(WriteMutation.java:58) > > at > org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:499) > > > After going through the source code > there is a suspicion that its a java serialization issue in ignite cassandra > module > In org.apache.ignite.cache.store.cassandra.persistence.PojoField.java, there > is a PojoFieldAccessor instance variable which is transient type, so it will > not be part of serialization and if PojoField object is serialized and then > deserialized it would have PojoFieldAccessor as null. And in the Exception > we are seeing the same, NullPointerException when getValue(..) is called on > null PojoFieldAccessor in PojoField.getValueFromObject() method . So when > ever PojoField object is serialized and then deserialized we might be > observing the issue. > Reproducer can be found at: > http://apache-ignite-users.70518.x6.nabble.com/Getting-NullPointerException-during-commit-into-cassandra-after-reconnecting-to-ignite-server-td22005.html > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632901#comment-16632901
]
Dmitriy Pavlov commented on IGNITE-7618:
Folks, let me remind that MTCGA was not handled
[MTCGA]: new failures in builds [1871897] needs to be handled
https://lists.apache.org/thread.html/16c8718047b6514f41c5987b8571a8fb64d20893ad5803dfe23d2ab7@%3Cdev.ignite.apache.org%3E
the test is still fail
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.7
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:197)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$Asyn
[jira] [Commented] (IGNITE-9272) PureJavaCrc32 vs j.u.zip.CRC32 benchmark and probably replace.
[ https://issues.apache.org/jira/browse/IGNITE-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632893#comment-16632893 ] Stanilovsky Evgeny commented on IGNITE-9272: [~NIzhikov], thanks for review, hope all your comments resolved besides crcWithReset func namig. > PureJavaCrc32 vs j.u.zip.CRC32 benchmark and probably replace. > -- > > Key: IGNITE-9272 > URL: https://issues.apache.org/jira/browse/IGNITE-9272 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.8 > > Attachments: BenchmarkCRC.java > > > I see that Ignite has its own crc32 realization called: PureJavaCrc32 and > from desc it seems to be : _The current version is ~10x to 1.8x as fast as > Sun's native java.util.zip.CRC32 in Java 1.6_ But my jmh tests show opposite > results. > + If it really so, looks like backward compatibility would be easy, all that > need is just to take lower part of long form zip.crc32 realization. > jmh results: > Benchmark Mode CntScoreError Units > BenchmarkCRC.Crc32 avgt5 1521060.716 ± 44083.424 ns/op > BenchmarkCRC.pureJavaCrc32 avgt5 4657756.671 ± 177243.254 ns/op > JMH version: 1.21 > VM version: JDK 1.8.0_131, Java HotSpot(TM) 64-Bit Server VM, 25.131-b11 > VM invoker: /usr/lib/jvm/java-8-oracle/jre/bin/java > op system : ubuntu 16.10 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
