February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6250) JMX inefficiently handles resource adapters

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-6250?page=com.atlassian.jira.plugin.... ] Stefano Maestri moved JBEAP-3513 to WFLY-6250: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6250 (was: JBEAP-3513) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA JMX (was: JCA) (was: JMX) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER5) > JMX inefficiently handles resource adapters > ------------------------------------------- > > Key: WFLY-6250 > URL: https://issues.jboss.org/browse/WFLY-6250 > Project: WildFly > Issue Type: Bug > Components: JCA, JMX > Affects Versions: 10.0.0.Final > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Attachments: README.txt, xaa, xab, xac, xad > > > If you connect to JBoss over JMX when it has many rars deployed (over 500), long running high CPU is seen in the following calls: > {code} > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:188) > at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) > at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) > {code} > It's evident that it is iterating over each deployment (each resource adapter counting as a deployment), but for each deployment, it is also iterating over all resource adapter's and their config properties. So it would iterate over all 500+ resource adapters once for each deployment, so it iterates over all 500 adapters at least 500 times. Is there anyway we could avoid that n^2 iteration for deployed rars? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-162) JAXWS SPI Provider should call ServiceLoader's load method within a privileged block

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBEE-162?page=com.atlassian.jira.plugin.s... ] Ivo Studensky updated JBEE-162: ------------------------------- Git Pull Request: https://github.com/jboss/jboss-jaxws-api_spec/pull/4 > JAXWS SPI Provider should call ServiceLoader's load method within a privileged block > ------------------------------------------------------------------------------------ > > Key: JBEE-162 > URL: https://issues.jboss.org/browse/JBEE-162 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-jaxws-api > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > The JAXWS SPI {{Provider}} uses {{ServiceLoader}} to look for user specified provider implementations. When invoking {{load}} method on the {{ServiceLoader}}, read permission on the relevant jar is required. > stacktrace: > {noformat} > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/studensky/work/git/jboss-eap-myfork5/dist/target/wildfly-10.0.0.Final-SNAPSHOT/modules/system/layers/base/org/jboss/ws/cxf/jbossws-cxf-factories/main/jbossws-cxf-factories-5.1.2.Final.jar" "read")" in code source "(vfs:/content/ws-serviceref-example.jar <no signer certificates>)" of "null") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) > at java.lang.SecurityManager.checkRead(SecurityManager.java:888) > at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377) > at java.util.zip.ZipFile.<init>(ZipFile.java:210) > at java.util.zip.ZipFile.<init>(ZipFile.java:149) > at java.util.jar.JarFile.<init>(JarFile.java:166) > at java.util.jar.JarFile.<init>(JarFile.java:103) > at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93) > at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) > at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99) > at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) > at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) > at java.net.URL.openStream(URL.java:1045) > at java.util.ServiceLoader.parse(ServiceLoader.java:304) > at java.util.ServiceLoader.access$200(ServiceLoader.java:185) > at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) > at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) > at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) > at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) > at javax.xml.ws.spi.Provider$1.run(Provider.java:154) > at javax.xml.ws.spi.Provider$1.run(Provider.java:152) > at java.security.AccessController.doPrivileged(Native Method) > at javax.xml.ws.spi.Provider.getProviderUsingServiceLoader(Provider.java:152) > at javax.xml.ws.spi.Provider.provider(Provider.java:108) > ... 102 more > {noformat} > Note: {{java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)}} calls {{doPrivileged}} block with an {{AccessControlContext}} cached from the {{load}} method invocation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBEE-162) JAXWS SPI Provider should call ServiceLoader's load method within a privileged block

by Ivo Studensky (JIRA)

Ivo Studensky created JBEE-162: ---------------------------------- Summary: JAXWS SPI Provider should call ServiceLoader's load method within a privileged block Key: JBEE-162 URL: https://issues.jboss.org/browse/JBEE-162 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jaxws-api Reporter: Ivo Studensky Assignee: Ivo Studensky The JAXWS SPI {{Provider}} uses {{ServiceLoader}} to look for user specified provider implementations. When invoking {{load}} method on the {{ServiceLoader}}, read permission on the relevant jar is required. stacktrace: {noformat} Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/studensky/work/git/jboss-eap-myfork5/dist/target/wildfly-10.0.0.Final-SNAPSHOT/modules/system/layers/base/org/jboss/ws/cxf/jbossws-cxf-factories/main/jbossws-cxf-factories-5.1.2.Final.jar" "read")" in code source "(vfs:/content/ws-serviceref-example.jar <no signer certificates>)" of "null") at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377) at java.util.zip.ZipFile.<init>(ZipFile.java:210) at java.util.zip.ZipFile.<init>(ZipFile.java:149) at java.util.jar.JarFile.<init>(JarFile.java:166) at java.util.jar.JarFile.<init>(JarFile.java:103) at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:93) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) at java.net.URL.openStream(URL.java:1045) at java.util.ServiceLoader.parse(ServiceLoader.java:304) at java.util.ServiceLoader.access$200(ServiceLoader.java:185) at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357) at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323) at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396) at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395) at java.security.AccessController.doPrivileged(Native Method) at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398) at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474) at javax.xml.ws.spi.Provider$1.run(Provider.java:154) at javax.xml.ws.spi.Provider$1.run(Provider.java:152) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.ws.spi.Provider.getProviderUsingServiceLoader(Provider.java:152) at javax.xml.ws.spi.Provider.provider(Provider.java:108) ... 102 more {noformat} Note: {{java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)}} calls {{doPrivileged}} block with an {{AccessControlContext}} cached from the {{load}} method invocation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6249) Upgrade to RESTEasy to 3.0.16.Final

by Weinan Li (JIRA)

Weinan Li created WFLY-6249: ------------------------------- Summary: Upgrade to RESTEasy to 3.0.16.Final Key: WFLY-6249 URL: https://issues.jboss.org/browse/WFLY-6249 Project: WildFly Issue Type: Component Upgrade Components: REST Affects Versions: 10.0.0.Final Reporter: Weinan Li Assignee: Stuart Douglas Fix For: 10.1.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-423) SSL Cache Size and SSL Sessions Timeout

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-423: ------------------------------------ Summary: SSL Cache Size and SSL Sessions Timeout Key: ELY-423 URL: https://issues.jboss.org/browse/ELY-423 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta4 Can either of these two be managed from our wrapper around the SSLContext? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-405: -------------------------------- Note by Darran: The Apache directory studio project by default uses entries with the appropriate objectClass and attributes on entires so may be a good starting point to check for standards > Add a KeyStore implementation backed by LDAP > -------------------------------------------- > > Key: ELY-405 > URL: https://issues.jboss.org/browse/ELY-405 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > > It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this. > LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated. > Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server. > In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered. > The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-405: ------------------------------ Assignee: Jan Kalina > Add a KeyStore implementation backed by LDAP > -------------------------------------------- > > Key: ELY-405 > URL: https://issues.jboss.org/browse/ELY-405 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 2.0.0.Alpha1 > > > It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this. > LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated. > Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server. > In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered. > The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6104) Too many invocations to a remote EJB from multiple threads cause infinite wait

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6104: ----------------------------------------------- Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 1302181|https://bugzilla.redhat.com/show_bug.cgi?id=1302181] from ASSIGNED to POST > Too many invocations to a remote EJB from multiple threads cause infinite wait > ------------------------------------------------------------------------------ > > Key: WFLY-6104 > URL: https://issues.jboss.org/browse/WFLY-6104 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1302181 > While a thread (1) of EJB client invokes a remote EJB which needs long > processing time and wait for the response, if the other threads complete > more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like > below occurs in EJB client side and the waiting thread (1) falls into > infinite wait for the response. > INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no > waiting context found > All invocations should successfully complete regardless of the number of > invocations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6211) Upgrade HAL to 2.8.21.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-6211?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-6211: ------------------------------ Summary: Upgrade HAL to 2.8.21.Final (was: Upgrade HAL to 2.8.20.Final) > Upgrade HAL to 2.8.21.Final > --------------------------- > > Key: WFLY-6211 > URL: https://issues.jboss.org/browse/WFLY-6211 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 10.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6241) Setting of non-existing factory class to connector service can cause ActiveMQ crash

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-6241?page=com.atlassian.jira.plugin.... ] Lin Gao updated WFLY-6241: -------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8710 > Setting of non-existing factory class to connector service can cause ActiveMQ crash > ----------------------------------------------------------------------------------- > > Key: WFLY-6241 > URL: https://issues.jboss.org/browse/WFLY-6241 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Critical > > When setting non-existing factory class to connector service, no validation is done and during startup after reload service will fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 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 2016