[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
[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
[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
[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
[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
[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
[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