August 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-621?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-621: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Support legacy slaves when invoking wildcard reads in a domain > -------------------------------------------------------------- > > Key: WFCORE-621 > URL: https://issues.jboss.org/browse/WFCORE-621 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Critical > Fix For: 2.0.0.CR1 > > > This is a follow-on to WFCORE-282. > The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.) > In particular, it won't work with slaves running EAP 6.x. > The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them. > Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-910) Reading metrics with dots in their names blows up

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-910?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-910: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Reading metrics with dots in their names blows up > ------------------------------------------------- > > Key: WFCORE-910 > URL: https://issues.jboss.org/browse/WFCORE-910 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.Beta4 > Reporter: Kabir Khan > Assignee: Tomaz Cerar > Priority: Blocker > Fix For: 2.0.0.CR1 > > > When doing a :read-resource(include-runtime=true,recursive=true) this blows up. Debugging shows that to be because e.g. the resource /subsystem=jgroups/channel=ee/protocol=UDP contains metrics called things like > {code} > "timer.keep_alive_time" => { > "type" => LONG, > "description" => "Timeout in ms to remove idle threads from the timer pool", > "expressions-allowed" => false, > "nillable" => false, > "access-type" => "metric", > "storage" => "runtime" > }, > "timer.max_threads" => { > "type" => INT, > "description" => "Max thread pool size for the timer thread pool", > "expressions-allowed" => false, > "nillable" => false, > "access-type" => "metric", > "storage" => "runtime" > }, > "timer.min_threads" => { > "type" => INT, > "description" => "Minimum thread pool size for the timer thread pool", > "expressions-allowed" => false, > "nillable" => false, > "access-type" => "metric", > "storage" => "runtime" > }, > {code} > i.e. they have a dot in their name. So when the r-r handler wants to read the attributes it in effect tries to do the following demonstrated by CLI commands: > {code} > [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer > timer.keep_alive_time timer.min_threads timer.rejection_policy timer.wheel_size timer_queue_size timer_threads > timer.max_threads timer.queue_max_size timer.tick_time timer_class timer_tasks timer_type > [standalone@localhost:9990 /] /subsystem=jgroups/channel=ee/protocol=UDP:read-attribute(name=timer.max_threads) > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0201: Unknown attribute 'timer'", > "rolled-back" => true > } > {code} > I see ReadResourceHandler has some stuff to extract the attribute name if 'extended syntax' is used. So we have two options: > 1) Ban dots in metric/attribute names > 2) Add a workaround to fall back. In other words if ReadAttributeHandler thinks extended syntax is being used, and cannot find the extracted 'timer' attribute, then try the full non-extracted name, e.g. timer.max_threads, and only then error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 1 month

1
0
0 / 0

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

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

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)

10 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2015