[JBoss JIRA] (ISPN-2933) MixedModeTest.testMixedMode fails intermittently
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-2933:
-----------------------------------
Summary: MixedModeTest.testMixedMode fails intermittently
Key: ISPN-2933
URL: https://issues.jboss.org/browse/ISPN-2933
Project: Infinispan
Issue Type: Bug
Reporter: Adrian Nistor
Assignee: Mircea Markus
{noformat}
2013-03-19 00:19:26,917 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-MixedModeTest) Test testMixedMode(org.infinispan.api.MixedModeTest) failed.
java.lang.NullPointerException
at org.infinispan.api.MixedModeTest.testMixedMode(MixedModeTest.java:72)
{noformat}
--
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
13 years
[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2814:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1658, https://github.com/infinispan/infinispan/pull/1708, https://github.com/infinispan/infinispan/pull/1729 (was: https://github.com/infinispan/infinispan/pull/1658, https://github.com/infinispan/infinispan/pull/1708)
> 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: Adrian Nistor
> Fix For: 5.2.3.Final, 5.3.0.Final
>
> Attachments: RpcManagerCustomCommandTest.java
>
>
> 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
13 years
[JBoss JIRA] (ISPN-863) Eviction based on JVM memory utilization
by Marc Bridner (JIRA)
[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ]
Marc Bridner commented on ISPN-863:
-----------------------------------
The very naive implementation of freeMemory/totalMemory (configurable as both a percentage and fixed value) would still be very useful in the cases where Infinispan is the only thing inside the JVM, an embedded or standalone Infinispan that is accessed remotely by hotrod for example. It needs a big "USE WITH CARE" warning, but for some usecases it would be a lot better than the fixed size eviction that is currently in use.
> Eviction based on JVM memory utilization
> ----------------------------------------
>
> Key: ISPN-863
> URL: https://issues.jboss.org/browse/ISPN-863
> Project: Infinispan
> Issue Type: Enhancement
> Components: Eviction
> Affects Versions: 4.2.0.Final
> Environment: N/A
> Reporter: Dave Marion
> Assignee: Manik Surtani
> Labels: eviction, threshold
> Fix For: 6.0.0.Final
>
>
> Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries.
--
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
13 years
[JBoss JIRA] (ISPN-2814) RpcManager doesn't return values properly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2814?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2814 started by Adrian Nistor.
> 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: Adrian Nistor
> Fix For: 5.2.3.Final, 5.3.0.Final
>
> Attachments: RpcManagerCustomCommandTest.java
>
>
> 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
13 years
[JBoss JIRA] (ISPN-2928) XML Parser for JDBC Cachestore configuration sets wrong value for connection url
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2928?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2928:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.2.6.Final
5.3.0.Alpha1
5.3.0.Final
Resolution: Done
> XML Parser for JDBC Cachestore configuration sets wrong value for connection url
> --------------------------------------------------------------------------------
>
> Key: ISPN-2928
> URL: https://issues.jboss.org/browse/ISPN-2928
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.2.1.Final, 5.2.3.Final
> Reporter: sarah a
> Assignee: Tristan Tarrant
> Fix For: 5.2.6.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: 0001-ISPN-2928-XML-Parser-for-JDBC-Cachestore-configurati.patch
>
>
> The new configuration parser for 5.2 (JdbcCacheStoreConfigurationParser52) doesn't set the connection url. There is a cut and paste error in a switch block:
> {code}
> switch (attribute) {
> case CONNECTION_URL: {
> builder.driverClass(value);
> break;
> }
> case DRIVER_CLASS: {
> builder.driverClass(value);
> break;
> }
> {code}
> This parse error causes a connection not found error at runtime.
--
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
13 years
[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2504?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2504:
-----------------------------------
Fix Version/s: 5.3.0.Alpha1
Affects Version/s: 5.2.5.Final
(was: 5.2.0.Beta3)
> WriteSkew check fails for entries which are inserted first time
> ---------------------------------------------------------------
>
> Key: ISPN-2504
> URL: https://issues.jboss.org/browse/ISPN-2504
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.5.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> If optimistic locking and write skew check are configured and there are two concurrent transactions performing
> {code}
> read(key) -> null
> write(key, value)
> {code}
> one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
> {code}
> EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
> if (versionSeen != null) entry.setVersion(versionSeen);
> {code}
> As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.
--
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
13 years
[JBoss JIRA] (ISPN-2504) WriteSkew check fails for entries which are inserted first time
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2504?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-2504:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> WriteSkew check fails for entries which are inserted first time
> ---------------------------------------------------------------
>
> Key: ISPN-2504
> URL: https://issues.jboss.org/browse/ISPN-2504
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency
> Affects Versions: 5.2.5.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Fix For: 5.3.0.Alpha1, 5.3.0.Final
>
>
> If optimistic locking and write skew check are configured and there are two concurrent transactions performing
> {code}
> read(key) -> null
> write(key, value)
> {code}
> one of them should fail (if both read {{null}}). However, both transaction succeed in this case. The reason is that that the {{VersionedPrepareCommand}} has {{null}} version for the key (because it was null) but in {{WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions}} there is
> {code}
> EntryVersion versionSeen = prepareCommand.getVersionsSeen().get(k);
> if (versionSeen != null) entry.setVersion(versionSeen);
> {code}
> As the {{entry}} contains the version injected into context from {{dataContainer}} in {{EntryFactoryImpl.wrapInternalCacheEntryForPut}} lately during the {{VersionedPrepareCommand}} execution, and the version is not overwritten from the {{getVersionsSeen()}} value (as this is null), the performWriteSkewCheck does not report this entry as changed.
--
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
13 years
[JBoss JIRA] (ISPN-2589) NPE in InvalidateL1Command
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2589?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-2589:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1727
> NPE in InvalidateL1Command
> --------------------------
>
> Key: ISPN-2589
> URL: https://issues.jboss.org/browse/ISPN-2589
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Thomas Fromm
> Assignee: Adrian Nistor
> Fix For: 5.3.0.Final
>
> Attachments: standalone_node0001.xml
>
>
> The used cache is an REPL_SYNC one w/o L1 and Optimistic TX.
> Can't provide unit test, just saw it in my logs.
> WARN 05.12.12 20:08:22,746 [OOB-173,IBIS-2147] CacheTopologyControlCommand ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MODULE_PROPERTIES_VERSION, type=CH_UPDATE, sender=IBIS-57850, joinInfo=null, topologyId=14, currentCH=ReplicatedConsistentHash{members=[IBIS-57850, IBIS-15651, IBIS-14611, IBIS-7942, IBIS-4256, IBIS-25472, IBIS-32523]}, pendingCH=null, throwable=null, viewId=8}
> java.lang.NullPointerException
> at org.infinispan.commands.write.InvalidateL1Command.perform(InvalidateL1Command.java:109)
> at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:110)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.CacheLoaderInterceptor.visitInvalidateCommand(CacheLoaderInterceptor.java:127)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:211)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitInvalidateL1Command(EntryWrappingInterceptor.java:143)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateL1Command(AbstractLockingInterceptor.java:99)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:256)
> at org.infinispan.interceptors.TxInterceptor.visitInvalidateCommand(TxInterceptor.java:224)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitInvalidateL1Command(StateTransferInterceptor.java:172)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:141)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateL1Command(AbstractVisitor.java:146)
> at org.infinispan.commands.write.InvalidateL1Command.acceptVisitor(InvalidateL1Command.java:192)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:592)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:239)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:58)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:117)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FC.up(FC.java:479)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
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
13 years