[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
James Perkins commented on LOGTOOL-132:
---------------------------------------
I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.
By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.
*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger
*After Change*
||Index||Super||Total||ClassName||
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
James Perkins edited comment on LOGTOOL-132 at 1/23/18 9:10 AM:
----------------------------------------------------------------
I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.
By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.
*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
*After Change*
||Index||Super||Total||ClassName||
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
was (Author: jamezp):
I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.
By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.
*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger
*After Change*
||Index||Super||Total||ClassName||
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (LOGTOOL-132) Support low-metaspace bundles/classes
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugi... ]
David Lloyd commented on LOGTOOL-132:
-------------------------------------
I think the distribution size should be approximately equal for all approaches, though we'd have to test to be sure.
> Support low-metaspace bundles/classes
> -------------------------------------
>
> Key: LOGTOOL-132
> URL: https://issues.jboss.org/browse/LOGTOOL-132
> Project: Log Tool
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-409) Intermittent connection TimeOut with CLI using https-remoting
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-409?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise resolved WFCORE-409.
-----------------------------------------
Fix Version/s: 3.0.0.Final
Resolution: Done
> Intermittent connection TimeOut with CLI using https-remoting
> -------------------------------------------------------------
>
> Key: WFCORE-409
> URL: https://issues.jboss.org/browse/WFCORE-409
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Filip Bogyai
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Final
>
>
> When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time.
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> {code}
> This problem also causes intermittent test failures in testsuite, for example:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-409) Intermittent connection TimeOut with CLI using https-remoting
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-409?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-409:
---------------------------------------------
A lot of fixing occurred in remoting to handle timeout when using https. I am closing this issue, if you still see this problem using 7.1 (WF-CORE 3.0), feel free to re-open.
> Intermittent connection TimeOut with CLI using https-remoting
> -------------------------------------------------------------
>
> Key: WFCORE-409
> URL: https://issues.jboss.org/browse/WFCORE-409
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Filip Bogyai
> Assignee: Jean-Francois Denise
>
> When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time.
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> {code}
> This problem also causes intermittent test failures in testsuite, for example:
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2566) Subsystem parsing tests ignores wrong END_ELEMENT
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugi... ]
Jan Kalina closed WFCORE-2566.
------------------------------
Resolution: Rejected
PersistentResourceXMLDescription already used everywhere in elytron - closing
> Subsystem parsing tests ignores wrong END_ELEMENT
> -------------------------------------------------
>
> Key: WFCORE-2566
> URL: https://issues.jboss.org/browse/WFCORE-2566
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Beta9
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
> Tests will fail only if some next element follows - its parsing fails in such case correctly.
> Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
> Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
> Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-423) No way to grep/more or find a line in the CLI
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-423?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-423:
---------------------------------------------
That is implemented by WFCORE-3221 and WFCORE-426. Paging of output is enabled by default. In addition "| grep" can be used to find content such as:
:read-resource | grep undefined
> No way to grep/more or find a line in the CLI
> ---------------------------------------------
>
> Key: WFCORE-423
> URL: https://issues.jboss.org/browse/WFCORE-423
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jim Tyrrell
> Assignee: Jean-Francois Denise
> Labels: eap6-ux
>
> In the CLI I should be able to page through the pages of information that are presenting using | more or equivalent. By the same token I should be able to grep to find the one line that I am looking for, when I know what it is I am looking for.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months