January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment

by Vratislav Marek (JIRA)

Vratislav Marek created WFCORE-3566: --------------------------------------- Summary: Different results of disabling commands already disabled deployment Key: WFCORE-3566 URL: https://issues.jboss.org/browse/WFCORE-3566 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Vratislav Marek Assignee: Jean-Francois Denise *Different command result in standalone and domain mode* * In standalone return {noformat} WFLYCTL0155: 'steps' may not be null {noformat} * In domain return nothing, no warning or error {noformat} [standalone@localhost:9990 /] deployment info NAME RUNTIME-NAME PERSISTENT ENABLED STATUS cli-test-another-deploy.war cli-test-another-deploy.war true true OK cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war WFLYCTL0155: 'steps' may not be null [standalone@localhost:9990 /] {noformat} {noformat} [domain@localhost:9990 /] deployment info --server-groups=main-server-group NAME RUNTIME-NAME STATE cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war [domain@localhost:9990 /] {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment

by Vratislav Marek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ] Vratislav Marek updated WFCORE-3566: ------------------------------------ Description: *Different command result of in standalone and domain mode* * In standalone return {noformat} WFLYCTL0155: 'steps' may not be null {noformat} * In domain return nothing, no warning or error {noformat} [standalone@localhost:9990 /] deployment info NAME RUNTIME-NAME PERSISTENT ENABLED STATUS cli-test-another-deploy.war cli-test-another-deploy.war true true OK cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war WFLYCTL0155: 'steps' may not be null [standalone@localhost:9990 /] {noformat} {noformat} [domain@localhost:9990 /] deployment info --server-groups=main-server-group NAME RUNTIME-NAME STATE cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war [domain@localhost:9990 /] {noformat} was: *Different command result in standalone and domain mode* * In standalone return {noformat} WFLYCTL0155: 'steps' may not be null {noformat} * In domain return nothing, no warning or error {noformat} [standalone@localhost:9990 /] deployment info NAME RUNTIME-NAME PERSISTENT ENABLED STATUS cli-test-another-deploy.war cli-test-another-deploy.war true true OK cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war WFLYCTL0155: 'steps' may not be null [standalone@localhost:9990 /] {noformat} {noformat} [domain@localhost:9990 /] deployment info --server-groups=main-server-group NAME RUNTIME-NAME STATE cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war [domain@localhost:9990 /] {noformat} > Different results of disabling commands already disabled deployment > ------------------------------------------------------------------- > > Key: WFCORE-3566 > URL: https://issues.jboss.org/browse/WFCORE-3566 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Vratislav Marek > Assignee: Jean-Francois Denise > > *Different command result of in standalone and domain mode* > * In standalone return > {noformat} > WFLYCTL0155: 'steps' may not be null > {noformat} > * In domain return nothing, no warning or error > {noformat} > [standalone@localhost:9990 /] deployment info > NAME RUNTIME-NAME PERSISTENT ENABLED STATUS > cli-test-another-deploy.war cli-test-another-deploy.war true true OK > cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED > cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK > [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war > WFLYCTL0155: 'steps' may not be null > [standalone@localhost:9990 /] > {noformat} > {noformat} > [domain@localhost:9990 /] deployment info --server-groups=main-server-group > NAME RUNTIME-NAME STATE > cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled > cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added > cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added > cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled > [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war > [domain@localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9742: ----------------------------------- I think there isn't one single perfect answer, but the best answer is probably to clear TCCL in JBoss Threads. The inherited TCCL behavior is usually not helpful, especially for pooled threads. > ClassLoader leak in JBoss Threads caused by MDBs > ------------------------------------------------ > > Key: WFLY-9742 > URL: https://issues.jboss.org/browse/WFLY-9742 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Final > Reporter: Markus Dlugi > Assignee: Jason Greene > Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip > > > There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread. > In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments. > As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3565) RequestController ignores queued tasks if max requests is configured

by Christoph Böhme (JIRA)

Christoph Böhme created WFCORE-3565: --------------------------------------- Summary: RequestController ignores queued tasks if max requests is configured Key: WFCORE-3565 URL: https://issues.jboss.org/browse/WFCORE-3565 Project: WildFly Core Issue Type: Bug Affects Versions: 4.0.0.Alpha7, 3.0.8.Final Reporter: Christoph Böhme We encountered an issue with EJB timers stopping randomly if the container is under load. Sometimes the timers get stalled right after deployment without firing at all. Sometimes the timers work fine for a couple of days before they suddenly stop working. The timers are defined using the {{@Scheduled}} annotation. We found out that the reason for the randomly stopping timers is a bug in the {{RequestController}} class which only appears if a maximum number of requests is configured in the request controller subsystem. If a timer is being triggered while the container has reached the request limit then the timer is put into a task queue to be processed later. However, the task queue is never checked for queued tasks if the request number goes down again. This leaves the timers stuck in the queue. Since every timer needs to reregister after it has been triggered, the timers appear to have stopped. In old versions of the {{RequestController}} class from before release wildfly-core-1.0.0.Alpha14 it looks like the idea was to check for queued requests whenever a request finished (see [here|https://github.com/wildfly/wildfly-core/blob/a426a14db6466549159a552...]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-6463. ------------------------------- Resolution: Rejected Dropped. > Common Annotations 1.3 Support > ------------------------------ > > Key: WFLY-6463 > URL: https://issues.jboss.org/browse/WFLY-6463 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6457) JMS 2.1 Support

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6457?page=com.atlassian.jira.plugin.... ] David Lloyd resolved WFLY-6457. ------------------------------- Resolution: Rejected Dropped. > JMS 2.1 Support > --------------- > > Key: WFLY-6457 > URL: https://issues.jboss.org/browse/WFLY-6457 > Project: WildFly > Issue Type: Sub-task > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9634) Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-9634: ---------------------------------- [~ehugonnet] The mixed domain tests have been merged, so this is ready for investigation :) > Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0 > ----------------------------------------------------------------------- > > Key: WFLY-9634 > URL: https://issues.jboss.org/browse/WFLY-9634 > Project: WildFly > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Kabir Khan > Assignee: ehsavoie Hugonnet > Fix For: 12.0.0.Alpha1 > > > I have added an > {code} > // TODO WFLY-9634 > Assume.assumeFalse(supportManagedExplodedDeployment()); > {code} > to this test in https://github.com/wildfly/wildfly/pull/10730 which introduces the 7.1.0 mixed domain tests. See WFCORE-3479 for more details. > If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2248) SASL protocol should not pass null callbackhandlers to Factories

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2248: --------------------------- Fix Version/s: 4.0.10 > SASL protocol should not pass null callbackhandlers to Factories > ---------------------------------------------------------------- > > Key: JGRP-2248 > URL: https://issues.jboss.org/browse/JGRP-2248 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.0.9 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 4.0.10 > > > Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2248) SASL protocol should not pass null callbackhandlers to Factories

by Ryan Emerson (JIRA)

Ryan Emerson created JGRP-2248: ---------------------------------- Summary: SASL protocol should not pass null callbackhandlers to Factories Key: JGRP-2248 URL: https://issues.jboss.org/browse/JGRP-2248 Project: JGroups Issue Type: Enhancement Reporter: Ryan Emerson Assignee: Bela Ban Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2248) SASL protocol should not pass null callbackhandlers to Factories

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.... ] Ryan Emerson reassigned JGRP-2248: ---------------------------------- Assignee: Ryan Emerson (was: Bela Ban) > SASL protocol should not pass null callbackhandlers to Factories > ---------------------------------------------------------------- > > Key: JGRP-2248 > URL: https://issues.jboss.org/browse/JGRP-2248 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.0.9 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

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 January 2018