[JBoss JIRA] (ISPN-2891) Calls to replace don't update cache until after tx commits
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2891:
----------------------------------------
Actually, forget what I just said, the write skew check is done on commit time, so no surprises that the exception is thrown. Seems to me that you can't really trust return of conditional operations with OL, because the locks and write skew checks are only done in commit time.
> Calls to replace don't update cache until after tx commits
> ----------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: bad.log, good.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2891) Calls to replace don't update cache until after tx commits
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2891:
----------------------------------------
Actually, forget what I said about implicit and replace() calls. There's no implicit transactions, except in the first put call. The replace is done within another, externally managed, transaction. My point could still be valid. Conditional operations have a more suited way of saying that the operation did not succeed: they can tailor the return value according to whether the operation succeeded or not.
> Calls to replace don't update cache until after tx commits
> ----------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: bad.log, good.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2891) Calls to replace don't update cache until after tx commits
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2891?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2891:
----------------------------------------
>From what I understand (I'll let [~mircea.markus] correct me if I'm wrong...), the test passing with the expected counter number, or failing with a write skew failure, are to be expected. If you wanna keep track of a count, pessimistic locking is more suited for the job. With optimistic locking, it could happen that two threads get to the update the value concurrently, with one of them doing it and the other failing with a write skew.
Side note: I wonder whether in an implicit transaction, with a conditional operation such as a replace(), no write skew exceptions should be returned, and instead the friendlier false return indicating that the replace() didn't complete... I'll send an email to the dev list.
What could be a bug is the ugly log, where the count ends in two and no exceptions. I need to look at the logs and the clojure test in more detail, cos I can't really figure out whether the count being logged as 2 (and TRACE showing 3), is a bug of the test code itself, or Infinispan.
> Calls to replace don't update cache until after tx commits
> ----------------------------------------------------------
>
> Key: ISPN-2891
> URL: https://issues.jboss.org/browse/ISPN-2891
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.1.Final
> Reporter: Jim Crossley
> Assignee: Galder Zamarreño
> Labels: 5.2.x
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: bad.log, good.log, ugly.log
>
>
> Since upgrading our AS7.2 dependency in Immutant (transitively pulling in 5.2.1.Final), one of our integration tests has begun failing intermittently on our CI server. We've yet to see the failure in local runs, only on CI, so I suspect there's something racist going on.
> The two tests (one for optimistic locking, the other for pessimistic) integrate an Infinispan cache (on which the Immutant cache is built) with HornetQ and XA transactions. A number of queue listeners respond to messages by attempting to increment a value in the cache. The failure occurs with both locking schemes, but much more often with optimistic.
> We've confirmed the failure on 5.2.2 as well.
> Attached you'll find three traces of the optimistic test: the good, the bad, and the ugly. All three correspond to this test: https://github.com/immutant/immutant/blob/31a2ef6222088ccb828898e9e3e4531...
> So you can correlate the log messages prefixed with "JC:" in the traces to the code. Note in particular the last two lines in locking.clj: a logged message containing the count, and then an assertion of the count. Note that the "bad" trace was an actual failing test, but the "ugly" trace was a successful test, even though the trace clearly shows the count logged as 2, not 3. The Infinispan TRACE output clearly shows the value as 3, hence the ugliness of this test.
> It's important to understand that the "work" function occurs within an XA transaction. This means, as I understand it, that if three messages are published to "/queue/done", the cached count should equal 3. Line #44 in locking.clj will block until it receives 3 messages, after which the cached count should be 3.
> These tests always pass locally. They only ever fail on CI, which runs *very* slowly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2892) View installation loop when restarting cache on multiple nodes
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/ISPN-2892?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on ISPN-2892:
-----------------------------------
The problem:
CacheViewsManagerImpl#clusterInstallView calls clusterPrepareView, which calls handlePrepareView on all nodes.
It has a finally block that calls either commit or rollback, UNLESS !isRunning().
CacheViewsManagerImpl#handlePrepareView on the remote node throws "Received cache view prepare request after the local node has already shut down", but only after calling cacheViewInfo.prepareView to save the new view.
clusterInstallView catches the exception, but does not call rollback because !isRunning().
So the remote node never gets that view rolled back, and all subsequent PrepareView calls error out with "Cannot prepare new view y on cache foo, we are currently preparing view x"
> View installation loop when restarting cache on multiple nodes
> --------------------------------------------------------------
>
> Key: ISPN-2892
> URL: https://issues.jboss.org/browse/ISPN-2892
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.7.Final
> Reporter: Dennis Reed
> Assignee: Mircea Markus
>
> Restarting a cache on multiple nodes at the same time can cause the following error:
> ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=18, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=17, members=[node1/web, node2/web]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: default-host/test: Received cache view prepare request after the local node has already shut down
> After the initial error, the following error began repeating every second for a few minutes until BaseStateTransferManagerImpl.waitForJoinToComplete() timed out and the cache failed to start:
> ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=21, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=20, members=[]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=21, members=[node2/web]} on cache default-host/test, we are currently preparing view CacheView{viewId=18, members=[node2/web]}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2892) View installation loop when restarting cache on multiple nodes
by Dennis Reed (JIRA)
Dennis Reed created ISPN-2892:
---------------------------------
Summary: View installation loop when restarting cache on multiple nodes
Key: ISPN-2892
URL: https://issues.jboss.org/browse/ISPN-2892
Project: Infinispan
Issue Type: Bug
Affects Versions: 5.1.7.Final
Reporter: Dennis Reed
Assignee: Mircea Markus
Restarting a cache on multiple nodes at the same time can cause the following error:
ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=18, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=17, members=[node1/web, node2/web]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: default-host/test: Received cache view prepare request after the local node has already shut down
After the initial error, the following error began repeating every second for a few minutes until BaseStateTransferManagerImpl.waitForJoinToComplete() timed out and the cache failed to start:
ERROR [org.infinispan.cacheviews.CacheViewsManagerImpl] (CacheViewInstaller-19,node1/web) ISPN000172: Failed to prepare view CacheView{viewId=21, members=[node2/web]} for cache default-host/test, rolling back to view CacheView{viewId=20, members=[]}: java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=21, members=[node2/web]} on cache default-host/test, we are currently preparing view CacheView{viewId=18, members=[node2/web]}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2787) NPE after ReplaceCommand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2787?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2787:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 907499|https://bugzilla.redhat.com/show_bug.cgi?id=907499] from MODIFIED to ON_QA
> NPE after ReplaceCommand
> ------------------------
>
> Key: ISPN-2787
> URL: https://issues.jboss.org/browse/ISPN-2787
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.3.Final, 5.3.0.Final
>
>
> (from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR...)
> {code}
> 05:11:10,804 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[Resteasy]] (http-/172.18.1.7:8080-15) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:351) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:220) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:196) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:551) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:513) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-2.jar:1.0.1.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
> Caused by: java.lang.NullPointerException
> at org.infinispan.CacheImpl.replaceInternal(CacheImpl.java:828) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:822) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:817) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.AbstractDelegatingCache.replace(AbstractDelegatingCache.java:153) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.rest.Server.putOrReplace(Server.scala:186) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$putInCache(Server.scala:157) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:133) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.protectCacheNotFound(Server.scala:254) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.putEntry(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:536) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> ... 18 more
> {code}
> Seems like the NPE is caused by ReplaceCommand.perform returning null:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
> Made possible here:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2850) CLI Synopsis[info, stats] need to be changed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2850?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2850:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 915268|https://bugzilla.redhat.com/show_bug.cgi?id=915268] from MODIFIED to ON_QA
> CLI Synopsis[info,stats] need to be changed
> -------------------------------------------
>
> Key: ISPN-2850
> URL: https://issues.jboss.org/browse/ISPN-2850
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 5.2.2.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 5.2.3.Final, 5.3.0.Final
>
>
> [disconnected//]> help info
> SYNOPSIS
> info [cachename]
>
> DESCRIPTION
> Shows configuration information about the specified cache or about the active cache manager
>
> ARGUMENTS
> cachename
> (optional) the name of the cache for which the configuration will be printed. If omitted, the active cache manager's configuration will be shown
> [disconnected//]> help s
> site start stats
> [disconnected//]> help stats
> SYNOPSIS
> info [cachename]
>
> DESCRIPTION
> Shows information about the specified cache or about the active cache manager
>
> ARGUMENTS
> cachename
> (optional) the name of the cache for which information will be printed. If omitted, information about the active cache manager will be shown
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ISPN-2787) NPE after ReplaceCommand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2787?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2787:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 907499|https://bugzilla.redhat.com/show_bug.cgi?id=907499] from ASSIGNED to MODIFIED
> NPE after ReplaceCommand
> ------------------------
>
> Key: ISPN-2787
> URL: https://issues.jboss.org/browse/ISPN-2787
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Final
> Reporter: Michal Linhard
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.2.3.Final, 5.3.0.Final
>
>
> (from https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR...)
> {code}
> 05:11:10,804 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/].[Resteasy]] (http-/172.18.1.7:8080-15) Servlet.service() for servlet Resteasy threw exception: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:351) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:220) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:196) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:551) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:513) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final-redhat-2.jar:1.0.1.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_38]
> Caused by: java.lang.NullPointerException
> at org.infinispan.CacheImpl.replaceInternal(CacheImpl.java:828) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:822) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.CacheImpl.replace(CacheImpl.java:817) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.AbstractDelegatingCache.replace(AbstractDelegatingCache.java:153) [infinispan-core-5.2.0.CR3-redhat-1.jar:5.2.0.CR3-redhat-1]
> at org.infinispan.rest.Server.putOrReplace(Server.scala:186) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.org$infinispan$rest$Server$$putInCache(Server.scala:157) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:133) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server$$anonfun$putEntry$1.apply(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.protectCacheNotFound(Server.scala:254) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at org.infinispan.rest.Server.putEntry(Server.scala:120) [infinispan-server-rest-5.2.0.CR3-redhat-1-classes.jar:]
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source) [:1.6.0_38]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_38]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_38]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:257) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:222) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:211) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:536) [resteasy-jaxrs-2.3.4.Final-redhat-2.jar:2.3.4.Final-redhat-2]
> ... 18 more
> {code}
> Seems like the NPE is caused by ReplaceCommand.perform returning null:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
> Made possible here:
> https://github.com/infinispan/infinispan/blob/5.2.0.Final/core/src/main/j...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months