[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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 months
[JBoss JIRA] (ISPN-4586) Too many OutdatedTopologyExceptions in non-transactional caches
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4586:
----------------------------------
Summary: Too many OutdatedTopologyExceptions in non-transactional caches
Key: ISPN-4586
URL: https://issues.jboss.org/browse/ISPN-4586
Project: Infinispan
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Final
In a non-tx cache, when the topology id is incremented, owners (both primary and backup) receiving a write command with a lower topology id throw an OutdatedTopologyException so that the originator retries the command on the new owners.
But the originator needs to retry the command only if the owners of the key changed in any way. During a join or a leave, most of the keys should not change owners, so throwing an OutdatedTopologyException is not necessary most of the time.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months