[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise closed WFCORE-1868.
----------------------------------------
Resolution: Done
The issue has been fixed in Aesh 0.66.+ branch, 0.66.12-SNAPSHOT.
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7384) Removal of messaging-activemq's server stops Infinispan services
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-7384.
-------------------------------
Resolution: Rejected
> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
> Key: WFLY-7384
> URL: https://issues.jboss.org/browse/WFLY-7384
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
> Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7384) Removal of messaging-activemq's server stops Infinispan services
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7384?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7384:
-----------------------------------
[~pferraro] thanks for looking at it
> Removal of messaging-activemq's server stops Infinispan services
> ----------------------------------------------------------------
>
> Key: WFLY-7384
> URL: https://issues.jboss.org/browse/WFLY-7384
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
> Attachments: WFLY-7384.diff
>
>
> This issue occurs after I fixed the issue for WFLY-7333 which ensures that all services related to a messaging-activemq server are stopped when the server is removed.
> When I run the command to remove the server:
> /subsystem=messaging-activemq/server=default:remove
> I see logs in the app server about Infinispan services being stopped:
> {noformat}
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting JGroups channel server
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel ejb
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000080: Disconnecting JGroups channel hibernate
> 09:28:46,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000080: Disconnecting JGroups channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher for channel server
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel ejb
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000082: Stopping the RpcDispatcher for channel web
> 09:28:46,347 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000082: Stopping the RpcDispatcher for channel hibernate
> 09:28:46,381 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 70) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.4.0 [c96316a7-9b4d-11e6-ab8c-b8f6b112daf7] stopped, uptime 18.904 seconds
> {noformat}
> There should be no reason than stopping the messaging server should stop such Infinispan services. The messaging-activemq subsystem has *no* dependency to Infinispan resources.
> However both messaging-activemq and infinispan resources depends on JGroups resources.
> I did a diff of the services dump before and after removing the messaging-activemq server (see attached file).
> The Infinispan services are stopped as a consequence of stopping the jboss.messaging-activemq.default service. Before removing the server, this service is in this state:
> {noformat}
> Service \"jboss.messaging-activemq.default\" (class org.wildfly.extension.messaging.activemq.ActiveMQServerService) mode ACTIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.management.jmx, org.wildfly.clustering.jgroups.default-channel-factory, jboss.outbound-socket-binding.http, jboss.binding.http, jboss.http-upgrade-registry.default, jboss.path.manager, jboss.security.security-domain.other)
> {noformat}
> The only relation between this messaging server and the Infinispan resources is that they depend on the org.wildfly.clustering.jgroups.default-channel-factory service. Before removing the messaging server, this service is in the state:
> {noformat}
> Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state UP (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> After removing the messaging server, this service is in the state:
> {noformat}
> > Service \"org.wildfly.clustering.jgroups.default-channel-factory\" (class org.jboss.msc.service.ValueService) mode PASSIVE state DOWN (WAITING) (parent: jboss.as.server-controller) (dependencies: org.wildfly.clustering.jgroups.channel-factory.ee)
> {noformat}
> I am not sure to understand why and when removing the jboss.messaging-activemq.default implies to remove the org.wildfly.clustering.jgroups.default-channel-factory service but there is no reason that removing any messaging-activemq resources should impact the state of Infinispan services
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes edited comment on WFLY-6173 at 10/27/16 2:27 AM:
------------------------------------------------------------
Hey [~mkouba],
I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.
!Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail!
was (Author: davidmaes):
Hey [~mkouba],
I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.
!Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes edited comment on WFLY-6173 at 10/27/16 2:27 AM:
------------------------------------------------------------
Hey [~mkouba],
I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.
!Screen Shot 2016-10-27 at 08.04.12.png|thumbnail!
was (Author: davidmaes):
Hey [~mkouba],
I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.
!Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail!
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-7393) Elytron Http status code for missing LoginPermission
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7393?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6657 to WFLY-7393:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7393 (was: JBEAP-6657)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
> Elytron Http status code for missing LoginPermission
> ----------------------------------------------------
>
> Key: WFLY-7393
> URL: https://issues.jboss.org/browse/WFLY-7393
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Optional
>
> Lack of {{LoginPermission}} leads to 401 http code. Which could IMO indicate user can try to login again with different password. However it won't help in this case. I wonder, wouldn't 403 Forbidden be more suitable here? Indicating user authentication passed, but user is missing some permission.
> Setting with low priority as in DR7 in default configuration LoginPermission is added by default.
> David: "I think you may be right @MartinChoma - 401 is called "unauthorized" but really it should say "authentication required" 403 is the correct response for an authorization error"
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes updated WFLY-6173:
-----------------------------
Attachment: Screen Shot 2016-10-27 at 08.15.27.png
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes commented on WFLY-6173:
----------------------------------
Hey [~mkouba],
I have done some investigating and I have a question. I viewed the heap dump off the application. Specifically the class loaders. I included the image of 2 separate heap dumps. The second heap dump is after a redeploy. As you can see a ModuleClassLoader was added but none were removed. Is this normal behaviour or is something fishy going on there.
!Screen Shot 2016-10-27 at 08.04.12.png|thumbnail! !Screen Shot 2016-10-27 at 08.15.27.png|thumbnail!
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by David Maes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
David Maes updated WFLY-6173:
-----------------------------
Attachment: Screen Shot 2016-10-27 at 08.04.12.png
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip, Screen Shot 2016-10-27 at 08.04.12.png
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
9 years, 6 months