[JBoss JIRA] (WFCORE-933) Embedded server start commands are lacking argument validation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-933?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-933:
-----------------------------------------
I put some logic in there for that, but it was cut-and-paste from somewhere else and obviously wasn't done right.
> Embedded server start commands are lacking argument validation
> --------------------------------------------------------------
>
> Key: WFCORE-933
> URL: https://issues.jboss.org/browse/WFCORE-933
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
> Priority: Minor
>
> Commands for starting embedded instances are lacking argument validation.
> {noformat}[disconnected /] embed-server foo
> [standalone@embedded /]
> [disconnected /] embed-server foo -foo
> [standalone@embedded /]
> [disconnected /] embed-server foo --foo
> [standalone@embedded /]
> [standalone@embedded /] stop-embedded-server foo
> The command accepts 0 unnamed argument(s) but received: [foo]
> [standalone@embedded /] stop-embedded-server -foo
> Unrecognized arguments: [-foo]
> [standalone@embedded /] stop-embedded-server --foo
> Unrecognized arguments: [--foo]{noformat}
> Same case for embedded host controller.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5234) Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5234?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5234:
-----------------------------------
Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2015-August/004362.html
> Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-5234
> URL: https://issues.jboss.org/browse/WFLY-5234
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS, Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.CR1
>
>
> ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
> We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant in most places, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
> I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
> Things I plan to look at:
> (xa-)datasources
> messaging destinations
> resource adapters
> JCA connectors
> security domains
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5234) Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5234?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-5234:
-----------------------------------
Description:
ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant in most places, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
Things I plan to look at:
(xa-)datasources
messaging destinations
resource adapters
JCA connectors
security domains
was:
ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
Things I plan to look at:
(xa-)datasources
messaging destinations
resource adapters
JCA connectors
security domains
> Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-5234
> URL: https://issues.jboss.org/browse/WFLY-5234
> Project: WildFly
> Issue Type: Bug
> Components: JCA, JMS, Security
> Affects Versions: 10.0.0.Beta2
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.CR1
>
>
> ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
> We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant in most places, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
> I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
> Things I plan to look at:
> (xa-)datasources
> messaging destinations
> resource adapters
> JCA connectors
> security domains
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5234) Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-5234:
--------------------------------------
Summary: Use of ModelNode.asPropertyList() is slow when marshaling potentially large subsystem model chunks
Key: WFLY-5234
URL: https://issues.jboss.org/browse/WFLY-5234
Project: WildFly
Issue Type: Bug
Components: JCA, JMS, Security
Affects Versions: 10.0.0.Beta2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.0.0.CR1
ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive.
We use this call quite a bit in subsystem xml marshallers. The cost is not likely to be significant, but in a few cases where users may end up adding a large number of nodes of a particular type, moving away from this call to another idiom that doesn't involve cloning may help with performance.
I've heard of a user planning to add thousands of datasources, for example, and wanting very fast performance of the write ops to add those.
Things I plan to look at:
(xa-)datasources
messaging destinations
resource adapters
JCA connectors
security domains
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated for a read-only request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated for a read-only request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this result in 42 bytes for each cache key. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #3 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5233) Optimize marshalled size of web sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5233?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5233:
-------------------------------
Description:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
was:
There are a couple of marshalling optimizations that we can make in the current web session clustering code:
* We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
* We currently store the metadata of a session in a single cache entry. The metadata is composed of:
*# Creation timestamp (long)
*# Last access timestamp (long)
*# Max inactive interval (int)
#1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into 2: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
> Optimize marshalled size of web sessions
> ----------------------------------------
>
> Key: WFLY-5233
> URL: https://issues.jboss.org/browse/WFLY-5233
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Beta2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.0.0.CR1
>
>
> There are a couple of marshalling optimizations that we can make in the current web session clustering code:
> * We currently marshal session identifiers as UTF-8 strings. For the default session id length, this comes out to 42 bytes. Since session ids use a limited alphabet (modified base64) we can easily reduce this to 30 bytes (31 to support variable length).
> * We currently store the metadata of a session in a single cache entry. The metadata is composed of:
> *# Creation timestamp (long)
> *# Last access timestamp (long)
> *# Max inactive interval (int)
> #1 is static. #2 updates every request. #3 is "effectively" static. If we split the metadata cache entry into two: one containing static metadata, the other dynamic metadata; we can reduce the size of the data that needs to be replicated every request. Additionally, #2 can be represented as a duration of time since #1, and thus can be expressed as a short or integer instead of a long. Thus, for requests that do not modify the session, we only need to replicate 4 bytes or less instead of 20.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JGRP-1954) SWIFT_PING discovery protocol fatal error on OpenStack Kilo
by Nick Sawadsky (JIRA)
[ https://issues.jboss.org/browse/JGRP-1954?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-1954:
-------------------------------------
That would probably be doable -- but having to write it two ways, depending on the Java version, makes this approach less attractive to me. There might be a version-independent option as well, using ScriptEngine.eval() -- but that may open up security risks. Moving SWIFT_PING to a separate project, or embedding JSON.simple, both seem like more attractive options, in my mind.
> SWIFT_PING discovery protocol fatal error on OpenStack Kilo
> -----------------------------------------------------------
>
> Key: JGRP-1954
> URL: https://issues.jboss.org/browse/JGRP-1954
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Environment: JGroups client running on Mac OS X - Yosemite
> JDK 1.7.71
> OpenStack Kilo
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I'm attempting to use the SWIFT_PING discovery protocol on the most recent version of OpenStack, "Kilo". An error occurs during initialization of the protocol stack, the stack trace is provided below.
> The problem appears to be that support for XML-formatted responses has been removed in the OpenStack Identity API (http://developer.openstack.org/api-ref-identity-v2.html). Even though SWIFT_PING sends an Accept header of application/xml, the response still comes back as JSON (around line 286 of SWIFT_PING.java).
> I've been able to repro the issue using Postman in Chrome. I tried providing the *request* in XML , with a Content-Type header of application/xml, but Swift returns an error: "Expecting to find application/json in Content-Type header".
> It seems like the resolution would be for SWIFT_PING to be modified so it can parse the JSON response that it is receiving. If that sounds like a reasonable approach, I can try to create a patch that fixes the issue.
> Stack Trace:
> 2015-08-21 14:30:16,123 FATAL [com.pingidentity.common.util.ErrorHandler] Problem creating factory for multiplexed cluster communications
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:257) ~[?:1.8.0_25]
> at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:348) ~[?:1.8.0_25]
> at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) ~[?:1.8.0_25]
> at org.jgroups.protocols.SWIFT_PING$Keystone_V_2_0_Auth.authenticate(SWIFT_PING.java:307) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING$SwiftClient.authenticate(SWIFT_PING.java:443) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.protocols.SWIFT_PING.init(SWIFT_PING.java:68) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.init(JChannel.java:854) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:159) ~[jgroups.jar:3.6.4.Final]
> at org.jgroups.JChannel.<init>(JChannel.java:120) ~[jgroups.jar:3.6.4.Final]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months