hotrod client - initial connection
by Mircea Markus
Hi Galder,
Here are some thoughts I have about how the hotrod client performs initial connection to the HR servers:
A list of servers is statically configured so that the client can connect to any of them
1. client will ping each configured server until it finds one that is up and running
2. at this point it will stop(i.e. not query other statically configured servers) and query this server for the cluster topology
3. a a response to this query, the server informs the client about hotrod cluster topology (which might be different than infinispan cluster, right?)
4. based on this information client builds a pool of connections to the servers
5. client register itself as cluster formation listener, and update the list of active servers whenever the topology changes
(cluster formation might not be the best name for this listener as it only refers to the time when cluster is formed, what about cluster topology listener?)
How does this sound to you?
Also, a question about the way in which the server notifies the client on topology changes: how is this going to be performed network-wise? Some of the approaches I see are:
- serv socket opened on the client, server connects to it. Advantage: immediate notification on change. Disadvantage: network security issues, firewall. (also very uncommon for clients to do that, afaik)
- A thread on the client constantly pings the server and the new topology (if any is piggybacked). This would increase the latency, but will solve the firewall issues
- on each request, we piggyback this info, if needed
Please let me know your thoughts,
Cheers,
Mircea
15 years, 7 months
fetchPersistentState and local cache store has some data
by Mircea Markus
Hi,
This is a discussion Galder and I started on the irc.
We son't currently have a well defined policy for what happens when fetchPersistentState="true" and the node that receives state already has some data in it, that might overlap with remotely received data.
Most of the loaders right now do a clear() now, before integrating any data. This is not done by all the loaders: JdbmCacheStore, BdbjeCacheStore override this.
So some of the loaders do a mirror of the data(first they empty the store), some do an override.
Mirror might make sense in at least one scenario: you have a cluster running, each node having it's own local store. One node goes down and, after a while you re-start it. This new node will integrate the persistent state of the others, and entries might have been deleted in between (while the node was down). now, if these deleted entries are in new joiner's store, this would mean data inconsistency.
So I think we should:
- clearly define what happens with the existing data in the cache store during fetchPersistentState
- if we decide to clear it before fetchPersistentState, we should call store.clear() from StateTransferManager and not from particular cache store implementation, as this is error prone
- we can even use a configurable strategy, e.g. fetchPersistentState="none" fetchPersistentState="override" fetchPersistentState="mirror"
Cheers,
Mircea
15 years, 7 months
Attention CacheStore authors
by Manik Surtani
Hi all.
I recently committed ISPN-311 [1] and ISPN-310 [2]. This affects anyone implementing CacheLoader [3], as it adds 2 new methods to the interface [4]. The Javadocs on these methods should explain how they should be implemented and the JIRAs explain why.
I have updated all implementations in Infinispan trunk accordingly, this email is really more of a heads-up to folks implementing their own cache loader/stores.
The LockSupportCacheStore - an abstract building-block for certain cache stores - has also been updated to implement these methods, and to expose protected loadLockSafe(int) and loadAllKeysLockSafe(Set) methods [5].
I have also made a change to the BucketBasedCacheStore [6] - another abstract building-block. The key difference here is that certain methods - loadAllLockSafe(), as well as the new loadLockSafe(int) and loadAllKeysLockSafe(Set) - are implemented [7]. This means that concrete implementations do not need to implement these methods. All they do need to implement, now, is the new, abstract loopOverBuckets() method in BucketBasedCacheStore. See the changes in FileCacheStore as an example [8].
Enjoy,
Manik
[1] https://jira.jboss.org/jira/browse/ISPN-311
[2] https://jira.jboss.org/jira/browse/ISPN-310
[3] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[4] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[5] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[6] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[7] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
[8] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 7 months
Hot Rod Ports
by Galder Zamarreno
Hi,
For the memcached server, I've defaulted to the same port as Memcached(Tm)
does: 11211.
Now, what shall we do for Hot Rod? Shall we leave the same default port as
for Memcached? or should we define a separate default port for it? My
preference is with the latter, i.e. 11311.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years, 7 months
Attention all CacheLoader/Store authors
by Manik Surtani
As pointed out by Amin in ISPN-333 [1], we instantiate all cache loader/store impls twice, if configured via XML. This is so that the configuration parser is able to call CacheLoader.getConfigurationClass() to get a hold of the corresponding CacheLoaderConfig instance to set it up. This additional instantiation is only incurred when starting a cache so it isn't really on the critical path, but as of Infinispan 4.1 (trunk at the moment) there is another way to provide this information, which will prevent unnecessary instantiation.
I just checked in the @CacheLoaderMetadata [2] annotation which you can use to annotate your cache loader/store implementation, which will prevent it from being instantiated twice since the CacheLoaderConfig type can be provided via this annotation.
Enjoy
Manik
[1] https://jira.jboss.org/jira/browse/ISPN-333
[2] http://fisheye.jboss.org/changelog/Infinispan/trunk?cs=1578
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 7 months
Comparing Infinispan with EHCache
by Steve Olson
Hello,
Can any of you point me to a reference (paper, article, web page) that
contains a comparison of Infinispan with EHCache? Specifically, we are
looking to evaluate Terracotta's EHCache FX with Infinispan; somehow,
I think that may have already been done!
Best regards,
Steve Olson
15 years, 7 months
Netty 3.2.0.BETA1 is out
by "Trustin Lee (이희승)"
Hey folks (mostly to Galder, since he asked),
Netty 3.2.0.BETA1 has been released last night. Check out the release
announcement: http://is.gd/9IsIa
Try to upgrade from 3.1 to 3.2 as a quick preview. It's feature-frozen
so it shouldn't take long until you see the final release.
Manik also might be interested in this release since it obviously
performs better than last time he tried. :)
Cheers,
Trustin
--
what we call human nature in actuality is human habit
http://gleamynode.net/
15 years, 7 months
