[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4131:
--------------------------------
Labels: 630betablocker (was: )
> Lock acquired forever with delayed PrepareCommand
> -------------------------------------------------
>
> Key: ISPN-4131
> URL: https://issues.jboss.org/browse/ISPN-4131
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
>
> Distributed transactional cache:
> 1. A sends Prepare to B
> 2. B receives Prepare, but due to ongoing ST it is blocked
> 3. B replication timeout elapses
> 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions.
> 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked)
> 6. Prepare is executed on B, acquiring lock on K
> Nobody will rollback the TX as originator thinks it was already rolled back.
> Result: key K will be locked forever, all attempts to update/remove it will fail.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-4236) RHQ JMX plugin causes Cache/CacheManager to report as not available
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4236?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4236:
--------------------------------
Labels: 630betablocker (was: )
> RHQ JMX plugin causes Cache/CacheManager to report as not available
> -------------------------------------------------------------------
>
> Key: ISPN-4236
> URL: https://issues.jboss.org/browse/ISPN-4236
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha3
> Reporter: William Burns
> Assignee: William Burns
> Labels: 630betablocker
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> With the update to use newer RHQ, the CacheManager and Cache sometimes report as being down when using library JMX plugin. It looks like RHQ added some additional checks which just pushes the operation time over the default of 5 seconds. This is to clean up our code a bit to make the availability check for efficient.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-4147) the new EAP-based CLI is not yet compatibile with the old JDG CLI
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4147?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4147:
--------------------------------
Labels: 630betablocker (was: )
> the new EAP-based CLI is not yet compatibile with the old JDG CLI
> -----------------------------------------------------------------
>
> Key: ISPN-4147
> URL: https://issues.jboss.org/browse/ISPN-4147
> Project: Infinispan
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.0.0.Alpha1
> Reporter: Vitalii Chepeliuk
> Assignee: Pedro Ruivo
> Labels: 630betablocker
>
> * Running JDG tests for CLI
> Fcli/standalone_caches_test.rb:84: warning: Insecure world writable dir /qa/tools in PATH, mode 040777
> Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/cli/CommandLineMain : Unsupported major.minor version 51.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
> at org.jboss.modules.Module.loadModuleClass(Module.java:548)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:249)
> at org.jboss.modules.Module.run(Module.java:280)
> at org.jboss.modules.Main.main(Main.java:455)
> ** Jobs are here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j...
> * ispn-cli --help
> Usage:
> jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port]
> [--connect] [--file=file_path]
> [--commands=command_or_operation1,command_or_operation2...]
> [--command=command_or_operation]
> [--user=username --password=password]
> [--no-local-auth]
> [--timeout=timeout]
> --help (-h) - prints (this) basic description of the command line utility.
> --version - prints the version info of the JBoss AS release, JVM and system environment.
> --controller - the default controller host and port to connect to when
> --connect option (described below) is specified or when the connect command is issued w/o the arguments. The default controller host is localhost and the port is 9999.
> --connect (-c) - instructs the CLI to connect to the controller on start-up (to avoid issuing a separate connect command later).
> --gui - GUI built on top of the CLI, the only difference is that it brings up a GUI instead of a command line. In this mode, the CLI will automatically connect during start-up. You can
> optionally specify --controller, if necessary.
> --file - specifies a path to a file which contains commands operations (one per line) that should be executed (in a non-interactive mode). The CLI will terminate the session
> immediately after the last command has been executed or if
> some command or operation failed.
> ... etc
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-4137:
--------------------------------
Labels: 630betablocker (was: )
> Transaction executed multiple times due to forwarded CommitCommand
> ------------------------------------------------------------------
>
> Key: ISPN-4137
> URL: https://issues.jboss.org/browse/ISPN-4137
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer, Transactions
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630betablocker
>
> When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well.
> Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}.
> However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3731?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3731:
--------------------------------
Labels: 620 630 630betablocker (was: 620 630)
> Multicast messages can be replayed to new node
> ----------------------------------------------
>
> Key: ISPN-3731
> URL: https://issues.jboss.org/browse/ISPN-3731
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630, 630betablocker
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Messages that target all current members are sent as multicast messages.
> However, these retransmissions can be replayed on new nodes that have just joined the cluster.
> This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them.
> The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4240:
--------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2531
> Migrate one intermediate key/value per maxCollectorSize threshold
> -----------------------------------------------------------------
>
> Key: ISPN-4240
> URL: https://issues.jboss.org/browse/ISPN-4240
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
>
> When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect.
> In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times).
> This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3904?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3904:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1088310|https://bugzilla.redhat.com/show_bug.cgi?id=1088310] from ON_QA to POST
> Migrate JDBC cache store tests
> ------------------------------
>
> Key: ISPN-3904
> URL: https://issues.jboss.org/browse/ISPN-3904
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: task
> Fix For: 7.0.0.Alpha3
>
>
> Migrating finctional tests for JDBC cache store
> Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation
> There is issue with passivating oldest entries https://issues.jboss.org/browse/ISPN-4187 . Should be resolved
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3731?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3731:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1031985|https://bugzilla.redhat.com/show_bug.cgi?id=1031985] from NEW to ON_QA
> Multicast messages can be replayed to new node
> ----------------------------------------------
>
> Key: ISPN-3731
> URL: https://issues.jboss.org/browse/ISPN-3731
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620, 630
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Messages that target all current members are sent as multicast messages.
> However, these retransmissions can be replayed on new nodes that have just joined the cluster.
> This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them.
> The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId.
--
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
9 years, 11 months
[JBoss JIRA] (ISPN-3784) Exiting because has NOT shut down all the cache managers it has started
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3784?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3784:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1037776|https://bugzilla.redhat.com/show_bug.cgi?id=1037776] from NEW to VERIFIED
> Exiting because has NOT shut down all the cache managers it has started
> -----------------------------------------------------------------------
>
> Key: ISPN-3784
> URL: https://issues.jboss.org/browse/ISPN-3784
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.0.Final
> Environment: All environmets
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: 630, testsuite_stability
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
>
> When following tests are running from infinispan testsuite
> RemoteStoreTest
> RemoteStoreRawValuesTest
> Adaptor52xCustomLoaderTest
> Adaptor52xCustomStoreTest
> JdbcStringTest
> FileStoreTest
> MixedStoreWithManagedConnectionTest
> JdbcMixedStore2Test
> Following exception is thrown
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-MixedStoreWithManagedConnectionTest) Exiting because *Test has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-MixedStoreWithManagedConnectionTest) See allocation stacktrace to find out where still-running cacheManager (org.infinispan.manager.DefaultCacheManager@51696e47@Address:null) was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> java.lang.Throwable
> at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:185)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:170)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createCacheManager(TestCacheManagerFactory.java:174)
> at org.infinispan.marshall.TestObjectStreamMarshaller.<init>(TestObjectStreamMarshaller.java:34)
> at org.infinispan.persistence.BaseStoreTest.setUp(BaseStoreTest.java:68)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> All of tests are superclasses of BaseStoreTest. Tests are passing well but when after all tests checkManagersClosed() from TestCacheManagerFactory is called there are some RUNNING cache managers and VM is stopped.
> Add link to jenkins job for RHEL and Windows
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
9 years, 11 months