[JBoss JIRA] (ISPN-6546) Soft Index File Store: Put on same key after remove leads to corrupted cache on shutdown
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6546?page=com.atlassian.jira.plugin.... ]
Radim Vansa closed ISPN-6546.
-----------------------------
Resolution: Done
Comments suggest that this is a duplicate; feel free to reopen if this is still applicable.
> Soft Index File Store: Put on same key after remove leads to corrupted cache on shutdown
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-6546
> URL: https://issues.jboss.org/browse/ISPN-6546
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 7.2.5.Final, 8.2.1.Final
> Reporter: Andreas Pabst
> Assignee: Radim Vansa
> Attachments: SoftIndexFileStoreRemoveTest.java
>
>
> When performing a remove and then a put on the same key, the persistent soft index store appears to be corrupted on shutdown. On next startup an exception occurs:
> org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:859)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:628)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:617)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:238)
> at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:849)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:635)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:585)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:451)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:437)
> at org.infinispan.quickstart.embeddedcache.SoftIndexFileStoreRemoveTest.createCache(SoftIndexFileStoreRemoveTest.java:38)
> at org.infinispan.quickstart.embeddedcache.SoftIndexFileStoreRemoveTest.testPutAfterRemove(SoftIndexFileStoreRemoveTest.java:26)
> 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:483)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> 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:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:174)
> 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:483)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> ... 39 more
> Caused by: org.infinispan.persistence.spi.PersistenceException: java.lang.IllegalArgumentException: Negative position
> at org.infinispan.persistence.sifs.SoftIndexFileStore.forEachOnDisk(SoftIndexFileStore.java:456)
> at org.infinispan.persistence.sifs.SoftIndexFileStore.start(SoftIndexFileStore.java:153)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:141)
> ... 44 more
> Caused by: java.lang.IllegalArgumentException: Negative position
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:685)
> at org.infinispan.persistence.sifs.FileProvider$Handle.read(FileProvider.java:291)
> at org.infinispan.persistence.sifs.EntryRecord.read(EntryRecord.java:85)
> at org.infinispan.persistence.sifs.EntryRecord.readEntryHeader(EntryRecord.java:55)
> at org.infinispan.persistence.sifs.SoftIndexFileStore$1.apply(SoftIndexFileStore.java:169)
> at org.infinispan.persistence.sifs.SoftIndexFileStore.forEachOnDisk(SoftIndexFileStore.java:443)
> ... 46 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-8348) Some methods from cache API do not work properly with off-heap
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8348?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8348:
-------------------------------------
Actually keySet remove is because of the double wrapping done. So it wraps the key into a WrappedByteArray and then marshalls that WBA again and wraps again. Thus the equality check isn't working as the byte[] is different.
> Some methods from cache API do not work properly with off-heap
> --------------------------------------------------------------
>
> Key: ISPN-8348
> URL: https://issues.jboss.org/browse/ISPN-8348
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Vojtech Juranek
>
> Following methods from cache API don't work properly with off-heap:
> * {{get()}} returns value even for keys, which are not equal (for keys, which have same content, but {{key#equals()}} returns {{false}})
> * {{keySet()}} - from docs: modifications and changes to the cache will be reflected in the set and vice versa. This is not the case for off-heap.
> * {{replaceAll()}} fails with class cast exception (e.g. in case of {{Cache<String,String>}} with {{java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes}})
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-8348) Some methods from cache API do not work properly with off-heap
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8348?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8348:
--------------------------------
Status: Open (was: New)
> Some methods from cache API do not work properly with off-heap
> --------------------------------------------------------------
>
> Key: ISPN-8348
> URL: https://issues.jboss.org/browse/ISPN-8348
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Vojtech Juranek
>
> Following methods from cache API don't work properly with off-heap:
> * {{get()}} returns value even for keys, which are not equal (for keys, which have same content, but {{key#equals()}} returns {{false}})
> * {{keySet()}} - from docs: modifications and changes to the cache will be reflected in the set and vice versa. This is not the case for off-heap.
> * {{replaceAll()}} fails with class cast exception (e.g. in case of {{Cache<String,String>}} with {{java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes}})
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-8348) Some methods from cache API do not work properly with off-heap
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8348?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8348:
-------------------------------------
get() - I don't know for sure if we can guarantee this or not. This is the same behavior for both OFF_HEAP, BINARY and remote caches. I would say we just need to document this when using off heap.
keySet() - I am surprised this one is failing. I have to dig deeper. Also while looking at this we do double converting toStorage btw [~gustavonalle]
replaceAll() - This is just a bug in the EncoderCache as Gustavo mentioned, it was in the previous version as well is all. Had to add like 15 characters to fix :)
> Some methods from cache API do not work properly with off-heap
> --------------------------------------------------------------
>
> Key: ISPN-8348
> URL: https://issues.jboss.org/browse/ISPN-8348
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Vojtech Juranek
>
> Following methods from cache API don't work properly with off-heap:
> * {{get()}} returns value even for keys, which are not equal (for keys, which have same content, but {{key#equals()}} returns {{false}})
> * {{keySet()}} - from docs: modifications and changes to the cache will be reflected in the set and vice versa. This is not the case for off-heap.
> * {{replaceAll()}} fails with class cast exception (e.g. in case of {{Cache<String,String>}} with {{java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes}})
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-6336) NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest random failures
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6336?page=com.atlassian.jira.plugin.... ]
Work on ISPN-6336 stopped by Adrian Nistor.
-------------------------------------------
> NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest random failures
> ---------------------------------------------------------------------------
>
> Key: ISPN-6336
> URL: https://issues.jboss.org/browse/ISPN-6336
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Labels: testsuite_stability
> Fix For: 9.2.0.Final
>
>
> Picked this failure when running the query testsuite in loop. It's somehow hard to reproduce.
> The presence of the Byteman test runner in the stacktrace looks suspicious, since it is not supposed to run this test.
> {code}
> Tests run: 2907, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 51.21 sec <<< FAILURE! - in TestSuite
> testSampleDomainQuery16(org.infinispan.query.dsl.embedded.NonIndexedClusteredDummyInMemoryStoreQueryDslConditionsTest) Time elapsed: 0.01 sec <<< FAILURE!
> java.lang.AssertionError: expected:<50> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.query.dsl.embedded.QueryDslConditionsTest.testSampleDomainQuery16(QueryDslConditionsTest.java:1366)
> 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:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:200)
> at org.jboss.byteman.contrib.bmunit.BMNGAbstractRunner.run(BMNGAbstractRunner.java:58)
> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:212)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:707)
> 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: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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-5475) Narayana should be configured to use a volatile store by default
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5475?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5475:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Narayana should be configured to use a volatile store by default
> ----------------------------------------------------------------
>
> Key: ISPN-5475
> URL: https://issues.jboss.org/browse/ISPN-5475
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Final
>
>
> The {{jbossts-properties.xml}} configuration file in the core module configures a file store by default, and tests have to call {{TestCacheManagerFactory.markAsTransactional()}} (or one of the methods that calls it) to configure a volatile store instead.
> Furthermore, the {{jbossts-properties.xml}} file is explicitly filtered out of the core tests jar, so other modules can't use it.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-8333) HotRod client test suite fails with java.net.BindException when run through IKVM
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8333?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8333:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.Alpha1
9.2.0.Final
Resolution: Done
> HotRod client test suite fails with java.net.BindException when run through IKVM
> --------------------------------------------------------------------------------
>
> Key: ISPN-8333
> URL: https://issues.jboss.org/browse/ISPN-8333
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 9.2.0.Alpha1, 9.2.0.Final
>
>
> The Java test suite being run through IKVM throws a BindException. The tests are run through IKVM in the .NET native client. Upgrading the ISPN dependency in the .NET client to 9.1.1 introduces this problem.
> The test suite is first trying to find a free port but this ends up with the following exception (when I print the stack trace), and it falls back to returning a predefined port 15232:
> {code}
> java.net.SocketException: socket closed
> 3: at ikvm.internal.JNI.JNU_ThrowByName(JNI.java:53)
> 3: at java.net.TwoStacksPlainSocketImpl_c.socketListen(TwoStacksPlainSocketImpl_c.java:586)
> 3: at java.net.TwoStacksPlainSocketImpl.socketListen(TwoStacksPlainSocketImpl.java:235)
> 3: at java.net.PlainSocketImpl.socketListen(PlainSocketImpl.java:329)
> 3: at java.net.AbstractPlainSocketImpl.listen(AbstractPlainSocketImpl.java:395)
> 3: at java.net.ServerSocket.bind(ServerSocket.java:377)
> 3: at java.net.ServerSocket.<init>(ServerSocket.java:237)
> 3: at java.net.ServerSocket.<init>(ServerSocket.java:129)
> 3: at org.infinispan.server.core.test.ServerTestingUtil.findFreePort(ServerTestingUtil.java:47)
> 3: at org.infinispan.server.core.test.ServerTestingUtil.startProtocolServer(ServerTestingUtil.java:73)
> 3: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:51)
> 3: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:47)
> 3: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:55)
> 3: at org.infinispan.client.hotrod.StringSerializerHotRodTest.createCacheManager(StringSerializerHotRodTest.java:74)
> 3: at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31)
> 3: at org.infinispan.client.hotrod.StringSerializerHotRodTest.setUp(StringSerializerHotRodTest.java:139)
> 3: at java.lang.reflect.Method.invoke(Method.java:486)
> 3: at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:79)
> 3: at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> 3: at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> 3: at org.testng.internal.Invoker.invokeMethod(Invoker.java:661)
> 3: at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> 3: at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1228)
> 3: at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> 3: at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> 3: at org.testng.TestRunner.privateRun(TestRunner.java:766)
> {code}
> Subsequently the test suite is assigning the same port to multiple tests and it results in the following exception:
> {code}
> java.lang.AssertionError: java.net.BindException: Only one usage of each socket address (protocol/network address/port) is normally permitted
> 2: at org.infinispan.server.core.test.ServerTestingUtil.startProtocolServer(ServerTestingUtil.java:79)
> 2: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:51)
> 2: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:47)
> 2: at org.infinispan.client.hotrod.test.HotRodClientTestingUtil.startHotRodServer(HotRodClientTestingUtil.java:55)
> 2: at org.infinispan.client.hotrod.CrossLanguageHotRodTest.createCacheManager(CrossLanguageHotRodTest.java:124)
> 2: at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:31)
> 2: at org.infinispan.client.hotrod.CrossLanguageHotRodTest.setUp(CrossLanguageHotRodTest.java:186)
> 2: at org.infinispan.client.hotrod.CrossLanguageHotRodTest.main(CrossLanguageHotRodTest.java:642)
> 2: Caused by: java.net.BindException: Only one usage of each socket address (protocol/network address/port) is normally permitted
> 2: at java.net.SocketUtil.convertSocketExceptionToIOException(SocketUtil.java:58)
> 2: at IKVM.NativeCode.sun.nio.ch.Net.bind0(Unknown Source)
> 2: at sun.nio.ch.Net.bind(Net.java:438)
> 2: at sun.nio.ch.Net.bind(Net.java:430)
> 2: at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 2: at io.netty.channel.socket.nio.NioServerSocketChannel.doBind(NioServerSocketChannel.java:128)
> 2: at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:554)
> 2: at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1259)
> 2: at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:501)
> 2: at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:486)
> 2: at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:980)
> 2: at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:250)
> 2: at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:365)
> 2: at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
> 2: at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:405)
> 2: at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
> 2: at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:859)
> 2: at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> 2: at java.lang.Thread.run(Thread.java:955)
> 2: ... Removed 20 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (ISPN-7385) Number of REST tests fail on Solaris Sparc
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7385?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7385:
-------------------------------
Labels: testsuite_stability (was: )
> Number of REST tests fail on Solaris Sparc
> ------------------------------------------
>
> Key: ISPN-7385
> URL: https://issues.jboss.org/browse/ISPN-7385
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 9.0.0.Beta1
> Reporter: Roman Macor
> Labels: testsuite_stability
>
> Affected tests:
> org.infinispan.rest.IntegrationTest*
> org.infinispan.server.test.client.rest.REST*
> org.infinispan.rest.TwoServerTest*
> org.infinispan.persistence.rest.RestStore*
> They fail with: (the logs differ slightly e.g. dataGET instead of dataPUT)
> javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for dataPUT, return 405 with Allow header
> Standard Output
> 03:45:36,766 ERROR (nioEventLoopGroup-3-1) [i18n] RESTEASY002010: Failed to execute
> javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for dataPUT, return 405 with Allow header
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:382)
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:121)
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43)
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:445)
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:264)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:201)
> at org.jboss.resteasy.plugins.server.netty.RequestDispatcher.service(RequestDispatcher.java:83)
> at org.jboss.resteasy.plugins.server.netty.RequestHandler.channelRead0(RequestHandler.java:55)[UnitTestTestNGListener] Test testPutReplication(org.infinispan.rest.TwoServerTest) failed.
> 03:45:36,770 ERROR (testng-TwoServerTest) [UnitTestTestNGListener] Test testPutReplication(org.infinispan.rest.TwoServerTest) failed.
> java.lang.AssertionError: expected:<405> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.infinispan.rest.TwoServerTest.testPutReplication(TwoServerTest.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[UnitTestTestNGListener]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months