[JBoss JIRA] (ISPN-6478) Netty worker thread starvation with events
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6478?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6478:
----------------------------------
Fix Version/s: (was: 9.0.0.Final)
(was: 9.0.0.CR3)
> Netty worker thread starvation with events
> ------------------------------------------
>
> Key: ISPN-6478
> URL: https://issues.jboss.org/browse/ISPN-6478
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
>
> As a result of ISPN-6005, we decoupled the incoming Hot Rod server invocations from sending events by adding a intermediate queue that maintains the events to send to clients. However, this separation can lead to a Netty worker thread starvation issue since we add the events to the queue in Netty's IO thread, so if the queue is full, incoming requests are stuck.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-6688) PreferAvailabilityStrategy: Improve selection of segment owners after merge
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6688?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6688:
----------------------------------
Fix Version/s: (was: 9.0.0.Final)
(was: 9.0.0.CR3)
> PreferAvailabilityStrategy: Improve selection of segment owners after merge
> ---------------------------------------------------------------------------
>
> Key: ISPN-6688
> URL: https://issues.jboss.org/browse/ISPN-6688
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> {{PreferAvailabilityStrategy}} picks a winning CH after merge, but that CH is very likely to be the wrong one. We should improve our odds at preserving cache data by mixing CHs, and keeping from each node's response only the information about the segments it owns itself.
> The downside is that {{PreferAvailabilityStrategy}} becomes tightly coupled with {{DefaultConsistentHash}}/{{ReplicatedConsistentHash}}, and users that want to add custom {{ConsistentHash}} implementations will have to re-implement {{PreferAvailabilityStrategy}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7533) Accessing cache with disabled security resolves in SecurityException
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7533?page=com.atlassian.jira.plugin.... ]
Roman Macor updated ISPN-7533:
------------------------------
Summary: Accessing cache with disabled security resolves in SecurityException (was: Accessing cache with disabled security resolved in SecurityException)
> Accessing cache with disabled security resolves in SecurityException
> ---------------------------------------------------------------------
>
> Key: ISPN-7533
> URL: https://issues.jboss.org/browse/ISPN-7533
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
>
> This happens when the security is defined in cache container, but the cache has security disabled.
> Steps to reproduce:
> - Start standalone with defined security e.g. docs/examples/configs/standalone-auth.xml
> - try accessing unsecured cache with hotrod e.g.
> {code:title=Reproducer.java|borderStyle=solid}
> ConfigurationBuilder builder = new ConfigurationBuilder();
> builder.addServer().host("127.0.0.1").port(ConfigurationProperties.DEFAULT_HOTROD_PORT)
> RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build());
> RemoteCache<String, String> cache = cacheManager.getCache("default");
> cache.put("key", "value");
> System.out.printf("key = %s\n", cache.get("key"));
> cacheManager.stop();
> {code}
> Result:
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=3 returned server error (status=0x85): java.lang.SecurityException: ISPN006017: Unauthorized operation
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:269)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at HotRodAuthTest.test(HotRodAuthTest.java:18)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-6369) Move eviction logic out of BCHMV8
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6369?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-6369.
---------------------------------
Fix Version/s: (was: 9.0.0.Final)
Resolution: Out of Date
> Move eviction logic out of BCHMV8
> ---------------------------------
>
> Key: ISPN-6369
> URL: https://issues.jboss.org/browse/ISPN-6369
> Project: Infinispan
> Issue Type: Enhancement
> Components: Eviction
> Reporter: William Burns
>
> We should move the eviction logic out of BoundedConcurrentHashMapV8 and instead only have this done as a wrapper around. This will make the logic a lot less complicated as we will not have to worry about Node types and resizing and other issues that made the initial implementation a problem.
> Unfortunately this has the side effect that the memory based eviction will not be as accurate as it was before, but the reduced complexity in code should make up for that. Also we can probably make the overall operations faster.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7517) Investigate Netty's "Too many open files" exception in testing of infinispan-compatibility-mode-it
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7517?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-7517 at 2/27/17 8:43 AM:
----------------------------------------------------------------
bq. Sanne Grinovero what are the results after increasing the open files limit?
The same results. Like you suggested on that email thread, I agree it's possibly not really related to open files limit.
- http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017233.html
I verified this tests again today on commit id 01b829d : seemed worth to try again as a Netty update was just applied as ISPN-7519, but I again have exactly the same errors.
was (Author: sannegrinovero):
> Sanne Grinovero what are the results after increasing the open files limit?
The same results. Like you suggested on that email thread, I agree it's possibly not really related to open files limit.
- http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017233.html
I verified this tests again today on commit id 01b829d : seemed worth to try again as a Netty update was just applied as ISPN-7519, but I again have exactly the same errors.
> Investigate Netty's "Too many open files" exception in testing of infinispan-compatibility-mode-it
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-7517
> URL: https://issues.jboss.org/browse/ISPN-7517
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Server
> Reporter: Sanne Grinovero
> Fix For: 9.0.0.CR3
>
>
> See also discussion on ML:
> - http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017232.html
> Running:
> {noformat}
> mci -rf :infinispan-compatibility-mode-it
> {noformat}
> {noformat}
> Failed tests:
> ByteArrayKeyDistEmbeddedHotRodTest.setup:27 » IllegalState failed to create a ...
> ByteArrayKeyReplEmbeddedHotRodTest.setup:87 » IllegalState failed to create a ...
> ByteArrayValueDistEmbeddedHotRodTest.setup:27 » IllegalState failed to create ...
> ByteArrayValueReplEmbeddedHotRodTest.setup:87 » IllegalState failed to create ...
> DistEmbeddedRestHotRodTest.setup:25 » IllegalState failed to create a child ev...
> DistL1EmbeddedHotRodTest.setup:30 » IllegalState failed to create a child even...
> DistMemcachedEmbeddedTest.setup:39 » IllegalState failed to create a child eve...
> org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest.setup(org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest)
> Run 1: EmbeddedHotRodCacheListenerTest.setup:36 » IllegalState failed to create a chi...
> Run 2: PASS
> Run 3: PASS
> EmbeddedHotRodTest.testEventFilteringStatic:274->lambda$testEventFilteringStatic$4:276 » Transport
> EmbeddedMemcachedCacheListenerTest.setup:39 » IllegalState failed to create a ...
> EmbeddedRestMemcachedHotRodTest.setup:50 » IllegalState failed to create a chi...
> ReplEmbeddedRestHotRodTest.setup:38 » IllegalState failed to create a child ev...
> Tests run: 101, Failures: 12, Errors: 0, Skipped: 47
> {noformat}
> Errors are all about a similar stacktrace.
> {noformat}
> java.lang.IllegalStateException: failed to create a child event loop
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:88)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:58)
> at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:51)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:87)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:82)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:63)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:51)
> at org.jboss.resteasy.plugins.server.netty.NettyJaxrsServer.start(NettyJaxrsServer.java:239)
> at org.infinispan.rest.NettyRestServer.start(NettyRestServer.java:81)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestCache(CompatibilityCacheFactory.java:199)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestMemcachedCaches(CompatibilityCacheFactory.java:137)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.setup(CompatibilityCacheFactory.java:123)
> at org.infinispan.it.compatibility.DistMemcachedEmbeddedTest.setup(DistMemcachedEmbeddedTest.java:39)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: io.netty.channel.ChannelException: failed to open a new selector
> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:157)
> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:148)
> at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:126)
> at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:36)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:84)
> ... 32 more
> Caused by: java.io.IOException: Too many open files
> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:69)
> at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:155)
> ... 36 more
> {noformat}
> N.B.
> The failure is quite consistent on my workstation, almost always results in the same tests failing. Yet occasionally they all pass.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7505) Non-functional read in transaction with modifications returns old value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7505?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7505:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4906
> Non-functional read in transaction with modifications returns old value
> -----------------------------------------------------------------------
>
> Key: ISPN-7505
> URL: https://issues.jboss.org/browse/ISPN-7505
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> See this modified FunctionalTxInMemoryTest:
> {code:java}
> @Test(dataProvider = "owningModeAndReadWrites")
> public void testReadWriteAfterMods(boolean isOwner, WriteMethod method) throws Exception {
> Object KEY = getKey(isOwner);
> cache(0, DIST).put(KEY, "a");
> tm.begin();
> assertEquals("a", rw.eval(KEY, append("b")).join());
> assertEquals("ab", rw.evalMany(Collections.singleton(KEY), append("c")).findAny().get());
> assertEquals("abc", cache(0, DIST).get(KEY)); // <-- THIS FAILS
> assertEquals(null, rw.eval("otherKey", append("d")).join());
> assertEquals("abc", method.action.eval(KEY, wo, rw,
> MarshallableFunctions.returnReadOnlyFindOrNull(),
> (BiConsumer<EntryView.WriteEntryView<String>, String> & Serializable) (e, prev) -> {}, getClass()));
> tm.commit();
> }
> {code}
> When the entry was modified in given transaction, we have to do the read using functional identity read which passes all modifications along. We need to do this for all {{remoteGet}} s, including those invoked for {{putIfAbsent}} etc.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7517) Investigate Netty's "Too many open files" exception in testing of infinispan-compatibility-mode-it
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-7517?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-7517:
---------------------------------------
> Sanne Grinovero what are the results after increasing the open files limit?
The same results. Like you suggested on that email thread, I agree it's possibly not really related to open files limit.
- http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017233.html
I verified this tests again today on commit id 01b829d : seemed worth to try again as a Netty update was just applied as ISPN-7519, but I again have exactly the same errors.
> Investigate Netty's "Too many open files" exception in testing of infinispan-compatibility-mode-it
> --------------------------------------------------------------------------------------------------
>
> Key: ISPN-7517
> URL: https://issues.jboss.org/browse/ISPN-7517
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Server
> Reporter: Sanne Grinovero
> Fix For: 9.0.0.CR3
>
>
> See also discussion on ML:
> - http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017232.html
> Running:
> {noformat}
> mci -rf :infinispan-compatibility-mode-it
> {noformat}
> {noformat}
> Failed tests:
> ByteArrayKeyDistEmbeddedHotRodTest.setup:27 » IllegalState failed to create a ...
> ByteArrayKeyReplEmbeddedHotRodTest.setup:87 » IllegalState failed to create a ...
> ByteArrayValueDistEmbeddedHotRodTest.setup:27 » IllegalState failed to create ...
> ByteArrayValueReplEmbeddedHotRodTest.setup:87 » IllegalState failed to create ...
> DistEmbeddedRestHotRodTest.setup:25 » IllegalState failed to create a child ev...
> DistL1EmbeddedHotRodTest.setup:30 » IllegalState failed to create a child even...
> DistMemcachedEmbeddedTest.setup:39 » IllegalState failed to create a child eve...
> org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest.setup(org.infinispan.it.compatibility.EmbeddedHotRodCacheListenerTest)
> Run 1: EmbeddedHotRodCacheListenerTest.setup:36 » IllegalState failed to create a chi...
> Run 2: PASS
> Run 3: PASS
> EmbeddedHotRodTest.testEventFilteringStatic:274->lambda$testEventFilteringStatic$4:276 » Transport
> EmbeddedMemcachedCacheListenerTest.setup:39 » IllegalState failed to create a ...
> EmbeddedRestMemcachedHotRodTest.setup:50 » IllegalState failed to create a chi...
> ReplEmbeddedRestHotRodTest.setup:38 » IllegalState failed to create a child ev...
> Tests run: 101, Failures: 12, Errors: 0, Skipped: 47
> {noformat}
> Errors are all about a similar stacktrace.
> {noformat}
> java.lang.IllegalStateException: failed to create a child event loop
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:88)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:58)
> at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:51)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:87)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:82)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:63)
> at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:51)
> at org.jboss.resteasy.plugins.server.netty.NettyJaxrsServer.start(NettyJaxrsServer.java:239)
> at org.infinispan.rest.NettyRestServer.start(NettyRestServer.java:81)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestCache(CompatibilityCacheFactory.java:199)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.createRestMemcachedCaches(CompatibilityCacheFactory.java:137)
> at org.infinispan.it.compatibility.CompatibilityCacheFactory.setup(CompatibilityCacheFactory.java:123)
> at org.infinispan.it.compatibility.DistMemcachedEmbeddedTest.setup(DistMemcachedEmbeddedTest.java:39)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:175)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:107)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: io.netty.channel.ChannelException: failed to open a new selector
> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:157)
> at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:148)
> at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:126)
> at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:36)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:84)
> ... 32 more
> Caused by: java.io.IOException: Too many open files
> at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
> at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130)
> at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:69)
> at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36)
> at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:155)
> ... 36 more
> {noformat}
> N.B.
> The failure is quite consistent on my workstation, almost always results in the same tests failing. Yet occasionally they all pass.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7533) Accessing cache with disabled security resolved in SecurityException
by Roman Macor (JIRA)
Roman Macor created ISPN-7533:
---------------------------------
Summary: Accessing cache with disabled security resolved in SecurityException
Key: ISPN-7533
URL: https://issues.jboss.org/browse/ISPN-7533
Project: Infinispan
Issue Type: Bug
Components: Security, Server
Affects Versions: 9.0.0.CR2
Reporter: Roman Macor
This happens when the security is defined in cache container, but the cache has security disabled.
Steps to reproduce:
- Start standalone with defined security e.g. docs/examples/configs/standalone-auth.xml
- try accessing unsecured cache with hotrod e.g.
{code:title=Reproducer.java|borderStyle=solid}
ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServer().host("127.0.0.1").port(ConfigurationProperties.DEFAULT_HOTROD_PORT)
RemoteCacheManager cacheManager = new RemoteCacheManager(builder.build());
RemoteCache<String, String> cache = cacheManager.getCache("default");
cache.put("key", "value");
System.out.printf("key = %s\n", cache.get("key"));
cacheManager.stop();
{code}
Result:
org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=3 returned server error (status=0x85): java.lang.SecurityException: ISPN006017: Unauthorized operation
at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:58)
at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:34)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:269)
at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
at HotRodAuthTest.test(HotRodAuthTest.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months