[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query
[ https://issues.apache.org/jira/browse/IGNITE-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Man updated IGNITE-3984: -- Attachment: ContQueryTest.java > NullPointerException in IgniteCacheProxy when creating continuous query > --- > > Key: IGNITE-3984 > URL: https://issues.apache.org/jira/browse/IGNITE-3984 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.7 >Reporter: Jason Man > Attachments: ContQueryTest.java > > > Test attached. This used to work fine in 1.6. This seem to be related to > this jira and PR: > https://issues.apache.org/jira/browse/IGNITE-3413 > https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284 > Here's the scenario: > * First node starts with special attribute and creates a cache with the node > filter that allows to deploy it only on nodes with this attribute > * Second node starts without the attribute is started. When creating a > continuous query to query the cache created by the first node, a > NullPointerException is thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query
[
https://issues.apache.org/jira/browse/IGNITE-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Man updated IGNITE-3984:
--
Description:
Test attached. This used to work fine in 1.6. This seem to be related to this
jira and PR:
{code}
Exception in thread "main" javax.cache.CacheException:
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}
https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
Here's the scenario:
* First node starts with special attribute and creates a cache with the node
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started. When creating a
continuous query to query the cache created by the first node, a
NullPointerException is thrown.
At first glance, it seems that because the NodeFilter prevented the
GridContinuousProcessor.registerHandler() to be called , the
ConcurrentMap rcvs is not initialized properly and
NullPointerException is thrown on this line:
{code}
@NotNull private PartitionRecovery
getOrCreatePartitionRecovery(GridKernalContext ctx, int partId) {
PartitionRecovery rec = rcvs.get(partId);
{code}
was:
Test attached. This used to work fine in 1.6. This seem to be related to this
jira and PR:
https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
Here's the scenario:
* First node starts with special attribute and creates a cache with the node
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started. When creating a
continuous query to query the cache created by the first node, a
NullPointerException is thrown.
> NullPointerException in IgniteCacheProxy when creating continuous query
> ---
>
> Key: IGNITE-3984
> URL: https://issues.apache.org/jira/browse/IGNITE-3984
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Jason Man
> Attachments: ContQueryTest.java
>
>
> Test attached. This used to work fine in 1.6. This seem to be related to
> this jira and PR:
> {code}
> Exception in thread "main" javax.cache.CacheException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
> at ContQueryTest.main(ContQueryTest.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
> at
>
[jira] [Created] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query
Jason Man created IGNITE-3984: - Summary: NullPointerException in IgniteCacheProxy when creating continuous query Key: IGNITE-3984 URL: https://issues.apache.org/jira/browse/IGNITE-3984 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 1.7 Reporter: Jason Man Test attached. This used to work fine in 1.6. This seem to be related to this jira and PR: https://issues.apache.org/jira/browse/IGNITE-3413 https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284 Here's the scenario: * First node starts with special attribute and creates a cache with the node filter that allows to deploy it only on nodes with this attribute * Second node starts without the attribute is started. When creating a continuous query to query the cache created by the first node, a NullPointerException is thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query
[
https://issues.apache.org/jira/browse/IGNITE-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Man updated IGNITE-3984:
--
Description:
Test attached. This used to work fine in 1.6.
{code}
Exception in thread "main" javax.cache.CacheException:
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}
This seem to be related to this jira and PR:
https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
Here's the scenario:
* First node starts with special attribute and creates a cache with the node
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started. When creating a
continuous query to query the cache created by the first node, a
NullPointerException is thrown.
At first glance, it seems that because the NodeFilter prevented the
GridContinuousProcessor.registerHandler() to be called , the
ConcurrentMap rcvs is not initialized properly and
NullPointerException is thrown on this line:
{code}
@NotNull private PartitionRecovery
getOrCreatePartitionRecovery(GridKernalContext ctx, int partId) {
PartitionRecovery rec = rcvs.get(partId);
{code}
was:
Test attached. This used to work fine in 1.6. This seem to be related to this
jira and PR:
{code}
Exception in thread "main" javax.cache.CacheException:
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
at ContQueryTest.main(ContQueryTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
... 6 more
{code}
https://issues.apache.org/jira/browse/IGNITE-3413
https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
Here's the scenario:
* First node starts with special attribute and creates a cache with the node
filter that allows to deploy it only on nodes with this attribute
* Second node starts without the attribute is started. When creating a
continuous query to query the cache created by the first node, a
NullPointerException is thrown.
At first glance, it seems that because the NodeFilter prevented the
[jira] [Commented] (IGNITE-3413) Node is not started if continuous query remote filter class is not found
[ https://issues.apache.org/jira/browse/IGNITE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15528088#comment-15528088 ] Jason Man commented on IGNITE-3413: --- Hi Alexander, fixing this seem to have introduced a NullPointerException in a slightly different scenario. I have filed issue IGNITE-3984 with the description of a scenario I encountered. > Node is not started if continuous query remote filter class is not found > > > Key: IGNITE-3413 > URL: https://issues.apache.org/jira/browse/IGNITE-3413 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Valentin Kulichenko > Fix For: 1.7 > > Attachments: ContQueryTest.java > > > Test attached. > The scenario is the following: > * First node starts with the special attribute and creates a cache with the > node filter that allows to deploy it only on nodes with this attribute. > * Continuous query with a remote filter is executed. > * Second node without the attribute is started. It doesn't have the remote > filter class, the factory throws an exception and the node doesn't start at > all, regardless of the fact that it doesn't even has the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3984) NullPointerException in IgniteCacheProxy when creating continuous query
[
https://issues.apache.org/jira/browse/IGNITE-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544198#comment-15544198
]
Jason Man commented on IGNITE-3984:
---
Although I'm not sure which PR fixes this, but the latest 1.8.0-SNAPSHOT seem
to have fixed this problem. I've downloaded it from here:
https://builds.apache.org/view/H-L/view/Ignite/job/Ignite-nightly/lastSuccessfulBuild/
and tried it successfully.
> NullPointerException in IgniteCacheProxy when creating continuous query
> ---
>
> Key: IGNITE-3984
> URL: https://issues.apache.org/jira/browse/IGNITE-3984
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.7
>Reporter: Jason Man
> Attachments: ContQueryTest.java
>
>
> Test attached. This used to work fine in 1.6.
> {code}
> Exception in thread "main" javax.cache.CacheException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:709)
> at ContQueryTest.main(ContQueryTest.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.getOrCreatePartitionRecovery(CacheContinuousQueryHandler.java:835)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.waitTopologyFuture(CacheContinuousQueryHandler.java:543)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:660)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery(CacheContinuousQueryManager.java:482)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.queryContinuous(IgniteCacheProxy.java:611)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:669)
> ... 6 more
> {code}
> This seem to be related to this jira and PR:
> https://issues.apache.org/jira/browse/IGNITE-3413
> https://github.com/apache/ignite/commit/89d64e74b697054a88c3a91433aaaf4f7fdd0284
> Here's the scenario:
> * First node starts with special attribute and creates a cache with the node
> filter that allows to deploy it only on nodes with this attribute
> * Second node starts without the attribute is started. When creating a
> continuous query to query the cache created by the first node, a
> NullPointerException is thrown.
> At first glance, it seems that because the NodeFilter prevented the
> GridContinuousProcessor.registerHandler() to be called , the
> ConcurrentMap rcvs is not initialized properly
> and NullPointerException is thrown on this line:
> {code}
> @NotNull private PartitionRecovery
> getOrCreatePartitionRecovery(GridKernalContext ctx, int partId) {
> PartitionRecovery rec = rcvs.get(partId);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265057#comment-16265057 ] Jason Man commented on IGNITE-6853: --- PR available above with the fix. Please review. Thanks. > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6972) BinaryObjectBuilderImpl.build is stuck when server cluster is restarted
Jason Man created IGNITE-6972:
-
Summary: BinaryObjectBuilderImpl.build is stuck when server
cluster is restarted
Key: IGNITE-6972
URL: https://issues.apache.org/jira/browse/IGNITE-6972
Project: Ignite
Issue Type: Bug
Components: binary
Affects Versions: 2.3
Reporter: Jason Man
When a client node is using a BinaryObjectBuilder to build a BinaryObject, the
build() method could get stuck if the cluster is being restarted.
Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition
[0x023bf000]
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.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
...
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6972) BinaryObjectBuilderImpl.build is stuck when server cluster is restarted
[
https://issues.apache.org/jira/browse/IGNITE-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Man updated IGNITE-6972:
--
Description:
When a client node is using a BinaryObjectBuilder to build a BinaryObject, the
build() method could get stuck if the cluster is being restarted.
Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition
[0x023bf000]
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.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
...
{code}
Possible solution
Should we use the get(long timeout) instead of get() which never times out?
was:
When a client node is using a BinaryObjectBuilder to build a BinaryObject, the
build() method could get stuck if the cluster is being restarted.
Thread dump of the stack is
{code}
"main" #1 prio=5 os_prio=0 tid=0x004d9000 nid=0x62ac waiting on condition
[0x023bf000]
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.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:441)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:182)
at
org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:793)
at
org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:752)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:623)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:207)
at
org.apache.ignite.internal.binary.builder.BinaryValueWithType.writeTo(BinaryValueWithType.java:48)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
at
org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
at
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313)
at
[jira] [Comment Edited] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326853#comment-16326853 ] Jason Man edited comment on IGNITE-6853 at 1/16/18 8:15 AM: This is less than ideal though. I am trying this and the number of lines of the test class quickly grows from 1xx lines to 800+ lines of boiler plate code. Even at this point I'm still not done mocking the objects manually. Then eventually I get stuck at mocking this class com.datastax.driver.core.ColumnDefinitions because it lacks a public constructor so I couldn't call super() when I try to extend it. See attachment of the work so far: [^CassandraSessionImplTest.java] I think there are good reasons Mockito is popular for testing and this is the use case where it is very powerful at helping write unit tests. Perhaps we could really consider adopting it or some other mocking framework if there is a preference for something else? was (Author: jason@gmail.com): This is less than ideal though. I am trying this and the number of lines of the test class quickly grows from 1xx lines to 800+ lines of boiler plate code. Then eventually I get stuck at mocking this class com.datastax.driver.core.ColumnDefinitions because it lacks a public constructor so I couldn't call super() when I try to extend it. See attachment of the work so far: [^CassandraSessionImplTest.java] > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.4 > > Attachments: CassandraSessionImplTest.java > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326853#comment-16326853 ] Jason Man commented on IGNITE-6853: --- This is less than ideal though. I am trying this and the number of lines of the test class quickly grows from 1xx lines to 800+ lines of boiler plate code. Then eventually I get stuck at mocking this class com.datastax.driver.core.ColumnDefinitions because it lacks a public constructor so I couldn't call super() when I try to extend it. See attachment of the work so far: [^CassandraSessionImplTest.java] > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.4 > > Attachments: CassandraSessionImplTest.java > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Man updated IGNITE-6853: -- Attachment: CassandraSessionImplTest.java > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.4 > > Attachments: CassandraSessionImplTest.java > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16326691#comment-16326691 ] Jason Man commented on IGNITE-6853: --- It's difficult to simulate the Cassandra errors without using a mocking framework. I think this is why currently there is a lack of 'negative' tests covering the ignite-cassandra module, and why this bug was not discovered/fixed earlier. Perhaps we could start discussing this in the community dev email list? > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328146#comment-16328146 ] Jason Man commented on IGNITE-6853: --- As discussed, updated the PR with the change to put the mockito version at the parent POM and using it on the cassandra module. [https://github.com/apache/ignite/pull/3088] [~irudyak] please review. Thanks. > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.4 > > Attachments: CassandraSessionImplTest.java > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Man reassigned IGNITE-6853: - Assignee: Jason Man (was: Mikhail Cherkasov) > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man > Labels: important > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265057#comment-16265057 ] Jason Man edited comment on IGNITE-6853 at 1/2/18 10:10 AM: The simple fix is to re-prepare the statement after recovering the connection. PR available above with the fix. Please review. Thanks. was (Author: jason@gmail.com): PR available above with the fix. Please review. Thanks. > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man > Labels: important > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307824#comment-16307824 ] Jason Man commented on IGNITE-6853: --- [~irudyak], Please review my changes. > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man > Labels: important > Fix For: 2.4 > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed
[ https://issues.apache.org/jira/browse/IGNITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Man updated IGNITE-6252: -- Fix Version/s: (was: 2.4) 2.5 > Cassandra Cache Store Session does not retry if prepare statement failed > > > Key: IGNITE-6252 > URL: https://issues.apache.org/jira/browse/IGNITE-6252 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.0, 2.1 >Reporter: Sunny Chan >Assignee: Igor Rudyak >Priority: Major > Fix For: 2.5 > > > During our testing, we have found that certain warning about prepared > statement: > 2017-08-31 11:27:19.479 > org.apache.ignite.cache.store.cassandra.CassandraCacheStore > flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster > error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have > used a PreparedStatement that was created with another Cluster instance. > We notice that after this warning occurs some of the data didn't persist > properly in cassandra cache. After further examining the Ignite's > CassandraSessionImpl code in method > execute(BatchExecutionAssistance,Iterable), we found that at around [line > 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283], > if the prepare statement fails in the asnyc call, it will not retry the > operation as the error is stored in [line > 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269] > and cleared in [line > 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277] > but it was not checked again after going through the [ResultSetFuture > |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307]. > I believe in line 307 you should check for error != null such that any > failure will be retry. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session
[ https://issues.apache.org/jira/browse/IGNITE-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Man updated IGNITE-6853: -- Fix Version/s: (was: 2.4) 2.5 > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session > > > Key: IGNITE-6853 > URL: https://issues.apache.org/jira/browse/IGNITE-6853 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Jason Man >Priority: Major > Labels: important > Fix For: 2.5 > > Attachments: CassandraSessionImplTest.java > > > Cassandra cache store does not clean prepared statements cache when remove > old cassandra session which can lead to: > Prepared > statement cluster error detected, refreshing Cassandra session > com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute > unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have > used a PreparedStatement that was created with another Cluster instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
