[JBoss JIRA] (ISPN-3129) If the status recovery fails for a cache, it stops recovery for all the caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3129?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3129:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1846
> If the status recovery fails for a cache, it stops recovery for all the caches
> ------------------------------------------------------------------------------
>
> Key: ISPN-3129
> URL: https://issues.jboss.org/browse/ISPN-3129
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.7.Final, 5.3.0.Final
>
>
> When a node becomes coordinator, it sends a GET_STATUS command to recover the status of all the caches in the cluster. Then it sends a CH_UPDATE command for each cache, to install a new topology.
> However, if the CH_UPDATE command fails for one cache, the coordinator will interrupt the recovery process, and it won't even install the cache topology for the rest of the caches locally. When a new node joins, it will act as if the cache was just started:
> {code}
> 09:05:22,542 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-1693,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=default-host/clusterbench-granular, type=CH_UPDATE, sender=perf03/web, joinInfo=null, topologyId=21, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf04/web, perf01/web, perf02/web]}, pendingCH=null, throwable=null, viewId=7} [sender=perf03/web]
> 09:06:21,484 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-2231,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=null, type=GET_STATUS, sender=perf04/web, joinInfo=null, topologyId=0, currentCH=null, pendingCH=null, throwable=null, viewId=7} [sender=perf04/web]
> 09:28:21,060 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (OOB-22206,shared=udp) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=default-host/clusterbench-granular, type=CH_UPDATE, sender=perf04/web, joinInfo=null, topologyId=1, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf04/web, perf02/web, perf03/web]}, pendingCH=null, throwable=null, viewId=10} [sender=perf04/web]
> {code}
> This is mitigated by the ISPN-2966 fix (https://github.com/infinispan/infinispan/pull/1742). Since the CH_UPDATE command is now sent asynchronously, it ignores any exceptions on the targets. But on the 5.2.x branch, the CH_UPDATE command is sent synchronously, and it can fail with an exception like this:
> {code}
> 05:43:56,513 WARN [org.infinispan.topology.CacheTopologyControlCommand] (notification-thread-0) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=default-host/clusterbench, type=CH_UPDATE, sender=perf21/web, joinInfo=null, topologyId=23, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf21/web, perf18/web, perf19/web]}, pendingCH=null, throwable=null, viewId=8}: java.lang.IllegalArgumentException: The task is already cancelled.
> at org.infinispan.statetransfer.InboundTransferTask.cancelSegments(InboundTransferTask.java:167)
> at org.infinispan.statetransfer.StateConsumerImpl.cancelTransfers(StateConsumerImpl.java:774)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:314)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:195)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:61)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:121)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:202)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:332)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:319)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:579)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_43]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_43]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_43]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_43]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_43]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_43]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_43]
> {code}
> If that happens, cluster recovery is interrupted and some caches may end up in a corrupted state where it's impossible for new members to join.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3130) Cancelling an InboundTransferTask should be idempotent
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3130?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3130:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1846
> Cancelling an InboundTransferTask should be idempotent
> ------------------------------------------------------
>
> Key: ISPN-3130
> URL: https://issues.jboss.org/browse/ISPN-3130
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 5.2.7.Final, 5.3.0.Final
>
>
> When installing a new topology, it's possible for the {{StateConsumerImpl.cancelSegments}} method to fail with an {{IllegalArgumentException}}:
> {code}
> 05:43:56,513 WARN [org.infinispan.topology.CacheTopologyControlCommand] (notification-thread-0) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=default-host/clusterbench, type=CH_UPDATE, sender=perf21/web, joinInfo=null, topologyId=23, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[perf21/web, perf18/web, perf19/web]}, pendingCH=null, throwable=null, viewId=8}: java.lang.IllegalArgumentException: The task is already cancelled.
> at org.infinispan.statetransfer.InboundTransferTask.cancelSegments(InboundTransferTask.java:167)
> at org.infinispan.statetransfer.StateConsumerImpl.cancelTransfers(StateConsumerImpl.java:774)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:314)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:195)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:61)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:121)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:202)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:332)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheStatusAfterMerge(ClusterTopologyManagerImpl.java:319)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleNewView(ClusterTopologyManagerImpl.java:236)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.handleViewChange(ClusterTopologyManagerImpl.java:579)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_43]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_43]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_43]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_43]
> at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:212)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_43]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_43]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_43]
> {code}
> Instead, it should just log a message and ignore the cancel request.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
Work on ISPN-761 started by William Burns.
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Labels: onboard, potential_performance_hit
> Fix For: 6.0.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-2995) FineGrainedAtomicHashMap may not lock all the composite keys in optimistic locking
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2995:
------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1845
> FineGrainedAtomicHashMap may not lock all the composite keys in optimistic locking
> ----------------------------------------------------------------------------------
>
> Key: ISPN-2995
> URL: https://issues.jboss.org/browse/ISPN-2995
> Project: Infinispan
> Issue Type: Bug
> Components: Fine-grained API
> Affects Versions: 5.3.0.Alpha1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: atomic_map, locking
> Fix For: 5.3.0.CR1
>
>
> In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node:
> {code}
> case ApplyDeltaCommand.COMMAND_ID:
> ApplyDeltaCommand command = (ApplyDeltaCommand) wc;
> if (cdl.localNodeIsOwner(command.getKey())) {
> Object[] compositeKeys = command.getCompositeKeys();
> set.addAll(Arrays.asList(compositeKeys));
> }
> break;
> {code}
> However, when we are going to acquire the lock in the node if it is the primary owner:
> {code}
> protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException {
> if (cdl.localNodeIsPrimaryOwner(key)) {
> lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking);
> } else if (cdl.localNodeIsOwner(key)) {
> ctx.getCacheTransaction().addBackupLockForKey(key);
> }
> }
> {code}
> The CompositeKey should always acquire the lock.
> This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3136) Argument type mismatch in RHQ for Amend XSite operations
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3136?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3136:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.CR1
5.3.0.Final
Resolution: Done
> Argument type mismatch in RHQ for Amend XSite operations
> ---------------------------------------------------------
>
> Key: ISPN-3136
> URL: https://issues.jboss.org/browse/ISPN-3136
> Project: Infinispan
> Issue Type: Bug
> Reporter: Tomas Sykora
> Assignee: Tomas Sykora
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> All 3 amend operations for XSite are not callable properly because of argument type mismatch exception.
> We need to specify type property for particular attributes in rhq-plugin.xml. It means we need to change Parameter class in jmx annotation slightly as well as description of XSite operations in XSiteAdminOperations class.
> Basically we need to add type="integer" or type="long" respectively for some fields.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3136) Argument type mismatch in RHQ for Amend XSite operations
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3136?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3136:
----------------------------------
Status: Pull Request Sent (was: Open)
> Argument type mismatch in RHQ for Amend XSite operations
> ---------------------------------------------------------
>
> Key: ISPN-3136
> URL: https://issues.jboss.org/browse/ISPN-3136
> Project: Infinispan
> Issue Type: Bug
> Reporter: Tomas Sykora
> Assignee: Tomas Sykora
>
> All 3 amend operations for XSite are not callable properly because of argument type mismatch exception.
> We need to specify type property for particular attributes in rhq-plugin.xml. It means we need to change Parameter class in jmx annotation slightly as well as description of XSite operations in XSiteAdminOperations class.
> Basically we need to add type="integer" or type="long" respectively for some fields.
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-761) Cache.keySet(), entrySet(), values(), size() ignore contents of cache loader
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-761?page=com.atlassian.jira.plugin.s... ]
William Burns reassigned ISPN-761:
----------------------------------
Assignee: William Burns (was: Galder Zamarreño)
> Cache.keySet(),entrySet(),values(),size() ignore contents of cache loader
> -------------------------------------------------------------------------
>
> Key: ISPN-761
> URL: https://issues.jboss.org/browse/ISPN-761
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 4.2.0.BETA1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Labels: onboard, potential_performance_hit
> Fix For: 6.0.0.Final
>
>
> Passivated cache entries are not represented in values returned by the keySet(), entrySet(), values(), and size() Cache methods. This results in inconsistent behavior, since it is possible that a given cache key may not be contained in keySet() even though Cache.get(...) would return a non-null value if the entry was previously passivated.
> I think CacheLoaderInterceptor needs to implement the following methods:
> Object visitSizeCommand(InvocationContext ctx, SizeCommand command) throws Throwable
> Object visitValuesCommand(InvocationContext ctx, ValuesCommand command) throws Throwable
> Object visitEntrySetCommand(InvocationContext ctx, EntrySetCommand command) throws Throwable
> Object visitKeySetCommand(InvocationContext ctx, KeySetCommand command) throws Throwable
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3144) Reduce memory consumption per cache entry
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3144?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-3144:
-----------------------------------
Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2013-May/012972.html
> Reduce memory consumption per cache entry
> -----------------------------------------
>
> Key: ISPN-3144
> URL: https://issues.jboss.org/browse/ISPN-3144
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> Basically, the difference between Hot Rod then (dc6708f) and now (6058358) is: 32 bytes, which is: new metadata object, a reference to it, and 2 unusued longs for immortal entries.
> With embedded metadata (~191 bytes per entry): https://dl.dropboxusercontent.com/u/6148072/with-embedded.png
> With versioned entries (~159 bytes per entry): https://dl.dropboxusercontent.com/u/6148072/with-versioned.png
> And there's more: we have internal cache entries that have a reference to internal cache values, per entry. This is useful for some cases (cache stores…etc), but this extra reference to the value, plus the value object itself, is 16 bytes (how useful is it really to have a separate value instance to keep just the value? Needs reassessing its usefulness...).
> So really, I think the minimum Hot Rod overhead we should aim for is ~143 bytes. If each server module could define what the ICE class (well, classes to cover all immortal, mortal…etc cases) to use, which is purely designed for their servers (i.e. hot rod just needs: value + version; memcached needs: value + version + flags), we could get to this level…
> You still want the metadata to be passed from the client, but for those specialised use cases in Infinispan, we could have a mapping between the metadata type and the type of ICEs created…
--
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
12 years, 10 months
[JBoss JIRA] (ISPN-3143) Cannot store custom objects via HotRod and read via REST
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3143?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-3143:
-------------------------------------
The same applies when storing object Person in embedded mode and trying to read it via REST. Reading via HotRod works nicely in this case.
> Cannot store custom objects via HotRod and read via REST
> --------------------------------------------------------
>
> Key: ISPN-3143
> URL: https://issues.jboss.org/browse/ISPN-3143
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 5.3.0.Beta2
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Fix For: 5.3.0.Final
>
>
> The following test fails when added to EmbeddedRestHotRodTest
> {code:java}
> public void testCustomObjectHotRodPutEmbeddedRestGet() throws Exception{
> final String key = "4";
> Person p = new Person("Martin");
> // 1. Put with Hot Rod
> RemoteCache<String, Object> remote = cacheFactory.getHotRodCache();
> assertEquals(null, remote.withFlags(Flag.FORCE_RETURN_VALUE).put(key, p));
> // 2. Get with Embedded
> assertTrue(cacheFactory.getEmbeddedCache().get(key) instanceof Person);
> assertEquals(p.getName(), ((Person) cacheFactory.getEmbeddedCache().get(key)).getName());
> // 3. Get with REST
> HttpMethod get = new GetMethod(cacheFactory.getRestUrl() + "/" + key);
> cacheFactory.getRestClient().executeMethod(get);
> assertEquals(HttpServletResponse.SC_OK, get.getStatusCode());
> //^^^ fails here - status code 500, status text: NullPointerException
> Object returnedPerson = remote.getRemoteCacheManager().getMarshaller().objectFromByteBuffer(get.getResponseBodyAsString().getBytes());
> assertTrue(returnedPerson instanceof Person);
> assertEquals(p.getName(), ((Person) returnedPerson).getName());
> }
> public static class Person implements Serializable {
> private String name;
> public Person(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> }
> {code}
> Storing and retrieving String keys works correctly.
--
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
12 years, 10 months
