[JBoss JIRA] (ISPN-2278) Implicit transaction enabling during configuration fails
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-2278?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-2278.
---------------------------------
Resolution: Out of Date
> Implicit transaction enabling during configuration fails
> --------------------------------------------------------
>
> Key: ISPN-2278
> URL: https://issues.jboss.org/browse/ISPN-2278
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 5.1.6.FINAL
> Reporter: Thomas Fromm
>
> The implicit enabling of transaction support does not work in all cases described in TransactionMode Javadoc inside the current configuration API.
> - transactionManagerLookup is explicit configured
> This works not in programmatic.
> - enabled batching
> When using XML configuration, this will not work, when only <invocationBatching> element and no <transaction> element is used.
> At ConfigurationBuilderHolder.newConfigurationBuilder(...) the default cache config is used as base for the new named cache. Since build() is called, the TransactionConfiguration is set to NON_TRANSACTIONAL in the Configuration template used for the new ConfigurationBuilder. Later then any if(transactionMode == null)-related conditions in TransactionConfigurationBuilder will fail.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-1146) Improve documentation around transaction and locking
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1146?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-1146:
----------------------------------
Priority: Minor (was: Major)
> Improve documentation around transaction and locking
> ----------------------------------------------------
>
> Key: ISPN-1146
> URL: https://issues.jboss.org/browse/ISPN-1146
> Project: Infinispan
> Issue Type: Task
> Components: Transactions
> Reporter: Mircea Markus
> Priority: Minor
>
> As suggested by Jonathan Halliday:
> - preserving some subset of the existing transactional guarantees is all well and good BUT if the user is relying on additional 'guarantees' that are not preserved in all cases then they'll be in trouble. Therefore, it's essential to document not just what the minimum expected guarantees for a given config are, but also that no additional properties that may coincidently be observed are actually guaranteed. Some vendors go further and explicitly document the bad things that may happen with given settings, since in some cases these are not easy to reproduce in testing.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3339) Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction]
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3339?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-3339.
---------------------------------
Resolution: Won't Fix
> Jon plugin, two deprecated ops are failing. [RpcManager] [Transaction]
> ----------------------------------------------------------------------
>
> Key: ISPN-3339
> URL: https://issues.jboss.org/browse/ISPN-3339
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Environment: Local machine, Fedora16
> Reporter: Tomas Sykora
> Labels: dm
>
> These 2 operations are failing using infinispan-rhq-plugin:
> [Transactions] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead.
> [RpcManager] Enable/disable statistics. Deprecated, use the statisticsEnabled attribute instead.
> While this is deprecated, should we remove it from plugin? Should we replace it by different operation?
> Typical error stack trace:
> org.mc4j.ems.connection.EmsInvocationException: Exception on invocation of [setStatisticsEnabled]javax.management.MBeanException
> at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:126)
> at org.infinispan.rhq.CacheComponent.invokeOperation(CacheComponent.java:192)
> at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:634)
> 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:722)
> Caused by: javax.management.MBeanException
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:271)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
> at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> 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)
> at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
> at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
> at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown Source)
> at javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1017)
> at sun.reflect.GeneratedMethodAccessor131.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.mc4j.ems.impl.jmx.connection.support.providers.proxy.JMXRemotingMBeanServerProxy.invoke(JMXRemotingMBeanServerProxy.java:59)
> at $Proxy110.invoke(Unknown Source)
> at org.mc4j.ems.impl.jmx.connection.bean.operation.DOperation.invoke(DOperation.java:110)
> ... 10 more
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:269)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:498)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:246)
> at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
> at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
> at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
> at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360)
> at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
> at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:303)
> at sun.rmi.transport.Transport$1.run(Transport.java:159)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
> 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)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3927:
-------------------------------------
Assignee: Pedro Ruivo
> rethinking ISPN transactions
> ----------------------------
>
> Key: ISPN-3927
> URL: https://issues.jboss.org/browse/ISPN-3927
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Labels: roadmap
>
> Umbrella JIRA for several transaction related improvements:
> 1. Async options for commit/rollback
> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
> - they complicate the code significantly
> - I think they should be removed
> 2. READ_COMMITTED
> - it has the same performance as REPEATABLE_READ, but offers less guarantees.
> - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
> - I think it should be removed
> 3. Optimistic tx without Write Skew Check (WSC)
> - well, without WSC the transactions are not optimistic by definition
> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
> 4. Remove 1PC option
> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
> [1] http://markmail.org/thread/a7fjko4dyejxqgdy
> [2] https://github.com/infinispan/infinispan/pull/2177
> [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
> [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-1862) fire TransactionCompletedEvent not as part of the transaction
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1862?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-1862:
-------------------------------------
Assignee: Pedro Ruivo
> fire TransactionCompletedEvent not as part of the transaction
> -------------------------------------------------------------
>
> Key: ISPN-1862
> URL: https://issues.jboss.org/browse/ISPN-1862
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 5.1.1.FINAL
> Reporter: Thomas Fromm
> Assignee: Pedro Ruivo
> Priority: Minor
>
> When catching TransactionCompletedEvent I would expect, the transaction is committed, especially when isTransactionSuccessful() == true.
> I need to perform some operations after a transaction was completed. My workaround is ATM to suspend the transaction, perform my (async) stuff, and
> resume it afterwards. But in case of errors after resume, I get another TransactionCompletedEvent for this transaction with isTransactionSuccessful() == false.
> You see, I need something like a TransactionReallyCompletedEvent :-)
> My change request is, that the TransactionCompletedEvents should be fired, after the transaction was committed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5076:
----------------------------------
Fix Version/s: (was: 8.2.0.Final)
> Pessimistic transactions can lose their locks when the primary owner changes
> ----------------------------------------------------------------------------
>
> Key: ISPN-5076
> URL: https://issues.jboss.org/browse/ISPN-5076
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 7.0
>
> In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v)}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s).
> If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-3702:
-------------------------------------
Assignee: Pedro Ruivo
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Pedro Ruivo
>
> When using multiple transactional caches, we are seeing that each cache has a dedicated cleanup thread. While this is not an issue for small number of caches, when the number of caches is high as in our case (~100), we see around a 100 threads dedicated for cleanup like the following.
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f50d3800 nid=0x10f03 waiting on condition [0x00000001a5a5d000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e800 nid=0x10e03 waiting on condition [0x00000001a595a000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f507e000 nid=0x10d03 waiting on condition [0x00000001a5857000]
> "TxCleanupService,{default}_{XXX},user-mac-54275" daemon prio=5 tid=0x00007fa0f5817800 nid=0x10c03 waiting on condition [0x00000001a5754000]
> ...
> Looking at the source code for
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> if (!totalOrder) {
> // Periodically run a task to cleanup the transaction table from completed transactions.
> ThreadFactory tf = new ThreadFactory() {
> @Override
> public Thread newThread(Runnable r) {
> String address = rpcManager != null ? rpcManager.getTransport().getAddress().toString() : "local";
> Thread th = new Thread(r, "TxCleanupService," + cacheName + "," + address);
> th.setDaemon(true);
> return th;
> }
> };
> executorService = Executors.newSingleThreadScheduledExecutor(tf);
> This code can benefit from drawing the threads from a dedicated pool which is bounded.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3891) Tune for batching without transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3891?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3891:
----------------------------------
Fix Version/s: (was: 8.2.0.Final)
> Tune for batching without transactions
> --------------------------------------
>
> Key: ISPN-3891
> URL: https://issues.jboss.org/browse/ISPN-3891
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Sanne Grinovero
>
> The usage of batching is a critically important feature, widely used to improve performance in many common scenarios, but while documentation makes it clear that it's built on transactions, it's unclear how these transactions should be configured.
> Also, I would challenge the decision of building batching on top of transactions and see if there are opportunities for further optimization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month