[JBoss JIRA] (WFLY-9164) ResourceAdapterPoolAttributesTestCase fails with security manage
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9164?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9164:
-------------------------------
Assignee: Chao Wang
> ResourceAdapterPoolAttributesTestCase fails with security manage
> ----------------------------------------------------------------
>
> Key: WFLY-9164
> URL: https://issues.jboss.org/browse/WFLY-9164
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> ResourceAdapterPoolAttributesTestCase fails with security manage
> {code}
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local8056268563783903312.challenge" "read")" in code source "(vfs:/content/pool-attributes-test.rar/pool-attributes-test.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.pool-attributes-test.rar" from Service Module Loader")
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:400)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:504)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:492)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118)
> ... 162 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9165) TransactionScopedJMSContextTestCase fails with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9165?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9165:
-------------------------------
Assignee: Chao Wang
> TransactionScopedJMSContextTestCase fails with security manager
> ---------------------------------------------------------------
>
> Key: WFLY-9165
> URL: https://issues.jboss.org/browse/WFLY-9165
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> TransactionScopedJMSContextTestCase fails with security manager
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")" in code source "(vfs:/content/TransactionScopedJMSContextTestCase.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.TransactionScopedJMSContextTestCase.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at org.wildfly.security.auth.server.SecurityDomain.getCurrent(SecurityDomain.java:160)
> at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory.createThread(ElytronManagedThreadFactory.java:48)
> at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl.newThread(ManagedThreadFactoryImpl.java:127)
> at org.jboss.as.test.integration.messaging.jms.context.transactionscoped.auxiliary.ThreadLauncher.start(ThreadLauncher.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:90)
> at org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:101)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:135)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> ... 180 more
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3186) Query MBean names takes forever when having many loggers and many classes
by Steffen Czymmeck (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3186?page=com.atlassian.jira.plugi... ]
Steffen Czymmeck commented on WFCORE-3186:
------------------------------------------
[~jamezp] I encountered this while migrating a big application from an older JBoss version to WildFly. I guess we could reduce the number of configured loggers, but even with only a few it's still pretty slow compared to JBoss 5, where you could query MBean names nearly instantaneously.
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFCORE-3186
> URL: https://issues.jboss.org/browse/WFCORE-3186
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9184) MultipleClientRemoteJndiTestCase fails with security manager
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-9184?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-9184:
-------------------------------
Assignee: Chao Wang
> MultipleClientRemoteJndiTestCase fails with security manager
> ------------------------------------------------------------
>
> Key: WFLY-9184
> URL: https://issues.jboss.org/browse/WFLY-9184
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Hynek Švábek
> Assignee: Chao Wang
>
> {code}
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local4252553253196379397.challenge" "read")" in code source "(vfs:/content/one.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.one.war" from Service Module Loader")
> at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:109)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:440)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:571)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:542)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:508)
> at org.jboss.remoting3.ConnectionInfo$None.getConnection(ConnectionInfo.java:83)
> at org.jboss.remoting3.ConnectionInfo.getConnection(ConnectionInfo.java:56)
> at org.jboss.remoting3.EndpointImpl.doGetConnection(EndpointImpl.java:459)
> at org.jboss.remoting3.EndpointImpl.getConnectedIdentity(EndpointImpl.java:405)
> at org.wildfly.naming.client.remote.SingleRemoteNamingProvider.lambda$new$0(SingleRemoteNamingProvider.java:82)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.naming.client.remote.SingleRemoteNamingProvider.getFuturePeerIdentity(SingleRemoteNamingProvider.java:117)
> at org.wildfly.naming.client.remote.SingleRemoteNamingProvider.getPeerIdentity(SingleRemoteNamingProvider.java:106)
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:65)
> ... 52 more
> Suppressed: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/hsvabek/securityworkspace/VERIFICATION/2017_08_02_BEAP-7584/jboss-eap-7.1.0.ER3-src/testsuite/integration/basic/target/jbossas/standalone/tmp/auth/local4252553253196379397.challenge" "read")" in code source "(vfs:/content/one.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.one.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> 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:350)
> at java.io.FileInputStream.<init>(FileInputStream.java:127)
> at org.wildfly.security.sasl.localuser.LocalUserClient.evaluateMessage(LocalUserClient.java:93)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.util.AbstractSaslClient.evaluateChallenge(AbstractSaslClient.java:59)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication.lambda$handleEvent$0(ClientConnectionOpenListener.java:644)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9230) ServletPrintWriter.checkError does not flush
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9230?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-9230:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> ServletPrintWriter.checkError does not flush
> --------------------------------------------
>
> Key: WFLY-9230
> URL: https://issues.jboss.org/browse/WFLY-9230
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: tony weston
> Assignee: Stuart Douglas
> Priority: Minor
>
> io.undertow.servlet.spec.ServletPrintWriter.checkError() does not flush the stream.
> according to JDK docs, printWriter.checkError() 'Flushes the stream if it's not closed and checks its error state'. This bug discovered by accident when converting a Payara to wildfly, which used checkError to flush the stream, and check errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9230) ServletPrintWriter.checkError does not flush
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9230?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-9230:
---------------------------------
Component/s: Web (Undertow)
> ServletPrintWriter.checkError does not flush
> --------------------------------------------
>
> Key: WFLY-9230
> URL: https://issues.jboss.org/browse/WFLY-9230
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: tony weston
> Assignee: Stuart Douglas
> Priority: Minor
>
> io.undertow.servlet.spec.ServletPrintWriter.checkError() does not flush the stream.
> according to JDK docs, printWriter.checkError() 'Flushes the stream if it's not closed and checks its error state'. This bug discovered by accident when converting a Payara to wildfly, which used checkError to flush the stream, and check errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ELY-1330) Elytron GS2-KRB5 SASL mechanism (non-PLUS) is allowed even if the channel binding is possible
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1330?page=com.atlassian.jira.plugin.s... ]
Farah Juma reassigned ELY-1330:
-------------------------------
Assignee: Farah Juma (was: Darran Lofthouse)
> Elytron GS2-KRB5 SASL mechanism (non-PLUS) is allowed even if the channel binding is possible
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1330
> URL: https://issues.jboss.org/browse/ELY-1330
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Farah Juma
> Priority: Blocker
>
> Using GS2-KRB5-PLUS mechanism should be forced when channel binding is possible (server-ssl-context is used) and GS2-KRB5 should not be allowed in such case.
> Currently the GS2-KRB5 authentication passes even if the SSL server context is used (channel binding possible).
> This is a follow up to JBEAP-11396 and JBEAP-12231 which were aimed on SCRAM PLUS mechanisms. Most of the related discussion takes place on JBEAP-11396.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3186) Query MBean names takes forever when having many loggers and many classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3186?page=com.atlassian.jira.plugi... ]
James Perkins moved WFLY-9222 to WFCORE-3186:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-3186 (was: WFLY-9222)
Component/s: JMX
Logging
(was: JMX)
(was: Logging)
Affects Version/s: (was: 10.1.0.Final)
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFCORE-3186
> URL: https://issues.jboss.org/browse/WFCORE-3186
> Project: WildFly Core
> Issue Type: Bug
> Components: JMX, Logging
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9222) Query MBean names takes forever when having many loggers and many classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9222?page=com.atlassian.jira.plugin.... ]
James Perkins edited comment on WFLY-9222 at 8/15/17 6:05 PM:
--------------------------------------------------------------
It looks like it has to do with the number of deployments and the size of the logging subsystem. Since there are 100 deployments each deployment essentially gets the logging subsystem copied to the deployments runtime resource, {{/deployment=*/subsystem=logging}} and {{/deployment=*/subdeployment=*/subsystem=logging}}.
I'm not really sure what the best solution would be here. I'm not even sure how likely it would be for so many loggers to be defined and so many deployments deployed on a single server.
{code:title=Example}
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar043.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.234
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar090.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.76
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar039.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.111
jboss.as:deployment=manyClasses.ear,subdeployment=jar048.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.176
jboss.as:deployment=manyClasses.ear,subdeployment=jar027.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.188
jboss.as:deployment=manyClasses.ear,subdeployment=jar076.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.132
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar029.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.199
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar000.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.26
jboss.as:deployment=manyClasses.ear,subdeployment=jar079.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.150
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar071.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.169
{code}
was (Author: jamezp):
It looks like it has to do with the number of deployments and the size of the logging subsystem. Since there are 100 deployments each deployment essentially gets the logging subsystem copied to the deployments runtime resource, {{/deployment=*/subsystem=logging}} and {{/deployment=*/subdeployment=*/subsystem=logging}}.
I'm not really sure what the best solution would be here. I'm not even sure how likely it would be for so many loggers to be defined and so many deployments deployed on a single server.
{code:title=Example}
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar043.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.234
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar090.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.76
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar039.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.111
jboss.as:deployment=manyClasses.ear,subdeployment=jar048.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.176
jboss.as:deployment=manyClasses.ear,subdeployment=jar027.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.188
jboss.as:deployment=manyClasses.ear,subdeployment=jar076.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.132
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar029.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.199
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar000.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.26
jboss.as:deployment=manyClasses.ear,subdeployment=jar079.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.150
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar071.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.169
{code}
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFLY-9222
> URL: https://issues.jboss.org/browse/WFLY-9222
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Logging
> Affects Versions: 10.1.0.Final
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (WFLY-9222) Query MBean names takes forever when having many loggers and many classes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9222?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-9222:
-------------------------------------
It looks like it has to do with the number of deployments and the size of the logging subsystem. Since there are 100 deployments each deployment essentially gets the logging subsystem copied to the deployments runtime resource, {{/deployment=*/subsystem=logging}} and {{/deployment=*/subdeployment=*/subsystem=logging}}.
I'm not really sure what the best solution would be here. I'm not even sure how likely it would be for so many loggers to be defined and so many deployments deployed on a single server.
{code:title=Example}
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar043.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.234
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar090.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.76
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar039.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.111
jboss.as:deployment=manyClasses.ear,subdeployment=jar048.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.176
jboss.as:deployment=manyClasses.ear,subdeployment=jar027.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.188
jboss.as:deployment=manyClasses.ear,subdeployment=jar076.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.132
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar029.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.199
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar000.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.26
jboss.as:deployment=manyClasses.ear,subdeployment=jar079.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.150
jboss.as.expr:deployment=manyClasses.ear,subdeployment=jar071.jar,subsystem=logging,configuration=default,logger=org.jboss.examples.169
{code}
> Query MBean names takes forever when having many loggers and many classes
> -------------------------------------------------------------------------
>
> Key: WFLY-9222
> URL: https://issues.jboss.org/browse/WFLY-9222
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Logging
> Affects Versions: 10.1.0.Final
> Environment: Windows 7 and Windows 10
> Reporter: Steffen Czymmeck
> Attachments: manyClasses.ear, standalone.xml
>
>
> If you configure many loggers (~300) and deploy a rather big ear with many classes, it takes forever to query mbean names with
> javax.management.MBeanServer#queryNames or via. jconsoles MBeans tab.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months