[JBoss JIRA] (ISPN-3234) Upgrade to JCache 0.x
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-3234:
--------------------------------------
Summary: Upgrade to JCache 0.x
Key: ISPN-3234
URL: https://issues.jboss.org/browse/ISPN-3234
Project: Infinispan
Issue Type: Component Upgrade
Components: JCache
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 6.0.0.Final
When next JCache version is released, upgrade and re-enable the following TCK tests which have been disabled in ISPN-3213:
{code}org.jsr107.tck.CacheStatisticsTest#testCacheStatistics
org.jsr107.tck.CacheStatisticsTest#testCacheStatisticsInvokeEntryProcessorGet
org.jsr107.tck.CacheStatisticsTest#testCacheStatisticsInvokeEntryProcessorCreate
org.jsr107.tck.CacheStatisticsTest#testCacheStatisticsInvokeEntryProcessorRemove
org.jsr107.tck.CacheStatisticsTest#testIterateAndRemove
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-2891) Gap in time between commit of transaction and actual value update
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño resolved ISPN-2891.
------------------------------------
Labels: (was: 5.2.x)
Assignee: Galder Zamarreño (was: Mircea Markus)
Fix Version/s: (was: 5.3.0.Final)
Resolution: Rejected
> Gap in time between commit of transaction and actual value update
> -----------------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Attachments: bad.log, good.log, pessimistic.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-2891) Gap in time between commit of transaction and actual value update
by Jim Crossley (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Jim Crossley commented on ISPN-2891:
------------------------------------
Config change fixed this. Close at your leisure!
> Gap in time between commit of transaction and actual value update
> -----------------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Mircea Markus
> Labels: 5.2.x
> Fix For: 5.3.0.Final
>
> Attachments: bad.log, good.log, pessimistic.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3220) Integration tests rely on a nonexistent artifact
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3220?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3220:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1902
> Integration tests rely on a nonexistent artifact
> ------------------------------------------------
>
> Key: ISPN-3220
> URL: https://issues.jboss.org/browse/ISPN-3220
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.3.0.CR1
> Reporter: Manik Surtani
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 5.3.0.CR2
>
>
> When running in a clean environment (no cached .m2 repo), {{AS Module Integration Tests}} fails with a broken dependency on {{org.jboss.as:jboss-as-dist:zip:7.2.0.Alpha1-redhat-4}}.
> The following repos are queried:
> {code}
> [ERROR] jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/, releases=true, snapshots=true),
> [ERROR] jboss-public-repository (https://repository.jboss.org/nexus/content/groups/public, releases=true, snapshots=true),
> [ERROR] central (http://repo1.maven.org/maven2, releases=true, snapshots=false)
> {code}
> If this integration test relies on specific installs of JBoss AS/EAP/WildFly then they should be made optional, and *not* enabled by default as it breaks community builds/tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3232) ClassCastException in LevelDBCacheStore
by Michal Linhard (JIRA)
Michal Linhard created ISPN-3232:
------------------------------------
Summary: ClassCastException in LevelDBCacheStore
Key: ISPN-3232
URL: https://issues.jboss.org/browse/ISPN-3232
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.3.0.CR1
Reporter: Michal Linhard
Assignee: Mircea Markus
The test org/infinispan/loaders/leveldb/LevelDBCacheStoreTest.java shows this error in the log:
{code}
2013-06-14 15:20:13,136 ERROR [AbstractCacheStore] (main) ISPN000045: Problems encountered while purging expired
org.infinispan.loaders.CacheLoaderException: org.infinispan.loaders.CacheLoaderException: java.lang.ClassCastException: [B cannot be cast to java.lang.Long
at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:412)
at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:111)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:44)
at org.infinispan.loaders.AbstractCacheStore.purgeExpired(AbstractCacheStore.java:107)
at org.infinispan.loaders.BaseCacheStoreTest.purgeExpired(BaseCacheStoreTest.java:214)
at org.infinispan.loaders.BaseCacheStoreTest.testLoadAndStoreWithIdle(BaseCacheStoreTest.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:335)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:330)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
at org.testng.TestNG.run(TestNG.java:1057)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175)
Caused by: org.infinispan.loaders.CacheLoaderException: java.lang.ClassCastException: [B cannot be cast to java.lang.Long
at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:403)
... 29 more
Caused by: java.lang.ClassCastException: [B cannot be cast to java.lang.Long
at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:367)
... 29 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2402:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 5.3.0.Final)
> Cache operations or transactions should never fail with SuspectException
> ------------------------------------------------------------------------
>
> Key: ISPN-2402
> URL: https://issues.jboss.org/browse/ISPN-2402
> Project: Infinispan
> Issue Type: Task
> Components: RPC, State transfer
> Affects Versions: 5.2.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: 5.2.x
> Fix For: 6.0.0.Final
>
> Attachments: vrstt.log
>
>
> This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user.
> After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back).
> For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (ISPN-3140) JMX operation to suppress state transfer
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3140?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3140:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> JMX operation to suppress state transfer
> ----------------------------------------
>
> Key: ISPN-3140
> URL: https://issues.jboss.org/browse/ISPN-3140
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache, State transfer
> Affects Versions: 5.2.6.Final
> Reporter: Manik Surtani
> Assignee: Dan Berindei
> Fix For: 5.2.7.Final, 5.3.0.CR2, 5.3.0.Final
>
>
> This feature request is to expose a JMX operation on each node, to suppress state transfer for a period of time. This flag would be {{false}} by default.
> The use case of this flag would be to ease bringing down (and up) a cluster for maintenance work. A typical workflow would be:
> 1) Shut down application requests to the data grid
> 2) Suppress state transfer on all nodes via JMX
> 3) Bring down all nodes
> 4) Perform maintenance work
> 5) Bring up nodes, one at a time. As each node comes up, disable state transfer for the node via JMX.
> 6) Once all nodes are up, enable state transfer for each node again via JMX
> 7) Allow application requests to reach the grid again.
> The purpose of this is to allow smooth and fast shutdown and startup, remove the risk of OOM errors (when bringing a grid down).
> This is a small but useful subset of full manual state transfer as defined in ISPN-1394.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months