[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
13 years, 2 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
13 years, 2 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
13 years, 2 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
13 years, 2 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
13 years, 2 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 reassigned WFLY-1168:
------------------------------------
Assignee: Stuart Douglas (was: jaikiran pai)
> 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
13 years, 2 months
[JBoss JIRA] (WFLY-442) Review of AccessController and PrivilegedAction use across AS7
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-442?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-442:
------------------------------
Assignee: Darran Lofthouse (was: Scott Marlow)
> Review of AccessController and PrivilegedAction use across AS7
> --------------------------------------------------------------
>
> Key: WFLY-442
> URL: https://issues.jboss.org/browse/WFLY-442
> Project: WildFly
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.0.Alpha1
>
>
> The following needs reviewing across AS7: -
> - On demand instantiation of PrivilegedActions where singletons would suffice (Consider frequency of calls, gc may be preferable).
> - Use of AccessController even though there is no SecurityManager set.
> - Code duplication, in every case I have seen so far the code is the same regardless of if PRIVILEGED or NON_PRIVILEGED
> - Utility methods with visibility too high.
> - In depth review of the other methods, i.e. if the first thing a public method does is set the class loader based on a parameter passed in it could be used badly - it may even be a justification for that method to NOT use a PrivilegedAction.
> - Code that requires to be executed using a PrivilegedAction should also be double checked that it is not doing too much as the identity of the caller.
--
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
13 years, 2 months