[JBoss JIRA] (ISPN-2878) Default iteration on QueryCache is changed to EAGER iteration
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2878?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-2878:
----------------------------------
Description:
This is needed to fix ISPN-2874: I'm creating a separate JIRA to track the API change in changelogs.
Example of otherwise broken code:
{code}
Query query = queryBuilder.all().createQuery();
CacheQuery cacheQuery = searchManager.getQuery(query, Bean.class);
for (Object object : cacheQuery) {
...
}{code}
(it's failing to close the iterable)
was:This is needed to fix ISPN-2874: I'm creating a separate JIRA to track the API change in changelogs.
> Default iteration on QueryCache is changed to EAGER iteration
> -------------------------------------------------------------
>
> Key: ISPN-2878
> URL: https://issues.jboss.org/browse/ISPN-2878
> Project: Infinispan
> Issue Type: Task
> Components: Querying
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Alpha1
>
>
> This is needed to fix ISPN-2874: I'm creating a separate JIRA to track the API change in changelogs.
> Example of otherwise broken code:
> {code}
> Query query = queryBuilder.all().createQuery();
> CacheQuery cacheQuery = searchManager.getQuery(query, Bean.class);
> for (Object object : cacheQuery) {
> ...
> }{code}
> (it's failing to close the iterable)
--
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, 1 month
[JBoss JIRA] (ISPN-2787) NPE after ReplaceCommand
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2787?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2787:
-------------------------------------
After adding TRACE logging to the REST suite the errors no longer happen. Unfortunately the logs without TRACE do not provide enough info to investigate this.
> 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, 1 month
[JBoss JIRA] (ISPN-2874) Index File handles leak
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-2874?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-2874:
---------------------------------------
The problem is that the default fetch mode for results implementing the java.lang.Iterable was changed to LAZY fetch mode.
This mode isn't exactly Iterable but its extension org.infinispan.query.ResultIterator : the main but very important difference is that such an Iterator has a close() method which needs to be invoked to avoid such resource leaks.
Bottomline, having the default as LAZY isn't suited for usage in "enhanced for loops" as the API user doesn't realize the mistake - and has no option to fix it anyway.
Workaround: avoid enhanced for loops to iterate on the resultsets.
> Index File handles leak
> -----------------------
>
> Key: ISPN-2874
> URL: https://issues.jboss.org/browse/ISPN-2874
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Affects Versions: 5.2.0.Final, 5.2.1.Final, 5.2.2.Final
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 5.2.3.Final, 5.3.0.Alpha1
>
>
> This forum post seems reliable and needs urgent investigation:
> https://community.jboss.org/thread/221319
> Seems that Infinispan Query is leaking references to open index readers.
--
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, 1 month
[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2814:
------------------------------------
I integrated the fix for problem 1, but I'm keeping the issue open for the second problem.
> RpcManager doesn't return values properly
> -----------------------------------------
>
> Key: ISPN-2814
> URL: https://issues.jboss.org/browse/ISPN-2814
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.1.5.FINAL
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> We currently use some custom commands with Infinispan. We have since moved over to wanting to use a custom command with a return value for the response.
> We have tried using the various methods on the RpcManager and have found a few issues.
> 1. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpc, boolean sync, boolean usePriorityQueue) throws RpcException;
> This method always returns a null for cluster responses. This is a simple issue that can be solved with the following diff
> {code}
> diff --git a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.
> index bf369bc..79bc02e 100644
> --- a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> +++ b/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> @@ -107,6 +107,6 @@ public ReplicableCommand getCommand() {
>
> @Override
> public boolean isReturnValueExpected() {
> - return false;
> + return command.isReturnValueExpected();
> }
> }
> {code}
> The SingleRpcCommand wraps the given command always forcing the return value expectation to be false.
> 2. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpcCommand, ResponseMode mode, long timeout);
> This method doesn't wrap the return value in a Response thus causing a ClassCastException when the client node gets the response back. I haven't looked into detail with this one yet.
> If needed I can send a sample project that shows the behavior.
--
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, 1 month
[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-2814:
-------------------------------
Fix Version/s: 5.3.0.Final
Component/s: RPC
> RpcManager doesn't return values properly
> -----------------------------------------
>
> Key: ISPN-2814
> URL: https://issues.jboss.org/browse/ISPN-2814
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.1.5.FINAL
> Reporter: William Burns
> Assignee: Mircea Markus
> Fix For: 5.3.0.Final
>
>
> We currently use some custom commands with Infinispan. We have since moved over to wanting to use a custom command with a return value for the response.
> We have tried using the various methods on the RpcManager and have found a few issues.
> 1. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpc, boolean sync, boolean usePriorityQueue) throws RpcException;
> This method always returns a null for cluster responses. This is a simple issue that can be solved with the following diff
> {code}
> diff --git a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.
> index bf369bc..79bc02e 100644
> --- a/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> +++ b/core/src/main/java/org/infinispan/commands/remote/SingleRpcCommand.java
> @@ -107,6 +107,6 @@ public ReplicableCommand getCommand() {
>
> @Override
> public boolean isReturnValueExpected() {
> - return false;
> + return command.isReturnValueExpected();
> }
> }
> {code}
> The SingleRpcCommand wraps the given command always forcing the return value expectation to be false.
> 2. Map<Address, Response> invokeRemotely(Collection<Address> recipients, ReplicableCommand rpcCommand, ResponseMode mode, long timeout);
> This method doesn't wrap the return value in a Response thus causing a ClassCastException when the client node gets the response back. I haven't looked into detail with this one yet.
> If needed I can send a sample project that shows the behavior.
--
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, 1 month
[JBoss JIRA] (ISPN-2877) TOA: review use of message batching and INTERNAL flags
by Bela Ban (JIRA)
Bela Ban created ISPN-2877:
------------------------------
Summary: TOA: review use of message batching and INTERNAL flags
Key: ISPN-2877
URL: https://issues.jboss.org/browse/ISPN-2877
Project: Infinispan
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Pedro Ruivo
Review TOA with focus on
* Implementation of message batching: up(MessageBatch)
* Are INTERNAL, DONT_BUNDLE and OOB flags used correctly ?
** Note that as of 3.30.Beta1, DONT_BUNDLE is not strictly needed anymore
*** I suggest leave it in though, as I have to verify that [1] doesn't break this. I'll deprecate DONT_BUNDLE once [1] has been implemented and I've verified it doesn't need DONT_BUNDLE anymore.
[1] https://issues.jboss.org/browse/JGRP-1601
--
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, 1 month