August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1730) Singleton service is not correctly being set in WILDFLY

by Panagiotis Sotiropoulos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos moved JBEAP-5747 to WFCORE-1730: -------------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1730 (was: JBEAP-5747) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: Clustering) Affects Version/s: 3.0.0.Alpha5 (was: 7.1.0.DR3) > Singleton service is not correctly being set in WILDFLY > ------------------------------------------------------- > > Key: WFCORE-1730 > URL: https://issues.jboss.org/browse/WFCORE-1730 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha5 > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib). > When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated. > $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log > 12:14:52,373 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed! > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,268 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim > erService' > 12:14:56,873 INFO [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6997) Test cases for JBERET-117 and JBERET-231

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6997?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko updated WFLY-6997: ------------------------------------------- Summary: Test cases for JBERET-117 and JBERET-231 (was: Test cases for JBEAP-4811 and JBEAP-4862) > Test cases for JBERET-117 and JBERET-231 > ---------------------------------------- > > Key: WFLY-6997 > URL: https://issues.jboss.org/browse/WFLY-6997 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > Test case for https://issues.jboss.org/browse/JBERET-117 and https://issues.jboss.org/browse/JBERET-231 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6997) Test cases for JBERET-117 and JBERET-231

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6997?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko updated WFLY-6997: ------------------------------------------- Git Pull Request: (was: https://github.com/jbossas/jboss-eap7/pull/555) > Test cases for JBERET-117 and JBERET-231 > ---------------------------------------- > > Key: WFLY-6997 > URL: https://issues.jboss.org/browse/WFLY-6997 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > Test case for https://issues.jboss.org/browse/JBERET-117 and https://issues.jboss.org/browse/JBERET-231 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6997) Test cases for JBEAP-4811 and JBEAP-4862

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6997?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko updated WFLY-6997: ------------------------------------------- Description: Test case for https://issues.jboss.org/browse/JBERET-117 and https://issues.jboss.org/browse/JBERET-231 (was: Test case for https://issues.jboss.org/browse/JBEAP-4811) > Test cases for JBEAP-4811 and JBEAP-4862 > ---------------------------------------- > > Key: WFLY-6997 > URL: https://issues.jboss.org/browse/WFLY-6997 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > Test case for https://issues.jboss.org/browse/JBERET-117 and https://issues.jboss.org/browse/JBERET-231 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6997) Test cases for JBEAP-4811 and JBEAP-4862

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-6997?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko moved JBEAP-5744 to WFLY-6997: ------------------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6997 (was: JBEAP-5744) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Batch (was: Batch) Affects Version/s: 10.1.0.Final (was: 7.0.0.GA) > Test cases for JBEAP-4811 and JBEAP-4862 > ---------------------------------------- > > Key: WFLY-6997 > URL: https://issues.jboss.org/browse/WFLY-6997 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > > Test case for https://issues.jboss.org/browse/JBEAP-4811 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6996) High CPU Usage By Infinispan when using ATTRIBUTE granularity

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6996?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6996: ------------------------------- Environment: (was: JBoss EAP 7 JBoss EAP 6.4 (for Comparison) Java 8) > High CPU Usage By Infinispan when using ATTRIBUTE granularity > ------------------------------------------------------------- > > Key: WFLY-6996 > URL: https://issues.jboss.org/browse/WFLY-6996 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Customer is deploying clustered application to EAP 7.0.1 and notices high CPU utilization by Infinispan (default configuration). Customer took thread dumps (attachment high-cpu1.zip and high-cpu1.zip) during the occurrence of the issue in question. Reports [1] show high CPU utilization with Infinispan. > Customer then gave us an app to reproduce the issue in question (attachment webapp3.zip). The attachment includes the app, which consist of JSP pages and code that can be used to test the app. During the test, we notice CPU utilization increases upwards to 80% -90% and remains there until the test is finished. If I deploy the same app to clustered EAP 6.4/Java 8 (with dist mode like default EAP 7), CPU utilization remains low (~2%) during the running of the test. > Customer is under the assumption that the high CPU is due to the number of entries in the cache (web cache). As the number of entries increases, so does the likelihood of the high CPU utilization by Infinispan. Inside the test code (SessionReplicationTest.java) provided by the customer, they included (commented out) a call to a JSP file (index3.jsp) that invalidates the session (thus removing it from cache). High CPU is not experienced when they invalidate the session. > [1] > https://access.redhat.com/labs/jvmpeg/results/8712a840-5da6-11e6-8f83-277... > https://access.redhat.com/labs/jvmpeg/results/56bc07a0-6322-11e6-b64b-2dd... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6996) High CPU Usage By Infinispan when using ATTRIBUTE granularity

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6996?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6996: ------------------------------- Summary: High CPU Usage By Infinispan when using ATTRIBUTE granularity (was: [GSS] (7.0.1) High CPU Usage By Infinispan In EAP 7) > High CPU Usage By Infinispan when using ATTRIBUTE granularity > ------------------------------------------------------------- > > Key: WFLY-6996 > URL: https://issues.jboss.org/browse/WFLY-6996 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Environment: JBoss EAP 7 > JBoss EAP 6.4 (for Comparison) > Java 8 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Customer is deploying clustered application to EAP 7.0.1 and notices high CPU utilization by Infinispan (default configuration). Customer took thread dumps (attachment high-cpu1.zip and high-cpu1.zip) during the occurrence of the issue in question. Reports [1] show high CPU utilization with Infinispan. > Customer then gave us an app to reproduce the issue in question (attachment webapp3.zip). The attachment includes the app, which consist of JSP pages and code that can be used to test the app. During the test, we notice CPU utilization increases upwards to 80% -90% and remains there until the test is finished. If I deploy the same app to clustered EAP 6.4/Java 8 (with dist mode like default EAP 7), CPU utilization remains low (~2%) during the running of the test. > Customer is under the assumption that the high CPU is due to the number of entries in the cache (web cache). As the number of entries increases, so does the likelihood of the high CPU utilization by Infinispan. Inside the test code (SessionReplicationTest.java) provided by the customer, they included (commented out) a call to a JSP file (index3.jsp) that invalidates the session (thus removing it from cache). High CPU is not experienced when they invalidate the session. > [1] > https://access.redhat.com/labs/jvmpeg/results/8712a840-5da6-11e6-8f83-277... > https://access.redhat.com/labs/jvmpeg/results/56bc07a0-6322-11e6-b64b-2dd... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6996) [GSS] (7.0.1) High CPU Usage By Infinispan In EAP 7

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6996?page=com.atlassian.jira.plugin.... ] Paul Ferraro moved JBEAP-5742 to WFLY-6996: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6996 (was: JBEAP-5742) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: 10.1.0.Final (was: 7.0.1.GA) Fix Version/s: 11.0.0.Alpha1 (was: 7.0.z.GA) > [GSS] (7.0.1) High CPU Usage By Infinispan In EAP 7 > --------------------------------------------------- > > Key: WFLY-6996 > URL: https://issues.jboss.org/browse/WFLY-6996 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Environment: JBoss EAP 7 > JBoss EAP 6.4 (for Comparison) > Java 8 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Customer is deploying clustered application to EAP 7.0.1 and notices high CPU utilization by Infinispan (default configuration). Customer took thread dumps (attachment high-cpu1.zip and high-cpu1.zip) during the occurrence of the issue in question. Reports [1] show high CPU utilization with Infinispan. > Customer then gave us an app to reproduce the issue in question (attachment webapp3.zip). The attachment includes the app, which consist of JSP pages and code that can be used to test the app. During the test, we notice CPU utilization increases upwards to 80% -90% and remains there until the test is finished. If I deploy the same app to clustered EAP 6.4/Java 8 (with dist mode like default EAP 7), CPU utilization remains low (~2%) during the running of the test. > Customer is under the assumption that the high CPU is due to the number of entries in the cache (web cache). As the number of entries increases, so does the likelihood of the high CPU utilization by Infinispan. Inside the test code (SessionReplicationTest.java) provided by the customer, they included (commented out) a call to a JSP file (index3.jsp) that invalidates the session (thus removing it from cache). High CPU is not experienced when they invalidate the session. > [1] > https://access.redhat.com/labs/jvmpeg/results/8712a840-5da6-11e6-8f83-277... > https://access.redhat.com/labs/jvmpeg/results/56bc07a0-6322-11e6-b64b-2dd... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6785) Modify web/DeploymentScannerTestCase.java to reflect WFCORE-1579

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-6785?page=com.atlassian.jira.plugin.... ] Tomas Hofman closed WFLY-6785. ------------------------------ Resolution: Done Test cased was moved to core and updated under WFCORE-1579. > Modify web/DeploymentScannerTestCase.java to reflect WFCORE-1579 > ---------------------------------------------------------------- > > Key: WFLY-6785 > URL: https://issues.jboss.org/browse/WFLY-6785 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > DeploymentScannerTestCase should be modified to reflect changes in WFCORE-1579 - specifically a deployment scanner can be created with inaccessible deployment directory configured. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-355) Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-355?page=com.atlassian.jira.plugin... ] Marco Rietveld edited comment on DROOLS-355 at 8/24/16 9:19 AM: ---------------------------------------------------------------- Notes: - {{Castor}} is not a viable alternative because of licensing issues - {{XStream}} can not handle XSDs - {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8 -- as well as OSGi problems, I suspect -- and the jar is also 2.7M.. -- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports) - {{JIBX}} might be usable, but I really don't like it, because: -- {{JIBX}} uses it's "own" ({{org.jibx}}) version of eclipse compiler/parser jars, which is not nice given that {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ecj}} -- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8) was (Author: marco.rietveld): Notes: - {{Castor}} is not a viable alternative because of licensing issues - {{XStream}} can not handle XSDs - {{XmlBeans}} contains `com.sun.javadoc.*` imports, which cause problems on Java 8 -- as well as OSGi problems, I suspect -- and the jar is also 2.7M.. -- and it's broken (if you try to go around the {{com.sun.javadoc.*}} imports) - {{JIBX}} might be usable, but I really don't like it, because: -- {{JIBX}} uses it's "own" ({{org.jibx}}) version of eclipse compiler/parser jars, which is not nice given that {{drools-compiler}} uses {{org.eclipse.jdt.core.compiler:ejc}} -- Also Dependency tree is not in order (would have to exclude `bcel` 5.1 and force include `bcel 6.0` because bcel < 6.0 can not handle java 8) > Do not import com.sun.tools.xjc in drools-core and drools-compiler to fix drools on Karaff/Fuse and/or Java 9 > ------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-355 > URL: https://issues.jboss.org/browse/DROOLS-355 > Project: Drools > Issue Type: Task > Affects Versions: 6.0.0.Final > Reporter: Geoffrey De Smet > Assignee: Marco Rietveld > Priority: Blocker > > By importing com.sun.tools.xjc, 3 problems arise: > * OSGi and Karaf trip over it. > {code} > [WARNING] No export found to match com.sun.tools.xjc (imported by mvn:org.drools/drools-core/6.0.0.Final) > {code} > * JDK 9 will break any java app that uses com.sun.* classes. See Mark Reinhold's Jigsaw presentation at devoxxBE 2013. > * IBM JDK's etc don't have com.sun.* classes. Why don't they trip over this? > Why do we have those imports in the first place? Looks like code for old JAXB code - which is hopefully stale now. > Where do we use it? > {code} > Targets > String 'com.sun.tools.xjc' > Found usages (38 usages found) > drools-compiler (7 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/drools/drools-compiler (1 usage found) > pom.xml (1 usage found) > (246: 15) com.sun.tools.xjc.*;resolution:=optional, > org.drools.compiler.builder.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (18: 8) import com.sun.tools.xjc.Options; > org.drools.compiler.runtime.pipeline.impl (5 usages found) > DroolsJaxbHelperProviderImpl.java (5 usages found) > (77: 8) import com.sun.tools.xjc.BadCommandLineException; > (78: 8) import com.sun.tools.xjc.ErrorReceiver; > (79: 8) import com.sun.tools.xjc.ModelLoader; > (80: 8) import com.sun.tools.xjc.Options; > (81: 8) import com.sun.tools.xjc.model.Model; > drools-core (2 usages found) > org.drools.core.builder.conf.impl (2 usages found) > JaxbConfigurationImpl.java (2 usages found) > (28: 8) import com.sun.tools.xjc.Language; > (34: 8) import com.sun.tools.xjc.Options; > kie-internal (6 usages found) > /home/gdesmet/projects/jboss/droolsjbpm/droolsjbpm-knowledge/kie-internal (1 usage found) > pom.xml (1 usage found) > (27: 15) com.sun.tools.xjc;resolution:=optional, > org.kie.internal.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (23: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.kie.internal.builder.help (2 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (1 usage found) > (30: 8) import com.sun.tools.xjc.Options; > knowledge-api (8 usages found) > org.drools.builder (3 usages found) > JaxbConfiguration.java (1 usage found) > (21: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactory.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderFactoryService.java (1 usage found) > (24: 8) import com.sun.tools.xjc.Options; > org.drools.builder.help (3 usages found) > DroolsJaxbHelperProvider.java (1 usage found) > (29: 8) import com.sun.tools.xjc.Options; > KnowledgeBuilderHelper.java (2 usages found) > (32: 8) import com.sun.tools.xjc.Language; > (33: 8) import com.sun.tools.xjc.Options; > org.drools.impl (1 usage found) > KnowledgeBuilderFactoryServiceImpl.java (1 usage found) > (16: 8) import com.sun.tools.xjc.Options; > org.drools.impl.adapters (1 usage found) > JaxbConfigurationAdapter.java (1 usage found) > (3: 8) import com.sun.tools.xjc.Options; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016