November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9544) Reduce instance loading of default set of clustering externalizers

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9544?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9544: ------------------------------- Description: Clustering externalizers are discovered via service loader, both for usage by the Infinispan marshaller and per-deployment for use by the distributed web session manager and distributed SFSB cache. The org.wildfly.clustering.marshalling.api module loads a significant number of externalizers, which end up loading multiple times. Eliminating this redundancy will help reduce the server memory footprint for these use cases. was: Clustering externalizers are discovered via service loader, both for usage by the Infinispan marshaller and per-deployment for use by the distributed web session manager. The org.wildfly.clustering.marshalling.api module loads a significant number of externalizers, which end up loading multiple times. Eliminating this redundancy will help reduce the server memory footprint for these use cases. > Reduce instance loading of default set of clustering externalizers > ------------------------------------------------------------------ > > Key: WFLY-9544 > URL: https://issues.jboss.org/browse/WFLY-9544 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 11.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Clustering externalizers are discovered via service loader, both for usage by the Infinispan marshaller and per-deployment for use by the distributed web session manager and distributed SFSB cache. > The org.wildfly.clustering.marshalling.api module loads a significant number of externalizers, which end up loading multiple times. Eliminating this redundancy will help reduce the server memory footprint for these use cases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3415) Cut the time to execute MBeanServerConnection.getMBeanCount()

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3415?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3415: ------------------------------------- Description: The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over a full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher if complex deployments are installed. See WFLY-9408. This enhancement proposes doing two things to mitigate this: 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. 2) Do not use RBAC to exclude from the count mbeans the user won't be allowed to see. They exist whether the user can see them or not. Simply count the resources. Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children. was: The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher is complex deployments are installed. See WFLY-9408. This enhancement proposes doing two things to mitigate this: 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. 2) Do not use RBAC to exclude mbeans the user won't be allowed to see from the count. Simply count the resources. Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children. > Cut the time to execute MBeanServerConnection.getMBeanCount() > ------------------------------------------------------------- > > Key: WFCORE-3415 > URL: https://issues.jboss.org/browse/WFCORE-3415 > Project: WildFly Core > Issue Type: Enhancement > Components: JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over a full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher if complex deployments are installed. See WFLY-9408. > This enhancement proposes doing two things to mitigate this: > 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. > 2) Do not use RBAC to exclude from the count mbeans the user won't be allowed to see. They exist whether the user can see them or not. Simply count the resources. > Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. > Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) > The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3415) Cut the time to execute MBeanServerConnection.getMBeanCount()

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3415: ---------------------------------------- Summary: Cut the time to execute MBeanServerConnection.getMBeanCount() Key: WFCORE-3415 URL: https://issues.jboss.org/browse/WFCORE-3415 Project: WildFly Core Issue Type: Enhancement Components: JMX Reporter: Brian Stansberry Assignee: Brian Stansberry The time it takes to count the mbeans associated with the jboss.as and jboss.as.expr domains is way too high, over full second when the WildFly full standalone-full-ha.xml config is used, and potentially much higher is complex deployments are installed. See WFLY-9408. This enhancement proposes doing two things to mitigate this: 1) There is no point doing a full count of both jboss.as and jboss.as.expr as they are just 2 views on the same underlying resources. If both are present, count one and double it. 2) Do not use RBAC to exclude mbeans the user won't be allowed to see from the count. Simply count the resources. Looking at the JMX specification (https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/JMX_1_4_specif...) I see nothing directly on the topic of the effect of any security checks on the result of getMBeanCount(). Section 12.1.2.4 "Permission Checking for Queries" clearly states that permission checks should remove mbeans that should not be visible according to the permission scheme from the query result, so definitely queries returning a subset of the entire mbean universe is contemplated. Now, that section is about security manager permissions, not our RBAC scheme, but it's the most on topic thing I see. Doing these two things I can get the cost of a getMBeanCount() from around 1 second to under 10 ms. (Note the 1 sec figure is the first call; once the JVM optimizes the existing code it drops to under 500ms.) The enhancement will also make it possible for custom Resource implementations to optimize things. For example a resource that represents a possibly large number of dynamic children could ask the system behind those children for a child count, rather that iterating over the children. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2125) Lists as unary tests should be checked for containment, not equality

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-2125: ------------------------------------- Summary: Lists as unary tests should be checked for containment, not equality Key: DROOLS-2125 URL: https://issues.jboss.org/browse/DROOLS-2125 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.4.1.Final Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.5.0.Final When a list is set as a value in a unary test, it should be checked for containment. Currently the engine checks for equality. E.g.: in a decision table, if the input expression is "bob" and the input entry in a row is listOfNames, the engine should check if "bob" is an element contained in listOfNames. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-181) LoggerConfiguration API does not support the useParentFilters property

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-181?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-181: --------------------------------- Fix Version/s: 2.0.9.Final 2.1.0.Alpha6 > LoggerConfiguration API does not support the useParentFilters property > ---------------------------------------------------------------------- > > Key: LOGMGR-181 > URL: https://issues.jboss.org/browse/LOGMGR-181 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.9.Final, 2.1.0.Alpha6 > > > The {{useParentFilters}} property was added in LOGMGR-45, but the {{org.jboss.logmanager.config.LoggerConfiguration}} was not updated to support this property. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9537) EJB Timer is not fired during the ambiguous hour during the switch from summer to winter times

by André Döblitz (JIRA)

[ https://issues.jboss.org/browse/WFLY-9537?page=com.atlassian.jira.plugin.... ] André Döblitz updated WFLY-9537: -------------------------------- Attachment: notfixed.JPG fixed.JPG > EJB Timer is not fired during the ambiguous hour during the switch from summer to winter times > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9537 > URL: https://issues.jboss.org/browse/WFLY-9537 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Environment: Here CEST -> CET change from 2017 Nov. 29 2:00 CEST .... 2017 Nov. 29 2:00 CET > Reporter: Wolf-Dieter Fink > Assignee: Eduardo Martins > Attachments: fixed.JPG, notfixed.JPG > > > If a calendar timer has a schedule less than an hour, and should fire during the DST switch it is expected to be fired like this: > Asume : @Schedule(hour="*", minute="5/15", timezone="Europe/Berlin") > 2017 Nov. 29 1:50 CEST > 2017 Nov. 29 2:05 CEST > 2017 Nov. 29 2:20 CEST > 2017 Nov. 29 2:35 CEST > 2017 Nov. 29 2:50 CEST > 2017 Nov. 29 2:05 CET > But the timer is fired like this: > 2017 Nov. 29 1:50 CEST > 2017 Nov. 29 2:05 CET > All events within that hour are lost! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9537) EJB Timer is not fired during the ambiguous hour during the switch from summer to winter times

by André Döblitz (JIRA)

[ https://issues.jboss.org/browse/WFLY-9537?page=com.atlassian.jira.plugin.... ] André Döblitz commented on WFLY-9537: ------------------------------------- Hi there, wow wildfly has a lot of modules. I can put your mind at ease, both tests failing before the fix. !notfixed.JPG|thumbnail! !fixed.JPG|thumbnail! > EJB Timer is not fired during the ambiguous hour during the switch from summer to winter times > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9537 > URL: https://issues.jboss.org/browse/WFLY-9537 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 11.0.0.Final > Environment: Here CEST -> CET change from 2017 Nov. 29 2:00 CEST .... 2017 Nov. 29 2:00 CET > Reporter: Wolf-Dieter Fink > Assignee: Eduardo Martins > Attachments: fixed.JPG, notfixed.JPG > > > If a calendar timer has a schedule less than an hour, and should fire during the DST switch it is expected to be fired like this: > Asume : @Schedule(hour="*", minute="5/15", timezone="Europe/Berlin") > 2017 Nov. 29 1:50 CEST > 2017 Nov. 29 2:05 CEST > 2017 Nov. 29 2:20 CEST > 2017 Nov. 29 2:35 CEST > 2017 Nov. 29 2:50 CEST > 2017 Nov. 29 2:05 CET > But the timer is fired like this: > 2017 Nov. 29 1:50 CEST > 2017 Nov. 29 2:05 CET > All events within that hour are lost! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3414) Enhance module descriptions with a version number

by David Lloyd (JIRA)

David Lloyd created WFCORE-3414: ----------------------------------- Summary: Enhance module descriptions with a version number Key: WFCORE-3414 URL: https://issues.jboss.org/browse/WFCORE-3414 Project: WildFly Core Issue Type: Enhancement Components: Modules Reporter: David Lloyd Since JBoss Modules 1.6, a module descriptor may contain a version number. The version number will appear in stack traces starting in Java 9, so it's useful to add that information in the build process. It will require a bit of work though because that information will have to be extracted from Maven properties as part of the build process. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9546) Enhance module descriptions with a version number

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9546?page=com.atlassian.jira.plugin.... ] David Lloyd moved WFCORE-3414 to WFLY-9546: ------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-9546 (was: WFCORE-3414) Component/s: Build System (was: Modules) > Enhance module descriptions with a version number > ------------------------------------------------- > > Key: WFLY-9546 > URL: https://issues.jboss.org/browse/WFLY-9546 > Project: WildFly > Issue Type: Enhancement > Components: Build System > Reporter: David Lloyd > > Since JBoss Modules 1.6, a module descriptor may contain a version number. The version number will appear in stack traces starting in Java 9, so it's useful to add that information in the build process. It will require a bit of work though because that information will have to be extracted from Maven properties as part of the build process. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3413) Enhance module descriptions with a version number

by David Lloyd (JIRA)

David Lloyd created WFCORE-3413: ----------------------------------- Summary: Enhance module descriptions with a version number Key: WFCORE-3413 URL: https://issues.jboss.org/browse/WFCORE-3413 Project: WildFly Core Issue Type: Enhancement Components: Modules Reporter: David Lloyd Since JBoss Modules 1.6, a module descriptor may contain a version number. The version number will appear in stack traces starting in Java 9, so it's useful to add that information in the build process. It will require a bit of work though because that information will have to be extracted from Maven properties as part of the build process. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 November 2017