[JBoss JIRA] (ISPN-7089) SingleFileCacheStore; Metadata is sometimes corrupted
by Elias Ross (JIRA)
[ https://issues.jboss.org/browse/ISPN-7089?page=com.atlassian.jira.plugin.... ]
Elias Ross commented on ISPN-7089:
----------------------------------
Code is:
// sanity check
if (fe.size < KEY_POS + fe.keyLen + fe.dataLen + fe.metadataLen) {
throw log.errorReadingFileStore(file.getPath(), filePos);
}
Perhaps this check does not apply for very large files, especially if the file is > 2GB? It seems to have consistently happened on a number of hosts.
> SingleFileCacheStore; Metadata is sometimes corrupted
> -----------------------------------------------------
>
> Key: ISPN-7089
> URL: https://issues.jboss.org/browse/ISPN-7089
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Elias Ross
> Assignee: Galder Zamarreño
>
> Over time I have observed the following exceptions:
> 2016-10-06 15:40:26.261 [level=ERROR] - java.io.IOException: Unsupported protocol version 163
> org.infinispan.persistence.spi.PersistenceException: java.io.IOException: Unsupported protocol version 163
> at org.infinispan.marshall.core.MarshalledEntryImpl.unmarshall(MarshalledEntryImpl.java:116) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.marshall.core.MarshalledEntryImpl.getMetadata(MarshalledEntryImpl.java:72) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.loadAndCheckExpiration(PersistenceUtil.java:120) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.lambda$loadAndStoreInDataContainer$0(PersistenceUtil.java:98) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.DefaultDataContainer.lambda$compute$3(DefaultDataContainer.java:325) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3600) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:324) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.loadAndStoreInDataContainer(PersistenceUtil.java:91) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:371) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:366) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:187) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:141) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> This seems to happen fairly regularly on a number of different hosts.
> The invalid version values seem to change.
> I'm wondering if there is a race condition in how the data is stored, and in particular the metadata.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7089) SingleFileCacheStore; Metadata is sometimes corrupted
by Elias Ross (JIRA)
[ https://issues.jboss.org/browse/ISPN-7089?page=com.atlassian.jira.plugin.... ]
Elias Ross commented on ISPN-7089:
----------------------------------
This can happen if the cache isn't cleanly shutdown and simply restarted.
I have also seen this:
Caused by: org.infinispan.persistence.spi.PersistenceException: ISPN000279: Failed to read stored entries from file. Error in file /opt/.../var/cache/raster.dat at offset 6774941351
at org.infinispan.persistence.file.SingleFileStore.rebuildIndex(SingleFileStore.java:195) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> SingleFileCacheStore; Metadata is sometimes corrupted
> -----------------------------------------------------
>
> Key: ISPN-7089
> URL: https://issues.jboss.org/browse/ISPN-7089
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Elias Ross
> Assignee: Galder Zamarreño
>
> Over time I have observed the following exceptions:
> 2016-10-06 15:40:26.261 [level=ERROR] - java.io.IOException: Unsupported protocol version 163
> org.infinispan.persistence.spi.PersistenceException: java.io.IOException: Unsupported protocol version 163
> at org.infinispan.marshall.core.MarshalledEntryImpl.unmarshall(MarshalledEntryImpl.java:116) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.marshall.core.MarshalledEntryImpl.getMetadata(MarshalledEntryImpl.java:72) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.loadAndCheckExpiration(PersistenceUtil.java:120) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.lambda$loadAndStoreInDataContainer$0(PersistenceUtil.java:98) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.DefaultDataContainer.lambda$compute$3(DefaultDataContainer.java:325) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3600) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:324) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.persistence.PersistenceUtil.loadAndStoreInDataContainer(PersistenceUtil.java:91) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:371) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:366) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:187) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:141) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> This seems to happen fairly regularly on a number of different hosts.
> The invalid version values seem to change.
> I'm wondering if there is a race condition in how the data is stored, and in particular the metadata.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7722) NPE in LocalTopologyManagerImpl when undeploying an application
by Alexis NICOLAS (JIRA)
[ https://issues.jboss.org/browse/ISPN-7722?page=com.atlassian.jira.plugin.... ]
Alexis NICOLAS updated ISPN-7722:
---------------------------------
Issue Type: Bug (was: Feature Request)
> NPE in LocalTopologyManagerImpl when undeploying an application
> ---------------------------------------------------------------
>
> Key: ISPN-7722
> URL: https://issues.jboss.org/browse/ISPN-7722
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Final
> Environment: JBoss 6.3.3.GA & Tomcat 8.5.8
> Reporter: Alexis NICOLAS
>
> When undeploying an application using Infinispan configured with global state disabled from an application server you get the following error:
> {code}
> 2017-04-12 15:54:28.617 WARN o.i.t.CacheTopologyControlCommand:165 - ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=XXXXX, type=SHUTDOWN_PERFORM, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=0}
> java.lang.NullPointerException: null
> at org.infinispan.topology.LocalTopologyManagerImpl.handleCacheShutdown(LocalTopologyManagerImpl.java:655)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:204)
> at org.infinispan.topology.CacheTopologyControlCommand.invokeAsync(CacheTopologyControlCommand.java:159)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.invokeReplicableCommand(GlobalInboundInvocationHandler.java:173)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runReplicableCommand(GlobalInboundInvocationHandler.java:154)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleReplicableCommand$1(GlobalInboundInvocationHandler.java:148)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:203)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It seems to be that in the method handleCacheShutdown(...) method of LocalTopologyManagerImpl a test whether globalStateManager is null is missing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7722) NPE in LocalTopologyManagerImpl when undeploying an application
by Alexis NICOLAS (JIRA)
[ https://issues.jboss.org/browse/ISPN-7722?page=com.atlassian.jira.plugin.... ]
Alexis NICOLAS updated ISPN-7722:
---------------------------------
Summary: NPE in LocalTopologyManagerImpl when undeploying an application (was: NPE in LocalTopologyManagerImpl when undeploying the application)
> NPE in LocalTopologyManagerImpl when undeploying an application
> ---------------------------------------------------------------
>
> Key: ISPN-7722
> URL: https://issues.jboss.org/browse/ISPN-7722
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 9.0.0.Final
> Environment: JBoss 6.3.3.GA & Tomcat 8.5.8
> Reporter: Alexis NICOLAS
>
> When undeploying an application using Infinispan configured with global state disabled from an application server you get the following error:
> {code}
> 2017-04-12 15:54:28.617 WARN o.i.t.CacheTopologyControlCommand:165 - ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=XXXXX, type=SHUTDOWN_PERFORM, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=0}
> java.lang.NullPointerException: null
> at org.infinispan.topology.LocalTopologyManagerImpl.handleCacheShutdown(LocalTopologyManagerImpl.java:655)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:204)
> at org.infinispan.topology.CacheTopologyControlCommand.invokeAsync(CacheTopologyControlCommand.java:159)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.invokeReplicableCommand(GlobalInboundInvocationHandler.java:173)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runReplicableCommand(GlobalInboundInvocationHandler.java:154)
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleReplicableCommand$1(GlobalInboundInvocationHandler.java:148)
> at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:203)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It seems to be that in the method handleCacheShutdown(...) method of LocalTopologyManagerImpl a test whether globalStateManager is null is missing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7722) NPE in LocalTopologyManagerImpl when undeploying the application
by Alexis NICOLAS (JIRA)
Alexis NICOLAS created ISPN-7722:
------------------------------------
Summary: NPE in LocalTopologyManagerImpl when undeploying the application
Key: ISPN-7722
URL: https://issues.jboss.org/browse/ISPN-7722
Project: Infinispan
Issue Type: Feature Request
Components: Core
Affects Versions: 9.0.0.Final
Environment: JBoss 6.3.3.GA & Tomcat 8.5.8
Reporter: Alexis NICOLAS
When undeploying an application using Infinispan configured with global state disabled from an application server you get the following error:
{code}
2017-04-12 15:54:28.617 WARN o.i.t.CacheTopologyControlCommand:165 - ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=XXXXX, type=SHUTDOWN_PERFORM, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=0}
java.lang.NullPointerException: null
at org.infinispan.topology.LocalTopologyManagerImpl.handleCacheShutdown(LocalTopologyManagerImpl.java:655)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:204)
at org.infinispan.topology.CacheTopologyControlCommand.invokeAsync(CacheTopologyControlCommand.java:159)
at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.invokeReplicableCommand(GlobalInboundInvocationHandler.java:173)
at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runReplicableCommand(GlobalInboundInvocationHandler.java:154)
at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleReplicableCommand$1(GlobalInboundInvocationHandler.java:148)
at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:203)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
It seems to be that in the method handleCacheShutdown(...) method of LocalTopologyManagerImpl a test whether globalStateManager is null is missing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7144) Cross-Site Replication: inconsistent data with multiple site masters
by Zefa Guan (JIRA)
[ https://issues.jboss.org/browse/ISPN-7144?page=com.atlassian.jira.plugin.... ]
Zefa Guan commented on ISPN-7144:
---------------------------------
Thank you!
> Cross-Site Replication: inconsistent data with multiple site masters
> --------------------------------------------------------------------
>
> Key: ISPN-7144
> URL: https://issues.jboss.org/browse/ISPN-7144
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.0.0.Alpha4
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 9.0.1.Final
>
>
> Cross-Site replication with multiple site masters may not work properly when configured asynchronously.
> It relies on the deliver order of the updates to the remote site but, with multiple site masters, it is possible an update to go through one of the possible routes. Having commands going through different routes violates the FIFO order needed leading to inconsistent data between sites.
> Note: it doesn't happen in synchronous mode.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7720) Add another kubernetes-dev JGroups stack
by Sebastian Łaskawiec (JIRA)
Sebastian Łaskawiec created ISPN-7720:
-----------------------------------------
Summary: Add another kubernetes-dev JGroups stack
Key: ISPN-7720
URL: https://issues.jboss.org/browse/ISPN-7720
Project: Infinispan
Issue Type: Enhancement
Reporter: Sebastian Łaskawiec
Assignee: Sebastian Łaskawiec
Priority: Critical
It should allow to do rolling updates quickly and will less pain.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months
[JBoss JIRA] (ISPN-7224) Support synchronous get in Spring's cache abstraction
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-7224:
-------------------------------------------
After talking with [~pruivo] and [~dan.berindei] about this, we have a couple of options:
* For Embedded mode:
** We can implement lightweight locking (in JDK sense) in {{CacheDelegate}}. With a [small change (currently {{SpringEmbeddedCacheManager}} always return new SpringCache instance)|https://github.com/infinispan/infinispan/blob/313b19301055c6267...] it should work fine within a single {{SpringEmbeddedCacheManager}}.
** For full support we need pessimistic transactions (which do the locking). This is definitely a heavyweight solution.
* For Client/Server mode
** For better support we should probably wait for Hot Rod transactions (which will happen soon).
** But to start with something, we could implement lightweight locking as I proposed in Embedded mode.
> Support synchronous get in Spring's cache abstraction
> -----------------------------------------------------
>
> Key: ISPN-7224
> URL: https://issues.jboss.org/browse/ISPN-7224
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Reporter: Stéphane Nicoll
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Fix For: 9.0.0.Beta1, 9.0.0.Final
>
>
> Spring Framework 4.3 has introduced a read-through option See https://jira.spring.io/browse/SPR-9254 for more details. In practice this would require you to compile against 4.3 and implement the additional method.
> The code is meant to be backward compatible with previous version, as long as you're guarding the new exception in an inner class, see [this implementation for an example|https://github.com/hazelcast/hazelcast/blob/37ba79c4a8d35617c5f6a...]
> Let me know if I can help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 12 months