[JBoss JIRA] (ISPN-4428) SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4428?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant resolved ISPN-4428.
-----------------------------------
Fix Version/s: 7.0.0.Alpha5
7.0.0.Final
Resolution: Done
Fixed by ISPN-4382
> SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4428
> URL: https://issues.jboss.org/browse/ISPN-4428
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Alpha5, 7.0.0.Final
>
>
> {{SecurityManagerCacheAuthorizationTest.testAllCombinations}} fails with
> {noformat}
> java.security.PrivilegedActionException: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.Security.doAs(Security.java:145)
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:139)
> at org.infinispan.security.SecurityManagerCacheAuthorizationTest.testAllCombinations(SecurityManagerCacheAuthorizationTest.java:21)
> 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:606)
> 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.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:158)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:139)
> at org.infinispan.security.Security.doAs(Security.java:143)
> ... 22 more
> Caused by: java.lang.reflect.InvocationTargetException
> 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:606)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:143)
> ... 24 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.container.versioning.NumericVersionGenerator.start() on object of type NumericVersionGenerator
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:696)
> at org.infinispan.security.impl.SecureCacheImpl.start(SecureCacheImpl.java:75)
> at org.infinispan.security.SecureCacheTestDriver.testStop(SecureCacheTestDriver.java:148)
> ... 29 more
> Caused by: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject:
> Principal: TestPrincipal [name=LIFECYCLE]
> Principal: TestPrincipal [name=LIFECYCLE_user]
> ' lacks 'LISTEN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:76)
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:54)
> at org.infinispan.manager.DefaultCacheManager.addListener(DefaultCacheManager.java:657)
> at org.infinispan.container.versioning.NumericVersionGenerator.start(NumericVersionGenerator.java:51)
> 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:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> {noformat}
> For details see e.g. [jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]. Seem to happen on all platforams and JDKs.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4428) SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4428?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4428:
---------------------------------------
This is no longer valid for Infinispan master, since the call to addListener is wrapped by a SecurityAction
> SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4428
> URL: https://issues.jboss.org/browse/ISPN-4428
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
>
> {{SecurityManagerCacheAuthorizationTest.testAllCombinations}} fails with
> {noformat}
> java.security.PrivilegedActionException: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.Security.doAs(Security.java:145)
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:139)
> at org.infinispan.security.SecurityManagerCacheAuthorizationTest.testAllCombinations(SecurityManagerCacheAuthorizationTest.java:21)
> 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:606)
> 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.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:158)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:139)
> at org.infinispan.security.Security.doAs(Security.java:143)
> ... 22 more
> Caused by: java.lang.reflect.InvocationTargetException
> 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:606)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:143)
> ... 24 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.container.versioning.NumericVersionGenerator.start() on object of type NumericVersionGenerator
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:696)
> at org.infinispan.security.impl.SecureCacheImpl.start(SecureCacheImpl.java:75)
> at org.infinispan.security.SecureCacheTestDriver.testStop(SecureCacheTestDriver.java:148)
> ... 29 more
> Caused by: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject:
> Principal: TestPrincipal [name=LIFECYCLE]
> Principal: TestPrincipal [name=LIFECYCLE_user]
> ' lacks 'LISTEN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:76)
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:54)
> at org.infinispan.manager.DefaultCacheManager.addListener(DefaultCacheManager.java:657)
> at org.infinispan.container.versioning.NumericVersionGenerator.start(NumericVersionGenerator.java:51)
> 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:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> {noformat}
> For details see e.g. [jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]. Seem to happen on all platforams and JDKs.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4424) ReplaceIfUnmodified is broken under concurrent execution
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño edited comment on ISPN-4424 at 6/23/14 4:03 AM:
-----------------------------------------------------------------
{code}
17109 TRACE [org.infinispan.client.hotrod.impl.protocol.Codec20] (pool-7-thread-2:) Wrote header for message 6561. Operation code: 0x11. Flags: 0x0
17111 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Decoded header HotRodHeader{op=GetWithVersionRequest, version=20, messageId=6561, cacheName=, flag=0, clientIntelligence=3, topologyId=2}
17113 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Write response GetWithVersionResponse{version=20, messageId=6561, operation=GetWithVersionResponse, status=Success, data=[B0x034b000001cf,h=3e25a7d7], dataVersion=281479271678483}
{code}
^ A client thread requests an entry's versioned data. This returns 463 (...000001cf) and version 281479271678483.
With the version and previous value in place, client calls replaceWithVersion(key, 464, 281479271678483), with the intention to update the entry to 464 value if the version is still 281479271678483.
Server side, we see the server requesting the cached entry and finding 463 as value and 281479271678483 version:
{code}17126 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3-1:___defaultcache) Executing command: GetKeyValueCommand {key=[B0x033e07484f47454b..[10], flags=[SKIP_LISTENER_NOTIFICATION]}
17126 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3-1:___defaultcache) Found entry MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}{code}
In parallel, an entry update happens:
{code}17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Creating new ICE for writing. Existing=MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}, new value=[B@7b55e60d
17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Store MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}} in container{code}
Entry is now updated to value 464 (...000001d0) and version 281479271678485.
However, the server ends up calling replace with the old value being 464 but it somehow passed the if condition where the version should be 281479271678483 (new version to be applied shown in the logs):
{code}17126 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3-1:___defaultcache) Invoked with command ReplaceCommand{key=[B0x033e07484f47454b..[10], oldValue=[B0x034b000001d0, newValue=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678486}}, flags=null, successful=true, valueMatcher=MATCH_EXPECTED} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@2feeb01e]{code}
One way to solve this issue would be to add synchronisation but that would hurt performance badly. The real problem though is the fact that when the server calls getCacheEntry(), this returns a mutable cache entry. This entry cannot be directly mutated by the client but can indeed mutated by the server, and in fact it does so when it calls InternalCacheEntryFactory.update() method. One way to solve this might be getCacheEntry to return a true immutable cache entry, whose call reordering cannot lead to race conditions such as this.
was (Author: galder.zamarreno):
{code}
17109 TRACE [org.infinispan.client.hotrod.impl.protocol.Codec20] (pool-7-thread-2:) Wrote header for message 6561. Operation code: 0x11. Flags: 0x0
17111 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Decoded header HotRodHeader{op=GetWithVersionRequest, version=20, messageId=6561, cacheName=, flag=0, clientIntelligence=3, topologyId=2}
17113 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Write response GetWithVersionResponse{version=20, messageId=6561, operation=GetWithVersionResponse, status=Success, data=[B0x034b000001cf,h=3e25a7d7], dataVersion=281479271678483}
{code}
^ A client thread requests an entry's versioned data. This returns 463 (...000001cf) and version 281479271678483.
With the version and previous value in place, client calls replaceWithVersion(key, 464, 281479271678483), with the intention to update the entry to 464 value if the version is still 281479271678483.
Server side, we see the server requesting the cached entry and finding 463 as value and 281479271678483 version:
{code}17126 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3-1:___defaultcache) Executing command: GetKeyValueCommand {key=[B0x033e07484f47454b..[10], flags=[SKIP_LISTENER_NOTIFICATION]}
2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3-1:___defaultcache) Found entry MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}{code}
In parallel, an entry update happens:
{code}17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Creating new ICE for writing. Existing=MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}, new value=[B@7b55e60d
17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Store MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}} in container{code}
Entry is now updated to value 464 (...000001d0) and version 281479271678485.
However, the server ends up calling replace with the old value being 464 but it somehow passed the if condition where the version should be 281479271678483 (new version to be applied shown in the logs):
{code}17126 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3-1:___defaultcache) Invoked with command ReplaceCommand{key=[B0x033e07484f47454b..[10], oldValue=[B0x034b000001d0, newValue=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678486}}, flags=null, successful=true, valueMatcher=MATCH_EXPECTED} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@2feeb01e]{code}
One way to solve this issue would be to add synchronisation but that would hurt performance badly. The real problem though is the fact that when the server calls getCacheEntry(), this returns a mutable cache entry. This entry cannot be directly mutated by the client but can indeed mutated by the server, and in fact it does so when it calls InternalCacheEntryFactory.update() method. One way to solve this might be getCacheEntry to return a true immutable cache entry, whose call reordering cannot lead to race conditions such as this.
> ReplaceIfUnmodified is broken under concurrent execution
> --------------------------------------------------------
>
> Key: ISPN-4424
> URL: https://issues.jboss.org/browse/ISPN-4424
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test:
> ```
> 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463
> 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464
> 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464
> 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465
> ```
> Here you see two threads applying the same replacement, from 463 to 464.
> The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4424) ReplaceIfUnmodified is broken under concurrent execution
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño edited comment on ISPN-4424 at 6/23/14 4:03 AM:
-----------------------------------------------------------------
{code}
17109 TRACE [org.infinispan.client.hotrod.impl.protocol.Codec20] (pool-7-thread-2:) Wrote header for message 6561. Operation code: 0x11. Flags: 0x0
17111 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Decoded header HotRodHeader{op=GetWithVersionRequest, version=20, messageId=6561, cacheName=, flag=0, clientIntelligence=3, topologyId=2}
17113 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Write response GetWithVersionResponse{version=20, messageId=6561, operation=GetWithVersionResponse, status=Success, data=[B0x034b000001cf,h=3e25a7d7], dataVersion=281479271678483}
{code}
^ A client thread requests an entry's versioned data. This returns 463 (...000001cf) and version 281479271678483.
With the version and previous value in place, client calls replaceWithVersion(key, 464, 281479271678483), with the intention to update the entry to 464 value if the version is still 281479271678483.
Server side, we see the server requesting the cached entry and finding 463 as value and 281479271678483 version:
{code}17126 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3-1:___defaultcache) Executing command: GetKeyValueCommand {key=[B0x033e07484f47454b..[10], flags=[SKIP_LISTENER_NOTIFICATION]}
2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3-1:___defaultcache) Found entry MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}{code}
In parallel, an entry update happens:
{code}17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Creating new ICE for writing. Existing=MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}, new value=[B@7b55e60d
17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Store MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}} in container{code}
Entry is now updated to value 464 (...000001d0) and version 281479271678485.
However, the server ends up calling replace with the old value being 464 but it somehow passed the if condition where the version should be 281479271678483 (new version to be applied shown in the logs):
{code}17126 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3-1:___defaultcache) Invoked with command ReplaceCommand{key=[B0x033e07484f47454b..[10], oldValue=[B0x034b000001d0, newValue=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678486}}, flags=null, successful=true, valueMatcher=MATCH_EXPECTED} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@2feeb01e]{code}
One way to solve this issue would be to add synchronisation but that would hurt performance badly. The real problem though is the fact that when the server calls getCacheEntry(), this returns a mutable cache entry. This entry cannot be directly mutated by the client but can indeed mutated by the server, and in fact it does so when it calls InternalCacheEntryFactory.update() method. One way to solve this might be getCacheEntry to return a true immutable cache entry, whose call reordering cannot lead to race conditions such as this.
was (Author: galder.zamarreno):
{code}
17109 TRACE [org.infinispan.client.hotrod.impl.protocol.Codec20] (pool-7-thread-2:) Wrote header for message 6561. Operation code: 0x11. Flags: 0x0
17111 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Decoded header HotRodHeader{op=GetWithVersionRequest, version=20, messageId=6561, cacheName=, flag=0, clientIntelligence=3, topologyId=2}
17113 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Write response GetWithVersionResponse{version=20, messageId=6561, operation=GetWithVersionResponse, status=Success, data=[B0x034b000001cf,h=3e25a7d7], dataVersion=281479271678483}
{code}
^ A client thread requests an entry's versioned data. This returns 463 (...000001cf) and version 281479271678483.
With the version and previous value in place, client calls replaceWithVersion(key, 464, 281479271678483), with the intention to update the entry to 464 value if the version is still 281479271678483.
Server side, we see the server requesting the cached entry and finding 463 as value and 281479271678483 version:
{code}17126 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3-1:___defaultcache) Executing command: GetKeyValueCommand {key=[B0x033e07484f47454b..[10], flags=[SKIP_LISTENER_NOTIFICATION]}
2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3-1:___defaultcache) Found entry MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}{code}
In parallel, an entry update happens:
{code}17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Creating new ICE for writing. Existing=MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}, new value=[B@7b55e60d
17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Store MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}} in container{code}
Entry is now updated to value 464 (...000001d0) and version 281479271678485.
However, the server ends up calling replace with the old value being 464 but it somehow passed the if condition where the version should be 281479271678483 (new version to be applied shown in the logs):
{code}2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3-1:___defaultcache) Invoked with command ReplaceCommand{key=[B0x033e07484f47454b..[10], oldValue=[B0x034b000001d0, newValue=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678486}}, flags=null, successful=true, valueMatcher=MATCH_EXPECTED} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@2feeb01e]{code}
One way to solve this issue would be to add synchronisation but that would hurt performance badly. The real problem though is the fact that when the server calls getCacheEntry(), this returns a mutable cache entry. This entry cannot be directly mutated by the client but can indeed mutated by the server, and in fact it does so when it calls InternalCacheEntryFactory.update() method. One way to solve this might be getCacheEntry to return a true immutable cache entry, whose call reordering cannot lead to race conditions such as this.
> ReplaceIfUnmodified is broken under concurrent execution
> --------------------------------------------------------
>
> Key: ISPN-4424
> URL: https://issues.jboss.org/browse/ISPN-4424
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test:
> ```
> 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463
> 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464
> 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464
> 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465
> ```
> Here you see two threads applying the same replacement, from 463 to 464.
> The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4424) ReplaceIfUnmodified is broken under concurrent execution
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-4424:
----------------------------------------
{code}
17109 TRACE [org.infinispan.client.hotrod.impl.protocol.Codec20] (pool-7-thread-2:) Wrote header for message 6561. Operation code: 0x11. Flags: 0x0
17111 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Decoded header HotRodHeader{op=GetWithVersionRequest, version=20, messageId=6561, cacheName=, flag=0, clientIntelligence=3, topologyId=2}
17113 TRACE [org.infinispan.server.hotrod.HotRodDecoder] (HotRodServerWorker-5-2:) Write response GetWithVersionResponse{version=20, messageId=6561, operation=GetWithVersionResponse, status=Success, data=[B0x034b000001cf,h=3e25a7d7], dataVersion=281479271678483}
{code}
^ A client thread requests an entry's versioned data. This returns 463 (...000001cf) and version 281479271678483.
With the version and previous value in place, client calls replaceWithVersion(key, 464, 281479271678483), with the intention to update the entry to 464 value if the version is still 281479271678483.
Server side, we see the server requesting the cached entry and finding 463 as value and 281479271678483 version:
{code}17126 TRACE [org.infinispan.interceptors.CallInterceptor] (HotRodServerWorker-3-1:___defaultcache) Executing command: GetKeyValueCommand {key=[B0x033e07484f47454b..[10], flags=[SKIP_LISTENER_NOTIFICATION]}
2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.commands.read.GetKeyValueCommand] (HotRodServerWorker-3-1:___defaultcache) Found entry MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}{code}
In parallel, an entry update happens:
{code}17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Creating new ICE for writing. Existing=MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001cf, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678483}}}, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}, new value=[B@7b55e60d
17126 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-NodeA-p3-t1:___defaultcache) Store MetadataImmortalCacheEntry{key=[B0x033e07484f47454b..[10], value=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678485}}} in container{code}
Entry is now updated to value 464 (...000001d0) and version 281479271678485.
However, the server ends up calling replace with the old value being 464 but it somehow passed the if condition where the version should be 281479271678483 (new version to be applied shown in the logs):
{code}2014-06-20 16:16:56,815 17126 TRACE [org.infinispan.interceptors.InvocationContextInterceptor] (HotRodServerWorker-3-1:___defaultcache) Invoked with command ReplaceCommand{key=[B0x033e07484f47454b..[10], oldValue=[B0x034b000001d0, newValue=[B0x034b000001d0, metadata=EmbeddedMetadata{version=NumericVersion{version=281479271678486}}, flags=null, successful=true, valueMatcher=MATCH_EXPECTED} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@2feeb01e]{code}
One way to solve this issue would be to add synchronisation but that would hurt performance badly. The real problem though is the fact that when the server calls getCacheEntry(), this returns a mutable cache entry. This entry cannot be directly mutated by the client but can indeed mutated by the server, and in fact it does so when it calls InternalCacheEntryFactory.update() method. One way to solve this might be getCacheEntry to return a true immutable cache entry, whose call reordering cannot lead to race conditions such as this.
> ReplaceIfUnmodified is broken under concurrent execution
> --------------------------------------------------------
>
> Key: ISPN-4424
> URL: https://issues.jboss.org/browse/ISPN-4424
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test:
> ```
> 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463
> 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464
> 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464
> 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465
> ```
> Here you see two threads applying the same replacement, from 463 to 464.
> The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4426) Transaction replayed but not committed
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4426?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on ISPN-4426 at 6/23/14 3:58 AM:
------------------------------------------------------------
Log is here: https://dl.dropboxusercontent.com/u/103079234/ispn4226.zip
The not committed transaction is {{GlobalTransaction:<edg-perf03-58446>:23655:remote}} executed by {{remote-thread-5}} at 10:07:31-10:07:32. Due to that, write to {{key_0000000000001519}} with value {{\[21 #17: 85, 300, 1263, 2398, 2909, 3485, 3684, 4037, 4473, 4673, 4754, 5156, 5429, 5444, 5595, 5641, 5767, \]}} was lost (notice the last 5767).
The test was executed against this JDG with some logging modifications [https://github.com/rvansa/jdg/tree/t_4426_logs] and with log filters as in [https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/jdg-60/log4j...].
was (Author: rvansa):
Log is here: https://dl.dropboxusercontent.com/u/103079234/ispn4226.zip
The not committed transaction is {{GlobalTransaction:<edg-perf03-58446>:23655:remote}} executed by {{remote-thread-5}} at 10:07:31-10:07:32. Due to that, write to {{key_0000000000001519}} with value {{\[21 #17: 85, 300, 1263, 2398, 2909, 3485, 3684, 4037, 4473, 4673, 4754, 5156, 5429, 5444, 5595, 5641, 5767, \]}} was lost (notice the last 5767).
The test was executed against this JDG with some logging modifications [https://github.com/rvansa/jdg/tree/t_4426_logs] and with log filters as in [https://svn.devel.redhat.com/repos/jboss-qa/load-testing/etc/jdg-60/log4j...].
> Transaction replayed but not committed
> --------------------------------------
>
> Key: ISPN-4426
> URL: https://issues.jboss.org/browse/ISPN-4426
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 63gablocker
>
> Dist TX cache, node C is joining. In previous topology, entry is owned by A (primary) and B (backup). In new topology, primary ownership is transferred to C, B stays backup.
> 1. TX is prepared in old topology and is being committed, when topology changes
> 2. on C (the new owner), the TX info is received and later even the old entry
> 3. C receives the CommitCommand, therefore, it correctly replays the PrepareCommand.
> 4. When the entries are about to be committed, in TxInterceptor the transaction is found to be already completed as it has lower TxID.
> Result: the transaction is not being executed and stale data stay on the node (with my algortihm it eventually led to complete entry loss).
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4424) ReplaceIfUnmodified is broken under concurrent execution
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4424:
-----------------------------------
Description:
Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test:
```
2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463
2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464
2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464
2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465
```
Here you see two threads applying the same replacement, from 463 to 464.
The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this.
was:Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread.
> ReplaceIfUnmodified is broken under concurrent execution
> --------------------------------------------------------
>
> Key: ISPN-4424
> URL: https://issues.jboss.org/browse/ISPN-4424
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Remote Protocols
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Final
>
>
> Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test:
> ```
> 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463
> 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464
> 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464
> 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465
> ```
> Here you see two threads applying the same replacement, from 463 to 464.
> The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4429) SyncReplLockingTest.createBeforeMethod fails randomly on Solaris
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-4429:
-------------------------------------
Summary: SyncReplLockingTest.createBeforeMethod fails randomly on Solaris
Key: ISPN-4429
URL: https://issues.jboss.org/browse/ISPN-4429
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite - Core
Reporter: Vojtech Juranek
Assignee: Dan Berindei
{{SyncReplLockingTest.createBeforeMethod}} fails randomly on Solaris with
{noformat}
java.lang.RuntimeException: Timed out before caches had complete views. Expected 2 members in each view. Views are as follows: [[SyncReplLockingTest-NodeGGN-33206, SyncReplLockingTest-NodeGGO-46678], [SyncReplLockingTest-NodeGGO-46678]]
at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:262)
at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:252)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:244)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:285)
at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:912)
at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:225)
at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:275)
at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:263)
at org.infinispan.replication.SyncReplLockingTest.createCacheManagers(SyncReplLockingTest.java:46)
at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69)
at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79)
at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
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.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
For details see e.g. [this jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4429) SyncReplLockingTest.createBeforeMethod fails randomly on Solaris
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4429?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4429:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1112117
> SyncReplLockingTest.createBeforeMethod fails randomly on Solaris
> ----------------------------------------------------------------
>
> Key: ISPN-4429
> URL: https://issues.jboss.org/browse/ISPN-4429
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Reporter: Vojtech Juranek
> Assignee: Dan Berindei
>
> {{SyncReplLockingTest.createBeforeMethod}} fails randomly on Solaris with
> {noformat}
> java.lang.RuntimeException: Timed out before caches had complete views. Expected 2 members in each view. Views are as follows: [[SyncReplLockingTest-NodeGGN-33206, SyncReplLockingTest-NodeGGO-46678], [SyncReplLockingTest-NodeGGO-46678]]
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:262)
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:252)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:244)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:285)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:912)
> at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:225)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:275)
> at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:263)
> at org.infinispan.replication.SyncReplLockingTest.createCacheManagers(SyncReplLockingTest.java:46)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79)
> at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> 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.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
> For details see e.g. [this jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (ISPN-4428) SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4428?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4428:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1112110
> SecurityManagerCacheAuthorizationTest.testAllCombinations fails due to missing permission
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4428
> URL: https://issues.jboss.org/browse/ISPN-4428
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Core
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
>
> {{SecurityManagerCacheAuthorizationTest.testAllCombinations}} fails with
> {noformat}
> java.security.PrivilegedActionException: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.Security.doAs(Security.java:145)
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:139)
> at org.infinispan.security.SecurityManagerCacheAuthorizationTest.testAllCombinations(SecurityManagerCacheAuthorizationTest.java:21)
> 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:606)
> 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.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.Exception: Unexpected non-SecurityException
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:158)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:139)
> at org.infinispan.security.Security.doAs(Security.java:143)
> ... 22 more
> Caused by: java.lang.reflect.InvocationTargetException
> 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:606)
> at org.infinispan.security.CacheAuthorizationTest$5.run(CacheAuthorizationTest.java:143)
> ... 24 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.container.versioning.NumericVersionGenerator.start() on object of type NumericVersionGenerator
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216)
> at org.infinispan.CacheImpl.start(CacheImpl.java:696)
> at org.infinispan.security.impl.SecureCacheImpl.start(SecureCacheImpl.java:75)
> at org.infinispan.security.SecureCacheTestDriver.testStop(SecureCacheTestDriver.java:148)
> ... 29 more
> Caused by: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject:
> Principal: TestPrincipal [name=LIFECYCLE]
> Principal: TestPrincipal [name=LIFECYCLE_user]
> ' lacks 'LISTEN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:76)
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:54)
> at org.infinispan.manager.DefaultCacheManager.addListener(DefaultCacheManager.java:657)
> at org.infinispan.container.versioning.NumericVersionGenerator.start(NumericVersionGenerator.java:51)
> 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:606)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 37 more
> {noformat}
> For details see e.g. [jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...]. Seem to happen on all platforams and JDKs.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months