Hide Forgot
Date of First Response: 2007-11-08 14:00:26 project_key: SOA When deploying ESB appilication the deployment fails as JMS gateway complains that it cannot connect to queue without user credentials
Link: Added: This issue is related to SOA-84
Link: Added: This issue related SOA-84
Link: Removed: This issue is related to SOA-84
06:22:01,585 WARN [ServiceController] Problem starting service jboss.esb:deployment=Performance1.esb org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Unexpected JMS error from prepareMessageReceiver at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doInitialise(JmsGatewayListener.java:114) at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133) at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:150) at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:69) at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployment.startService(JBoss4ESBDeployment.java:83) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) 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.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417) at org.jboss.system.ServiceController.start(ServiceController.java:435) at sun.reflect.GeneratedMethodAccessor9.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 $Proxy4.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:566) 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 sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) at sun.reflect.GeneratedMethodAccessor106.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.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.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74) 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.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) at sun.reflect.GeneratedMethodAccessor105.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.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:818) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:419) at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) at sun.rmi.transport.Transport$1.run(Transport.java:153) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:149) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) at java.lang.Thread.run(Thread.java:595) Caused by: javax.jms.JMSSecurityException: User: null is not authorized to read from destination A at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:312) at org.jboss.jms.server.container.SecurityAspect.handleCreateConsumerDelegate(SecurityAspect.java:112) at sun.reflect.GeneratedMethodAccessor95.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105) at org.jboss.jms.server.endpoint.advised.SessionAdvised$createConsumerDelegate_8721389917985689973.invokeNext(SessionAdvised$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.server.endpoint.advised.SessionAdvised.createConsumerDelegate(SessionAdvised.java) at org.jboss.jms.wireformat.SessionCreateConsumerDelegateRequest.serverInvoke(SessionCreateConsumerDelegateRequest.java:100) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144) 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:186) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157) at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$createConsumerDelegate$aop(ClientSessionDelegate.java:241) at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.client.container.StateCreationAspect.handleCreateConsumerDelegate(StateCreationAspect.java:148) at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect30.invoke(StateCreationAspect30.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.client.container.ConsumerAspect.handleCreateConsumerDelegate(ConsumerAspect.java:68) at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect29.invoke(ConsumerAspect29.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientSessionDelegate$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDelegate_8721389917985689973.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$createConsumerDelegate_8721389917985689973.invokeNext(ClientSessionDelegate$createConsumerDelegate_8721389917985689973.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.createConsumerDelegate(ClientSessionDelegate.java) at org.jboss.jms.client.JBossSession.createConsumer(JBossSession.java:237) at org.jboss.jms.client.JBossSession.createConsumer(JBossSession.java:220) at org.jboss.jms.client.JBossSession.createReceiver(JBossSession.java:402) at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.prepareMessageReceiver(JmsGatewayListener.java:398) at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doInitialise(JmsGatewayListener.java:106) ... 83 more
In my opinion these messages also relates to the bug 06:25:23,083 WARN [MessageAwareListener] Error processing courier, backing off for 8000 milliseconds 06:25:23,122 WARN [MessageAwareListener] Error processing courier, backing off for 8000 milliseconds 06:25:23,439 WARN [MessageAwareListener] Error processing courier, backing off for 8000 milliseconds 06:25:23,749 WARN [MessageAwareListener] Error processing courier, backing off for 8000 milliseconds
Link: Added: This issue is a dependency of SOA-111
Discussed this with Tom, I am going to take it off his plate for now.
Link: Added: This issue is related to SOA-142
Cannot yet recreate the problem listed above - but, seeing the helloworld quickstart (runtest target) hang. control/c on runtest ccauses this in the servler log: 12:50:34,086 ERROR [ServerThread] failed java.io.IOException at java.io.DataInputStream.readFully(DataInputStream.java:178) at java.io.DataInputStream.readLong(DataInputStream.java:380) at org.jboss.jms.wireformat.SessionSendRequest.read(SessionSendRequest.java:80) at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:299) at org.jboss.remoting.transport.socket.ServerThread.versionedRead(ServerThread.java:666) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:534) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) 12:50:41,351 WARN [BisocketClientInvoker] Unable to send ping: shutting down PingTimerTask
The error you are seeing with runtest is because the QS is using a different jboss-messaging jar file. I have already fixed this issue in my local codebase but cannot reproduce the issue Jirka has reported. The helloworld works correctly. The initial comment on this issue is also incorrect as it refers to the 'default' server and does not contain ESB, hence the error with the deployer. I'll try reproducing Jirka's issue.
Link: Added: This issue related SOA-139
JBESB-1335 fixes the wrong version of the JBM classes.
Link: Added: This issue is related to JBESB-1335
Server log with the problem. Search for JMSSecurityException...
Attachment: Added: server.log.gz
I haven't been able to reproduce this yet but I have been digging into the JAAS configurations used in the platform and compared them against the current ESB configurations. jboss-soa-p-standalone.4.2.0 (login-config.xml) - contains 'soa' application policy - does not contain 'jbpm' application policy - 'messaging' application policy is based on property files jboss-soa-p.4.2.0 - does not contain 'jbpm' application policy - 'messaging' application policy is based on database So my questions would be - What happened to the 'jbpm' policy? - The 'soa' policy appears to be securing the jmx-console, should this not exist in both? - What are the contents of the JBM_USER/JBM_ROLE tables used by the 'messaging' policy? Perhaps the answers to these can shed some light on the issue, especially the last one.
A subsequent question may be - should jboss-soa-p-standalone.4.2.0 be using DB configuration for the 'messaging' policy?
OK, but the files used are the standard ones located JBM distribution. We thus need to know the modifications required for these files to get the SOA platform running.
The JBM config must have been modified to support MySql. It is this config which is using dilbert/dogbert. Check out hsqldb-persistence-service.xml for the standard JBM configuration.
Okay, I see what has been done. The MySql configuration has been taken from the examples directory of the JBM distribution but this is different from the configuration provided in the EAP.
The JBM examples in EAP also does not contain valid configuration.
Sorry Jirka, not sure what you are referring to. Within eap-4.3 I get the following [kevin@rincewind jboss-as]$ find . -type f -name \*pers\*xml ./docs/examples/jms/null-persistence-service.xml ./server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml ./server/all/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml ./server/production/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml Within soa-p I get the following [kevin@rincewind jboss-as]$ find . -name \*persistence-service.xml ./docs/examples/jms/null-persistence-service.xml ./server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml ./server/all/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml ./server/production/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml Wherever the mysql config is coming from, it is definitely inconsistent with the rest of the configuration.
jboss-as/docs/examples/jms/*-persistence-service.xml
Jirka, I have already listed all the files that are in my version of eap-4.3 (jboss-eap-4.3.0-0.1.test_CP02.ep1.2) and the soa-p (which is based on that eap). Neither of them have MySql files. In any case, where this file is coming from is irrelevant. What *does* matter is that the MySQL configuration being used in the attached log is *inconsistent* with the remainder of the JMS configuration and is therefore wrong. Please look at one of the hsqldb-persistence-service.xml files listed previously.
Problem in config files
Link: Added: This issue is related to SOA-147
Link: Added: This issue related JBPAPP-437
The sample config files are still from JBossMQ, not from JBM
Jirka, are we still talking about the same issue?
Yes, the problem was caused by missing roles in the config files. I was using the config files from EAP. I suppose that fix for this issue is 1) Add correct config files to dist package 2) Add missing roles into the file And files are not there...
Okay, so this is really a different issue (although related). The original issue was with the DB configuration, this sounds like the build process has missed out the config files.
Moving to IR8.
Just to confirm - the issue described in this JIRA (SOA-112) is a superset of the issue described in SOA-147 in that (1) the files are mising (as is described in SOA-147) and the JBM roles/users must be added to the files. Is this an accurate problem statement?
Yes
I think the issue with http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/SOA-Platform-Release-IntegrationTest-testsuite-matrix/ is that issue, so you can use that hudson job for verification.
Link: Added: This issue is a dependency of JBQA-1110
Link: Removed: This issue related SOA-84