[JBoss JIRA] (ISPN-2459) Rollback not preceded by Prepare sent to remote site
by Radim Vansa (JIRA)
Radim Vansa created ISPN-2459:
---------------------------------
Summary: Rollback not preceded by Prepare sent to remote site
Key: ISPN-2459
URL: https://issues.jboss.org/browse/ISPN-2459
Project: Infinispan
Issue Type: Bug
Components: Cross-Site Replication, Transactions
Affects Versions: 5.2.0.Beta3
Reporter: Radim Vansa
Assignee: Mircea Markus
When a {{TransactionManager.rollback()}} is called under optimistic locking, the {{RollbackCommand}} is sent to the remote site with backup cache. This makes no sense as there are no changes to roll back, and furthermore, the command fails in the remote site as the transaction which is rolled back is not known:
{code}
05:37:00,727 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-2,global,_edg-perf01-58034:LON) Problems invoking command SingleRpcCommand{cacheName='nycCache', command=RollbackCommand {gtx=GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local, cacheName='nycCache', topologyId=-1}}
org.infinispan.CacheException: Couldn't find a local transaction corresponding to remote transaction GlobalTransaction:<c25cba86-1e90-e190-b101-155e93063c9c[T]>:5:local
at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.completeTransaction(BackupReceiver.java:187)
at org.infinispan.xsite.BackupReceiver$BackupCacheUpdater.visitRollbackCommand(BackupReceiver.java:178)
at org.infinispan.commands.tx.RollbackCommand.acceptVisitor(RollbackCommand.java:61)
at org.infinispan.xsite.BackupReceiver.handleRemoteCommand(BackupReceiver.java:76)
at org.infinispan.xsite.BackupReceiverRepositoryImpl.handleRemoteCommand(BackupReceiverRepositoryImpl.java:60)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromRemoteSite(CommandAwareRpcDispatcher.java:240)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:217)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
at org.jgroups.JChannel.up(JChannel.java:670)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.relay.RELAY2.deliver(RELAY2.java:420)
at org.jgroups.protocols.relay.RELAY2.route(RELAY2.java:316)
at org.jgroups.protocols.relay.RELAY2.handleMessage(RELAY2.java:292)
at org.jgroups.protocols.relay.RELAY2.handleRelayMessage(RELAY2.java:272)
at org.jgroups.protocols.relay.Relayer$Bridge.receive(Relayer.java:214)
at org.jgroups.JChannel.invokeCallback(JChannel.java:712)
at org.jgroups.JChannel.up(JChannel.java:673)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.RSVP.up(RSVP.java:188)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:769)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:601)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1293)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1856)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1829)
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:662)
{code}
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2482) Simplify XSite configuration
by Mircea Markus (JIRA)
Mircea Markus created ISPN-2482:
-----------------------------------
Summary: Simplify XSite configuration
Key: ISPN-2482
URL: https://issues.jboss.org/browse/ISPN-2482
Project: Infinispan
Issue Type: Feature Request
Components: Cross-Site Replication
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.2.0.CR1
The relay.xml configuration file which is referred from the local cluster's jgroups.xml can be code-injected in JGroups directly. Nice to have a simplified configuration file.
Sample code for the code-injection is Relay2Test
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2560) Distribution ZIP file polluted
by Manik Surtani (JIRA)
Manik Surtani created ISPN-2560:
-----------------------------------
Summary: Distribution ZIP file polluted
Key: ISPN-2560
URL: https://issues.jboss.org/browse/ISPN-2560
Project: Infinispan
Issue Type: Bug
Components: Build process
Affects Versions: 5.2.0.Beta4
Reporter: Manik Surtani
Assignee: Mircea Markus
Priority: Critical
Fix For: 5.2.0.CR1, 5.2.0.Final
There appear to be a lot of files packaged up and archived in various (incorrect and superfluous) places in the ZIP archives.
1. Looking at 5.2.0.Beta4-all.zip, I see:
{{
Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf infinispan-core.jar | grep "\.sh"
functions.sh
importConfig.sh
Multiverse:infinispan-5.2.0.Beta4-all manik $
}}
Why are these shell scripts in the JAR file?
2. Also, I see similar things in other JAR files:
{{
Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/demos/ec2/infinispan-ec2-demo.jar | grep "\.sh"
runEC2Demo-all.sh
runEC2Demo-influenza.sh
runEC2Demo-nucleotide.sh
runEC2Demo-protein.sh
runEC2Demo-query.sh
runEC2Demo-reader.sh
Multiverse:infinispan-5.2.0.Beta4-all manik $
}}
{{
Multiverse:infinispan-5.2.0.Beta4-all manik $ jar tf modules/cli-client/infinispan-cli-client.jar | grep "\.sh"
ispn-cli.sh
Multiverse:infinispan-5.2.0.Beta4-all manik $
}}
3. I see these in {{/etc/}} which, if I now put {{/etc/}} in my classpath, causes things to break in spectacular ways due to the service loaded picking up incorrect metadata.
{{
Multiverse:infinispan-5.2.0.Beta4-all manik $ ls etc/META-INF/services/
org.infinispan.cli.commands.Command
org.infinispan.cli.connection.Connector
org.infinispan.commands.module.ModuleCommandExtensions
org.infinispan.configuration.parsing.ConfigurationParser
org.infinispan.distexec.mapreduce.spi.MapReduceTaskLifecycle
org.infinispan.distexec.spi.DistributedTaskLifecycle
org.infinispan.factories.components.ModuleMetadataFileFinder
org.infinispan.lifecycle.ModuleLifecycle
Multiverse:infinispan-5.2.0.Beta4-all manik $
}}
4. Why do we package {{etc/infinispan-query-component-metadata.dat}}? That should be a part of infinispan-query.jar, and not in etc.
5. What is in {{/etc/help}}? Looks like resource files for the CLI, which should really be in one of the CLI jars.
Marking this as critical, since this is messy and confusing for users, and can cause breakage when running some demos and makes things very confusing to debug.
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
by Robert Stupp (JIRA)
Robert Stupp created ISPN-2240:
----------------------------------
Summary: Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
Key: ISPN-2240
URL: https://issues.jboss.org/browse/ISPN-2240
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.1.6.FINAL
Reporter: Robert Stupp
Assignee: Mircea Markus
Attachments: somehow.zip
Hi,
I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster.
I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions.
A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-)
In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows:
{noformat}
public void releaseLock(Object lockOwner, Object key) {
ReentrantLock l = locks.get(key);
if (l != null) {
if (!l.isHeldByCurrentThread())
throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread());
while (l.isHeldByCurrentThread())
unlock(l, lockOwner);
if (!l.hasQueuedThreads())
locks.remove(key);
}
else
throw new IllegalStateException("No lock for [" + key + ']');
}
{noformat}
The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock.
If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client.
The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key.
The re-implemented method should also fix some replication timeout exceptions.
Please, please add this to 5.1.7, if possible.
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2510) PrepareCommands should fail on nodes where the cache is not running
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2510:
----------------------------------
Summary: PrepareCommands should fail on nodes where the cache is not running
Key: ISPN-2510
URL: https://issues.jboss.org/browse/ISPN-2510
Project: Infinispan
Issue Type: Bug
Components: Distributed Cache, RPC
Affects Versions: 5.2.0.Beta3
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 5.2.0.Final
When the user stops a cache without stopping the cache manager on that node, subsequent PrepareCommands sent to that node will return a {{SuccessfulResponse}}.
If that node used to the primary owner of the command's modified key, the originator will proceed with the transaction as if it had acquired a lock on that key. It is thus possible for multiple transactions to think they have acquired the key lock at the same time.
On the other hand, in replicated caches is is quite possible that a cache is not running on all the cluster node and yet PrepareCommands are broadcasted to everyone in parallel. So the solution should not involve sending exceptions (which have huge stack traces), and the originator should be able to ignore failures responses from nodes that were not targeted in the first place.
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2205:
----------------------------------
Summary: Design HotRod protocol version 1.2
Key: ISPN-2205
URL: https://issues.jboss.org/browse/ISPN-2205
Project: Infinispan
Issue Type: Task
Components: Cache Server
Affects Versions: 5.2.0.ALPHA2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.FINAL
The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be.
The new version could also incorporate fixes for older issues like ISPN-1293.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (ISPN-2568) Javadoc: Missing some documentations
by Thomas Fromm (JIRA)
Thomas Fromm created ISPN-2568:
----------------------------------
Summary: Javadoc: Missing some documentations
Key: ISPN-2568
URL: https://issues.jboss.org/browse/ISPN-2568
Project: Infinispan
Issue Type: Enhancement
Components: Core API
Affects Versions: 5.2.0.Beta4
Reporter: Thomas Fromm
Assignee: Mircea Markus
Priority: Minor
When browsing ajavdoc of infinispan I miss following stuff:
Important for the Overview:
1) Package description of org.infinispan.config should contain information that this is deprecated.
2) org.infinispan.configuration package description in general and hints where to start with (e.g. at the Builder classes). Also the link to the generated configuration reference.
3) The configuration reference is missing in general. e.g.
http://docs.jboss.org/infinispan/5.2/apidocs/config.html#ce_infinispan_de...
--
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
11 years, 4 months
[JBoss JIRA] (ISPN-2561) RejectedExecutionException thrown from StaleTransactionCleanupService during cache shutdown
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-2561:
-----------------------------------
Summary: RejectedExecutionException thrown from StaleTransactionCleanupService during cache shutdown
Key: ISPN-2561
URL: https://issues.jboss.org/browse/ISPN-2561
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 5.2.0.Beta4
Reporter: Adrian Nistor
Assignee: Mircea Markus
Priority: Minor
Fix For: 5.2.0.Final
We should not submit stale transaction cleanup tasks after we started shutdown. This exception is now caught and logged. It does not impact functionality but it clutters the logs a lot.
{noformat}
2012-11-26 17:49:07,855 ERROR [org.infinispan.transaction.StaleTransactionCleanupService] (OOB-2,ISPN,NodeB-36237) Unable to submit task to executor
java.util.concurrent.RejectedExecutionException
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1768)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767)
at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:215)
at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:397)
at java.util.concurrent.ScheduledThreadPoolExecutor.submit(ScheduledThreadPoolExecutor.java:470)
at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:600)
at org.infinispan.transaction.StaleTransactionCleanupService.cleanTxForWhichTheOwnerLeft(StaleTransactionCleanupService.java:91)
at org.infinispan.transaction.StaleTransactionCleanupService.onTopologyChange(StaleTransactionCleanupService.java:80)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:200)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:44)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:221)
at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:356)
at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:191)
at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:60)
at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:119)
at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:194)
at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:165)
at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:604)
at org.jgroups.JChannel.up(JChannel.java:688)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
at org.jgroups.protocols.FC.up(FC.java:479)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:721)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:574)
at org.jgroups.protocols.Discovery.up(Discovery.java:359)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1294)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1857)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1830)
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:662)
{noformat}
--
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
11 years, 4 months