[JBoss JIRA] (WFLY-255) Improve reporting during deployment hang
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-255?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated WFLY-255:
----------------------------------
Assignee: (was: Brian Stansberry)
> Improve reporting during deployment hang
> ----------------------------------------
>
> Key: WFLY-255
> URL: https://issues.jboss.org/browse/WFLY-255
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: http://java.net/jira/browse/EJB_SPEC-60
> java version "1.7.0_09"
> OpenJDK Runtime Environment (IcedTea7 2.3.3) (7u9-2.3.3-0ubuntu1~12.10.1)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
> Ubuntu 12.10
> Reporter: Carlo de Wolf
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment-hang-20130205.txt, server.log
>
>
> Management Thread waits indefinitely for, what seems to be, a finished operation.
> {noformat}
> "management-handler-thread - 2" prio=10 tid=0x00007fa1380d0000 nid=0x7683 in Object.wait() [0x00007fa136deb000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.as.controller.ContainerStateMonitor.awaitContainerStateChangeReport(ContainerStateMonitor.java:158)
> - locked <0x00000000e04ae778> (a org.jboss.as.controller.ContainerStateMonitor)
> at org.jboss.as.controller.ModelControllerImpl.awaitContainerStateChangeReport(ModelControllerImpl.java:464)
> at org.jboss.as.controller.OperationContextImpl.awaitModelControllerContainerMonitor(OperationContextImpl.java:148)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:299)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:142)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-44) unavailable datasource statistics
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-44?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry updated WFLY-44:
---------------------------------
Assignee: (was: Brian Stansberry)
> unavailable datasource statistics
> ---------------------------------
>
> Key: WFLY-44
> URL: https://issues.jboss.org/browse/WFLY-44
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JCA, JMX
> Reporter: Mathieu Lachance
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> In the java visual vm, in the mbean tab, under the "jboss.as:subsystem=datasources,data-source=MyDataSource" mbean, attribute "statistics" is marked as "Unavailable"
> When using the spy="true" attribute in the datasource subsystem in conjunction with the "org.jboss.jca" logger set as TRACE level in the logging subsystem, statistics are outputted as follow :
> Statistics:
> ActiveCount: 1
> AvailableCount: 99
> AverageBlockingTime: 0
> AverageCreationTime: 248
> CreatedCount: 1
> DestroyedCount: 0
> MaxCreationTime: 248
> MaxUsedCount: 1
> MaxWaitCount: 0
> MaxWaitTime: 0
> TimedOut: 0
> TotalBlockingTime: 0
> TotalCreationTime: 248
> I would except to find those statistics available through separates jmx attributes when using the spy="true".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-1149:
-----------------------------------
Assignee: (was: Brian Stansberry)
> Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1149
> URL: https://issues.jboss.org/browse/WFLY-1149
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming, Test Suite
> Environment: IBM JDK 6 (build 20110203_074623)
> IBM JDK 7 (build 20120809_118929)
> Reporter: Ivo Studensky
> Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml
>
>
> RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed.
> test.log snippet:
> {noformat}
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl@345642e1
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl@1dc68cf2
> 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false}
> 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447
> 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open
> at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:422)
> at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74)
> {noformat}
> server.log snippet:
> {noformat}
> 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar"
> 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866
> 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01
> 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed.
> 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-1168) MDB is looking up UserTransaction even if it isn't Bean Managed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1168?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1168:
--------------------------------------
It looks like this will not affect EAP 6.1 as far as I can tell.
Perosnally I would be ok with just backing out the commits that caused this. Even though it is the spec behaviour it is not tested, and it does represent a backwards incompatible change from EAP 6.1.
Otherwise JCA is going to have to come up with a different way to get the UserTransaction other than looking it up from JNDI, such as getting it directly from the UserTransaction service.
> MDB is looking up UserTransaction even if it isn't Bean Managed
> ---------------------------------------------------------------
>
> Key: WFLY-1168
> URL: https://issues.jboss.org/browse/WFLY-1168
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Stefano Maestri
> Assignee: Stuart Douglas
>
> Investigating on a use case I've seen that MDB comes to org.jboss.jca.adapters.jdbc.WrapperDataSource looking up for UT. It fails with this exception
> javax.naming.NamingException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction [Root exception is java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction]
> the problem is exposed running
> org.jboss.as.test.integration.ejb.mdb.MDBTestCase
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-939:
-----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=955818
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
> Key: WFLY-939
> URL: https://issues.jboss.org/browse/WFLY-939
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
> https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
> The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
> When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
> When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
> I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-939:
----------------------------------------------
James Livingston <jlivings(a)redhat.com> made a comment on [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818]
ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
> Key: WFLY-939
> URL: https://issues.jboss.org/browse/WFLY-939
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
> https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
> The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
> When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
> When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
> I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months