[JBoss JIRA] (ISPN-4084) NotSerializableException for RecoveryInfoKey
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4084?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-4084:
------------------------------------
The recovery cache is not supposed to be clustered: http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_recovery_cache
[~mircea.markus] should we make the recovery cache keys serializable, or should we prohibit clustered recovery caches?
> NotSerializableException for RecoveryInfoKey
> --------------------------------------------
>
> Key: ISPN-4084
> URL: https://issues.jboss.org/browse/ISPN-4084
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.0.0.Alpha1
> Reporter: Jakub Markos
> Assignee: Dan Berindei
>
> While testing the recovery, this below exception showed up. I've sent a PR that fixes this.
> {code}
> 14:53:54,139 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (remote-thread-0) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581) [infinispan-commons.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:176) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:521) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:280) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleNonTxWriteCommand(BaseDistributionInterceptor.java:225) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.distribution.NonTxDistributionInterceptor.visitRemoveCommand(NonTxDistributionInterceptor.java:110) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:326) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:407) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:221) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitRemoveCommand(NonTransactionalLockingInterceptor.java:83) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:218) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:156) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1399) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:409) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.CacheImpl.remove(CacheImpl.java:402) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.CacheImpl.remove(CacheImpl.java:397) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.transaction.xa.recovery.RecoveryManagerImpl.removeRecoveryInformation(RecoveryManagerImpl.java:145) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.transaction.xa.recovery.RecoveryManagerImpl.removeRecoveryInformationFromCluster(RecoveryManagerImpl.java:131) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.transaction.xa.TransactionXaAdapter.forgetSuccessfullyCompletedTransaction(TransactionXaAdapter.java:222) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:114) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:682) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2270) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [jbossjts-jacorb-4.17.15.Final-redhat-4.jar:4.17.15.Final-redhat-4]
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.infinispan.statetransfer.StateConsumerImpl.doApplyState(StateConsumerImpl.java:548) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.statetransfer.StateConsumerImpl.applyState(StateConsumerImpl.java:495) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.statetransfer.StateResponseCommand.perform(StateResponseCommand.java:62) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:50) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:178) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_06]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_06]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_06]
> Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:348) [infinispan-core.jar:7.0.0-SNAPSHOT]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:167) [infinispan-core.jar:7.0.0-SNAPSHOT]
> ... 59 more
> Caused by: org.infinispan.commons.marshall.NotSerializableException: org.infinispan.transaction.xa.recovery.RecoveryInfoKey
> Caused by: an exception which occurred:
> in object org.infinispan.transaction.xa.recovery.RecoveryInfoKey@df5e0f57
> -> toString = RecoveryInfoKey{xid=< 131077, 29, 36, 0000000000-1-11034-127122-10-7-80638321-38-47000849, 0000000000-1-11034-127122-10-7-80638321-38-47000900000000 >, cacheName='myCache'}
> in object org.infinispan.commands.write.RemoveCommand@c63db89
> -> toString = RemoveCommand{key=RecoveryInfoKey{xid=< 131077, 29, 36, 0000000000-1-11034-127122-10-7-80638321-38-47000849, 0000000000-1-11034-127122-10-7-80638321-38-47000900000000 >, cacheName='myCache'}, value=null, flags=null, valueMatcher=MATCH_ALWAYS}
> in object org.infinispan.commands.remote.SingleRpcCommand@1781c43c
> -> toString = SingleRpcCommand{cacheName='recoveryCache', command=RemoveCommand{key=RecoveryInfoKey{xid=< 131077, 29, 36, 0000000000-1-11034-127122-10-7-80638321-38-47000849, 0000000000-1-11034-127122-10-7-80638321-38-47000900000000 >, cacheName='myCache'}, value=null, flags=null, valueMatcher=MATCH_ALWAYS}}
> {code}
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-4096) The unstable profile for server testsuite is not working correctly
by Jakub Markos (JIRA)
Jakub Markos created ISPN-4096:
----------------------------------
Summary: The unstable profile for server testsuite is not working correctly
Key: ISPN-4096
URL: https://issues.jboss.org/browse/ISPN-4096
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Server
Reporter: Jakub Markos
Assignee: Jakub Markos
There are several surefire executions defined in the testsuites pom.xml, each can use a different arquillian group (which is just a set of container configurations). There are 4 main executions: suite-client-local, suite-client-dist, suite-client-repl, suite-manual. The unstable profile is configured to run the tests marked with Unstable category, but it's only using the arquillian group from suite-manual, so if there is a unstable client test, it fails because it can't find the arquillian container definition.
Looking for a nice solution.
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3942:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Final, 7.0.0.Alpha2
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-4095) Flag.SKIP_LISTENER_NOTIFICATION does not work for CacheEntryModifiedEvent and CacheEntryCreatedEvent
by tina tian (JIRA)
[ https://issues.jboss.org/browse/ISPN-4095?page=com.atlassian.jira.plugin.... ]
tina tian updated ISPN-4095:
----------------------------
Affects Version/s: 7.0.0.Alpha1
6.0.0.Final
> Flag.SKIP_LISTENER_NOTIFICATION does not work for CacheEntryModifiedEvent and CacheEntryCreatedEvent
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-4095
> URL: https://issues.jboss.org/browse/ISPN-4095
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 6.0.0.Final, 7.0.0.Alpha1
> Reporter: tina tian
> Assignee: Dan Berindei
>
> When setting Flag.SKIP_LISTENER_NOTIFICATION, listener still can be invoked when new entry is created or entry is modified.
> I check the change log and found it should be caused by logic in CacheNotifierImpl, it did not check the flag on createEntry and modifyEntry event.
> You can reproduce it by the code below:
> public class TestInfinispan {
>
> public static void main(String[] args) {
> Cache<String, String> testCache = new DefaultCacheManager().getCache();
>
> testCache.addListener(new TestListener());
>
> AdvancedCache<String, String> advancedCache = testCache.getAdvancedCache();
>
> advancedCache = advancedCache.withFlags(Flag.SKIP_LISTENER_NOTIFICATION);
> advancedCache.put("key1", "value1");
> advancedCache.replace("key1", "value2");
> }
> @Listener
> private static class TestListener {
> @CacheEntryModified
> public void cacheEntryModified(CacheEntryModifiedEvent event) {
> System.out.println(
> "######## modify event with key " + event.getKey() + " and value " + event.getValue() );
> }
> @CacheEntryCreated
> public void cacheEntryCreated(CacheEntryCreatedEvent event) {
> System.out.println(
> "######## create event with key " + event.getKey() + " and value " + event.getValue() );
> }
> }
> }
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-4095) Flag.SKIP_LISTENER_NOTIFICATION does not work for CacheEntryModifiedEvent and CacheEntryCreatedEvent
by tina tian (JIRA)
tina tian created ISPN-4095:
-------------------------------
Summary: Flag.SKIP_LISTENER_NOTIFICATION does not work for CacheEntryModifiedEvent and CacheEntryCreatedEvent
Key: ISPN-4095
URL: https://issues.jboss.org/browse/ISPN-4095
Project: Infinispan
Issue Type: Bug
Components: Listeners
Reporter: tina tian
Assignee: Dan Berindei
When setting Flag.SKIP_LISTENER_NOTIFICATION, listener still can be invoked when new entry is created or entry is modified.
I check the change log and found it should be caused by logic in CacheNotifierImpl, it did not check the flag on createEntry and modifyEntry event.
You can reproduce it by the code below:
public class TestInfinispan {
public static void main(String[] args) {
Cache<String, String> testCache = new DefaultCacheManager().getCache();
testCache.addListener(new TestListener());
AdvancedCache<String, String> advancedCache = testCache.getAdvancedCache();
advancedCache = advancedCache.withFlags(Flag.SKIP_LISTENER_NOTIFICATION);
advancedCache.put("key1", "value1");
advancedCache.replace("key1", "value2");
}
@Listener
private static class TestListener {
@CacheEntryModified
public void cacheEntryModified(CacheEntryModifiedEvent event) {
System.out.println(
"######## modify event with key " + event.getKey() + " and value " + event.getValue() );
}
@CacheEntryCreated
public void cacheEntryCreated(CacheEntryCreatedEvent event) {
System.out.println(
"######## create event with key " + event.getKey() + " and value " + event.getValue() );
}
}
}
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-4094) Memory leak in RemoteQueryDslConditionsTest
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4094?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-4094:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Memory leak in RemoteQueryDslConditionsTest
> -------------------------------------------
>
> Key: ISPN-4094
> URL: https://issues.jboss.org/browse/ISPN-4094
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha2
>
>
> A {{RemoteCacheManager}} instance is created for each test method in {{RemoteQueryDslConditionsTest}}, because of the {{@CleanupAfterMethod}} annotation. But the {{@AfterTest}} method that stops the remote cache is only once for the entire class, so all but one of the remote cache managers are not stopped properly.
> {{GenericKeyedObjectPool}} registers a timer in {{EvictionTimer}}, which keeps the pool and the {{TcpTransport}} objects in it alive. And because the size of the buffer used by the transport is very big (1838kb on my system), {{RemoteQueryDslConditionsTest}} and its subclasses can quickly fill up the heap.
--
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
10 years, 10 months
[JBoss JIRA] (ISPN-4094) Memory leak in RemoteQueryDslConditionsTest
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4094?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4094:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2433
> Memory leak in RemoteQueryDslConditionsTest
> -------------------------------------------
>
> Key: ISPN-4094
> URL: https://issues.jboss.org/browse/ISPN-4094
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha2
>
>
> A {{RemoteCacheManager}} instance is created for each test method in {{RemoteQueryDslConditionsTest}}, because of the {{@CleanupAfterMethod}} annotation. But the {{@AfterTest}} method that stops the remote cache is only once for the entire class, so all but one of the remote cache managers are not stopped properly.
> {{GenericKeyedObjectPool}} registers a timer in {{EvictionTimer}}, which keeps the pool and the {{TcpTransport}} objects in it alive. And because the size of the buffer used by the transport is very big (1838kb on my system), {{RemoteQueryDslConditionsTest}} and its subclasses can quickly fill up the heap.
--
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
10 years, 10 months