[JBoss JIRA] (DROOLS-1783) [Guided Decision Table] Focus is lost after renaming the GDT
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1783?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-3395 to DROOLS-1783:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-1783 (was: GUVNOR-3395)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Guided Decision Table Editor
(was: Guided Decision Table)
Affects Version/s: 7.2.0.Final
(was: 7.2.0.Final)
> [Guided Decision Table] Focus is lost after renaming the GDT
> ------------------------------------------------------------
>
> Key: DROOLS-1783
> URL: https://issues.jboss.org/browse/DROOLS-1783
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.2.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Trivial
> Attachments: Screenshot from 2017-08-09 15-01-39.png
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1784) Guided Decision Table Editor: Default value for Actions with Value List does not work
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1784?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-2566 to DROOLS-1784:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-1784 (was: GUVNOR-2566)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Guided Decision Table Editor
(was: Guided Decision Table)
> Guided Decision Table Editor: Default value for Actions with Value List does not work
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1784
> URL: https://issues.jboss.org/browse/DROOLS-1784
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Reporter: Michael Anstis
> Assignee: Guilherme Carreiro
> Priority: Minor
>
> [~tirelli] Demonstrated an issue:-
> Create a Guided Decision Table; add an Action column with a "optional value list" and pick a "default value". The default value is not retained and does not appear as the default value in cells. Edson's "optional value list" only had one entry.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1785) Guided Decision Table editor does not allow proper operators after editing a BRL clause
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1785?page=com.atlassian.jira.plugi... ]
Michael Anstis moved GUVNOR-2164 to DROOLS-1785:
------------------------------------------------
Project: Drools (was: Guvnor)
Key: DROOLS-1785 (was: GUVNOR-2164)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Guided Decision Table Editor
(was: Guided Decision Table)
Affects Version/s: 6.1.0.Final
(was: drools_6.1.0.Final)
> Guided Decision Table editor does not allow proper operators after editing a BRL clause
> ---------------------------------------------------------------------------------------
>
> Key: DROOLS-1785
> URL: https://issues.jboss.org/browse/DROOLS-1785
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 6.1.0.Final
> Environment: RedHat Linux 6.3 x86_64; firefox 10.0.5
> Reporter: Stephen Slaboda
> Assignee: Guilherme Carreiro
> Labels: decision_table, drools-wb
> Attachments: exampleModel.png, occurrenceOfBug.png, sourceTabAfterBugObserved.png
>
>
> When editing an existing BRL condition column in the guided rule editor, condition clauses in the BRL that compare using relational operators (i.e. <, >, etc.) for Long values (maybe other numerics as well) are reset to "--- please choose ---". The choices then given are only ==, !=, == NULL, and != NULL.
> The choices should be the same as when I first selected "greater than or equal to" or the like, and should retain the value I originally set. Looking at the source tab, I still see the > value. This happens with both Literal and Formula entries (didn't try others). When initially editing the rule, this bug does not appear. However, after closing the editor and opening the rule in the decision table editor again, it happens consistently.
> Looking at the .gdst file for the rule, I see that the <operator> tag for the column in question is >= in order to escape the XML tag trigger. This may be a factor in what is causing this bug. In my production environment, I am not able to make the decision table rule fire.
> If I copy the source from the decision table editor's source tab into a pure DRL rule, the DRL rule fires just fine given the same input.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-8817) The jboss.dist system property is not used in testsuite/integration/elytron module
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-8817?page=com.atlassian.jira.plugin.... ]
Yeray Borges reopened WFLY-8817:
--------------------------------
> The jboss.dist system property is not used in testsuite/integration/elytron module
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8817
> URL: https://issues.jboss.org/browse/WFLY-8817
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Josef Cacek
> Assignee: Yeray Borges
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> Elytron testsuite module doesn't work correctly with the {{jboss.dist}} system property.
> The {{jboss.dist}} system property is used by QE to run the AS testsuite against the correct bits (e.g. comming from PROD team). The {{testsuite/integration/elytron}} module seems not to be taking this property into account. It seems it always uses output of {{wildfly-server-provisioning-maven-plugin}} to test against.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9488) WeldDeployment initialisation error causes session fail-over to fail.
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9488?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-9488:
------------------------------------
[~klaasjanb] Thanks for the report! I assume the same error also occurs with older versions of WildFly (e.g. 10.1)? This part of the integration code was last changed few years ago.
> WeldDeployment initialisation error causes session fail-over to fail.
> ---------------------------------------------------------------------
>
> Key: WFLY-9488
> URL: https://issues.jboss.org/browse/WFLY-9488
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final
> Environment: Testen on OS X Sierra with Oracle JDK 1.8.0_152
> Reporter: Klaasjan Brand
> Assignee: Martin Kouba
> Attachments: serviceregistry.patch
>
>
> At Topicus we've tested one of our Java EE applications to check compatibility with Wildfly session replication. This resulted in deserialization errors when performing a failover test.
> (WELD-001122: Failed to deserialize annotated type identified with AnnotatedTypeIdentifier)
> The application is deployed as an EAR archive containing several modules, one of them a WAR which hosts the main web frontend.
> Point of interest is our application uses Wicket (with Wicket-CDI) to inject CDI resources in Wicket pages.
> After a debugging session we concluded the "tryToLoadUnknownBackedAnnotatedType" method in the Weld class "SlimAnnotatedType" uses the wrong ResourceLoader when trying to load the class containing an injected object.
> Further debugging proved the initialisation in the WeldDeployment method "createAndRegisterAdditionalBeanDeploymentArchive" copies all of the ServiceRegistry entries of the parent BeanDeployment to the child, overwriting the already set ResourceLoader.
> I've attached a patch which prevents the overwriting of the deployment's already set entries. This fixed the replication problems with our application.
--
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 edited comment on WFLY-9408 at 10/27/17 2:29 AM:
-----------------------------------------------------------------------
Side note unrelated to this thread.
I have detected that cost of creating the EntityManagerFactory in Wildfly is for an unclear reason slightly higher than the cost of setting up the enitty manager factory on Weblogic, although the code is the same.
One step that seems to cost a lot more in Wildfly is the:
---------------
Wildfly: Load Mapping files executed in 667 ms
----------
Vs:
Oracle: Load Mapping files executed in 244 ms
----------------------------------
I have been able to modify the EclipseLink source code to accelerate a bit the Load Mapping Files:
https://www.eclipse.org/forums/index.php/t/1089617/
This has given 400 ms of time reduction on Wildfly.
But in any case I find the results interesting, because it might be an indication that there is a sunstancial performance diffences between the "virutal file system" versus whatever approach applies to weblogic in the cost of some operations.
I am not sure whether or not the eclipselink community is interested in the optimization.
Remains to be seen, but using eclipselink 2.6.4 in the case of our application, we have 1 seconds less of cost of creating an entity manager factory on Weblogic in relation to wildfly.
------------------------ Wildfly 10.1.0.Final :
EntityManagerSetupImpl:
Load Mapping files executed in 667 ms
Process Entity Mappings executed in 1049 ms
Process OR M. Metadata executed in 312 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 2341 ms
--------------------------------- Weblogic 12.2.1.2
EntityManagerSetupImpl:
Load Mapping files executed in 244 ms
Process Entity Mappings executed in 1115 ms
Process OR M. Metadata executed in 195 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 1737 ms
-------------------------
The optimizations I tested, were mostly written on the class:
org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor
To try to reduce the cost and redundancy of the calls:
par = PersistenceUnitProcessor.getArchiveFactory(m_loader).createArchive(rootURL, null);
If eclipselink does decide to optimize this process, It would be good if on a future edition of wildfly we could use a more update version of the eclipselink library.
Many thanks for keeping an eye.
Kindest regards.
was (Author: nuno.godinhomatos):
Side note unrelated to this thread.
I have detected that cost of creating the EntityManagerFactory in Wildfly is for an unclear reason slightly higher than the cost of setting up the enitty manager factory on Weblogic, although the code is the same.
One step that seems to cost a lot more in Wildfly is the:
---------------
Wildfly: Load Mapping files executed in 667 ms
----------
Vs:
Oracle: Load Mapping files executed in 244 ms
----------------------------------
I have been able to modify the EclipseLink source code to accelerate a bit the Load Mapping Files:
https://www.eclipse.org/forums/index.php/t/1089609/
This has given 400 ms of time reduction on Wildfly.
But in any case I find the results interesting, because it might be an indication that there is a sunstancial performance diffences between the "virutal file system" versus whatever approach applies to weblogic in the cost of some operations.
I am not sure whether or not the eclipselink community is interested in the optimization.
Remains to be seen, but using eclipselink 2.6.4 in the case of our application, we have 1 seconds less of cost of creating an entity manager factory on Weblogic in relation to wildfly.
------------------------ Wildfly 10.1.0.Final :
EntityManagerSetupImpl:
Load Mapping files executed in 667 ms
Process Entity Mappings executed in 1049 ms
Process OR M. Metadata executed in 312 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 2341 ms
--------------------------------- Weblogic 12.2.1.2
EntityManagerSetupImpl:
Load Mapping files executed in 244 ms
Process Entity Mappings executed in 1115 ms
Process OR M. Metadata executed in 195 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 1737 ms
-------------------------
The optimizations I tested, were mostly written on the class:
org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor
To try to reduce the cost and redundancy of the calls:
par = PersistenceUnitProcessor.getArchiveFactory(m_loader).createArchive(rootURL, null);
If eclipselink does decide to optimize this process, It would be good if on a future edition of wildfly we could use a more update version of the eclipselink library.
Many thanks for keeping an eye.
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
[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:
---------------------------------------------
Side note unrelated to this thread.
I have detected that cost of creating the EntityManagerFactory in Wildfly is for an unclear reason slightly higher than the cost of setting up the enitty manager factory on Weblogic, although the code is the same.
One step that seems to cost a lot more in Wildfly is the:
---------------
Wildfly: Load Mapping files executed in 667 ms
----------
Vs:
Oracle: Load Mapping files executed in 244 ms
----------------------------------
I have been able to modify the EclipseLink source code to accelerate a bit the Load Mapping Files:
https://www.eclipse.org/forums/index.php/t/1089609/
This has given 400 ms of time reduction on Wildfly.
But in any case I find the results interesting, because it might be an indication that there is a sunstancial performance diffences between the "virutal file system" versus whatever approach applies to weblogic in the cost of some operations.
I am not sure whether or not the eclipselink community is interested in the optimization.
Remains to be seen, but using eclipselink 2.6.4 in the case of our application, we have 1 seconds less of cost of creating an entity manager factory on Weblogic in relation to wildfly.
------------------------ Wildfly 10.1.0.Final :
EntityManagerSetupImpl:
Load Mapping files executed in 667 ms
Process Entity Mappings executed in 1049 ms
Process OR M. Metadata executed in 312 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 2341 ms
--------------------------------- Weblogic 12.2.1.2
EntityManagerSetupImpl:
Load Mapping files executed in 244 ms
Process Entity Mappings executed in 1115 ms
Process OR M. Metadata executed in 195 ms
Creation of EntityManagerFactory for PersistenceUnit: APP_PU executed in: 1737 ms
-------------------------
The optimizations I tested, were mostly written on the class:
org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor
To try to reduce the cost and redundancy of the calls:
par = PersistenceUnitProcessor.getArchiveFactory(m_loader).createArchive(rootURL, null);
If eclipselink does decide to optimize this process, It would be good if on a future edition of wildfly we could use a more update version of the eclipselink library.
Many thanks for keeping an eye.
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
[JBoss JIRA] (WFLY-9480) Undertow Web-Socket when using Atmosphere
by Jason Bruwer (JIRA)
[ https://issues.jboss.org/browse/WFLY-9480?page=com.atlassian.jira.plugin.... ]
Jason Bruwer commented on WFLY-9480:
------------------------------------
The only reason I logged it, is due the the issue not happening on Wildfly10.
Please also note my ssl config.
<ssl protocol="openssl.TLS">
<engine enabled-protocols="TLSv1.1 TLSv1.2"/>
<keystore path="${KS_PATH}" relative-to="jboss.server.config.dir" keystore-password="${KS_KEYSTORE_PASSWORD}" alias="${KS_ALIAS}" key-password="${KS_KEY_PASSWORD}" generate-self-signed-certificate-host="localhost"/>
</ssl>
> Undertow Web-Socket when using Atmosphere
> -----------------------------------------
>
> Key: WFLY-9480
> URL: https://issues.jboss.org/browse/WFLY-9480
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Environment: CentOS in Docker.
> Reporter: Jason Bruwer
> Assignee: Stuart Douglas
>
> 2017-10-25 13:26:54,166 DEBUG [com.flowjob.web.backing.ABaseManagedBean] (default task-25) * User Populate Top Menu Model Took '1' millis.
> 2017-10-25 13:26:54,166 DEBUG [com.flowjob.web.backing.ABaseManagedBean] (default task-25) User Retrieve All Personal Inventory Items Took '0' millis.
> 2017-10-25 13:26:54,718 DEBUG [com.flowjob.web.backing.push.endpoint.RefreshViewEndpoint] (Atmosphere-Scheduler-190) [/refresh_view] : onClose()
> 2017-10-25 13:26:54,744 DEBUG [com.flowjob.web.backing.push.endpoint.RefreshViewEndpoint] (default task-28) [/refresh_view] : onOpen()
> 2017-10-25 13:26:55,022 ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /fluid/primepush/user_session/ZKAen-M9wRcAFnnjsaI2wzjb0sBE80YCWPRChM-j: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at org.atmosphere.cpr.AtmosphereRequest$LocalAttributes.put(AtmosphereRequest.java:589)
> at org.atmosphere.cpr.AtmosphereRequestImpl.wrap(AtmosphereRequestImpl.java:1415)
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:191)
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:177)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:130)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 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.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 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 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.handleRequest(ServletInitialHandler.java:104)
> 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)
> 2017-10-25 13:26:55,228 ERROR [org.jboss.weld.Bean] (default task-25) WELD-000019: Error destroying an instance com.flowjob.web.backing.attachment.AttachmentBean@355e10bd of Managed Bean [class com.flowjob.web.backing.attachment.AttachmentBean] with qualifiers [@Default @Named @Any]
> 2017-10-25 13:26:55,242 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /fluid/primepush/refresh_view: java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months