Bug 901248 (JBPAPP6-1699)
Summary: | [GSS](6.4.z) SaslException connecting to server, but actual EJB invocations are fine | ||
---|---|---|---|
Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Ladislav Thon <lthon> |
Component: | Remoting | Assignee: | Enrique Gonzalez Martinez <egonzale> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1.1 | CC: | bmaxwell, cdewolf, darran.lofthouse, egonzale, hokuda, jbilek, jkudrnac, jtruhlar, lthon, msochure, olukas, rsvoboda |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | http://jira.jboss.org/jira/browse/JBPAPP6-1699 | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Cause:
Consequence:
Workaround (if any):
Result:
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2017-01-03 12:25:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1361648, 1375357 |
Description
Ladislav Thon
2012-12-06 12:15:34 UTC
Maybe this is not a bug: https://issues.jboss.org/browse/JBPAPP-9233 We'll have to try to configure the 'ejb' cluster in the client and see. Seen during 6.1.DR4 testing. Upstream bug ID? I do not know of any upstream bug. Still seeing this with EAP 6.1.1.ER7. For example: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-ejbremote-undeploy-repl-sync/31/ https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-ejbremote-shutdown-repl-sync/29/ I can reproduce the problem with EAP 6.4 During EJBClientContext creation through the InitialContextFactory in jboss-remoting-naming component, the EJBClientContext is created without the configuration passed as parameter to the InitialContext. https://github.com/jbossas/jboss-remote-naming/blob/1.0.10.Final/src/main/java/org/jboss/naming/remote/client/ejb/RemoteNamingStoreEJBClientHandler.java#L59 When a new cluster node is added the system checks whether the ejb client configuration is set or not, creating a callback based on that setup. Due to the lack of ejb client configuration the system creates a org.jboss.ejb.client.DefaultCallbackHandler. This callback handler does not support PasswordCallback which is the one being used and the one throwing the exception during cluster connection (DigestMD5Client::evaluateChallenge) https://github.com/jbossas/jboss-ejb-client/blob/1.0.26.Final/src/main/java/org/jboss/ejb/client/remoting/RemotingConnectionClusterNodeManager.java#L93 Enrique González Martínez <elguardian> updated the status of jira JBNAME-62 to Coding In Progress *** Bug 996897 has been marked as a duplicate of this bug. *** This was merged upstream: https://github.com/jbossas/jboss-remote-naming/commit/4a439c2acf04947f64b6bfbe14de60c84bd57b40 lacks backport and upgrade for naming component. PR up 6.4.z :https://github.com/jbossas/jboss-remote-naming/pull/29 no upstream required. Reopened because still seeing this with EAP 6.4.11.CP.CR1 On perf17 output (sfDaemon - perf17) in job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-ejbremote-undeploy-repl-sync/76/ you can still see the error message. But now it looks as follows: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:448) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) at org.xnio.nio.NioHandle.run(NioHandle.java:90) at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:293) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:423) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:152) at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78) at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:77) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:475) at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:449) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662) Hi Jiří Bílek is it possible to run the job with different parameters/file jboss-ejb-client.properties ? Hi: The new error is due to a missconfiguration in the ejb-client-properties. When you are working as anonymous you need to setup the property SASL_POLICY_NOANONYMOUS for the cluster. by default SASL_POLICY_NOANONYMOUS is true so it needs credentials. You need to add the next two lines to your jboss-ejb-client.properties remote.clusters=ejb remote.cluster.ejb.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false This is not a bug but a missconfiguration. closing it. |