[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:
------------------------------------
Yes, I'm now realizing it's a bug in the Immutant config code. I'm running the tests again with a fix to confirm. Thanks for the help.
> 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.CR1, 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
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
William Burns updated ISPN-761:
-------------------------------
Fix Version/s: 5.3.0.CR1
5.3.0.Final
(was: 6.0.0.Final)
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Labels: onboard, potential_performance_hit
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
William Burns updated ISPN-761:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1854
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Labels: onboard, potential_performance_hit
> Fix For: 6.0.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
[JBoss JIRA] (ISPN-3156) Add tests for interoperability mode - reading via REST
by Martin Gencur (JIRA)
Martin Gencur created ISPN-3156:
-----------------------------------
Summary: Add tests for interoperability mode - reading via REST
Key: ISPN-3156
URL: https://issues.jboss.org/browse/ISPN-3156
Project: Infinispan
Issue Type: Task
Reporter: Martin Gencur
Assignee: Martin Gencur
Fix For: 5.3.0.CR1
Add tests for REST:
* accepting application/json and application/xml format of objects stored via HotRod and embedded cache
* read expiry header with HEAD method for objects stored via HotRod and embedded cache
--
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
[JBoss JIRA] (ISPN-3152) Configuration update
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3152?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-3152:
---------------------------------------
LoadersConfigurationBuilder.read() is not clearing the existing array on defineConfiguration.
To workaround, remove the
builder.read(manager.getDefaultCacheConfiguration());
since the behaviour of the defineConfiguration() method is to use the new configuration as an override to the existing one, which means you'll get the expected behaviour anyway.
> Configuration update
> --------------------
>
> Key: ISPN-3152
> URL: https://issues.jboss.org/browse/ISPN-3152
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 5.2.1.Final
> Reporter: Marta Sedlakova
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Final
>
>
> Hello,
>
> I am upgrading infinispan configuration and I have following problem:
> In old configuration, we use:
> Configuration config;
> JdbmCacheStoreConfig storeConfig = new JdbmCacheStoreConfig();
> storeConfig.setLocation(location);
> storeConfig.setCacheLoaderClassName("org.infinispan.loaders.jdbm.JdbmCacheStore");
> storeConfig.setFetchPersistentState(true);
> storeConfig.setIgnoreModifications(false);
> storeConfig.setPurgeOnStartup(false);
> config = lc.addCacheLoader(storeConfig).build();
>
> manager = new DefaultCacheManager(new GlobalConfiguration(), config);
> Configuration c = manager.getDefaultConfiguration();
> c.setEvictionMaxEntries(maxEntries);
> c.setExpirationLifespan(lifespan);
> manager.defineConfiguration(name, c);
> And this works fine. Now I am updating to new configuration:
> ConfigurationBuilder configuration = new ConfigurationBuilder();
> configuration.invocationBatching().enable();
> JdbmCacheStoreConfigurationBuilder builder = new JdbmCacheStoreConfigurationBuilder(configuration.loaders());
> builder.location(location).fetchPersistentState(true);
> configuration.loaders().addStore(builder);
> manager = new DefaultCacheManager(new GlobalConfigurationBuilder().build(), configuration.build());
>
> And I want to change some properties from previous default configuration for named cache:
>
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.read(manager.getDefaultCacheConfiguration());
> builder.eviction().maxEntries(maxEntries));
> builder.expiration().lifespan(lifespan);
> manager.defineConfiguration(name, builder.build());
> Cache<String, Object> cache = manager.getCache(name);
> cache.start();
>
> But I got following exception:
>
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199)
> at org.infinispan.CacheImpl.start(CacheImpl.java:559)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> at eu.ysoft.cache.ifspn.replicator.IfspnReplicationBuffer.start(IfspnReplicationBuffer.java:117)
> at eu.ysoft.cache.replicator.ReplicatorImpl.start(ReplicatorImpl.java:373)
> at eu.ysoft.cache.replicator.ReplicatorImpl.start(ReplicatorImpl.java:233)
> at eu.ysoft.cache.ifspn.replicator.helpers.IfspnReplicationClient.start(IfspnReplicationClient.java:46)
> at eu.ysoft.cache.ifspn.replicator.functional.IfspnTestSimpleReplications.init(IfspnTestSimpleReplications.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:525)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:202)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:613)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:842)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1166)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at org.testng.TestRunner.runWorkers(TestRunner.java:1178)
> at org.testng.TestRunner.privateRun(TestRunner.java:757)
> at org.testng.TestRunner.run(TestRunner.java:608)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
> 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:1158)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1083)
> at org.testng.TestNG.run(TestNG.java:999)
> at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:203)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:111)
> Caused by: org.infinispan.CacheException: Unable to start cache loaders
> at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 42 more
> Caused by: java.lang.Exception: Invalid cache loader configuration!! Only ONE cache loader may have fetchPersistentState set to true. Cache will not start!
> at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:324)
> at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:146)
> ... 47 more
>
>
> I need some help how to solve this issue, when we were using the old deprecated configuration, this configuration scenarion works.
> Thanks
> Marta
--
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
[JBoss JIRA] (ISPN-3149) Unexpected reporting of no live owners
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3149?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3149:
--------------------------------------
yup, I forgot to add: this happens at the beginning of my test, so the scenario is basically: start 4 nodes in dist_sync mode owners=2 with testCache containing no data at all and this happens, therefore I consider it unexpected - there should be no state transfer at all.
And btw isn't this strange that node01 is processing initial cache topology 0 ?
It's natural that StateConsumerImpl.findSource won't find any sources since it's the only node in the cluster.
> Unexpected reporting of no live owners
> --------------------------------------
>
> Key: ISPN-3149
> URL: https://issues.jboss.org/browse/ISPN-3149
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.3.0.Beta2
> Reporter: Michal Linhard
> Assignee: Mircea Markus
>
> Running a four node test with infinispan-server 5.3.0-SNAPSHOT
> produces following errors:
> {code}
> 08:46:22,962 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Starting StateTransferManager of cache testCache on node node01/default
> 08:46:22,969 TRACE [org.infinispan.statetransfer.StateTransferManagerImpl] (MSC service thread 1-3) Installing new cache topology CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null} on cache testCache
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Received new topology for cache testCache, isRebalance = false, isMember = true, topology = CacheTopology{id=0, currentCH=DefaultConsistentHash{numSegments=40, numOwners=2, members=[node01/default]}, pendingCH=null}
> 08:46:22,972 TRACE [org.infinispan.statetransfer.StateTransferLockImpl] (MSC service thread 1-3) Signalling topology 0 is installed
> 08:46:22,973 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) On cache testCache we have: added segments: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37]
> 08:46:22,974 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) Adding inbound state transfer for segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37] of cache testCache
> 08:46:22,974 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 0 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,975 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 1 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 2 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,976 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 3 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 4 of cache testCache. Current owners are: [node01/default]. Faulty owners: []
> 08:46:22,977 ERROR [org.infinispan.statetransfer.StateConsumerImpl] (MSC service thread 1-3) ISPN000208: No live owners found for segment 5 of cache testCache. Current owners are:
> {code}
> all logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> configs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
> infinispan-server build info:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM...
--
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