Generalizing Externalizer interface
by Galder Zamarreño
As part of https://jira.jboss.org/browse/ISPN-246, we're gonna be making Externalizer interface (http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/marshall/Exte...) even more public allowing users to provide their own externalizer implementations.
I had a brief scan and it seems like (or so should be unless it's a very strange externalizer), that all Externalizers are symmetric. IOW, whatever type the writeObject() object is passed, that's the type we return in readObject(). So, I was thinking of generalizing Externalizer to look something like this:
interface Externalizer<T> {
void writeObject(ObjectOutput output, T object) throws IOException;
T readObject(ObjectInput input) throws IOException, ClassNotFoundException;
}
Does anyone have any objections? This would safe a lot of casting in implementations, making externalizers easier to code and type safer.
Cheers,
p.s. This would only be included in 5.x.
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 6 months
5.0.0.ALPHA1
by Galder Zamarreño
I've just created this version in JIRA: https://jira.jboss.org/browse/ISPN/fixforversion/12315747
If you're planning to include any work in this release, make sure you set the fix version accordingly.
Note that we're planning to release this before Xmas.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 6 months
Rehashing on view changes
by Bela Ban
Quick question: when I have a view {A,B,C,D,E,F} at time T and then
receive 2 subsequent views within 3 seconds:
- {A,B,C}
- {A,B,C,E,F}
will there be 2 rehashes / rebalancings, or 1 ? Is there a delay that
can be configured for rebalancing on view changes ?
The reason I'm asking is that I'm working on RELAY for JGroups, which
will allow for distribution of data across geographically separate
clusters, e.g. NYC={A,B,C} and SFO={D,E,F}.
NYC and SFO are linked by a relay, and the global view is therefore
{A,B,C,D,E,F}.
A is responsible for establishing a global view for NYC, and D does the
same for SFO.
What happens in NYC when D crashes, or leaves is:
- All nodes from the remote cluster are removed from the global view:
{A,B,C}
- E then takes over as coordinator in SFO and establishes a bridge
cluster with A, so A now installs {A,B,C,E,F}
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
13 years, 6 months
server hinting improvement
by Mircea Markus
Hi,
Just had a chat with Bela on the IRC related to server hinting. Following improvement can be implemented within infinispan:
{A,B,C} in NYC and {X,Y,Z} in SFO. K hashes to A and topology aware CH sets X as backup. Now if Y is asked for K, it would go to A - not optimal as the info is already on its site within X.The optimisation would be to go to X for such a call, and avoid a inter-sites RPC.
Cheers,
Mircea
13 years, 6 months
Exception during rehash
by Tristan Tarrant
Dear all,
we are using 4.2.0.BETA1 and we are getting the following message when a
second node is started.
2010-11-11 15:04:38,397 INFO [STDOUT] (main) 20101111 150438 INFO
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] (main) Cache
local address is asrab02-38676, physical addresses are [10.100.0.6:55448]
2010-11-11 15:06:38,656 INFO [STDOUT] (Rehasher-asrab02-38676) 20101111
150638 ERROR [org.infinispan.distribution.JoinTask] (Rehasher-asrab02-38676)
Caught exception!
org.infinispan.CacheException:
org.infinispan.util.concurrent.TimeoutException: Timed out after 120 seconds
waiting for a response from asrab01-58616
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:122)
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:403)
at
org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:101)
at
org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:125)
at org.infinispan.distribution.JoinTask.retrieveOldCH(JoinTask.java:187)
at org.infinispan.distribution.JoinTask.performRehash(JoinTask.java:87)
at org.infinispan.distribution.RehashTask.call(RehashTask.java:53)
at org.infinispan.distribution.RehashTask.call(RehashTask.java:33)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out after
120 seconds waiting for a response from asrab01-58616
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$ReplicationTask.call(CommandAwareRpcDispatcher.java:304)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:120)
... 12 more
2010-11-11 15:06:38,657 INFO [STDOUT] (Rehasher-asrab02-38676) 20101111
150638 INFO [org.infinispan.distribution.TransactionLoggerImpl]
(Rehasher-asrab02-38676) Stopping transaction logging
2010-11-11 15:06:38,657 INFO [STDOUT] (Rehasher-asrab02-38676) 20101111
150638 INFO [org.infinispan.distribution.JoinTask] (Rehasher-asrab02-38676)
asrab02-38676 completed join rehash!
The first node prints out the following:
2010-11-11 15:01:55,725 INFO [STDOUT]
(Incoming-1,ngs-infinispan-preprod_cluster,asrab01-58616) 20101111 150155
INFO [org.infinispan.distribution.DistributionManagerImpl]
(Incoming-1,ngs-infinispan-preprod_cluster,asrab01-58616) Detected a view
change. Member list changed from [asrab01-58616] to [asrab01-58616,
asrab02-38676]
.....
2010-11-11 15:01:55,731 INFO [STDOUT]
(Incoming-1,ngs-infinispan-preprod_cluster,asrab01-58616) 20101111 150155
INFO [org.infinispan.distribution.DistributionManagerImpl]
(Incoming-1,ngs-infinispan-preprod_cluster,asrab01-58616) This is a JOIN
event! Wait for notification from new joiner asrab02-38676
What does it mean ?
Thanks in advance
Tristan
13 years, 6 months
RC1 today
by Mircea Markus
Hi,
I want to cut an RC1 today lunch time - 12 GMT. How does that sound?
Cheers,
Mircea
13 years, 6 months
Move to JGroups 2.11.0GA
by Vladimir Blagojevic
Hi,
With a move to JGroups 2.11.0.GA I get a about dozen test failures
locally in Infinispan test suite. I made no changes to tcp.xml
configuration file. Upon closer inspection I noticed that message are
sometimes getting dropped at discovery phase since logical names did not
get mapped to physical addresses. In order to alleviate such cases
JGroups has return_entire_cache boolean flag in all discovery protocols.
If return_entire_cache is true the entire cache of these mappings is
returned to a joining node upon join request.
However, JGroups 2.11 also has ergonomics protocol attribute (true by
default) and if we are dealing with small clusters (<10 nodes)
return_entire_cache is set to false during runtime despite
return_entire_cache being preset to true by default in TCPPING (see
Discovery#down).
After I set ergonomics="false" for TCPPING a local run of Infinispan
test suite passed with zero failures or skipped tests!
What should we do?
Regards,
Vladimir
13 years, 6 months
