-
Bug
-
Resolution: Done
-
Critical
-
7.1.0.DR13
-
None
I configured an EAP 7.1.0.DR13 server to expose a bare remoting connector (without http remoting) on port 4447 (so it should work the same as in default EAP 6 config).
I have an EJB client with a scoped context like this:
public static void main(String[] args) throws NamingException {
InitialContext ctx = new InitialContext(getCtxProperties());
String lookupName = "ejb:/server/HelloBean!ejb.HelloBeanRemote";
HelloBeanRemote bean = (HelloBeanRemote)ctx.lookup(lookupName);
System.out.println(bean.hello());
ctx.close();
}
public static Properties getCtxProperties() {
Properties props = new Properties();
props.put("org.jboss.ejb.client.scoped.context", "true");
props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
props.put("remote.connections", "main");
props.put("remote.connection.main.host", "localhost");
props.put("remote.connection.main.port", "4447");
props.put("remote.connection.main.protocol", "remoting");
props.put("remote.connection.main.username", "joe");
props.put("remote.connection.main.password", "joeIsAwesome2013!");
props.put("remote.connection.main.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS","true");
props.put("remote.connection.main.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT","true");
props.put("remote.connection.main.connect.options.org.xnio.Options.SSL_ENABLED", "false");
props.put("remote.connection.main.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");
return props;
}
When the client tries to connect to the server, it freezes. Thread dump of client reveals this:
Thread 21371: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame) - java.util.concurrent.locks.LockSupport.park(java.lang.Object) @bci=14, line=175 (Interpreted frame) - org.xnio.AbstractIoFuture.await() @bci=48, line=419 (Interpreted frame) - org.xnio.AbstractIoFuture.get() @bci=4, line=535 (Interpreted frame) - org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity() @bci=20, line=107 (Interpreted frame) - org.jboss.ejb.protocol.remote.RemoteEJBReceiver.getConnection(org.jboss.ejb.client.EJBLocator, org.wildfly.naming.client.NamingProvider) @bci=11, line=158 (Interpreted frame) - org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(org.jboss.ejb.client.EJBReceiverInvocationContext) @bci=20, line=115 (Interpreted frame) - org.jboss.ejb.client.EJBClientInvocationContext.sendRequest() @bci=66, line=316 (Interpreted frame) - org.jboss.ejb.client.TransactionInterceptor.handleInvocation(org.jboss.ejb.client.EJBClientInvocationContext) @bci=123, line=70 (Interpreted frame) - org.jboss.ejb.client.EJBClientInvocationContext.sendRequest() @bci=76, line=319 (Interpreted frame) - org.jboss.ejb.client.EJBInvocationHandler.lambda$invoke$0(org.jboss.ejb.client.EJBClientContext, java.lang.Object, java.lang.Object[], org.jboss.ejb.client.EJBProxyInformation$ProxyMethodInfo, java.lang.reflect.Method, org.jboss.ejb.client.EJBReceiver, org.jboss.ejb.client.EJBLocator, org.jboss.ejb.client.Affinity) @bci=68, line=160 (Interpreted frame) - org.jboss.ejb.client.EJBInvocationHandler$$Lambda$46.execute(org.jboss.ejb.client.EJBReceiver, org.jboss.ejb.client.EJBLocator, org.jboss.ejb.client.Affinity) @bci=27 (Interpreted frame) - org.jboss.ejb.client.EJBClientContext.performLocatedAction(org.jboss.ejb.client.EJBLocator, org.jboss.ejb.client.EJBClientContext$LocatedAction) @bci=133, line=393 (Interpreted frame) - org.jboss.ejb.client.EJBInvocationHandler.invoke(java.lang.Object, org.jboss.ejb.client.EJBProxyInformation$ProxyMethodInfo, java.lang.Object[]) @bci=360, line=150 (Interpreted frame) - org.jboss.ejb.client.EJBInvocationHandler.invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[]) @bci=44, line=100 (Interpreted frame) - com.sun.proxy.$Proxy2.hello() @bci=9 (Interpreted frame) - client.Client.main(java.lang.String[]) @bci=27, line=19 (Interpreted frame)
Thread dump on server doesn't reveal any threads doing any related work.
I suspect the root cause is that the remote.connection.main.protocol property is not taken into account and defaults to http-remoting, because this very same freeze occurs when I configure an EJB client with a programmatically created context to connect using http-remoting protocol to a bare remoting connector.
So we probably have two issues, ignoring the remote.connection.main.protocol property and not failing gracefully when connecting via http-remoting to a connector which doesn't do http-remoting.
