[JBoss JIRA] (ISPN-4587) Re-add old owners in the pending CH when a node leaves during rebalance
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4587:
----------------------------------
Summary: Re-add old owners in the pending CH when a node leaves during rebalance
Key: ISPN-4587
URL: https://issues.jboss.org/browse/ISPN-4587
Project: Infinispan
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Core, State Transfer
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Minor
Fix For: 7.0.0.Beta1
Say we have a distributed cache \[A, B\] with {{numSegments = 1}} and {{numOwners = 2}}. The initial topology is _T_: currentCH = {0: A B}, pendingCH = null
C joins, and A starts a rebalance. The topology is now _T + 1_: currentCH = {0: A B}, pendingCH = {0: A C}
C now leaves, A updates the consistent hashes to remove it with a new topology _T + 2: currentCH = {0: A B}, pendingCH = {0: A}
A doesn't need to receive any data, so the rebalance ends and the pending CH is installed as the current CH in topology _T + 3_: currentCH = {0: A}, pendingCH = null
This algorithm is relatively easy to follow and implement, but it does result in reduced availability of the cache data. It would be better if topology _T + 2_ could re-add B as an owner in the pending CH.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3076:
---------------------------------------
Right I agree then, sorry for the misunderstanding.
BTW there where some recent fixes in jboss-logging to make it compatible with log4j, sorry I forgot the details and references but make sure you include those fixes.
Let's also make sure we don't introduce it as a hard dependency: we should have some integration tests using a different one and *not* having it available at runtime. In other words, please don't mandate it as a dependency in the global parent.
> Infinispan should enable use of log4j2
> --------------------------------------
>
> Key: ISPN-3076
> URL: https://issues.jboss.org/browse/ISPN-3076
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 5.2.5.Final, 6.0.0.Final
> Environment: Any
> Reporter: Divya Mehra
> Assignee: Dan Berindei
>
> log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing
> 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar).
> Also refer: https://issues.jboss.org/browse/ISPN-2976
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-3076 at 7/30/14 8:32 AM:
-------------------------------------------------------------
I've started investigating this again for the test suite, as I've started seeing log messages delayed by several minutes (!) in the CI logs, and I think delays in log4j may cause random failures:
{noformat}
15:37:06,079 INFO (testng-MergeViewTest:) [UnitTestTestNGListener] Starting test testMergeViewHappens(org.infinispan.notifications.MergeViewTest)
15:45:57,491 ERROR (testng-MergeViewTest:) [UnitTestTestNGListener] Test testMergeViewHappens(org.infinispan.notifications.MergeViewTest) failed.
java.lang.RuntimeException: Timed out before caches had complete views. Expected 2 members in each view. Views are as follows: [[MergeViewTest-NodeA-7118], [MergeViewTest-NodeB-19815]]
15:37:19,720 DEBUG (Timer-2,MergeViewTest-NodeA-7118:) [MERGE3] I (MergeViewTest-NodeA-7118) will be the merge leader
{noformat}
[~sannegrinovero] I only intend to change the test suite to use log4j2, production code will still log through jboss-logging and it will support anything that jboss-logging supports. Bela has already changed the JGroups test suite to use log4j2, so I'm confident it won't cause problems.
was (Author: dan.berindei):
I've started investigating this again for the test suite, as I've started seeing log messages delayed by several minutes (!) in the CI logs, and I think delays in log4j may :
{noformat}
15:37:06,079 INFO (testng-MergeViewTest:) [UnitTestTestNGListener] Starting test testMergeViewHappens(org.infinispan.notifications.MergeViewTest)
15:45:57,491 ERROR (testng-MergeViewTest:) [UnitTestTestNGListener] Test testMergeViewHappens(org.infinispan.notifications.MergeViewTest) failed.
java.lang.RuntimeException: Timed out before caches had complete views. Expected 2 members in each view. Views are as follows: [[MergeViewTest-NodeA-7118], [MergeViewTest-NodeB-19815]]
15:37:19,720 DEBUG (Timer-2,MergeViewTest-NodeA-7118:) [MERGE3] I (MergeViewTest-NodeA-7118) will be the merge leader
{noformat}
[~sannegrinovero] I only intend to change the test suite to use log4j2, production code will still log through jboss-logging and it will support anything that jboss-logging supports. Bela has already changed the JGroups test suite to use log4j2, so I'm confident it won't cause problems.
> Infinispan should enable use of log4j2
> --------------------------------------
>
> Key: ISPN-3076
> URL: https://issues.jboss.org/browse/ISPN-3076
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 5.2.5.Final, 6.0.0.Final
> Environment: Any
> Reporter: Divya Mehra
> Assignee: Dan Berindei
>
> log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing
> 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar).
> Also refer: https://issues.jboss.org/browse/ISPN-2976
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-4436) Karaf stucked when running iOSGI integration tests on IBM JDK
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4436?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4436:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1112960|https://bugzilla.redhat.com/show_bug.cgi?id=1112960] from NEW to MODIFIED
> Karaf stucked when running iOSGI integration tests on IBM JDK
> -------------------------------------------------------------
>
> Key: ISPN-4436
> URL: https://issues.jboss.org/browse/ISPN-4436
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> {noformat}
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (2.3.3)
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
> karaf@root> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
> at org.ops4j.pax.exam.rbc.internal.Activator.<clinit>(Activator.java:46)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1774)
> at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4177)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1972)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:530)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:1207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
> at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:259)
> at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:222)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:853)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder not found by org.ops4j.pax.exam.rbc [87]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:827)
> {noformat}
> Jenkins job could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-3076) Infinispan should enable use of log4j2
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3076?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3076:
------------------------------------
I've started investigating this again for the test suite, as I've started seeing log messages delayed by several minutes (!) in the CI logs, and I think delays in log4j may :
{noformat}
15:37:06,079 INFO (testng-MergeViewTest:) [UnitTestTestNGListener] Starting test testMergeViewHappens(org.infinispan.notifications.MergeViewTest)
15:45:57,491 ERROR (testng-MergeViewTest:) [UnitTestTestNGListener] Test testMergeViewHappens(org.infinispan.notifications.MergeViewTest) failed.
java.lang.RuntimeException: Timed out before caches had complete views. Expected 2 members in each view. Views are as follows: [[MergeViewTest-NodeA-7118], [MergeViewTest-NodeB-19815]]
15:37:19,720 DEBUG (Timer-2,MergeViewTest-NodeA-7118:) [MERGE3] I (MergeViewTest-NodeA-7118) will be the merge leader
{noformat}
[~sannegrinovero] I only intend to change the test suite to use log4j2, production code will still log through jboss-logging and it will support anything that jboss-logging supports. Bela has already changed the JGroups test suite to use log4j2, so I'm confident it won't cause problems.
> Infinispan should enable use of log4j2
> --------------------------------------
>
> Key: ISPN-3076
> URL: https://issues.jboss.org/browse/ISPN-3076
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 5.2.5.Final, 6.0.0.Final
> Environment: Any
> Reporter: Divya Mehra
> Assignee: Dan Berindei
>
> log4j locks up on a certain amount of load, especially under concurrent access. The recommendation was to move up to log4j2. This can be done by removing
> 1 JAR (log4j.jar) and adding 2 JARs (log4j-bridge and log4j-core.jar).
> Also refer: https://issues.jboss.org/browse/ISPN-2976
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-3702) Too many threads for cleaning up infinispan transactions
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3702?page=com.atlassian.jira.plugin.... ]
Dan Berindei reassigned ISPN-3702:
----------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Too many threads for cleaning up infinispan transactions
> --------------------------------------------------------
>
> Key: ISPN-3702
> URL: https://issues.jboss.org/browse/ISPN-3702
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core, Transactions
> Affects Versions: 5.3.0.Final
> Environment: Mac and Linux
> Reporter: Prasanth Pallamreddy
> Assignee: Dan Berindei
>
> 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.2.6#6264)
11 years, 4 months
[JBoss JIRA] (ISPN-1748) Allow consistency for concurrent updates when syncCommitPhase=false
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-1748?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-1748:
-------------------------------
Labels: experimental performance (was: experimental performace)
> Allow consistency for concurrent updates when syncCommitPhase=false
> -------------------------------------------------------------------
>
> Key: ISPN-1748
> URL: https://issues.jboss.org/browse/ISPN-1748
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 5.1.0.CR4, 5.1.0.FINAL
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Optional
> Labels: experimental, performance
> Attachments: All_PUT.png
>
>
> when syncCommitPhase=false then there is a window of inconsistency in the case multipel tx access the same key at the same time.
> This can be avoided by sending the lock release command after the commit command, in the same thread which is async triggered by the TM.commit.
> This should be a very important performance buster for default configurations.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 4 months