[JBoss JIRA] (WFCORE-3380) Elytron client + keystore which retrieve credential from credential store works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3380?page=com.atlassian.jira.plugi... ]
Hynek Švábek closed WFCORE-3380.
--------------------------------
Resolution: Won't Fix
I accidentally used credential store storage file created on Oracle JDK.
> Elytron client + keystore which retrieve credential from credential store works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3380
> URL: https://issues.jboss.org/browse/WFCORE-3380
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Elytron client + keystore which retrieve credential from credential store works fine when using OracleJDK and OpenJDK.
> Problem occurs when we use IBM JDK,
> {code}
> ./jboss-cli.sh -c -Dwildfly.config.url=path/to/wfly-config.xml
> java.lang.ExceptionInInitializerError: org.wildfly.client.config.ConfigXMLParseException: ELY01139: Failed to create credential store
> at file:///home/hsvabek/securityworkspace/VERIFICATION/2017_10_23_PKCS12/reproducer/wfly-config.xml:5:9: ELY01139: Failed to create credential store
> at file:///home/hsvabek/securityworkspace/VERIFICATION/2017_10_23_PKCS12/reproducer/wfly-config.xml:5:9: ELY09514: Unable to initialize credential store: com.sun.crypto.provider.SealedObjectForKeyProtector
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2225:
--------------------------------
We could check at initialization time (setting a flag) whether a protocol implements {{down(Message)}} but not {{down(MessageBatch)}} and throw an exception (bad!) or translate the batched {{down()}} method into multiple unbatches ones.
However, this still means we have to implement the batched {{down()}} method for almost all protocols, plus a single (e.g. new) protocol not doing this would break the batched down-chain...
I'm therefore currently leaning toward closing this JIRA...
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2225 at 10/25/17 6:29 AM:
----------------------------------------------------------
Hmm, quite an effort involved in this:
* All bundlers now have to handle an additional {{down(MessageBatch)}} method
* If the default impl of {{down(MessageBatch)}} in {{Protocol}} sends messages down one-by-one (calling {{down(Message)}}), then most batches will get sent down one-by-one, unless all protocols implement the {{down(MessageBatch)}} method
* If the default impl passes the batch down to the next protocol, then *all* protocols which implement {{down(Message)}} will also have to implement {{down(MessageBatch)}}, or else batches will be sent down unchanged -> this is incorrect
** This is *not* like {{up(MessageBatch)}} where the default impl removes messages from the batch relevant to it (calling {{up(Message)}} on them) and then passes the batch up, which is acceptable
** Also, if someone implements a new protocol and only overrides {{down()}}, but forgets to implement {{down(MessageBatch)}}, then the protocol will be incorrect!
[~pruivo] I think you'll have to send your ACKs to the same destination inside of a single {{Message}}, at least until I come up with a better idea on a default impl of {{down(MessageBatch)}} in {{Protocol}}...
was (Author: belaban):
Hmm, quite an effort involved in this:
* All bundlers now have to handle an additional {{down(MessageBatch)}} method
* If the default impl of {{down(MessageBatch)}} in {{Protocol}} sends messages down one-by-one (calling {{down(Message)}}), then most batches will get sent down one-by-one, unless all protocols implement the {{down(MessageBatch)}} method
* If the default impl passes the batch down to the next protocol, then *all* protocols which implement {{down(Message)}} will also have to implement {{down(MessageBatch)}}, or else batches will be sent down unchanged -> this is incorrect
** This is *not* like {{up(MessageBatch)}} where the default impl removes messages from the batch relevant to it (calling {{up(Message)}} on them) and then passes the batch up, which is acceptable
[~pruivo] I think you'll have to send your ACKs to the same destination inside of a single {{Message}}, at least until I come up with a better idea on a default impl of {{down(MessageBatch)}} in {{Protocol}}...
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2225:
--------------------------------
Hmm, quite an effort involved in this:
* All bundlers now have to handle an additional {{down(MessageBatch)}} method
* If the default impl of {{down(MessageBatch)}} in {{Protocol}} sends messages down one-by-one (calling {{down(Message)}}), then most batches will get sent down one-by-one, unless all protocols implement the {{down(MessageBatch)}} method
* If the default impl passes the batch down to the next protocol, then *all* protocols which implement {{down(Message)}} will also have to implement {{down(MessageBatch)}}, or else batches will be sent down unchanged -> this is incorrect
** This is *not* like {{up(MessageBatch)}} where the default impl removes messages from the batch relevant to it (calling {{up(Message)}} on them) and then passes the batch up, which is acceptable
[~pruivo] I think you'll have to send your ACKs to the same destination inside of a single {{Message}}, at least until I come up with a better idea on a default impl of {{down(MessageBatch)}} in {{Protocol}}...
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9464) Some XACML tests fail with security manager
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-9464?page=com.atlassian.jira.plugin.... ]
Yeray Borges reassigned WFLY-9464:
----------------------------------
Assignee: Yeray Borges
> Some XACML tests fail with security manager
> -------------------------------------------
>
> Key: WFLY-9464
> URL: https://issues.jboss.org/browse/WFLY-9464
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite, XML Frameworks
> Affects Versions: 11.0.0.Final
> Reporter: Ondrej Kotek
> Assignee: Yeray Borges
> Priority: Critical
> Labels: security-manager
>
> Some XACML tests fail with security manager, mostly because of missing permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")":
> {noformat}
> ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /custom-xacml-web-test/secured: java.lang.ExceptionInInitializerError
> at org.jboss.as.test.integration.security.xacml.CustomXACMLAuthorizationModule.<init>(CustomXACMLAuthorizationModule.java:68)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.instantiateModule(JBossAuthorizationContext.java:329)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.initializeModules(JBossAuthorizationContext.java:205)
> at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:141)
> at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:438)
> at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115)
> at org.jboss.security.plugins.javaee.WebAuthorizationHelper.checkResourcePermission(WebAuthorizationHelper.java:119)
> at org.wildfly.extension.undertow.security.JbossAuthorizationManager.canAccessResource(JbossAuthorizationManager.java:160)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:55)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/okotek/git/wildfly/dist/target/wildfly-11.0.0.Final-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.2.11.jbossorg-1.jar" "read")" in code source "(vfs:/content/custom-xacml-web-test.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.custom-xacml-web-test.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.util.zip.ZipFile.<init>(ZipFile.java:216)
> at java.util.zip.ZipFile.<init>(ZipFile.java:155)
> 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:84)
> 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 javax.xml.bind.ContextFinder.find(ContextFinder.java:292)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:412)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:375)
> at org.jboss.security.xacml.core.JBossPDP.<clinit>(JBossPDP.java:126)
> ... 55 more
> {noformat}
> Looks like a privileged block is missing. Hence Critical.
> After adding such permission, there are another permissions missing:
> * {{WebXACMLAuthorizationModuleTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}, {{ReflectPermission("suppressAccessChecks")}}, {{RuntimePermission("getClassLoader")}}
> * {{JBossPDPServletInitializationTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}
> * {{JBossPDPInteroperabilityTestCase}} -- additional file permissions, {{RuntimePermission("accessDeclaredMembers")}}, {{RuntimePermission("getClassLoader")}}, {{ReflectPermission("suppressAccessChecks")}}, {{PropertyPermission("user.dir", "read")}}
> * {{EjbXACMLAuthorizationModuleTestCase}} -- {{RuntimePermission("accessDeclaredMembers")}}, {{RuntimePermission("getClassLoader")}}, {{ReflectPermission("suppressAccessChecks")}}, {{ElytronPermission("getSecurityDomain")}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9408) Wildfly 10 - The cost of creating the first eclipselink EntityManager during deployment is extremelly high due to MBeanServer.getMbeanCount() cost
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9408?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-9408:
---------------------------------------------
Hi Just a very small update.
Right now I am taking a look of the deployment of the same application on a different AppServer.
In this case it would be Weblogic.
In weblogic there are also dedicated server platforms.
In particular, there is the:
org.eclipse.persistence.platform.server.wls.WebLogic_12_Platform
That extends
org.eclipse.persistence.platform.server.wls.WebLogic_10_Platform
And this 10_Platform class, does override the:
public MBeanServer getMBeanServer() {
and adpts it to a weblogic specific lookup approach.
But in any case, the implementation still has the:
mBeanServer.getMBeanCount()
Log statement in there.
So there is a substancial difference in the MBean echosystem performance, at least as far as this specific API is concerned.
In a debug break point where things tend to be slower when you step over statements, the return of this API is instantaneous.
It might be worth-while to perhaps consider accelrating the same API on wildfly, if posisble.
Kindest regards.
> Wildfly 10 - The cost of creating the first eclipselink EntityManager during deployment is extremelly high due to MBeanServer.getMbeanCount() cost
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9408
> URL: https://issues.jboss.org/browse/WFLY-9408
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
> Fix For: 12.0.0.Alpha1
>
>
> I have been trying to reduce the deployment of a WAR application.
> One of the greate bottlenecks on the deployment is the cost of getting the first EntityManager instance of eclipselink.
> To try to reduce cost of startup I found myself forced to during @Startup fire a CDI event observed by an @Asynchronous ejb whose only task is to do a dummy entityManager.flush().
> The results I had for the execution time of this observer could go as high as 13 seconds.
> On top of that, I had already noticed while writting an arquillian system test for eclipselink on:
> https://issues.jboss.org/browse/WFLY-8954
> that the cost of starting up elcipselink under wildfly was much much higher than that of Hibernate and OpenJPA.
> With this introduction done let us go to the facts, and they are quite ridiculous.
> I have sampled the deployment of an application from begging to end with a sampling script that took a thread dump every second to analyse where the app is spending deployment time generically.
> Eventually, I reached the eclipselink deployment.
> And I had entries on the log such as:
> DatabaseEntityManagerStarter] - <- StartupDatabaseEntityManagerStarter.observeApplicationReadyLoadEntityManagerEvent {5948 ms} <EJB aync-ejb-thread-pool - 1>
> While sampling why this was happening I got more than 7 straight thread dump samples (more than 7 seconds) where the following stack trace was present:
> {panel}
> at java.security.AccessController.getContext(Unknown Source)
> at org.jboss.as.controller.SecurityActions.getCaller(SecurityActions.java:47)
> at org.jboss.as.controller.AbstractOperationContext.getCaller(AbstractOperationContext.java:1138)
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1306)
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:128)
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:429)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1329)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:400)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:208)
> 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)
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:125)
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:161)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:545)
> ----- Because of the mBeanServer.getMBeanCount():
> getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_mbeanserver_print",
> new Object[]{mBeanServer, mBeanServer.getMBeanCount(), mBeanServer.getDefaultDomain(), 0});
>
>
> at org.eclipse.persistence.platform.server.JMXServerPlatformBase.getMBeanServer(JMXServerPlatformBase.java:271)
> at org.eclipse.persistence.platform.server.JMXServerPlatformBase.serverSpecificRegisterMBean(JMXServerPlatformBase.java:297)
> ---- Will register Managed beans under the prefix: TopLink:Name="
> at org.eclipse.persistence.platform.server.jboss.JBossPlatform.serverSpecificRegisterMBean(JBossPlatform.java:147)
> at org.eclipse.persistence.platform.server.ServerPlatformBase.registerMBean(ServerPlatformBase.java:581)
> ------- this.serverSpecificRegisterMBean();
> at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.postConnectDatasource(DatabaseSessionImpl.java:857)
> at org.eclipse.persistence.internal.sessions.DatabaseSessionImpl.loginAndDetectDatasource(DatabaseSessionImpl.java:762)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryProvider.login(EntityManagerFactoryProvider.java:265)
> at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:731)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
> - locked [0x00000000a90d1210] (a org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate)
> at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
> {panel}
> After chekcing the eclipselink source code associated to line:
> {panel}
> at org.eclipse.persistence.platform.server.JMXServerPlatformBase.getMBeanServer(JMXServerPlatformBase.java:271)
> {panel}
> I found the following source code - which I could hardly believe would explain this deployment bottleneck:
> {panel}
> } else {
> // Only a single MBeanServer instance was found
> getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_mbeanserver_print",
> new Object[]{mBeanServer, mBeanServer.getMBeanCount(), mBeanServer.getDefaultDomain(), 0});
> }
> {panel}
> In short, the first eclipselink entity manager cost of creation is a never ending task under wildfly because of how expensive the above log statement is:
> {panel}
> mBeanServer.getMBeanCount()
> {panel}
> I do not know how to interpret this.
> Is the problem that the API should cost ms and it literally takes several seconds to calculate - and the problem is the cost of the API under wildfly.
> Or is it that eclipselink should never have written such a log statement on the first place?
> To address the issue, I have hacked up my local:
> org.jipijapa.eclipselink.WildFlyServerPlatform
> In this class, I have override the getMeabServer API from the base class.
> I Have created a hacked constant:
> {panel}
> /**
> * During deployment, when the first entity manager is created, the
> * application deployment becomes extremelty slow due to the
> * MbeanServer.getbeanCount() access done by eclipselink. This access is on
> * top of all things done only for logging purposes. We completely kill the
> * call to the api.
> */
> private static final int MBEAN_SERVER_COUNT_DUMMY_VALUE = -999;
> {panel}
> And finally I added an overriden method:
> {panel}
> @Override
> public MBeanServer getMBeanServer() {
> /**
> * This function will attempt to get the MBeanServer via the
> * findMBeanServer spec call. 1) If the return list is null we attempt
> * to retrieve the PlatformMBeanServer (if it exists or is enabled in
> * this security context). 2) If the list of MBeanServers returned is
> * more than one we get the lowest indexed MBeanServer that does not on
> * a null default domain. 3) 333336: we need to wrap JMX calls in
> * doPrivileged blocks 4) fail-fast: if there are any issues with JMX -
> * continue - don't block the deploy()
> */
> // lazy initialize the MBeanServer reference
> if (null == mBeanServer) {
> List<MBeanServer> mBeanServerList = null;
> try {
> if (PrivilegedAccessHelper.shouldUsePrivilegedAccess()) {
> try {
> mBeanServerList = (List<MBeanServer>) AccessController
> .doPrivileged(new PrivilegedExceptionAction() {
> @Override
> public List<MBeanServer> run() {
> return MBeanServerFactory.findMBeanServer(null);
> }
> });
> } catch (PrivilegedActionException pae) {
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER, "failed_to_find_mbean_server",
> "null or empty List returned from privileged MBeanServerFactory.findMBeanServer(null)");
> Context initialContext = null;
> try {
> initialContext = new InitialContext(); // the
> // context
> // should be
> // cached
> mBeanServer = (MBeanServer) initialContext.lookup(JMX_JNDI_RUNTIME_REGISTER);
> } catch (NamingException ne) {
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
> "failed_to_find_mbean_server", ne);
> }
> }
> } else {
> mBeanServerList = MBeanServerFactory.findMBeanServer(null);
> }
> // Attempt to get the first MBeanServer we find - usually there
> // is only one - when agentId == null we return a List of them
> if (null == mBeanServer && (null == mBeanServerList || mBeanServerList.isEmpty())) {
> // Unable to acquire a JMX specification List of MBeanServer
> // instances
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER, "failed_to_find_mbean_server",
> "null or empty List returned from MBeanServerFactory.findMBeanServer(null)");
> // Try alternate static method
> if (!PrivilegedAccessHelper.shouldUsePrivilegedAccess()) {
> mBeanServer = ManagementFactory.getPlatformMBeanServer();
> if (null == mBeanServer) {
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
> "failed_to_find_mbean_server",
> "null returned from ManagementFactory.getPlatformMBeanServer()");
> } else {
> getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_mbeanserver_print",
> new Object[] { mBeanServer, MBEAN_SERVER_COUNT_DUMMY_VALUE,
> mBeanServer.getDefaultDomain(), 0 });
> }
> }
> } else {
> // Use the first MBeanServer by default - there may be
> // multiple domains each with their own MBeanServer
> mBeanServer = mBeanServerList.get(JMX_MBEANSERVER_INDEX_DEFAULT_FOR_MULTIPLE_SERVERS);
> if (mBeanServerList.size() > 1) {
> // There are multiple MBeanServerInstances (usually only
> // JBoss)
> // 328006: WebLogic may also return multiple instances
> // (we need to register the one containing the com.bea
> // tree)
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_encountered_multiple_mbeanserver_instances",
> mBeanServerList.size(), JMX_MBEANSERVER_INDEX_DEFAULT_FOR_MULTIPLE_SERVERS,
> mBeanServer);
> // IE: for JBoss we need to verify we are using the
> // correct MBean server of the two (default, null)
> // Check the domain if it is non-null - avoid using this
> // server
> int index = 0;
> for (MBeanServer anMBeanServer : mBeanServerList) {
> getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_mbeanserver_print",
> new Object[] { anMBeanServer, MBEAN_SERVER_COUNT_DUMMY_VALUE,
> anMBeanServer.getDefaultDomain(), index });
> if (null != anMBeanServer.getDefaultDomain()) {
> mBeanServer = anMBeanServer;
> getAbstractSession().log(SessionLog.WARNING, SessionLog.SERVER,
> "jmx_mbean_runtime_services_switching_to_alternate_mbeanserver", mBeanServer,
> index);
> }
> index++;
> }
> } else {
> // Only a single MBeanServer instance was found
> // mBeanServer.getMBeanCount() - This is very slow on
> // wildfly
> // we are disabling this statemnt
> getAbstractSession().log(SessionLog.FINER, SessionLog.SERVER,
> "jmx_mbean_runtime_services_registration_mbeanserver_print", new Object[] { mBeanServer,
> MBEAN_SERVER_COUNT_DUMMY_VALUE, mBeanServer.getDefaultDomain(), 0 });
> }
> }
> } catch (Exception e) {
> // TODO: Warning required
> e.printStackTrace();
> }
> }
> return mBeanServer;
> }
> {panel}
> The above code looks extremelly complex to me just to get a MBeanserver in an application server.
> I find it hard to believe that this operation should ever have a code with this many lines of code behind it, but ok.
> As you can see in the code I am pasting the only trick I am putting in place to address the deployment time on my machine is to replace every single mebanserver.getMbeanCoundt() by a "dumb" reference to the constant: MBEAN_SERVER_COUNT_DUMMY_VALUE.
> Would it possible that the wildflt server platform be tuned to address this issue?
> I think it would be a good Idea if you revise the getMbeanServer api to be as simple as possible for JBOSS/Wildfly - the base eclipselink code make slittle since in my oppinion.
> But you will know best.
> It is also interesting that now when i run the test suite project from wildfly eclipselink actualy manages to be few ms faster than hibernate:
> {panel}
> Running org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.662 sec - in org.jboss.as.test.compat.jpa.eclipselink.EclipseLinkSharedModuleProviderTestCase
> This eclipselink test is actually now faster than
> Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.354 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.PersistenceXmlHelperTest
> Running org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.685 sec - in org.jboss.as.test.compat.jpa.eclipselink.wildfly8954.WFLY8954BaseTest
> Running org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.714 sec - in
> The hibernate test here loses to the eclipselink test above.
> org.jboss.as.test.compat.jpa.hibernate.HibernateJarsInDeploymentTestCase
> Running org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.218 sec - in org.jboss.as.test.compat.jpa.openjpa.OpenJPASharedModuleProviderTestCase
> {panel}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months