[JBoss JIRA] (WFCORE-553) ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-553?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-553:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1199319|https://bugzilla.redhat.com/show_bug.cgi?id=1199319] from POST to MODIFIED
> ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-553
> URL: https://issues.jboss.org/browse/WFCORE-553
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha18
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> ModelControllerClientOperationHandler's constructor creates a ThreadPoolExecutor for handling client requests and then the class doesn't clean it up.
> In addition, an instance of ModelControllerClientOperationHandler is created per channel, not one per ModelControllerClientOperationHandlerFactoryService. I know I at least thought of the thread pool as being per remote management interface, not per channel.
> Making it be per ModelControllerClientOperationHandlerFactoryService and cleaning it up in that service's stop would be the easiest fix, but the pool settings may not be appropriate if we do that, so tread carefully.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (WFLY-4572) wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4572?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-4572:
------------------------------
Summary: wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository (was: wildfly-parent manages dependency slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository)
> wildfly-arquillian uses slf4j-api:1.7.7.jbossorg-1 which is not available in maven central repository
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-4572
> URL: https://issues.jboss.org/browse/WFLY-4572
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.2.0.Final, 9.0.0.Beta2
> Reporter: Martin Kouba
> Assignee: Paul Gier
>
> GAV: {{org.slf4j:slf4j-api:1.7.7.jbossorg-1}}
> As a result, it's not possible to build a project which depends on some referencing module, e.g. {{wildfly-arquillian-common}}, and does not define JBoss repository at the same time.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (WFLY-2807) Messaging subsystem runtime-queue resource is not registered as "runtime-only"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2807?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-2807:
--------------------------------------
Assignee: Kabir Khan (was: Brian Stansberry)
Resolution: Done
> Messaging subsystem runtime-queue resource is not registered as "runtime-only"
> ------------------------------------------------------------------------------
>
> Key: WFLY-2807
> URL: https://issues.jboss.org/browse/WFLY-2807
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMS
> Affects Versions: 8.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
> Fix For: 9.0.0.CR1
>
>
> The runtime-queue resource only exists at runtime but isn't registered as such. I noticed this as ManagementClient does a recursive read-resource of the entire tree, but with include-runtime=false, but a CI run showed a failure reading one of these resources anyway:
> ```
> 21:01:01,754 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014613: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "messaging"),
> ("hornetq-server" => "default"),
> ("runtime-queue" => "jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5")
> ]) - failure description: "JBAS011676: No resource exists at address [
> (\"subsystem\" => \"messaging\"),
> (\"hornetq-server\" => \"default\"),
> (\"runtime-queue\" => \"jms.tempqueue.661a6b15-7863-4d6c-b4b1-f8d62d294ea5\")
> ]"
> ```
> Doing read-resource with these is a bit problematic in any case, since a bunch of read-attribute calls get executed as steps (that's what the above was) but the resource can disappear in the middle. But that's a separate problem.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months