Re: [infinispan-dev] javax.transaction.xa.Xid
by Mircea Markus
On 17 Mar 2011, at 10:33, Jonathan Halliday wrote:
>
> You'll need to store the content, not the Object. The interface has getters to extract the field values which are primitive types and thus easy to store. You'll need your own impl of the interface if you need to recreate internally. JBossTS does not care what it receives, as long as it implements the Xid interface. It won't necessarily give you back your own impl when calling your methods though.
good, that's what I expected.
>
> If you're writing your own impl the most important bit oddly enough is toString(). We have endless hassle from systems that print Xids binary value in different forms, making correlation of the TM and RM logs rather hairy. Try not to invent yet another format please :-)
What I can do is use the same .toString from JBossTM: can you please confirm this is the one: com.arjuna.ats.jta.xa.toString()
The problem is still there for other TMs though, so at one point we might want to do this pluggable.
Pluggable .toString() - can't believe I've just said that!!! :-)
>
> Jonathan.
>
> On 03/17/2011 10:26 AM, Mircea Markus wrote:
>> Hi Jonathan,
>>
>> We need to serialize the javax.transaction.xa.Xid received from TM in order to back up information on other nodes. Xid is not serializable so we need to use our internal Xid implementation in order to be able to de-serialize it.
>> This also means that XAResource.recover returns Xid instances that are of type org.infinispan.tx.Xid, with its own implementation of equals and hashcode, but with exactly the same state as the org.custom.tm.Xid.
>> Would JBossTM expect XAResource.recover to return Xids of a different java.lang.Class? What's your take in general on this problem?
>>
>> Cheers,
>> Mircea
>
> --
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).
15 years
javax.transaction.xa.Xid
by Mircea Markus
Hi Jonathan,
We need to serialize the javax.transaction.xa.Xid received from TM in order to back up information on other nodes. Xid is not serializable so we need to use our internal Xid implementation in order to be able to de-serialize it.
This also means that XAResource.recover returns Xid instances that are of type org.infinispan.tx.Xid, with its own implementation of equals and hashcode, but with exactly the same state as the org.custom.tm.Xid.
Would JBossTM expect XAResource.recover to return Xids of a different java.lang.Class? What's your take in general on this problem?
Cheers,
Mircea
15 years
Problem creating a cache on second node
by Brian Ashburn
I am doing a POC to test out some things with Infinispan. I have two nodes
with the same deployment on each one. If I go to a node, doesn't matter
which one, and create a cache there, I can access that cache from the second
node, but when I go to create another cache on the second node, I get the
following exception:
15:05:23,316 INFO [STDOUT] 15:05:23,314 ERROR [RpcManagerImpl] unexpected
error while replicating
org.infinispan.manager.NamedCacheNotFoundException: Cache: cacheB
at
org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:72)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:177)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:149)
at
org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:578)
at
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:489)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:771)
at org.jgroups.JChannel.up(JChannel.java:1465)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:430)
at
org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:265)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:190)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:419)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:419)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:888)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:577)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:295)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:707)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:120)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:169)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:269)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:210)
at org.jgroups.protocols.Discovery.up(Discovery.java:292)
at org.jgroups.protocols.PING.up(PING.java:67)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1093)
at org.jgroups.protocols.TP.access$100(TP.java:56)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1633)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1615)
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:636)
15:05:23,318 INFO [STDOUT] 15:05:23,317 ERROR [JoinTask] Caught exception!
org.infinispan.CacheException:
org.infinispan.manager.NamedCacheNotFoundException: Cache: cacheB
at
org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:114)
at
org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:125)
at org.infinispan.distribution.JoinTask.retrieveOldCH(JoinTask.java:192)
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:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:636)
Caused by: org.infinispan.manager.NamedCacheNotFoundException: Cache: cacheB
at
org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:72)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:177)
at
org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:149)
at
org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:578)
at
org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:489)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
at
org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:771)
at org.jgroups.JChannel.up(JChannel.java:1465)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:954)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:430)
at
org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:265)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:190)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:419)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:419)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:888)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:577)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:295)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:707)
at org.jgroups.protocols.BARRIER.up(BARRIER.java:120)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:169)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:269)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:210)
at org.jgroups.protocols.Discovery.up(Discovery.java:292)
at org.jgroups.protocols.PING.up(PING.java:67)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1093)
at org.jgroups.protocols.TP.access$100(TP.java:56)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1633)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1615)
... 3 more
I'm accessing this with the following configuration:
<?xml version="1.0" encoding="UTF-8"?>
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:4.2
http://www.infinispan.org/schemas/infinispan-config-4.2.xsd"
xmlns="urn:infinispan:config:4.2">
<global>
<transport
clusterName="myCluster"
transportClass="org.infinispan.remoting.transport.jgroups.JGroupsTransport"/>
<globalJmxStatistics enabled="true"/>
</global>
<default>
<jmxStatistics enabled="true"/>
<clustering mode="distribution">
<l1 enabled="true" lifespan="60000"/>
<hash numOwners="2" rehashRpcTimeout="120000"/>
<async/>
</clustering>
</default>
</infinispan>
And this is the code I'm executing:
DefaultCacheManager cacheContainer = (DefaultCacheManager)
ctx.lookup("java:comp/env/CacheContainer");
Cache cache;
if (cacheContainer.getCacheNames() != null &&
cacheContainer.getCacheNames().contains(name)) {
cache = cacheContainer.getCache(name);
} else {
Configuration conf = new Configuration();
if (name.endsWith("A")) {
conf.setExpirationLifespan(5000);
} else if (name.endsWith("B")) {
conf.setExpirationLifespan(30000);
} else {
conf.setExpirationLifespan(60000);
}
cacheContainer.defineConfiguration(name, conf);
cache = cacheContainer.getCache(name);
}
Integer counter = (Integer) cache.get("counter");
if (counter == null)
counter = new Integer(0);
counter++;
response.getOutputStream().println("Counter : " + counter);
cache.put("counter", counter);
This seems like a pretty straightforward use-case. I'm going to grab the
git repo and start to look into it, but any help or hints would be great.
Thanks,
Brian Ashburn
15 years
Adding a cache in another cache..
by venkatesh k c
hi,
I'm trying to store a cache in another cache.
is it possible..?
EmbeddedCacheManager cacheManager = new DefaultCacheManager("config.xml");
Cache<Object,Object> cache = cacheManager.getCache();
Cache<Object,Object> store = cacheManager.getCache();
cache.put("Cache",store);
Please reply ASAp
Thanks in Advance
Regards..
Venkatesha.k.c
15 years
EmbeddedCacheManager needs getRunningCacheNames, doesn't it?
by Galder Zamarreño
Guys,
This (http://community.jboss.org/message/592436#592436) thread brought up an interesting limitation of our CacheManager API.
Let's say you wanna remove all caches within a cache manager, and by remote I mean not only clear the in memory contents, but also the cache store stuff (so, similar to what is suggested in https://issues.jboss.org/browse/ISPN-905 but at the cache manager level)
I don't think this is such a common use case to require a removeAllCaches() at the CacheManager level (or maybe it does?). One would imagine that given a removeCache(name), you should be able to get all cache names and loop through them. However, there's no such method. We have getCacheNames() but that's only limited to the cache names that have predefined either via XML, as <namedCache>, or programmatically via defineConfiguration. Any other cache that might have been started and whose name was not predefined would be a running a cache based on the default config. However, there's no way to find out about all these caches.
So, rather than providing removeAllCaches(), it might more interesting to provide: getRunningCacheNames() which would be getCacheNames() + (undefined caches that have been started which are based on default config). Or maybe we wanna provide both!
Clearly, something for 5.0.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
15 years
Primary-Backup replication scheme in Infinispan
by Sebastiano Peluso
Hi all,
first let us introduce ourselves given that it's the first time we write
in this mailing list.
Our names are Sebastiano Peluso and Diego Didona, and we are working at
INESC-ID Lisbon in the context of the Cloud-TM project. Our work is
framed in the context of self-adaptive replication mechanisms (please
refer to previous message by Paolo on this mailing list and to the
www.cloudtm.eu website for additional details on this project).
Up to date we have been working on developing a relatively simple
primary-backup (PB) replication mechanism, which we integrated within
Infinispan 4.2 and 5.0. In this kind of scheme only one node (called the
primary) is allowed to process update transactions, whereas the
remaining nodes only process read-only transactions. This allows coping
very efficiently with write transactions, as the primary does not have
to incur in the cost of remote coordination schemes nor in distributed
deadlocks, which can hamper performance at high contention with two
phase commit schemes. With PB, in fact, the primary can serialize
transactions locally, and simply propagate the updates to the backups
for fault-tolerance as well as to allow them to process read-only
transactions on fresh data of course. On the other hand, the primary is
clearly prone to become the bottleneck especially in large clusters and
write intensive workloads.
Thus, this scheme does not really represent a replacement for the
default 2PC protocol, but rather an alternative approach that results
particularly attractive (as we will illustrate in the following with
some radargun-based performance results) in small scale clusters, or, in
"elastic" cloud scenarios, in periods where the workload is either read
dominated or not very intense. Being this scheme particularly efficient
in these scenarios, in fact, its adoption would allow to minimize the
number of resources acquired from the cloud provider in these periods,
with direct benefits in terms of cost reductions. In Cloud-TM, in fact,
we aim at designing autonomic mechanisms that would dynamically switch
among multiple replication mechanisms depending on the current workload
characteristics.
Before discussing the results of our preliminary benchmarking study, we
would like to briefly overview how we integrated this replication
mechanism within Infinispan. Any comment/feedback is clearly highly
appreciated. First of all we have defined a new command, namely
PassiveReplicationCommand, that is a subclass of PrepareCommand. We had
to define a new command because we had to design customized "visiting"
methods for the interceptors. Note that our protocol only affects the
commit phase of a transaction, specifically, during the prepare phase,
in the prepare method of the TransactionXaAdapter class, if the Primary
Backup mode is enabled, then a PassiveReplicationCommand is built by the
CommandsFactory and it is passed to the invoke method of the invoker.
The PassiveReplicationCommand is then visited by the all the
interceptors in the chain, by means of the
visitPassiveReplicationCommand methods. We describe more in detail the
operations performed by the non-trivial interceptors:
-TxInterceptor: like in the 2PC protocol, if the context is not
originated locally, then for each modification stored in the
PassiveReplicationCommand the chain of interceptors is invoked.
-LockingInterceptor: first the next interceptor is called, then the
cleanupLocks is performed with the second parameter set to true (commit
the operations). This operation is always safe: on the primary it is
called only after that the acks from all the slaves are received (see
the ReplicationInterceptor below); on the slave there are no concurrent
conflicting writes since these are already locally serialized by the
locking scheme performed at the primary.
-ReplicationInterceptor: first it invokes the next iterceptor; then if
the predicate shouldInvokeRemoteTxCommand(ctx) is true, then the method
rpcManager.broadcastRpcCommand(command, true, false) is performed, that
replicates the modifications in a synchronous mode (waiting for an
explicit ack from all the backups).
As for the commit phase:
-Given that in the Primary Backup the prepare phase works as a commit
too, the commit method on a TransactionXaAdapter object in this case
simply returns.
On the resulting extended Infinispan version a subset of unit/functional
tests were executed and successfully passed:
- commands.CommandIdUniquenessTest
- replication.SyncReplicatedAPITest
- replication.SyncReplImplicitLockingTest
- replication.SyncReplLockingTest
- replication.SyncReplTest
- replication.SyncCacheListenerTest
- replication.ReplicationExceptionTest
We have tested this solution using a customized version of Radargun. Our
customizations were first of all aimed at having each thread accessing
data within transactions, instead of executing single put/get
operations. In addition, now every Stresser thread accesses with uniform
probability all of the keys stored by Infinispan, thus generating
conflicts with a probability proportional to the number of concurrently
active threads and inversely proportional to the total number of keys
maintained.
As already hinted, our results highlight that, depending on the current
workload/number of nodes in the system, it is possible to identify
scenarios where the PB scheme significantly outperforms the current 2PC
scheme, and vice versa. Our experiments were performed in a cluster of
homogeneous 8-core (Xeon(a)2.16GhZ) nodes interconnected via a Gigabit
Ethernet and running a Linux Kernel 64 bit version 2.6.32-21-server. The
results were obtained by running for 30 seconds 8 parallel Stresser
threads per nodes, and letting the number of node vary from 2 to 10. In
2PC, each thread executes transactions which consist of 10 (get/put)
operations, with a 10% of probability of generating a put operation.
With PB, the same kind of transactions are executed on the primary, but
the backups execute read-only transactions composed of 10 get
operations. This allows to compare the maximum throughput of update
transactions provided by the two compared schemes, without excessively
favoring PB by keeping the backups totally idle.
The total write transactions' throughput exhibited by the cluster (i.e.
not the throughput per node) is shown in the attached plots, relevant to
caches containing 1000, 10000 and 100000 keys. As already discussed, the
lower the number of keys, the higher the chance of contention and the
probability of aborts due to conflicts. In particular with the 2PC
scheme the number of failed transactions steadily increases at high
contention up to 6% (to the best of our understanding in particular due
to distributed deadlocks). With PB, instead the number of failed txs due
to contention is always 0.
Note that, currently, we are assuming that backup nodes do not generate
update transactions. In practice this corresponds to assuming the
presence of some load balancing scheme which directs (all and only)
update transactions to the primary node, and read transactions to the
backup. In the negative case (a put operation is generated on a backup
node), we simply throw a PassiveReplicationException at the
CacheDelegate level. This is probably suboptimal/undesirable in real
settings, as update transactions may be transparently rerouted (at least
in principle!) to the primary node in a RPC-style. Any suggestion on how
to implement such a redirection facility in a transparent/non-intrusive
manner would be highly appreciated of course! ;-)
To conclude, we are currently working on a statistical model that is
able to predict the best suited replication scheme given the current
workload/number of machines, as well as on a mechanism to dynamically
switch from one replication scheme to the other.
We'll keep you posted on our progresses!
Regards,
Sebastiano Peluso, Diego Didona
15 years
4.2.1.CR4 tag not visible in github
by Michal Linhard
Hi guys,
I can't see 4.2.1.CR4 tag in github:
https://github.com/infinispan/infinispan
It also doesn't appear to be present in the repo
I did git fetch --tags
and git tag -l 4.2.* doesn't show it.
is it only my local problem or does anyone else have it ?
m.
--
Michal Linhard
Quality Assurance Engineer
Red Hat Czech s.r.o.
Purkynova 99 612 45 Brno, Czech Republic
phone: +420 532 294 320 ext. 62320
mobile: +420 728 626 363
15 years
XAResource.recover
by Mircea Markus
Hi Jonathan,
We're thinking to implement the following optimisation around recovery and want to run it by you first.
As discussed, XAResource.recover broadcasts a call to all cluster members, and all the prepared transactions initiated by this node's TM would be returned from this method.
What we are thinking is the following: only perform the broadcast once, the first time XARespurce.recover is called. After that keep track of the prepared tx that originated on the same node, and return this list only *without* doing the broadcast.
Do you see any problem this approach?
One more (unrelated) question: how does a TM determine that a tx pertains to it or not. Based on Xid's branch identifier perhaps? We might do some further optimisations based on this.
Cheers,
Mircea
15 years
Node being an owner of key
by Vladimir Blagojevic
Hey,
Can we make method getAddress public on DistributionManager? Either that
or add a new method to DistributionManager which returns true if node is
an owner of a key, that is, if key is local and locate(key) returns a
list of addresses where first address equals to this node. It would be
great if we can do this under the lock, just like getLocality, so we can
detect situation where distributed task execution was done during rehash.
I'd prefer to have a new method :-). This is all for 5.0
Let me know,
Vladimir
15 years
