[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[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)
9 years, 8 months
[JBoss JIRA] (SECURITY-877) AdvancedLdapLodinMogule is Logging LDAP Bind Credential Password during authentication.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-877?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-877:
--------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1199641|https://bugzilla.redhat.com/show_bug.cgi?id=1199641] from POST to MODIFIED
> AdvancedLdapLodinMogule is Logging LDAP Bind Credential Password during authentication.
> ---------------------------------------------------------------------------------------
>
> Key: SECURITY-877
> URL: https://issues.jboss.org/browse/SECURITY-877
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2_3_6_Final
> Environment: Wildfly is logging the bindCredentials when using SPNEGO
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Fix For: Negotiation_2_3_7_Final
>
>
> The bind Credential are being logged:
> 2015-03-19 19:33:28,569 TRACE [org.jboss.security.auth.spi.AbstractServerLoginModule] (http-localhost/127.0.0.1:8080-1) Logging into LDAP server, env={baseFilter=(userPrincipalName={0}), java.naming.security.credentials=***, jboss.security.security_domain=SPNEGO, java.naming.ldap.attributes.binary=objectSid, password-stacking=useFirstPass, recurseRoles=false, java.naming.security.authentication=simple, baseCtxDN=DC=example,DC=com, roleAttributeIsDN=true, rolesCtxDN=DC=example,DC=com, java.naming.security.principal=bindUser, allowEmptyPassword=true, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://127.0.0.1:389, roleNameAttributeID=cn, roleAttributeID=memberOf, bindDN=bindUser, bindCredential=password}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (WFLY-4441) web.xml parser process cannot handle exception for xml file which does not have the encoding attribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4441?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4441:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1184292|https://bugzilla.redhat.com/show_bug.cgi?id=1184292] from POST to MODIFIED
> web.xml parser process cannot handle exception for xml file which does not have the encoding attribute
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4441
> URL: https://issues.jboss.org/browse/WFLY-4441
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Alpha1
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> Description copied from https://bugzilla.redhat.com/show_bug.cgi?id=1184292
> Description of problem:
> When XMLStreamException occurs by web.xml parser process for xml file which does not have the encoding attribute, e.getLocation()[1] is null. We cannot find cause of exception by NullPointerException.
> [1]
> - org.jboss.as.web.deployment.WebParsingDeploymentProcessor.java
> #115 } catch (XMLStreamException e) {
> -> #116 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml, e.getLocation().getLineNumber(), e.getLocation().getColumnNumber()), e);
> #117 } catch (IOException e) {
> #118 throw new DeploymentUnitProcessingException(MESSAGES.failToParseXMLDescriptor(webXml), e);
> #119 }
> Version-Release number of selected component (if applicable):
> EAP 6.3.2
> How reproducible:
> Attached web.xml for reproducing.
> Steps to Reproduce:
> 1. Create war application using attached web.xml.
> 2. Deploy war to EAP.
> 3. Start EAP.
> Actual results:
> You can confirm NullPointerException.
> 15:56:23,190 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."test.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."test.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "test.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_71]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_71]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.web.deployment.WebParsingDeploymentProcessor.deploy(WebParsingDeploymentProcessor.java:116)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> ... 5 more
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months