[JBoss JIRA] Created: (JBMESSAGING-1147) NullPointerException in ServerConsumerEndpoint.localClose
by Carlo de Wolf (JIRA)
NullPointerException in ServerConsumerEndpoint.localClose
---------------------------------------------------------
Key: JBMESSAGING-1147
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1147
Project: JBoss Messaging
Issue Type: Bug
Reporter: Carlo de Wolf
Assigned To: Tim Fox
Something I snatched from the console. Can't reproduce it.
12:22:30,426 ERROR [ExceptionUtil] SessionEndpoint[861-adw6ls8f-1-65ltks8f-axkhkk-110j3] close [a81-uvedms8f-1-65ltks8f-axkhkk-110j3]
java.lang.NullPointerException
at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.localClose(ServerConsumerEndpoint.java:526)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.localClose(ServerSessionEndpoint.java:1166)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.close(ServerSessionEndpoint.java:329)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$close$aop(SessionAdvised.java:72)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$close_N4742752445160157748.invokeNext(SessionAdvised$close_N4742752445160157748.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$close_N4742752445160157748.invokeNext(SessionAdvised$close_N4742752445160157748.java)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.close(SessionAdvised.java)
at org.jboss.jms.wireformat.CloseRequest.serverInvoke(CloseRequest.java:66)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:101)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.remoting.Client.invoke(Client.java:536)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:187)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:158)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$close$aop(ClientSessionDelegate.java:152)
at org.jboss.jms.client.delegate.ClientSessionDelegate$close_N4742752445160157748.invokeNext(ClientSessionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.container.SessionAspect.handleClose(SessionAspect.java:204)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect25.invoke(SessionAspect25.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$close_N4742752445160157748.invokeNext(ClientSessionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$close_N4742752445160157748.invokeNext(ClientSessionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$close_N4742752445160157748.invokeNext(ClientSessionDelegate$close_N4742752445160157748.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.close(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossConnectionConsumer.doClose(JBossConnectionConsumer.java:338)
at org.jboss.jms.client.JBossConnectionConsumer.close(JBossConnectionConsumer.java:163)
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.teardownConsumer(JmsServerSessionPool.java:277)
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.stop(JmsServerSessionPool.java:99)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownSessionPool(JmsActivation.java:567)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:321)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.stop(JmsActivation.java:223)
at org.jboss.resource.adapter.jms.JmsResourceAdapter.endpointDeactivation(JmsResourceAdapter.java:80)
at org.jboss.resource.deployment.RARDeployment.endpointDeactivation(RARDeployment.java:287)
at org.jboss.resource.deployment.RARDeployment.internalInvoke(RARDeployment.java:235)
at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.ejb3.JmxClientKernelAbstraction.invoke(JmxClientKernelAbstraction.java:44)
at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.deactivate(JBossMessageEndpointFactory.java:323)
at org.jboss.ejb3.mdb.inflow.JBossMessageEndpointFactory.stop(JBossMessageEndpointFactory.java:200)
at org.jboss.ejb3.mdb.MessagingContainer.stopProxies(MessagingContainer.java:297)
at org.jboss.ejb3.mdb.MessagingContainer.stop(MessagingContainer.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.ServiceDelegateWrapper.stopService(ServiceDelegateWrapper.java:119)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.GeneratedMethodAccessor120.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy119.stop(Unknown Source)
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:175)
at org.jboss.ejb3.JmxKernelAbstraction.uninstall(JmxKernelAbstraction.java:202)
at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:661)
at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.GeneratedMethodAccessor120.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy33.stop(Unknown Source)
at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:538)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.stop(DeployerInterceptor.java:98)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy34.stop(Unknown Source)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:516)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:1058)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1033)
at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:996)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-979) Servlet transport for JBoss Messaging
by Daniel Weeks (JIRA)
Servlet transport for JBoss Messaging
-------------------------------------
Key: JBMESSAGING-979
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-979
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Remoting
Affects Versions: 1.2.0.SP1
Environment: Windows 2003 with IIS as front-end web server.
Reporter: Daniel Weeks
Assigned To: Tim Fox
Although there is an https transport for JBoss Messaging, it does not support going over the same port that Tomcat is using like the JBoss MQ jbossmq-httpil.sar does. This capability is required for environments in which port 443 is the only port that is open for communication. Although url proxying/forwarding could be used under Apache to work around this issue, there is not a good solution for doing this with IIS (or for applications that don't use a front-end web server and are limited to port 443). Many enterprise PKI solutions (such as DoD) favor the use of IIS over Apache due to cost of COTS products, so this is a show stopper for JBoss Messaging in those environments.
This issue is preventing us from migrating an enterprise application that runs in the DoD environment to to JBoss Messaging. The application makes heavy use of JMS and would benefit greatly from the improved performance that JBoss Messaging provides.
This feature request is originating from a JBoss Customer Support Portal case at the following URL:
https://network.jboss.com/jbossnetwork/restricted/caseDetail.html?caseId=...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-1107) Less noisy client-side failover
by Ovidiu Feodorov (JIRA)
Less noisy client-side failover
-------------------------------
Key: JBMESSAGING-1107
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1107
Project: JBoss Messaging
Issue Type: Feature Request
Components: JMS Clustering
Affects Versions: 1.4.0.GA
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Minor
When a cluster node failure occurs, the client side reports a significant amount of ERROR logging. This is technically correct, those errors are actually occurring, but a clustered connection factory has in-place a fail-over mechanism whose job is to cope with those errors and hopefully make them disappear.
If the fail-over succeeds, the user should not see any ERROR-level logging. At most, there should be a WARN along the lines of "node failure detected, the fail-over mechanism is dealing with it". The user should see ERRORs only if the fail-over itself fails.
Tons of stack traces produce a significant level of discomfort even if the fail-over succeeds, leaving the user in doubt whether actually the process worked.
The logging information should be naturally still available, but at DEBUG level.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBAS-4858) SecurityDeployer changes with metadata
by Anil Saldhana (JIRA)
SecurityDeployer changes with metadata
--------------------------------------
Key: JBAS-4858
URL: http://jira.jboss.com/jira/browse/JBAS-4858
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.Beta3
The Security Deployer needs to be changed as per the following rant from Adrian
=============================
To me this is the wrong approach anyway.
There shouldn't be any code that does
if (ejbdeployment)
doThis();
else if (webdeployment)
doThat();
else if (unknowntype) // OOPS (pun intended ;-)
cantDoIt();
The webservice deployers should be working off some generic metadata that triggers them to operate.
Then each type of deployment can populate that metadata to say "I want a webservice endpoint for this".
This is a seperate deployer for each type we know how to map to a webservice it takes the ejb/web/other metadata and maps or bridges it to the webservice metadata.
It shouldn't just be restricted to ejbs and wars.
e.g. An MBean should be capable of being an endpoint if there is a deployer that creates the relevant metadata attachment from say a META-INF/jboss-webservice.xml in the sar.
The security deployers take the same brain dead (non object orientated) approach.
============================================================
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 10 months
[JBoss JIRA] Created: (JBRULES-1229) separate compile classpath from class loader's getResource() facility
by Godmar Back (JIRA)
separate compile classpath from class loader's getResource() facility
---------------------------------------------------------------------
Key: JBRULES-1229
URL: http://jira.jboss.com/jira/browse/JBRULES-1229
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.1
Reporter: Godmar Back
Assigned To: Mark Proctor
Priority: Minor
The current compiler relies on being able to read the bytecode for referred-to classes as a resource. For instance, to resolve the name "org.jboss.pkg.Clazz", a resource "org/jboss/pkg/Clazz.class" must be accessible.
This requirement is not part of the public interface of a class loader. Read the Sun Java documentation, which states: "A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code."
Although, this approach works by coincidence since most class loaders in fact return this resource - at least class loaders that don't do anything fancy to bytecode before defining classes, a more principled solution would separate the classpath used by the runtime engine from the classpath used by the compiler. (This is, for instance, what javac or practically all command-line compilers do.)
My suggestion is to either document this dependency on this particular class loader behavior, or, better, introduce a specific type resolver for the compilation process that is separated from the class loader's resource loading mechanism.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Created: (JBAS-4998) App could Dynamically create Connection Pool in 3.0, but crashes in 4.2.1
by Steve Davidson (JIRA)
App could Dynamically create Connection Pool in 3.0, but crashes in 4.2.1
-------------------------------------------------------------------------
Key: JBAS-4998
URL: http://jira.jboss.com/jira/browse/JBAS-4998
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment services, Transaction Manager
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
Environment: SuSE 10.1
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
JBoss 4.2.1
Reporter: Steve Davidson
Assigned To: Dimitris Andreadis
Greetings.
Due to the fact that this application has dozen's of different Databases to talk to (later hundreds, then maybe more), other than a 'bootstrap connection pool' to the 'master database, all connection pools have to be created dynamically. The connection information is stored in a master database (the fact that we need a Database to keep track of the connection info for all the databases should say much).
In JBoss 3.0 & 3.2.8, it is quite possible to create these connections dynamically. This has been working for some time, actually (starting with JBoss 3.0Beta2). Had to tweak the code a bit when migrating to 3.2.8 a while back, but got it working again quite nicely (still is, actually, in production).
Since JBoss 3.x is end of life, we've started migrating to JBoss 4.2.8. The objects that were originally used seem to have been changed. I've updated most of the calls, but at this time, I am getting the following failure;
14:56:39,120 DEBUG [com.security.ejb.UserEJB.initializeState(UserEJB.java:318)] Exception getting Row from Service layer: Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
Error! Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\n\nPlease contact Administrator and relay the following information:\n\nMessage: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\nSQLState: null\nError Code: 0\n
at com.common.ejb.DBConnection.getConnection(DBConnection.java:171)
at com.common.ejb.DBConnection.prepareStatement(DBConnection.java:469)
at com.common.ejb.DBConnection.executePreparedSQLQuery(DBConnection.java:386)
at com.common.ejb.CommonService.getRow(HRXCommonService.java:318)
at com.security.ejb.UserEJB.initializeState(UserEJB.java:306)
at com.security.ejb.UserEJB.ejbLoad(UserEJB.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb.plugins.BMPPersistenceManager.loadEntity(BMPPersistenceManager.java:435)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEntity(CachedConnectionInterceptor.java:252)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:243)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:278)
at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:76)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:138)
at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
at org.jboss.ejb.Container.invoke(Container.java:960)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:169)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:112)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
at $Proxy75.logIn(Unknown Source)
at com.security.ThinUserProxy.logIn(ThinUserProxy.java:233)
at com.security.servlet.LoginServlet.logIn(LoginServlet.java:275)
at com.security.servlet.LoginServlet.doPost(LoginServlet.java:127)
at com.security.servlet.LoginServlet.service(LoginServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.jsr77.Jsr77ServletHolder.handle(Jsr77ServletHolder.java:74)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:227)
at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:626)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Caused by: org.jboss.util.NestedSQLException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94)
at com.common.ejb.DBConnection.getConnection(DBConnection.java:164)
... 68 more
Caused by: org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >)
at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:343)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
... 69 more
Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >
at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:744)
at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:577)
at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:337)
... 73 more
14:56:39,160 WARN [com.security.ejb.UserEJB.ejbLoad(UserEJB.java:257)] common.error.db.connectionfailed
E
The line failing in DBConnection is 'datasource.getConnection'.
I will be attaching the appropriately sanitized log files shortly.
There is currently no viable workaround. I will be posting the code used to create the Connection Pools and DataSources dynamically. If helpful, I can post the the 3. & 3.2 version as well as the 4.2 version.
Regards,
Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months
[JBoss JIRA] Created: (JBAS-5001) JBoss MBean Creation/Delpoyment no longer compatible with 2-Phase JBoss Transaction Manager
by Steve Davidson (JIRA)
JBoss MBean Creation/Delpoyment no longer compatible with 2-Phase JBoss Transaction Manager
-------------------------------------------------------------------------------------------
Key: JBAS-5001
URL: http://jira.jboss.com/jira/browse/JBAS-5001
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX, Transaction Manager
Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
Environment: Linux (SuSE 10.0/10.1)
java version "1.5.0_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
Reporter: Steve Davidson
Assigned To: Dimitris Andreadis
Greetings.
This issue was discovered when upgrading from JBoss 3.2 -> JBoss 4.2. When creating a Datasource dynamically from an EJB with an active transaction, via the appropriate JBoss Manager classes, the trransaction can not complete with the following exception;
14:56:39,120 DEBUG [com.security.ejb.UserEJB.initializeState(UserEJB.java:318)] Exception getting Row from Service layer: Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))
Error! Unable to obtain Database Connection from the Connection Pool: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\n\nPlease contact Administrator and relay the following information:\n\nMessage: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < ac, BasicAction: -3f5702ff:38cc:47449b39:2e status: ActionStatus.ABORT_ONLY >))\nSQLState: null\nError Code: 0\n
Specifically, once the DataSource has been created, it can not be used in the same transaction that it was created, and is destroyed when the transaction rollsback due to the above exception.
This was originally misdiagnosed/misreported, under http://jira.jboss.com/jira/browse/JBAS-4998?page=all. Logs, and code snippets can be found there.
Current workaround is to 'allowMultipleLastResources=true' in conf/jbossjta-properties.xml.
19:47:18,092 WARN [com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:910)] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.multipleWarning] [com.arjuna.ats.internal.jta.transaction.arjunacore.lastResource.multipleWarning] Multiple last resources have been added to the current transaction. This is transactionally unsafe and should not be relied upon. Current resource is org.jboss.resource.connectionmanager.TxConnectionManager$LocalXAResource@23d87f
-Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 11 months