February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-44) unavailable datasource statistics

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-44?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry updated WFLY-44: --------------------------------- Fix Version/s: 8.0.1.Final (was: 8.0.0.CR1) (was: 8.0.0.Final) > unavailable datasource statistics > --------------------------------- > > Key: WFLY-44 > URL: https://issues.jboss.org/browse/WFLY-44 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, JCA, JMX > Reporter: Mathieu Lachance > Priority: Minor > Fix For: 8.0.1.Final > > > In the java visual vm, in the mbean tab, under the "jboss.as:subsystem=datasources,data-source=MyDataSource" mbean, attribute "statistics" is marked as "Unavailable" > When using the spy="true" attribute in the datasource subsystem in conjunction with the "org.jboss.jca" logger set as TRACE level in the logging subsystem, statistics are outputted as follow : > Statistics: > ActiveCount: 1 > AvailableCount: 99 > AverageBlockingTime: 0 > AverageCreationTime: 248 > CreatedCount: 1 > DestroyedCount: 0 > MaxCreationTime: 248 > MaxUsedCount: 1 > MaxWaitCount: 0 > MaxWaitTime: 0 > TimedOut: 0 > TotalBlockingTime: 0 > TotalCreationTime: 248 > I would except to find those statistics available through separates jmx attributes when using the spy="true". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-269) Updated infinispan management API

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-269?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved WFLY-269. ----------------------------------- Fix Version/s: (was: 8.0.0.CR1) (was: 8.0.0.Final) Resolution: Incomplete Description > Updated infinispan management API > --------------------------------- > > Key: WFLY-269 > URL: https://issues.jboss.org/browse/WFLY-269 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Heiko Braun > Assignee: Richard Achmatowicz > > Expose updated management operations -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-209) Move ClientConfigurationImpl factory methods into ModelControllerClientConfiguration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-209?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-209: ---------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.CR1) (was: 8.0.0.Final) > Move ClientConfigurationImpl factory methods into ModelControllerClientConfiguration > ------------------------------------------------------------------------------------ > > Key: WFLY-209 > URL: https://issues.jboss.org/browse/WFLY-209 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 9.0.0.CR1 > > > ClientConfigurationImpl includes a bunch of static factory methods that would fit better in a Factory class in the ModelControllerClientConfiguration interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-202) Include registered attributes with no model representation in read-resource results

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-202?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-202: ---------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.CR1) (was: 8.0.0.Final) > Include registered attributes with no model representation in read-resource results > ----------------------------------------------------------------------------------- > > Key: WFLY-202 > URL: https://issues.jboss.org/browse/WFLY-202 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 9.0.0.CR1 > > > Following situation: > 1) resource includes attribute xyz > 2) No read-handler is registered for xyz (i.e. default read semantic Resource.getModel().get("xyz") is to be used) > 3) Poorly coded "add" handler for the resource doesn't call model.get("xyz") for some reason. > The effect of this is the read-resource result will not include "xyz" => undefined in the output. Nothing for xyz will appear at all, hiding the existence of the attribute from the caller. > The read-resource handler can deal with a check in its loop through the AttributeAccess registration for the "no read-handler" case. (This check is already there; an 'else' clause is needed.) If no read-handler, see if there is an entry in the directAttributes map for the attribute; if not, add one with a value of new ModelNode(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-53) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-53?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry updated WFLY-53: --------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.CR1) (was: 8.0.0.Final) > Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true" > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-53 > URL: https://issues.jboss.org/browse/WFLY-53 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Environment: FreeBSD, OpenJDK 1.6 > Reporter: Brian Stansberry > Priority: Minor > Fix For: 9.0.0.CR1 > > > Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable. > Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others. > This leads to this unit test failure on jvms where the UOE is thrown: > failure message="thread-cpu-time-enabled is undefined" > type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined > at junit.framework.Assert.fail(Assert.java:50) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn > itTestCase.java:595) > at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-19) JMX over remoting pollutes query results with ModelController objects

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-19?page=com.atlassian.jira.plugin.sy... ] Brian Stansberry commented on WFLY-19: -------------------------------------- If this can't be reproduced, please resolve. Thanks! > JMX over remoting pollutes query results with ModelController objects > --------------------------------------------------------------------- > > Key: WFLY-19 > URL: https://issues.jboss.org/browse/WFLY-19 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management, JMX > Reporter: NadirX > Assignee: Kabir Khan > Fix For: 8.0.0.Final > > > When issuing MBean queries over JMX remoting, the AS is returning a list of org.jboss.as.controller.ModelController objects in addition to those matching the query. > This is a transcript of a chat we had about it on IRC: > Oct 15 14:51:46 <ttarrant> darranl, if I issue a jmx query over jmx-remoting I get many more objects than expected > Oct 15 14:51:55 <ttarrant> darranl, i.e. ones that do not match the query > Oct 15 14:52:09 <ttarrant> darranl, this is with 7.1.x > Oct 15 14:52:57 <ttarrant> darranl, this works if I use the standard JMX over RMI > Oct 15 14:53:08 --> fnasser (~fnasser(a)CPE602ad07ab726-CM602ad07ab723.cpe.net.cable.rogers.com) has joined #jboss-as7 > Oct 15 14:53:09 <-- fnasser has quit (Changing host) > Oct 15 14:53:09 --> fnasser (~fnasser@redhat/jboss/fnasser) has joined #jboss-as7 > Oct 15 14:53:09 --- ChanServ gives voice to fnasser > Oct 15 14:53:16 <ttarrant> darranl, do you just pass the query the the mbeanserver ? > Oct 15 14:53:39 <darranl> ttarrant: what kind of objects? within AS7 I think there are two things that could affec > t this 1 - The Remoting JMX protocol, 2 - The domain management representation over JMX > Oct 15 14:53:54 <darranl> For #1 yes we just pass it to the MBEanServer and return whatever it returns > Oct 15 14:54:04 <darranl> if it was a Remoting JMX bug maybe we are messing up the query > Oct 15 14:54:16 <ttarrant> darranl, the query is as follows: *:type=CacheManager,component=Interpreter,name=* > Oct 15 14:54:16 <darranl> But not sure if #2 could be the reason more is getting added > Oct 15 14:54:32 <ttarrant> darranl, wait a sec > Oct 15 14:54:57 <darranl> ttarrant: I would suggest getting a Jira raised and assigned to me, I can verify if it i > s a remoting jmx issue or pass over if it is a domain management integration issue > Oct 15 14:55:20 <darranl> regardless of where it is happenign it sounds like you may have discovered a bug > Oct 15 14:56:23 <ttarrant> darranl, let me get the objects it's returning > Oct 15 14:56:39 <darranl> ttarrant: when you enable the RMI approach you bypass both Remoting JMX AND the domain m > anagement integration > Oct 15 14:56:42 <darranl> ok > Oct 15 15:26:08 <ttarrant> darranl, ok, my query actually returns the object I queried for and a bunch of org.jboss.as.controller.ModelController (one for each subsystem) > Oct 15 15:51:24 <darranl> ttarrant: ok that does then sound like it is the domain management integration that is 'poluting' the query results > Oct 15 15:51:53 <darranl> ttarrant: going RMI was just bypassing that as well > Oct 15 15:52:05 <ttarrant> darranl, shall I open a Jira ? > Oct 15 15:52:34 <ttarrant> darranl, I work around the issue by manually filtering the returned objects based on class name > Oct 15 15:53:23 <darranl> ttarrant: it would probably be one for kkhan to look into, think he is just back today so may be worth the Jira so he can have a look once he has caught back up ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-428) Move DC operation stream cleaning from OperationCoordinatorStepHandler and into the OSHs that actual process the input streams

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-428?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-428: ---------------------------------- Fix Version/s: 8.0.1.Final (was: 8.0.0.Final) > Move DC operation stream cleaning from OperationCoordinatorStepHandler and into the OSHs that actual process the input streams > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-428 > URL: https://issues.jboss.org/browse/WFLY-428 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.1.Final > > > Get rid of hackaliciousness at [1] and replace using OperationAttachments the way Stuart did for deployment overlays. > [1] https://github.com/jbossas/jboss-as/blob/master/host-controller/src/main/... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-142) inconsistent usage of min/max-occurs in model description

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-142?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-142: ---------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.CR1) (was: 8.0.0.Final) > inconsistent usage of min/max-occurs in model description > --------------------------------------------------------- > > Key: WFLY-142 > URL: https://issues.jboss.org/browse/WFLY-142 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Emanuel Muckenhuber > Fix For: 9.0.0.CR1 > > Attachments: patch.txt > > > The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation. > I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it. > [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2512) Transformers chained for versions

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2512?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2512: ----------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.Final) > Transformers chained for versions > --------------------------------- > > Key: WFLY-2512 > URL: https://issues.jboss.org/browse/WFLY-2512 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 9.0.0.CR1 > > > Say you have a subsystem with model versions 1.0, 1.1 and currently 2.0. > At present we register a transformer doing everything that needs doing from 2.0 to 1.1, and another one duplicating all that with everything that needs doing from 1.1 to 1.0. As more model versions are added, more transformers 'doing everything' are needed. > Richard and Tomaz have both come up with the same idea, to avoid this code duplication by only having transformers for each model version increment, and to chain them together, so you would have > * a transformer for 2.0 to 1.1 > * a transformer for 1.1 to 1.0 > Then if someone wanted to transform from 2.0 to 1.0 we would take the current model/operation and feed that into the 2.0-to-1.1 transformer, giving us the 1.1 model/operation. The 1.1 model/operation would then be fed into the 1.1-to-1.0 transformer giving us the 1.0 model/operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-543) Provide an operation to request service status report after server has been started

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-543?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-543: ---------------------------------- Fix Version/s: 9.0.0.CR1 (was: 8.0.0.Final) > Provide an operation to request service status report after server has been started > ------------------------------------------------------------------------------------- > > Key: WFLY-543 > URL: https://issues.jboss.org/browse/WFLY-543 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Heiko Braun > Labels: console_prio > Fix For: 9.0.0.CR1 > > > For proper healthcare it would beneficial if I could verify the server status after it has been started. I.e. to catch these, which currently only appear in the server log: > [Server:server-three] 17:48:26,636 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report > [Server:server-three] New missing/unsatisfied dependencies: > [Server:server-three] service jboss.binding.http2 (missing) > [Server:server-three] > [Server:server-three] 17:48:26,636 ERROR [org.jboss.as] (MSC service thread 1-4) JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 3893ms - Started 101 of 149 services (1 services failed or missing dependencies, 47 services are passive or on-demand) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 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 2014