July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2043 at 7/13/16 12:47 AM: ---------------------------------------------------------- Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection. The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.: {code:java} Supplier<? extends Header> supplier; Header hdr=supplier.get(); {code} This requires all headers to implement a Creationable interface which returns a supplier. [1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte... was (Author: belaban): Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection. The onyl fast way I found so far is to create a methd handle _indirectly_ via a lambda, ie.: {code:java} Supplier<? extends Header> supplier; Header hdr=supplier.get(); {code} This requires all headers to implement a Creationable interface which returns a supplier. [1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte... > Improve performance of Message#readHeader > ----------------------------------------- > > Key: JGRP-2043 > URL: https://issues.jboss.org/browse/JGRP-2043 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > A CPU hot spot highlighed by profiling via JFR: > {noformat}Stack Trace Sample Count Percentage(%) > java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392 > java.lang.Class.newInstance() 71 2.392 > org.jgroups.Message.readHeader(DataInput) 71 2.392 > {noformat} > I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into. > It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2043: -------------------------------- Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection. The onyl fast way I found so far is to create a methd handle _indirectly_ via a lambda, ie.: {code:java} Supplier<? extends Header> supplier; Header hdr=supplier.get(); {code} This requires all headers to implement a Creationable interface which returns a supplier. [1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte... > Improve performance of Message#readHeader > ----------------------------------------- > > Key: JGRP-2043 > URL: https://issues.jboss.org/browse/JGRP-2043 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > A CPU hot spot highlighed by profiling via JFR: > {noformat}Stack Trace Sample Count Percentage(%) > java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392 > java.lang.Class.newInstance() 71 2.392 > org.jgroups.Message.readHeader(DataInput) 71 2.392 > {noformat} > I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into. > It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-1649: ------------------------------------- Maybe one option would be to go on with implementing "dynamic transformers registration" using service loader. I have some prototype impl somewhere for subsystems work, but shouldn't be much more work to do the same for kernel transformers. This would allow us to register transformers separately from kernel itself. > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta1 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1649: ---------------------------------------- Assignee: Brian Stansberry > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 3.0.0.Beta1 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1649: ---------------------------------------- Summary: RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave Key: WFCORE-1649 URL: https://issues.jboss.org/browse/WFCORE-1649 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Priority: Critical Fix For: 3.0.0.Beta1 The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. This is a big problem in the following scenarios: 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: -- that doesn't help with problem 2) -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-142) Default app-name value of Syslog handler in Audit Logging violates specification

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-142?page=com.atlassian.jira.plugin... ] James Perkins moved WFCORE-1648 to LOGMGR-142: ---------------------------------------------- Project: JBoss Log Manager (was: WildFly Core) Key: LOGMGR-142 (was: WFCORE-1648) Component/s: (was: Domain Management) Affects Version/s: (was: 3.0.0.Alpha3) > Default app-name value of Syslog handler in Audit Logging violates specification > -------------------------------------------------------------------------------- > > Key: LOGMGR-142 > URL: https://issues.jboss.org/browse/LOGMGR-142 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: Jan Tymel > Assignee: Ken Wills > > According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent. > E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}} > Suggestions for improvement: > Change default value {{WildFly Core}} to one without space character. > Also please consider addition of check whether {{app-name}} contains space character. > [1] https://tools.ietf.org/html/rfc5424#page-8 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-142) Default app-name value of Syslog handler in Audit Logging violates specification

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-142?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-142: ------------------------------------ Assignee: James Perkins (was: Ken Wills) > Default app-name value of Syslog handler in Audit Logging violates specification > -------------------------------------------------------------------------------- > > Key: LOGMGR-142 > URL: https://issues.jboss.org/browse/LOGMGR-142 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: Jan Tymel > Assignee: James Perkins > > According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent. > E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}} > Suggestions for improvement: > Change default value {{WildFly Core}} to one without space character. > Also please consider addition of check whether {{app-name}} contains space character. > [1] https://tools.ietf.org/html/rfc5424#page-8 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1648) Default app-name value of Syslog handler in Audit Logging violates specification

by James Perkins (JIRA)

James Perkins created WFCORE-1648: ------------------------------------- Summary: Default app-name value of Syslog handler in Audit Logging violates specification Key: WFCORE-1648 URL: https://issues.jboss.org/browse/WFCORE-1648 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha3 Reporter: Jan Tymel Assignee: Ken Wills According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent. E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}} Suggestions for improvement: Change default value {{WildFly Core}} to one without space character. Also please consider addition of check whether {{app-name}} contains space character. [1] https://tools.ietf.org/html/rfc5424#page-8 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1647) Default app-name value of Syslog handler in Audit Logging violates specification

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1647?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1647: --------------------------------------- I think you're correct [~luck3y]. So ignore me this looks good. > Default app-name value of Syslog handler in Audit Logging violates specification > -------------------------------------------------------------------------------- > > Key: WFCORE-1647 > URL: https://issues.jboss.org/browse/WFCORE-1647 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha3 > Reporter: Jan Tymel > Assignee: Ken Wills > > According to syslog specification[1] {{app-name}} cannot contain space character (" "). However, the default value in WildFly Core 3.0.0.Alpha3 is {{WildFly Core}}. This results in the syslog server is not able to capture Process ID from which the message was sent. > E.g. following piece of information is captured {{WildFly[Core] (...)}} instead of {{WildFlyCore[795]}} > Suggestions for improvement: > Change default value {{WildFly Core}} to one without space character. > Also please consider addition of check whether {{app-name}} contains space character. > [1] https://tools.ietf.org/html/rfc5424#page-8 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6713) Upgrade Jackson to 2.7.4 due to CVE-2016-3720

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-6713?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-6713: ---------------------------------- Fix Version/s: 10.1.0.Final > Upgrade Jackson to 2.7.4 due to CVE-2016-3720 > --------------------------------------------- > > Key: WFLY-6713 > URL: https://issues.jboss.org/browse/WFLY-6713 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Juergen Zimmermann > Assignee: Alessio Soldano > Fix For: 10.1.0.Final > > > Jackson 2.7.3 is currently used, but reported at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3720 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 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 July 2016