project_key: JBPAPP6 When EJB invocations from a remote server instance is used and remoting connector of the remote server is secured and the attempt to connection fails an incorrect exception is thrown. In case of version 7.1.0.Final when authentication si not correctly defined then during deployment following exception is thrown: {code} ERROR [org.jboss.remoting.remote.connection] (Remoting "clientnode" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": org.jboss.msc.service.StartException in service jboss.ejb3.dd-based-ejb-client-context."client-ear.ear": Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23] Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91) at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.createRemotingConnections(DescriptorBasedEJBClientContextService.java:124) at org.jboss.as.ejb3.remote.DescriptorBasedEJBClientContextService.start(DescriptorBasedEJBClientContextService.java:86) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] ... 3 more Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) [xnio-api-3.0.3.GA-redhat-1.jar:3.0.3.GA-redhat-1] at org.xnio.nio.NioHandle.run(NioHandle.java:90) at org.xnio.nio.WorkerThread.run(WorkerThread.java:184) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337) [jboss-remoting-3.2.2.GA-redhat-1.jar:3.2.2.GA-redhat-1] at org.jboss.as.remoting.RemoteOutboundConnectionService.connect(RemoteOutboundConnectionService.java:130) [jboss-as-remoting-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] {code} which is correct. But in case that the remote server is shut down, configuration is changed to use security connection then incorrect and confusing exception is thrown: {code} ERROR [org.jboss.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component CallingBean for method public abstract java.lang.String serverclient.CallingBeanRemote.call(): javax.ejb.EJBException: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropogatingInterceptor.processInvocation(EJBRemoteTransactionPropogatingInterceptor.java:80) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:300) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:194) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_23] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_23] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23] at org.jboss.threads.JBossThread.run(JBossThread.java:122) Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination at serverclient.CallingBean.call(CallingBean.java:39) [serverclient-ejb.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-1.jar:1.1.1.Final-redhat-1] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228) [jboss-as-ejb3-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1] ... 27 more Caused by: java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:myejb,distinctname:] combination at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:516) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) [jboss-ejb-client-1.0.4.Final.jar:1.0.4.Final] at $Proxy15.sayHello(Unknown Source) at serverclient.CallingBean.call(CallingBean.java:34) [serverclient-ejb.jar:] ... 46 more {code} The exception seems that everything was connected correctly only module does not exist in remote context. In case of the AS7 Final version is not so problematic but when you take source codes from git then after deploying of application to client server which would like to connect to a secured remote server then no exception is thrown during deployment. Everything looks fine but after execution of remote call the confusing exception is thrown and it's hard to understand that the problem is in not connected context because of security.
Link: Added: This issue Cloned from AS7-4042
I forgot to change the assignee after changing of jira workflow when EAP6 ER releases came. Adding info from AS7 cloned jira: I've checked it whether the current upstream version has the same "problem" and it has. In my point of view there should be some information that the connection failed. I guess that when I spot exception "No EJB receiver available for handling [...]" that it means that the connection succeeded but I put incorrect ejb name to search for. In case that the connection was not successful at all I think that would be nice to have some another more informative exception.
Docs QE Status: Removed: NEW
Assigning jpai EJB issues to david.lloyd. Please re-assign to Cheng or others as needed.
Requesting clarification on owner, relevance, target since this bug more than than two years old and less than POST state: http://post-office.corp.redhat.com/archives/eap6-triage/2014-March/msg00001.html
I don't think this is a valid bug, unless I'm reading it wrong. If the remote server is shut down before deployment, it's arguable whether or not the deployment should start, but if an invocation fails at run time, there's no reason to shut down the deployment or anything like that.
Hi, the idea of this bug was request for improvement of the log message. The thing is that you are getting the same error message when container is up and you specify incorrect ejb name and the same one when remote server is down. There is no info about connection failure or so. If you think that it's not valid request then, please, close this bz. Thanks Ondra
Here's my thoughts. I think the two error messages say exactly what the problem is - at the time - however, I don't think it makes sense to fail the service start just because the connection didn't come up. Connections are by definition outside the control of their corresponding service; the service state should represent the *desire* for a connection to be up, but it cannot represent the actual presence of the connection as long as it cannot control it. Thus I think the deployment should succeed whether or not the connection is available, which would in turn cause all failures to produce the second error message consistently. However, I know that my opinion on this matter may be opposed by some people, so I'm going to solicit some additional commentary before moving forward.
I agree that the deployment should succeed. I'm all the time during testing a bit confused to understand whether ejb name was incorrect or the remote server is down when this message appears. But I agree. I think that the bz could be closed as not a bug. Thanks
Per agreement. We can look at a separate issue to address the deployment question, upstream first.