April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1505) Missing services for outbound socket bindings on the HC

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-1505: ---------------------------------- Summary: Missing services for outbound socket bindings on the HC Key: WFCORE-1505 URL: https://issues.jboss.org/browse/WFCORE-1505 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Kabir Khan Assignee: Brian Stansberry Fix For: 3.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1504) Add /core-service=service-container resource to host model

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-1504: ---------------------------------- Summary: Add /core-service=service-container resource to host model Key: WFCORE-1504 URL: https://issues.jboss.org/browse/WFCORE-1504 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Kabir Khan Assignee: Brian Stansberry Fix For: 3.0.0.Alpha1 {quote} Kabir Khan·17:30 @BrianStansberry I'm replying to mazz Just trying to dump services though, is there any reason why we have /core-service=service-container on a server, but no /host=master/core-service=service-container on a HC? Brian Stansberry·17:37 @KabirKhan I don't think so for some reason I was poking at that a few days ago and I couldn't find any reason why not Kabir Khan·17:37 I'll add a Jira Brian Stansberry·17:37 I think it's something historical that no longer applies Kabir Khan·17:37 Probably just an oversight we had jconsole all the time and probably enhanced this for servers at some stage Brian Stansberry·17:38 I'm quite certain I put that TODO in there and there was a real reason at the time Kabir Khan·17:38 where is the TODO? Brian Stansberry·17:40 @KabirKhan https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m... {quote} So we should a) investigate if this is possible or not b) Make it happen if it is -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1503) Reading the logging subsystem resource can be slow if several log files exist

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1503?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1503: --------------------------------------- This also affects MBeans as it looks like the resource tree is read. The {{ModelControllerMBeanServerPlugin.queryNames()}} reads resources. The logging resource definitely needs to be fixed. This could be any issue with any other dynamic resources as well. > Reading the logging subsystem resource can be slow if several log files exist > ----------------------------------------------------------------------------- > > Key: WFCORE-1503 > URL: https://issues.jboss.org/browse/WFCORE-1503 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The logging subsystem uses a dynamic resource to list log files as resources. These are the files that are allowed to be read or downloaded and are attached to known file handlers. > When several file handlers are defined the file tree walker is invoked several times per {{read-resource-operation}}. This may be happening for each stage of an operation. Ideally we could either cache the file listing per-operation or only execute at the runtime stage. This may not be an option for dynamic resources however. > As a result of this poor performance the web console is very slow to load the logging subsystem configuration. This is not an issue with the web console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1503) Reading the logging subsystem resource can be slow if several log files exist

by James Perkins (JIRA)

James Perkins created WFCORE-1503: ------------------------------------- Summary: Reading the logging subsystem resource can be slow if several log files exist Key: WFCORE-1503 URL: https://issues.jboss.org/browse/WFCORE-1503 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins The logging subsystem uses a dynamic resource to list log files as resources. These are the files that are allowed to be read or downloaded and are attached to known file handlers. When several file handlers are defined the file tree walker is invoked several times per {{read-resource-operation}}. This may be happening for each stage of an operation. Ideally we could either cache the file listing per-operation or only execute at the runtime stage. This may not be an option for dynamic resources however. As a result of this poor performance the web console is very slow to load the logging subsystem configuration. This is not an issue with the web console. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6553) -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6553?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6553: --------------------------------- Description: https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... org.jboss.as.test.clustering.cluster.singleton (6) SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test SingletonDeploymentDescriptorTestCase(ASYNC-udp).test SingletonDeploymentDescriptorTestCase(SYNC-udp).test SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test SingletonDeploymentJBossAllTestCase(ASYNC-udp).test SingletonDeploymentJBossAllTestCase(SYNC-udp).test seems to have been caused by https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... https://github.com/wildfly/wildfly-core/commits/2.1.0.Final was: https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... org.jboss.as.test.clustering.cluster.singleton (6) SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test SingletonDeploymentDescriptorTestCase(ASYNC-udp).test SingletonDeploymentDescriptorTestCase(SYNC-udp).test SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test SingletonDeploymentJBossAllTestCase(ASYNC-udp).test SingletonDeploymentJBossAllTestCase(SYNC-udp).test seems to have been caused by https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... > -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6553 > URL: https://issues.jboss.org/browse/WFLY-6553 > Project: WildFly > Issue Type: Quality Risk > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... > org.jboss.as.test.clustering.cluster.singleton (6) > SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test > SingletonDeploymentDescriptorTestCase(ASYNC-udp).test > SingletonDeploymentDescriptorTestCase(SYNC-udp).test > SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test > SingletonDeploymentJBossAllTestCase(ASYNC-udp).test > SingletonDeploymentJBossAllTestCase(SYNC-udp).test > seems to have been caused by > https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... > https://github.com/wildfly/wildfly-core/commits/2.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6553) -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6553?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6553: --------------------------------- Description: https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... org.jboss.as.test.clustering.cluster.singleton (6) SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test SingletonDeploymentDescriptorTestCase(ASYNC-udp).test SingletonDeploymentDescriptorTestCase(SYNC-udp).test SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test SingletonDeploymentJBossAllTestCase(ASYNC-udp).test SingletonDeploymentJBossAllTestCase(SYNC-udp).test seems to have been caused by https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... changelog https://github.com/wildfly/wildfly-core/commits/2.1.0.Final was: https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... org.jboss.as.test.clustering.cluster.singleton (6) SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test SingletonDeploymentDescriptorTestCase(ASYNC-udp).test SingletonDeploymentDescriptorTestCase(SYNC-udp).test SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test SingletonDeploymentJBossAllTestCase(ASYNC-udp).test SingletonDeploymentJBossAllTestCase(SYNC-udp).test seems to have been caused by https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... https://github.com/wildfly/wildfly-core/commits/2.1.0.Final > -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6553 > URL: https://issues.jboss.org/browse/WFLY-6553 > Project: WildFly > Issue Type: Quality Risk > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > > https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... > org.jboss.as.test.clustering.cluster.singleton (6) > SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test > SingletonDeploymentDescriptorTestCase(ASYNC-udp).test > SingletonDeploymentDescriptorTestCase(SYNC-udp).test > SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test > SingletonDeploymentJBossAllTestCase(ASYNC-udp).test > SingletonDeploymentJBossAllTestCase(SYNC-udp).test > seems to have been caused by > https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... > changelog > https://github.com/wildfly/wildfly-core/commits/2.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6553) -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6553: ------------------------------------ Summary: -DextendedTests: SingletonDeploymentDescriptorTestCase/SingletonDeploymentJBossAllTestCase started failing consistently after core 2.1.0.Final upgrade Key: WFLY-6553 URL: https://issues.jboss.org/browse/WFLY-6553 Project: WildFly Issue Type: Quality Risk Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Paul Ferraro https://ci.wildfly.org/viewLog.html?buildId=13580&tab=buildResultsDiv&bui... org.jboss.as.test.clustering.cluster.singleton (6) SingletonDeploymentDescriptorTestCase(ASYNC-tcp).test SingletonDeploymentDescriptorTestCase(ASYNC-udp).test SingletonDeploymentDescriptorTestCase(SYNC-udp).test SingletonDeploymentJBossAllTestCase(ASYNC-tcp).test SingletonDeploymentJBossAllTestCase(ASYNC-udp).test SingletonDeploymentJBossAllTestCase(SYNC-udp).test seems to have been caused by https://github.com/wildfly/wildfly/commit/fb0bad069826c67e10226625933150a... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-6540: ------------------------------------ [~dmlloyd] Yep, it seems EJB subsystem is also using {{UnboundedQueueThreadPoolService}}. On the other hand, I'm not quite sure we should mark this as duplicate. > Batch thread pool keepAlive setting seems to be ignored > ------------------------------------------------------- > > Key: WFLY-6540 > URL: https://issues.jboss.org/browse/WFLY-6540 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.0.0.Final > Reporter: Martin Kouba > Assignee: James Perkins > > Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce. > Snippet from the default config file: > {code} > <thread-pool name="batch"> > <max-threads count="10"/> > <keepalive-time time="30" unit="seconds"/> > </thread-pool> > {code} > Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used. > Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop: > {code} > public void setAllowCoreThreadTimeout(final boolean allow) { > setAllowCoreThreadTimeout(allow); > } > {code} > should be replaced with: > {code} > public void setAllowCoreThreadTimeout(final boolean allow) { > allowCoreThreadTimeOut(allow); > } > {code} > Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-160?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar resolved JBEE-160. ------------------------------ Fix Version/s: No Release Resolution: Done fixed in 1.0.1.Final which was already released to maven repository. > jboss-transaction-api OSGi bundle requiring optional packages > ------------------------------------------------------------- > > Key: JBEE-160 > URL: https://issues.jboss.org/browse/JBEE-160 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-transaction-api > Reporter: Brett Meyer > Assignee: Tomaz Cerar > Fix For: No Release > > > The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-6540: ----------------------------------- I think this is a duplicate of WFLY-5332. > Batch thread pool keepAlive setting seems to be ignored > ------------------------------------------------------- > > Key: WFLY-6540 > URL: https://issues.jboss.org/browse/WFLY-6540 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 10.0.0.Final > Reporter: Martin Kouba > Assignee: James Perkins > > Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce. > Snippet from the default config file: > {code} > <thread-pool name="batch"> > <max-threads count="10"/> > <keepalive-time time="30" unit="seconds"/> > </thread-pool> > {code} > Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used. > Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop: > {code} > public void setAllowCoreThreadTimeout(final boolean allow) { > setAllowCoreThreadTimeout(allow); > } > {code} > should be replaced with: > {code} > public void setAllowCoreThreadTimeout(final boolean allow) { > allowCoreThreadTimeOut(allow); > } > {code} > Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

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 April 2016