[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
by Robert Stupp (JIRA)
[ https://issues.jboss.org/browse/ISPN-2240?page=com.atlassian.jira.plugin.... ]
Robert Stupp commented on ISPN-2240:
------------------------------------
[~Mircea Markus] ISPN-2710 is a blocker for us to retest ISPN-2240 - it consumes a lot of CPU after a short period of time.
> Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2240
> URL: https://issues.jboss.org/browse/ISPN-2240
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.1.6.FINAL, 5.1.x
> Reporter: Robert Stupp
> Assignee: Mircea Markus
> Priority: Critical
> Fix For: 5.3.0.Final
>
> Attachments: ISPN-2240_fix_TimeoutExceptions.patch, somehow.zip
>
>
> Hi,
> I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster.
> I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions.
> A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-)
> In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows:
> {noformat}
> public void releaseLock(Object lockOwner, Object key) {
> ReentrantLock l = locks.get(key);
> if (l != null) {
> if (!l.isHeldByCurrentThread())
> throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread());
> while (l.isHeldByCurrentThread())
> unlock(l, lockOwner);
> if (!l.hasQueuedThreads())
> locks.remove(key);
> }
> else
> throw new IllegalStateException("No lock for [" + key + ']');
> }
> {noformat}
> The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock.
> If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client.
> The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key.
> The re-implemented method should also fix some replication timeout exceptions.
> Please, please add this to 5.1.7, if possible.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-1965) Some entries not available during view change
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-1965:
--------------------------------------
Yes, I think we can still simulate scenario with network partition where we lose data. I haven't done that lately, since I know recovering from partitions after merge isn't implemented yet. Maybe [~rvansa] has seen some of these symptoms recently during his RadarGun resilience tests ?
> Some entries not available during view change
> ---------------------------------------------
>
> Key: ISPN-1965
> URL: https://issues.jboss.org/browse/ISPN-1965
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.3.FINAL
> Reporter: Michal Linhard
> Assignee: Dan Berindei
>
> In the 4 node, dist mode, num-owners=2, elasticity test
> http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/
> there is a cca 90 sec period of time where clients get null responses to GET
> requests on entries that should exist in the cache.
> first occurence:
> hyperion1139.log 05:31:01,202 286.409
> last occurence:
> hyperion1135.log 05:32:45,441 390.648
> total occurence count: (in all 19 driver nodes)
> 152241
> (this doesn't mean it happens for 152K keys, because each key is retried after
> erroneous attempt)
> data doesn't seem to be lost, because these errors cease after a while and
> number of entries returns back to normal (see cache_entries.csv)
> this happens approximately in the period between node0001 is killed and cluster
> {node0002 - node0004} is formed (and shortly after).
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2793) REST Server WAR default config
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-2793?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-2793:
--------------------------------------
No, there's a file <distro>/etc/config-samples/sample.xml, but it doesn't get included into the war during the build
That might be another solution to make it work out of the box (requires a little more maven magic)
> REST Server WAR default config
> ------------------------------
>
> Key: ISPN-2793
> URL: https://issues.jboss.org/browse/ISPN-2793
> Project: Infinispan
> Issue Type: Feature Request
> Components: Server
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Mircea Markus
> Priority: Minor
>
> REST Server war file comes with this web.xml
> {code}
> <!-- Specify your cache configuration file -->
> <init-param>
> <param-name>infinispan.config</param-name>
> <param-value>config-samples/sample.xml</param-value>
> </init-param>
> {code}
> that depend's on certain file to exist, otherwise the deployment will throw an exception:
> {code}
> 09:20:14,148 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/infinispan]] (MSC service thread 1-2) Servlet /infinispan threw load() exception: java.io.FileNotFoundException: config-samples/sample.xml (No such file or directory)
> at java.io.FileInputStream.open(Native Method) [rt.jar:1.6.0_37]
> at java.io.FileInputStream.<init>(FileInputStream.java:120) [rt.jar:1.6.0_37]
> at java.io.FileInputStream.<init>(FileInputStream.java:79) [rt.jar:1.6.0_37]
> at org.infinispan.util.AbstractFileLookup.lookupFileStrict(AbstractFileLookup.java:83) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:326) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:313) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.rest.StartupListener.init(StartupListener.scala:59) [classes:]
> at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3655) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3873) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
> What about commenting this out, so that default config is used.
> I'll do the pull if you agree..
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2752) IllegalStateException on shutdown
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2752?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2752:
-----------------------------------------------
Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 903308|https://bugzilla.redhat.com/show_bug.cgi?id=903308]
I haven't seen this in any scenario where it would affect data integrity. I considered this low prio/severity cause it only happened on cluster shutdown.
> IllegalStateException on shutdown
> ---------------------------------
>
> Key: ISPN-2752
> URL: https://issues.jboss.org/browse/ISPN-2752
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.CR2
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 5.2.1, 5.3.0.Final
>
>
> This happens on graceful shutdown of 8 or 6 nodes of 5.2.0.CR2:
> {code}
> 07:17:45,892 ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] ISPN000196: Failed to recover cluster state after the current node became the coordinator: java.util.concurrent.ExecutionException: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.get(FutureTask.java:91) [rt.jar:1.6.0_33]
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:567) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.recoverClusterStatus(ClusterTopologyManagerImpl.java:432) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:231) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:597) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.infinispan.CacheException: Remote (node0005/default) failed unexpectedly
> at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:96) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:549) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:546) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
> Caused by: java.lang.IllegalStateException: transport was closed
> at org.jgroups.blocks.GroupRequest.transportClosed(GroupRequest.java:273) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.RequestCorrelator.stop(RequestCorrelator.java:269) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.stop(MessageDispatcher.java:152) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.blocks.MessageDispatcher.channelDisconnected(MessageDispatcher.java:455) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.Channel.notifyChannelDisconnected(Channel.java:507) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.jgroups.JChannel.disconnect(JChannel.java:363) [jgroups-3.2.6.Final-redhat-1.jar:3.2.6.Final-redhat-1]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:258) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_33]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_33]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_33]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_33]
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:690) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:568) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.factories.GlobalComponentRegistry.stop(GlobalComponentRegistry.java:260) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:742) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager.stop(AbstractDelegatingEmbeddedCacheManager.java:179) [infinispan-core-5.2.0.CR2-redhat-1.jar:5.2.0.CR2-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.EmbeddedCacheManagerService.stop(EmbeddedCacheManagerService.java:76) [jboss-datagrid-infinispan-6.1.0.ER9-redhat-1.jar:6.1.0.ER9-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA-redhat-2.jar:1.0.2.GA-redhat-2]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> {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
13 years, 2 months
[JBoss JIRA] (ISPN-2788) NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2788?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2788:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1643
> NullPointerException appears in case passing null as an exclusion list to LuceneCacheLoader.loadAllKeys()
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2788
> URL: https://issues.jboss.org/browse/ISPN-2788
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> NullPointerException is thrown in case of passing null as a keyExclusionList to LuceneCacheLoader.loadAllKeys() method.
> The log is:
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadSomeKeys(DirectoryLoaderAdaptor.java:108)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllKeys(DirectoryLoaderAdaptor.java:174)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAllKeys(LuceneCacheLoader.java:126)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadAllKeysWithNullExclusion(LuceneCacheLoaderTest.java:263)
> 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:80)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {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
13 years, 2 months
[JBoss JIRA] (ISPN-2789) OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2789?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-2789:
---------------------------------------
[~amanukyan] other pull was merged
> OutOfMemoryError in case if LuceneCacheLoader.loadAll() is called
> -----------------------------------------------------------------
>
> Key: ISPN-2789
> URL: https://issues.jboss.org/browse/ISPN-2789
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.0.Final
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> In case when calling LuceneCacheLoader.loadAll() method, the following exception appears:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.HashMap.<init>(HashMap.java:204)
> at java.util.HashMap.<init>(HashMap.java:216)
> at java.util.HashSet.<init>(HashSet.java:142)
> at org.infinispan.lucene.cachestore.DirectoryLoaderAdaptor.loadAllEntries(DirectoryLoaderAdaptor.java:87)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.load(LuceneCacheLoader.java:116)
> at org.infinispan.lucene.cachestore.LuceneCacheLoader.loadAll(LuceneCacheLoader.java:105)
> at org.infinispan.lucene.cacheloader.LuceneCacheLoaderTest.testLoadEntries(LuceneCacheLoaderTest.java:146)
> 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:80)
> 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:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> I tried to edit VM options for make it to work, but even in case of high numbers for memory usage, this still happens.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2799) Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager
by Emond Papegaaij (JIRA)
Emond Papegaaij created ISPN-2799:
-------------------------------------
Summary: Deprecated OverrideDefault annotation is the only way to prevent construction of the default CacheManager
Key: ISPN-2799
URL: https://issues.jboss.org/browse/ISPN-2799
Project: Infinispan
Issue Type: Bug
Components: CDI integration
Affects Versions: 5.2.0.Final
Reporter: Emond Papegaaij
Assignee: Pete Muir
The signature of DefaultEmbeddedCacheManagerProducer.getDefaultEmbeddedCacheManager, with @OverrideDefault, causes the providedDefaultEmbeddedCacheManager to only be satisfied when your producer method is annotated with @OverrideDefault.
For example:
{code}
@Produces
@ApplicationScoped
@Default
@OverrideDefault
public EmbeddedCacheManager defaultEmbeddedCacheManager() {
return new DefaultCacheManager(
new GlobalConfigurationBuilder()
.globalJmxStatistics().allowDuplicateDomains(true)
.cacheManagerName("CDICacheManager").enable().build(),
new ConfigurationBuilder().jmxStatistics().disable()
.eviction().strategy(EvictionStrategy.LRU)
.maxEntries(10000).build());
}
{code}
If I remove @OverrideDefault, my CacheManager is still used as the default CacheManager, but the CacheManager from DefaultEmbeddedCacheManagerProducer is also instantiated. This happens because DefaultCacheResolver iterates over all EmbeddedCacheManagers to check if one of them contains a specific cache.
The default CacheManager is giving me problems because it conflicts with another CacheManager (probably from JBoss AS) in JMX.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-595) Replication timeout if lock acquired before other node join
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-595?page=com.atlassian.jira.plugin.s... ]
Mircea Markus commented on ISPN-595:
------------------------------------
This should work with Infinispan 5.2.0.Final and the new non-blocking state transfer.
> Replication timeout if lock acquired before other node join
> -----------------------------------------------------------
>
> Key: ISPN-595
> URL: https://issues.jboss.org/browse/ISPN-595
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 4.1.0.CR2
> Reporter: Rodrigo Faria
> Assignee: Manik Surtani
> Attachments: config.xml, Test.java, Test.java
>
>
> If a node acquires a lock and then a another node joins in and tries to acquire the same lock, a replication timeout exception occurs.
> This does not have to do with lock timeout, since a much higher lockAcquisitionTimeout was configured.
> This is the exception stack trace:
> 14:25:28,218 [main] ERROR s.InvocationContextInterceptor - Execution error:
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for myhostname-50939
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:421)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:100)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:124)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:229)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:216)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:199)
> at org.infinispan.interceptors.base.BaseRpcInterceptor.visitLockControlCommand(BaseRpcInterceptor.java:59)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:149)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:171)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:115)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
> at org.infinispan.CacheDelegate.lock(CacheDelegate.java:296)
> at org.infinispan.CacheDelegate.lock(CacheDelegate.java:289)
> at infinispan.Test.main(Test.java:29)
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-595) Replication timeout if lock acquired before other node join
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-595?page=com.atlassian.jira.plugin.s... ]
Mircea Markus closed ISPN-595.
------------------------------
Resolution: Out of Date
> Replication timeout if lock acquired before other node join
> -----------------------------------------------------------
>
> Key: ISPN-595
> URL: https://issues.jboss.org/browse/ISPN-595
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 4.1.0.CR2
> Reporter: Rodrigo Faria
> Assignee: Manik Surtani
> Attachments: config.xml, Test.java, Test.java
>
>
> If a node acquires a lock and then a another node joins in and tries to acquire the same lock, a replication timeout exception occurs.
> This does not have to do with lock timeout, since a much higher lockAcquisitionTimeout was configured.
> This is the exception stack trace:
> 14:25:28,218 [main] ERROR s.InvocationContextInterceptor - Execution error:
> org.infinispan.util.concurrent.TimeoutException: Replication timeout for myhostname-50939
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:421)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:100)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:124)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:229)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:216)
> at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:199)
> at org.infinispan.interceptors.base.BaseRpcInterceptor.visitLockControlCommand(BaseRpcInterceptor.java:59)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.LockingInterceptor.visitLockControlCommand(LockingInterceptor.java:149)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:171)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:115)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:82)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
> at org.infinispan.CacheDelegate.lock(CacheDelegate.java:296)
> at org.infinispan.CacheDelegate.lock(CacheDelegate.java:289)
> at infinispan.Test.main(Test.java:29)
--
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
13 years, 2 months