April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4468) Remove JGroups subsystem transformers for version < 1.2.0

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-4468?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-4468: ------------------------------- Fix Version/s: 9.0.0.CR1 > Remove JGroups subsystem transformers for version < 1.2.0 > --------------------------------------------------------- > > Key: WFLY-4468 > URL: https://issues.jboss.org/browse/WFLY-4468 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Affects Versions: 9.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Paul Gier commented on WFLY-4571: --------------------------------- The imported dependencies should still only affect the versions of dependencies that the user has already added to their pom. But I agree it kind of makes sense to keep these separate. I'll update the PR. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola updated DROOLS-775: ------------------------------------ Steps to Reproduce: Unzip the attached project. For using drools5: {{mvn test -Dtest=org.acme.test.drools5.DroolsPerformance -Pdrools5}} For using drools6: {{mvn test -Dtest=org.acme.test.drools6.DroolsPerformance -Pdrools6}} was: Unzip the attached project. For using drools5: {{mvn test -Pdrools5}} For using drools6: {{mvn test -Pdrools6}} > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola commented on DROOLS-775: ----------------------------------------- As per request, I removed the code that generate new methods bytecode. > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola updated DROOLS-775: ------------------------------------ Attachment: drools-test_new.zip > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip, drools-test_new.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Steve Ebersole commented on JBLOGGING-114: ------------------------------------------ I will have more information today. Brett is helping me debug the Karaf issues. JBoss Logging is not the only one. Quite a few WIldFly jars have problems. The plan is to follow up with an email to wildfly-dev regarding all of them. The others I know for sure are all the wildfly "spec" jars (aside from JPA, of course :). Moving to the geronimo jars fix the issues there. Anyway, will keep you updated. Thanks! > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Steve Ebersole commented on JBLOGGING-114: ------------------------------------------ [~brmeyer] In case you have anything to add... > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] David Lloyd commented on JBLOGGING-114: --------------------------------------- I created the JIRA but [~sebersole] is the real reporter so I put him in the Reporter field. > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] David Lloyd updated JBLOGGING-114: ---------------------------------- Reporter: Steve Ebersole (was: David Lloyd) > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by David Lloyd (JIRA)

David Lloyd created JBLOGGING-114: ------------------------------------- Summary: jboss-logging's OSGi metadata is somehow wrong Key: JBLOGGING-114 URL: https://issues.jboss.org/browse/JBLOGGING-114 Project: JBoss Logging Issue Type: Bug Reporter: David Lloyd Assignee: James Perkins Apparently jboss-logging places a non-optional dependency on log4j: {noformat} [22:04] <sebersole> dmlloyd: if you are around... [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar [22:04] <sebersole> it essentially requires log4j [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed [22:06] <sebersole> it works when we install log4j first as well [22:06] <sebersole> even though we are not using log4j {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015