February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-340) A write-config operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-340?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-340: --------------------------------------- Assignee: Yeray Santana Borges > A write-config operation > ------------------------ > > Key: WFCORE-340 > URL: https://issues.jboss.org/browse/WFCORE-340 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Yeray Santana Borges > > Operation to force the server to write its config file, without making any actual config change. > One use case mentioned was to get the config file updated to the latest xml namespaces following an upgrade. > This should be trivial to implement with an operation step handler that simply does > context.readResourceForUpdate(PathAddress.EMPT_ADDRESS); > context.stepCompleted(); > That handler would be registered on: > 1) The root resource for a non-managed-domain server (for standalone.xml). > 2) The host=* resource on any HostController (for host.xml). > 3) The root resource on a HostController that is the master (for domain.xml). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1406) CLI client freezes for undefined security realm

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1406?page=com.atlassian.jira.plugi... ] Alexey Loubyansky moved JBEAP-3543 to WFCORE-1406: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1406 (was: JBEAP-3543) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Target Release: (was: 7.backlog.GA) Affects Version/s: 2.1.0.CR1 (was: 7.0.0.ER5) > CLI client freezes for undefined security realm > ----------------------------------------------- > > Key: WFCORE-1406 > URL: https://issues.jboss.org/browse/WFCORE-1406 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.1.0.CR1 > Environment: Fedora 23, Ubuntu 14.04 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Priority: Blocker > > During work, CLI freezes randomly. See attached thread dump which was taken on Fedora 23. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3407) Native Management Endpoint information is wrong

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3407?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-3407: ---------------------------------------- [~anrobert] Sure, contributions are always welcome! I don't think any special permissions are needed to edit those docs; if I'm wrong please let me know. Note the current version of these docs has changed and that particular section is gone: https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-Comma... > Native Management Endpoint information is wrong > ----------------------------------------------- > > Key: WFLY-3407 > URL: https://issues.jboss.org/browse/WFLY-3407 > Project: WildFly > Issue Type: Feature Request > Components: Documentation > Environment: https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-Native... > Reporter: Steve Fisher > Assignee: ANGELA ROBERTSON > > It would appear that port 9999 is no longer used for the CLI -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1408) Basic Authentication does not mention SSL

by ANGELA ROBERTSON (JIRA)

[ https://issues.jboss.org/browse/WFLY-1408?page=com.atlassian.jira.plugin.... ] ANGELA ROBERTSON reassigned WFLY-1408: -------------------------------------- Assignee: Zach Rhoads (was: ANGELA ROBERTSON) > Basic Authentication does not mention SSL > ----------------------------------------- > > Key: WFLY-1408 > URL: https://issues.jboss.org/browse/WFLY-1408 > Project: WildFly > Issue Type: Bug > Components: Documentation > Reporter: floyd floyd > Assignee: Zach Rhoads > > In the following documentation Basic Authentication is suggested. I have two comments: > - The documentation should clearly state that SSL (so HTTPS) should be used when using Basic authentication or Digest authentication. Usernames and Passwords will be sent in Cleartext in every single HTTP request to the server if SSL is not used when using Basic authentication. Which is clearly a security issue. > - The documentation should suggest Digest authentication rather than Basic authentication. > https://docs.jboss.org/author/display/WFLY8/WS-Security#WS-Security-Authe... > The same problem exists for the AS7 documentation: > https://docs.jboss.org/author/display/AS7/Developer+Guide#DeveloperGuide-... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6261) Upgrade Artemis to 1.1.0.wildfly-013

by Flavia Rainone (JIRA)

Flavia Rainone created WFLY-6261: ------------------------------------ Summary: Upgrade Artemis to 1.1.0.wildfly-013 Key: WFLY-6261 URL: https://issues.jboss.org/browse/WFLY-6261 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: Flavia Rainone Assignee: Flavia Rainone Priority: Blocker Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1157) Managmement and JMX notifications when ControlledProcessState changes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1157: ------------------------------------------ [~clychyb] A JMX notification will be emitted. The API for receiving the notification is by registering a javax.management.NotificationListener with the MBeanServer. That can either be done via a remote JMX client or something they register locally. There's no polling involve; the listener is registered and receives notifications. The notification will also emitted to native management listeners. EAP7-472 is a separate RFE to expose a supported API and configuration mechanism to allow end users to register a native management listener. > Managmement and JMX notifications when ControlledProcessState changes > --------------------------------------------------------------------- > > Key: WFCORE-1157 > URL: https://issues.jboss.org/browse/WFCORE-1157 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, JMX > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha1 > > > When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2017 at 2/22/16 1:14 PM: --------------------------------------------------------- OK, I'll take a look whether byte[] arrays can be reused, too. Something to try out might be to replace the payload of the existing messages *in-place* and add a {{CompressHeader}} if successful. We have to consider the following cases: h5. {{COMPRESS}} is _above_ {{NAKACK2}} / {{UNICAST3}} The message is added to {{NAKACK2}} / {{UNICAST3}} with a compressed payload and a {{CompressHeader}} attached. {{NAKACK2}} / {{UNICAST3}} will retransmit the _compressed_ message h5. {{COMPRESS}} is _below_ {{NAKACK2}} / {{UNICAST3}} {{NAKACK2}} / {{UNICAST3}} will retransmit the _compressed_ message (it was compressed by {{COMPRESS}} on the first send). {{COMPRESS}} will try to compress the message again. To prevent this, we could check if the message has a {{CompressHeader}} and skip compression if so. However, small messages, or messages which grew in size rather than shrunk, will not have a header, so perhaps we need to add a {{CompressHeader}} in all instances and add a flag which tells {{COMPRESS}} whether to uncompress or not. was (Author: belaban): OK, I'll take a look whether byte[] arrays can be reused, too. Something to try out might be to replace the payload of the existing messages *in-place* and add a {{CompressHeader}} if successful. We have to consider the following cases: h5. {{COMPRESS}} is _above_ {{NAKACK2}} / {{UNICAST3}} The message is added to {{NAKACK2}} with a compressed payload and a {{CompressHeader}} attached. NAKACK2 will retransmit the _compressed_ message h5. {{COMPRESS}} is _below_ {{NAKACK2}} / {{UNICAST3}} NAKACK2 will retransmit the _compressed_ message (it was compressed by COMPRESS on the first send). COMPRESS will try to compress the message again. To prevent this, we could check if the message has a CompressHeader and skip compression if so. However, small messages, or messages which grew in size rather than shrunk, will not have a header, so perhaps we need to add a CompressHeader in all instances and add a flag which tells COMPRESS whether to uncompress or not. > Optimize COMPRESS protocol by pooling / re-using byte array/buffer > ------------------------------------------------------------------ > > Key: JGRP-2017 > URL: https://issues.jboss.org/browse/JGRP-2017 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4.5, 3.6.7 > Environment: Wildfly 8.2.1.Final (JGroups 3.4.5) > Reporter: Mathieu Lachance > Assignee: Bela Ban > Fix For: 3.6.8, 4.0 > > > I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final. > Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat. > The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector. > When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great). > This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum. > Here is some notable classes of the Netty implementation: > https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects? > Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them? > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1405) Ability to configure a listener to receive management notifications

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1405: ---------------------------------------- Summary: Ability to configure a listener to receive management notifications Key: WFCORE-1405 URL: https://issues.jboss.org/browse/WFCORE-1405 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Provide a means to configure registration of a listener registration for management notifications. Users would implement a new NotificationRegistrar interface and register their impl in the configuration, with a management resource created for each configured NotificationRegistrar. The interface would be invoked by the kernel during add of the NotificationRegistrar resource (at boot or post-boot if it's added then.) The method passes in a ref to a client that subsequently can be used to invoke management ops, and a registry users can use to register listeners for future management notifications. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2017?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2017: --------------------------- Fix Version/s: 3.6.8 4.0 OK, I'll take a look whether byte[] arrays can be reused, too. Something to try out might be to replace the payload of the existing messages *in-place* and add a {{CompressHeader}} if successful. We have to consider the following cases: h5. {{COMPRESS}} is _above_ {{NAKACK2}} / {{UNICAST3}} The message is added to {{NAKACK2}} with a compressed payload and a {{CompressHeader}} attached. NAKACK2 will retransmit the _compressed_ message h5. {{COMPRESS}} is _below_ {{NAKACK2}} / {{UNICAST3}} NAKACK2 will retransmit the _compressed_ message (it was compressed by COMPRESS on the first send). COMPRESS will try to compress the message again. To prevent this, we could check if the message has a CompressHeader and skip compression if so. However, small messages, or messages which grew in size rather than shrunk, will not have a header, so perhaps we need to add a CompressHeader in all instances and add a flag which tells COMPRESS whether to uncompress or not. > Optimize COMPRESS protocol by pooling / re-using byte array/buffer > ------------------------------------------------------------------ > > Key: JGRP-2017 > URL: https://issues.jboss.org/browse/JGRP-2017 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.4.5, 3.6.7 > Environment: Wildfly 8.2.1.Final (JGroups 3.4.5) > Reporter: Mathieu Lachance > Assignee: Bela Ban > Fix For: 3.6.8, 4.0 > > > I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final. > Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat. > The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector. > When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great). > This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum. > Here is some notable classes of the Netty implementation: > https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... > I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects? > Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them? > Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2017) Optimize COMPRESS protocol by pooling / re-using byte array/buffer

by Mathieu Lachance (JIRA)

Mathieu Lachance created JGRP-2017: -------------------------------------- Summary: Optimize COMPRESS protocol by pooling / re-using byte array/buffer Key: JGRP-2017 URL: https://issues.jboss.org/browse/JGRP-2017 Project: JGroups Issue Type: Enhancement Affects Versions: 3.6.7, 3.4.5 Environment: Wildfly 8.2.1.Final (JGroups 3.4.5) Reporter: Mathieu Lachance Assignee: Bela Ban I'm currently working to minimize our application UDP bandwith usage by enabling the COMPRESS protocol in Wildfly 8.2.1.Final. Enabling the COMPRESS protocol works fine on that regards by reducing approximatly by 7x the amount of UDP traffic which is really neat. The thing is by enabling compression we are trading off increased cpu / memory usage for lowered network bandwith usage. In our case, we actually a notable increase of the cpu / memory usage due to increased usage of the garbage collector. When I had a look at the COMPRESS protocol implementation we see that both Deflator and Inflator are pooled and re-used (great) but not at the byte array level (not great). This compression pattern is very similar to GZip compression filter we can find in any recent Http spec implementors. In the Netty project for example, there's various compression protocol and/or utilities that are available and fine-tunable and they all have in common to re-use byte buffer and/or try to avoid byte arrays instantiation/copy at maximum. Here is some notable classes of the Netty implementation: https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty... https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... https://github.com/netty/netty/blob/4.1/codec/src/main/java/io/netty/hand... I think re-implementing something similar in JGroups would yield great benefits to the COMPRESS protocol. Maybe also, there's something that could be picked off right from the JBoss XNIO and/or the Undertow projects? Finally, I do not know also if we could add ergonomics at the same time to automatically determine the best number of Deflator and Inflator by keeping trace of the amount of time waited to pool one of them? Thanks, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 February 2016