[JBoss JIRA] (ISPN-6496) Custom interceptor's start method not called if interceptor added via AdvancedCache
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-6496:
---------------------------------
Summary: Custom interceptor's start method not called if interceptor added via AdvancedCache
Key: ISPN-6496
URL: https://issues.jboss.org/browse/ISPN-6496
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.2.Final
Reporter: Jiří Holuša
Suppose I want to add trivial custom interceptor like this:
{code}
public class LocalIndexInterceptor extends BaseCustomInterceptor {
@Override
protected void start() {
System.out.println("Start method executed");
}
// override some command methods here
}
{code}
When I attach the interceptor via:
{code}
cache.getAdvancedCache().addInterceptor(new LocalIndexInterceptor(), 0);
{code}
the start method never gets called and nothing is printed. When I add the interceptor during the cache configuration (via ConfigurationBuilder.customInterceptor().addInterceptor().interceptor()), everything works fine and the start method is executed.
I noticed at the @Start annotation Javadoc: "Method level annotation that indicates a (no-param) method to be called on a component registered in the ComponentRegistry when the cache starts.", so I get it that it's not executed since the cache is already started. However, without the start() method being executed, I cannot access cache additional object (DistributionManager, RpcManager) in the interceptor, which might be needed (and I needed it :) ).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3905:
----------------------------------
Fix Version/s: (was: 9.0.0.Alpha2)
> Murmurhash3 implementation is slow on String keys
> -------------------------------------------------
>
> Key: ISPN-3905
> URL: https://issues.jboss.org/browse/ISPN-3905
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 6.0.0.Final, 6.0.1.Final
> Reporter: Sanne Grinovero
> Assignee: Dan Berindei
> Priority: Minor
>
> String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too.
> I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-3729) Minimize the number of moved segments for SyncConsistentHashFactory
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3729?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3729:
----------------------------------
Fix Version/s: (was: 9.0.0.Alpha2)
> Minimize the number of moved segments for SyncConsistentHashFactory
> -------------------------------------------------------------------
>
> Key: ISPN-3729
> URL: https://issues.jboss.org/browse/ISPN-3729
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
>
> SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes.
> In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments).
> Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "lose" segments to another existing node (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-317?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant closed ISPN-317.
--------------------------------
Fix Version/s: 5.2.0.Final
Resolution: Done
> when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
> ----------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-317
> URL: https://issues.jboss.org/browse/ISPN-317
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.1.0.FINAL
> Reporter: Mircea Markus
> Priority: Minor
> Fix For: 5.2.0.Final
>
>
> at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months