[JBoss JIRA] (WFLY-9460) Sample application with 4999 CDI beans 19 seconds on initial scanning and only 2 seconds of WeldBootStrap
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9460?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-9460:
---------------------------------------------
Hi Stuart,
I do not have Yourkit license.
And infeed if I had, I am not so sure I would be allowed to share that information if I requested for authorization for that.
But I am very thankful for the openess and interest in analyzing this data.
In case you are interested, for the problem of Jersey delaying the WeldBootstrap process, I have now opened an issue for the project on git hub under:
https://github.com/jersey/jersey/issues/3703
Many thanks for all the support.
Kindest regards.
> Sample application with 4999 CDI beans 19 seconds on initial scanning and only 2 seconds of WeldBootStrap
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9460
> URL: https://issues.jboss.org/browse/WFLY-9460
> Project: WildFly
> Issue Type: Enhancement
> Components: CDI / Weld
> Environment: Wildfly 10.1.0.final
> Reporter: Nuno Godinho de Matos
> Assignee: Martin Kouba
> Priority: Optional
>
> During the analsysis of an application depyloment, I ended up creating a sample application to demonstrate a small but important issue that Jersey causes to deployments in Weblogic echosystem, by expensively taking 2/3 of WeldBootsrap time during the "deployBeans()" phase.
> This application is a trivial WAR application composed 99% of CDI beans.
> In particularl it holds 4999 CDI beans automcatically generated via groovy.
> URL to sample app:
> https://github.com/99sono/wls-jsf-2-2-12-jersey-weldstartup-bottleneck
> Just mvn clean install. I has no data source dependencies, just CDI beans essentially.
> It should deploy in any application server without problems.
> While testing the same application deployment on Wildfly, I noticed that essentially:
> WeldBootstrap costs almost nothing in this case (2 seconds).
> But the time spent during deployment leading up to the WeldBootstrap phase is quite costly.
> In particular, we have about 19 seconds of deployment time.
> I will now quote the deployment time log:
> {panel}
> ####2017-10-20 13:16:50,196 ThreadId:17 INFO [logger: org.jboss.as.server.deployment] - WFLYSRV0027: Starting deployment of "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war" (runtime-name: "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war") <LogContext:none> <MSC service thread 1-3>
> ####2017-10-20 13:17:07,279 ThreadId:18 INFO [logger: org.jboss.weld.deployer] - WFLYWELD0003: Processing weld deployment wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war <LogContext:none> <MSC service thread 1-4>
> ####2017-10-20 13:17:07,360 ThreadId:18 INFO [logger: org.hibernate.validator.internal.util.Version] - HV000001: Hibernate Validator 5.2.4.Final <LogContext:none> <MSC service thread 1-4>
> ####2017-10-20 13:17:07,408 ThreadId:18 INFO [logger: org.jboss.as.ejb3.deployment] - WFLYEJB0473: JNDI bindings for session bean named 'LogEjbStartupPhaseSingleton' in deployment unit 'deployment "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war"' are as follows:
> java:global/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:app/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:module/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:global/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton
> java:app/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton
> java:module/LogEjbStartupPhaseSingleton
> <LogContext:none> <MSC service thread 1-4>
> NOTE:
> This is when the WeldBootstrapt Actually starts.
> And compared to the time spent to come here, this step costs nothing 2 seconds. [09 seocnds to 11seconds]. But to get here, we spent 19 seconds of deployment time.
> Is it possible to lower the time to come here?
> ####2017-10-20 13:17:09,208 ThreadId:15 INFO [logger: org.jboss.weld.Version] - WELD-000900: 2.3.5 (Final) <LogContext:none> <MSC service thread 1-1>
> ####2017-10-20 13:17:11,388 ThreadId:528 INFO [logger: startup.LogEjbStartupPhaseSingleton] -
> DEPLOYMENT IS NOW INVOKING STARTUP EJBS.
> <LogContext:none> <ServerService Thread Pool -- 359>
> -- Now we have a very expensive and costly mojarra startup.
> -- For this we already have opened the issue: https://github.com/javaserverfaces/mojarra/issues/4298
> ####2017-10-20 13:17:11,499 ThreadId:528 INFO [logger: javax.enterprise.resource.webcontainer.jsf.config] - Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT' <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [62ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/com/sun/faces/jsf-ri-runtime.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-extensions-6.0.0.jar/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/jsf-injection/main/wildfly-jsf-injection-10.1.0.Final.jar!/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,783 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [15ms] : Parse file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/tmp/vfs/temp/temp7406137a79d4ce52/content-9b229cec60054d8f/WEB-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,783 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : "faces-config" document sorting complete in 2. <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,799 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Configuration annotation scan complete. <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,158 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/META-INF/mojarra_ext.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,158 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/primefaces-pm.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,174 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [16ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/primefaces-p.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,190 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [16ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-extensions-6.0.0.jar/META-INF/primefaces-extensions.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,190 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/META-INF/mojarra_ext.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,274 ThreadId:528 INFO [logger: javax.enterprise.resource.webcontainer.jsf.config] - Monitoring file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/tmp/vfs/temp/temp7406137a79d4ce52/content-9b229cec60054d8f/WEB-INF/faces-config.xml for modifications <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 INFO [logger: org.primefaces.webapp.PostConstructApplicationEventListener] - Running on PrimeFaces 6.0 <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 INFO [logger: org.primefaces.extensions.application.PostConstructApplicationEventListener] - Running on PrimeFaces Extensions 6.0.0 <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [2894ms] : Initialization of context /wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,658 ThreadId:528 INFO [logger: org.jboss.resteasy.resteasy_jaxrs.i18n] - RESTEASY002225: Deploying javax.ws.rs.core.Application: class rest.RestApplication$Proxy$_$$_WeldClientProxy <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,689 ThreadId:528 INFO [logger: org.wildfly.extension.undertow] - WFLYUT0021: Registered web context: /wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,748 ThreadId:507 INFO [logger: org.jboss.as.server] - WFLYSRV0010: Deployed "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war" (runtime-name : "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war") <LogContext:none> <External Management Request Threads -- 5>
> {panel}
> Would it possible for a CDI expert to try deploying the application and determine if the 19 seocnds that lead up to the first message: WELD-000900 2.3.5
> Is well justified, or if there is room optimizing this boostraping costs.
> To me 19 seonds to analyse 4999 CDI beans, that are all located uner WEB-INF/classes looks like an expensive cost.
> Is there any sort of static configuration that we could perhaps create to lower the annotation analysis cost or any other sort of trick.
> I would have hoped that this war file could deploy in under 5 seconds.
> Many thanks for any feedback on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on JGRP-2224:
-------------------------------------------
Ok looks good to me.
Could you please explain how it works in details? I'm especially interested in:
* What is the order of invoked discovery protocols? Is {{FILE_PING}} invoked before {{MPING}} in your example or it's the other way around?
* What happens if all discovery protocols return different results? Can I merge them somehow?
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2224.
----------------------------
Resolution: Done
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2224) Multiple discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2224?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2224:
--------------------------------
I don't like the idea of having to point to a different file, that's just another moving part that can be missing.
I ended up picking the solution where {{MULTI_PING}} needs to be somewhere above all other discovery protocols, e.g.
{code:xml}
<TCP ... />
<TCPPING initial_hosts="127.0.0.1[7800]" port_range="0"/>
<PING />
<MPING/>
<FILE_PING/>
<MULTI_PING async_discovery="true"/>
<MERGE3/>
...
{code}
The reason I did _not_ pick the embeded configuration above is that it would have required an awkward match between protocol IDs and header IDs, and forwarding of messages up the stack.
> Multiple discovery protocols
> ----------------------------
>
> Key: JGRP-2224
> URL: https://issues.jboss.org/browse/JGRP-2224
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.8
>
>
> Allow for multiple discovery protocols. This would allow us to use a single configuration which includes discovery protocols for multiple cloud providers.
> The discovery protocols could be queried sequentially (return on result), or in parallel.
> Investigate whether we need a super discovery protocol which instantiates the individual protocols, or whether each protocol should be changed e.g. to forward events down the stack.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by Klaus Erber (JIRA)
[ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.... ]
Klaus Erber commented on WFLY-9456:
-----------------------------------
We face the same problem with WF11Final on Centos 7.
> High non heap memory consumption
> --------------------------------
>
> Key: WFLY-9456
> URL: https://issues.jboss.org/browse/WFLY-9456
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 11.0.0.CR1, 11.0.0.Final
> Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Klaus Erber
> Assignee: David Lloyd
> Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4 1652 14.0 22.1 2863404 *801620* pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> wf10
> ke4 1836 42.1 5.7 2687744 *209204* pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by Klaus Erber (JIRA)
[ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.... ]
Klaus Erber updated WFLY-9456:
------------------------------
Affects Version/s: 11.0.0.Final
> High non heap memory consumption
> --------------------------------
>
> Key: WFLY-9456
> URL: https://issues.jboss.org/browse/WFLY-9456
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 11.0.0.CR1, 11.0.0.Final
> Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Klaus Erber
> Assignee: David Lloyd
> Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4 1652 14.0 22.1 2863404 *801620* pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> wf10
> ke4 1836 42.1 5.7 2687744 *209204* pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3379) AttributeNamePathCompleter pollutes terminal by calling e.printStackTrace on CommandFormatException
by Chao Wang (JIRA)
Chao Wang created WFCORE-3379:
---------------------------------
Summary: AttributeNamePathCompleter pollutes terminal by calling e.printStackTrace on CommandFormatException
Key: WFCORE-3379
URL: https://issues.jboss.org/browse/WFCORE-3379
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.8.Final
Reporter: Chao Wang
Assignee: Chao Wang
I run into this by accident. command:
{noformat}
/subsystem=datasources/data-source=ExampleDS:read-attribute(name=[PRESS_TAB_HERE
{noformat}
terminal output:
{noformat}
[standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=[org.jboss.as.cli.CommandFormatException: Attribute name is missing before [ at index 0 in '['
at org.jboss.as.cli.impl.AttributeNamePathCompleter$AttributeNamePathCallbackHandler.enteredState(AttributeNamePathCompleter.java:394)
at org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:297)
at org.jboss.as.cli.parsing.EnterStateCharacterHandler.handle(EnterStateCharacterHandler.java:44)
at org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.parse(StateParser.java:139)
at org.jboss.as.cli.parsing.StateParser.doParse(StateParser.java:106)
at org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:73)
at org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:63)
at org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:56)
at org.jboss.as.cli.impl.AttributeNamePathCompleter.parse(AttributeNamePathCompleter.java:246)
at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:231)
at org.jboss.as.cli.impl.AttributeNamePathCompleter.complete(AttributeNamePathCompleter.java:220)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:276)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:89)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:137)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:64)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:143)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:155)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:429)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:166)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:778)
at org.jboss.aesh.console.Console.execute(Console.java:738)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:647)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
command above is an edge case when people tries incorrectly AttributeNamePathCompleter with malformed command. However, it's better to log a warning message than print exception stack trace into client terminal.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months