August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-886) Upgrade to Xerces jboss-2.11.0.SP4 after merging pr#

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-886?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-886: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Upgrade to Xerces jboss-2.11.0.SP4 after merging pr# > ---------------------------------------------------- > > Key: WFCORE-886 > URL: https://issues.jboss.org/browse/WFCORE-886 > Project: WildFly Core > Issue Type: Task > Components: XML Frameworks > Reporter: Scott Marlow > Assignee: Carlo de Wolf > Priority: Blocker > Fix For: 2.0.0.CR1 > > > After [https://github.com/jboss/xerces/pull/9] is merged, please release a jboss-2.11.0.SP4 (via https://github.com/jboss/xerces) and create a PR for wildfly-core. [https://github.com/jboss/xerces/pull/9] is needed to pass the JAXB TCK. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-933) Embedded server start commands are lacking argument validation

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-933?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-933: ---------------------------------- I'll get a fix in for this in both embedded server types. > 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)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-936) PersistentResourceXMLDescription & friends shouldn't use ModelNode#asPropertyList()

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-936?page=com.atlassian.jira.plugin... ] Tomaz Cerar updated WFCORE-936: ------------------------------- Component/s: Domain Management > PersistentResourceXMLDescription & friends shouldn't use ModelNode#asPropertyList() > ----------------------------------------------------------------------------------- > > Key: WFCORE-936 > URL: https://issues.jboss.org/browse/WFCORE-936 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive. > We need to go trough PersistentResourceXMLDescription and all related parsers / marshallers to make sure we don't use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-936) PersistentResourceXMLDescription & friends shouldn't use ModelNode#asPropertyList()

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-936: ---------------------------------- Summary: PersistentResourceXMLDescription & friends shouldn't use ModelNode#asPropertyList() Key: WFCORE-936 URL: https://issues.jboss.org/browse/WFCORE-936 Project: WildFly Core Issue Type: Enhancement Reporter: Tomaz Cerar Assignee: Tomaz Cerar ModelNode.asPropertyList() results in a clone of the model node. If the node is very large this can be expensive. We need to go trough PersistentResourceXMLDescription and all related parsers / marshallers to make sure we don't use it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

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

8 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015