July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1656) log4j per logging deployment configuration errors are swallowed

by James Perkins (JIRA)

James Perkins created WFCORE-1656: ------------------------------------- Summary: log4j per logging deployment configuration errors are swallowed Key: WFCORE-1656 URL: https://issues.jboss.org/browse/WFCORE-1656 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins Anything logged through log4j's {{org.apache.log4j.helpers.LogLog}} seems to be swallowed. This includes debug messages if log4j debugging is turned on as well as any warnings or errors found during configuration are not printed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1655) verbose patch info should match in offline and online modes

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFCORE-1655: ----------------------------------------- Summary: verbose patch info should match in offline and online modes Key: WFCORE-1655 URL: https://issues.jboss.org/browse/WFCORE-1655 Project: WildFly Core Issue Type: Bug Components: CLI, Patching Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 3.0.0.Alpha4 When the CLI is connected to the controller, patch info reflects the outcome of read-resource operation. It could be basic info or extended (--verbose). In the offline mode though, the only information available is the basic one. It is actually limited by the tool's API, which means it never meant to support --verbose. This difference is not reflected in the help content of the command and simply looks like an inconsistent behavior of the same command depending on the connection status. Another issue with the offline mode is that, the current version was not propagated to the CLI and would always read "Unknown" for the user. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 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 thanks [~jtymel]. I missed that definition at the bottom. > 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 > Fix For: 3.0.0.Alpha4, 2.2.0.CR8 > > > 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)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2048) ClassConfigurator: use constructors rather than Classes in map

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2048?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2048. ---------------------------- Resolution: Duplicate Issue JGRP-2043 uses lambdas ({{Supplier<Header>}}) as values of the classMap hashmap. This is faster than storing {{MethodHandles}}. > ClassConfigurator: use constructors rather than Classes in map > -------------------------------------------------------------- > > Key: JGRP-2048 > URL: https://issues.jboss.org/browse/JGRP-2048 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Investigate whether use of {{Constructor}} as values in the maps rather than {{Class<?>}} improves performance. {{Class.newInstance()}} does cache the constructor, but there's a security check that's executed once, so using the constructor may improve perf. > Also, if a class doesn't have an empty constructor, using {{Class.newInstance()}} would throw an exception, whereas using constructors would detect this at load time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2048) ClassConfigurator: use constructors rather than Classes in map

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2048?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2048: -------------------------------- Duplicate of JGRP-2043 > ClassConfigurator: use constructors rather than Classes in map > -------------------------------------------------------------- > > Key: JGRP-2048 > URL: https://issues.jboss.org/browse/JGRP-2048 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > Investigate whether use of {{Constructor}} as values in the maps rather than {{Class<?>}} improves performance. {{Class.newInstance()}} does cache the constructor, but there's a security check that's executed once, so using the constructor may improve perf. > Also, if a class doesn't have an empty constructor, using {{Class.newInstance()}} would throw an exception, whereas using constructors would detect this at load time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2042. ---------------------------- Resolution: Done > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2042: -------------------------------- The solution picked was to add IDs to all {{Header}} subclasses and sanity check them against {{jg-magic-map.xml}}. When serializing a header instance, instead of getting the magic-ID via hashmap lookup, {{Header.getMagicId()}} is called instead. This avoids a hashmap lookup per header when serializaing a message. We have usually 3-4 headers per message, so 3-4 lookups per message we don't have to perform. > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2042: --------------------------- Fix Version/s: (was: 3.6.11) Quite a few changes; don't want to de-stabilize the 3.6 branch. > Improve performance of Message#writeHeader > ------------------------------------------ > > Key: JGRP-2042 > URL: https://issues.jboss.org/browse/JGRP-2042 > Project: JGroups > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised. > {noformat}Stack Trace Sample Count Percentage(%) > java.util.IdentityHashMap.get(Object) 66 2.224 > org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224 > org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224 > {noformat} > One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1654) Enhancements for set/unset test suite

by Martin Schvarcbacher (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1654?page=com.atlassian.jira.plugi... ] Martin Schvarcbacher moved JBEAP-5208 to WFCORE-1654: ----------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1654 (was: JBEAP-5208) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: (was: 7.0.0.GA) > Enhancements for set/unset test suite > ------------------------------------- > > Key: WFCORE-1654 > URL: https://issues.jboss.org/browse/WFCORE-1654 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Martin Schvarcbacher > Assignee: Martin Schvarcbacher > Priority: Minor > > Added tests for jboss-cli ‘set’ and ‘unset’ commands > Use cases: > set variable1=value > set variable2=$variable1 > unset variable1 > set #prints all set variables -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1653) Enhancements for set/unset testsuite

by Martin Schvarcbacher (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1653?page=com.atlassian.jira.plugi... ] Martin Schvarcbacher deleted WFCORE-1653: ----------------------------------------- > Enhancements for set/unset testsuite > ------------------------------------ > > Key: WFCORE-1653 > URL: https://issues.jboss.org/browse/WFCORE-1653 > Project: WildFly Core > Issue Type: Task > Reporter: Martin Schvarcbacher > Assignee: Martin Schvarcbacher > Priority: Minor > > Added tests for jboss-cli ‘set’ and ‘unset’ commands > Use cases: > set variable1=value > set variable2=$variable1 > unset variable1 > set #prints all set variables -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 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 July 2016