Develop Reference

"Read past end of file" on lookup jms/RemoteConnectionFactory on wildfly

I'm trying to do basic a JMS operation using WildFly 26.1.1. I have simple method to lookup jms/RemoteConnectionFactory:
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
properties.put(Context.PROVIDER_URL, "http-remoting://localhost:8080");
InitialContext ic=new InitialContext(properties);
ConnectionFactory f = (ConnectionFactory) ic.lookup("jms/RemoteConnectionFactory") ;
Unfortunately I'm still receiving this exception:
Exception in thread "main" javax.naming.CommunicationException: WFNAM00020: Remote naming operation failed [Root exception is java.io.EOFException: Read past end of file]
at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:289)
at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:190)
at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.store.RelativeFederatingContext.lookupNative(RelativeFederatingContext.java:58)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:66)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at first.jms.WildflyJms.sendMessage(WildflyJms.java:17)
at first.jms.WildflyJms.main(WildflyJms.java:9)
Caused by: java.io.EOFException: Read past end of file
at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:151)
at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:294)
at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:249)
at org.jboss.marshalling.river.BlockUnmarshaller.readUnsignedByte(BlockUnmarshaller.java:258)
at org.jboss.marshalling.river.BlockUnmarshaller.readInt(BlockUnmarshaller.java:296)
at org.jboss.marshalling.river.BlockUnmarshaller.readUTF(BlockUnmarshaller.java:326)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.readExternal(ActiveMQConnectionFactory.java:200)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1444)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:298)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:231)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.wildfly.naming.client.remote.RemoteClientTransport.lookup(RemoteClientTransport.java:271)
... 13 more
Caused by: an exception which occurred:
in object of type org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory

Connecting to as400 JDBC on Play Framework

I'm having issues making a connection to an AS400 database inside of Play!.
My application.conf looks like:
db.default.driver="com.ibm.as400.access.AS400JDBCDriver"
db.default.url="jdbc:as400://SERVER;libraries=A,B,C;toolbox trace=all;trace=true"
db.default.username="user"
db.default.password="password"
I've set up jt400 in the classpath, and I can see under "external libraries" that it shows up and is available. But essentially I get an error message about failing to connect (on user/password I know works) and failure to execute isValid(), which is a function that can not be found inside of AS400JDBCConnection class.
[error] c.z.h.p.PoolBase - HikariPool-1 - Failed to execute isValid() for connection, configure connection test query. (com.ibm.as400.access.AS400JDBCConnection.isValid(I)Z)
[error] application -
! #72265nf0a - Internal server error, for (GET) [/] ->
play.api.Configuration$$anon$1: Configuration error[Cannot connect to database [default]]
at play.api.Configuration$.configError(Configuration.scala:154)
at play.api.Configuration.reportError(Configuration.scala:806)
at play.api.db.DefaultDBApi$$anonfun$connect$1.apply(DefaultDBApi.scala:48)
at play.api.db.DefaultDBApi$$anonfun$connect$1.apply(DefaultDBApi.scala:42)
at scala.collection.immutable.List.foreach(List.scala:381)
at play.api.db.DefaultDBApi.connect(DefaultDBApi.scala:42)
at play.api.db.DBApiProvider.get$lzycompute(DBModule.scala:72)
at play.api.db.DBApiProvider.get(DBModule.scala:62)
at play.api.db.DBApiProvider.get(DBModule.scala:58)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
Caused by: play.api.Configuration$$anon$1: Configuration error[Failed to initialize pool: com.ibm.as400.access.AS400JDBCConnection.isValid(I)Z]
at play.api.Configuration$.configError(Configuration.scala:154)
at play.api.PlayConfig.reportError(Configuration.scala:996)
at play.api.db.HikariCPConnectionPool.create(HikariCPModule.scala:70)
at play.api.db.PooledDatabase.createDataSource(Databases.scala:199)
at play.api.db.DefaultDatabase.dataSource$lzycompute(Databases.scala:123)
at play.api.db.DefaultDatabase.dataSource(Databases.scala:121)
at play.api.db.DefaultDatabase.getConnection(Databases.scala:142)
at play.api.db.DefaultDatabase.getConnection(Databases.scala:138)
at play.api.db.DefaultDBApi$$anonfun$connect$1.apply(DefaultDBApi.scala:44)
at play.api.db.DefaultDBApi$$anonfun$connect$1.apply(DefaultDBApi.scala:42)
Caused by: com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: com.ibm.as400.access.AS400JDBCConnection.isValid(I)Z
at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:512)
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:105)
at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:71)
at play.api.db.HikariCPConnectionPool$$anonfun$1.apply(HikariCPModule.scala:58)
at play.api.db.HikariCPConnectionPool$$anonfun$1.apply(HikariCPModule.scala:54)
at scala.util.Try$.apply(Try.scala:192)
at play.api.db.HikariCPConnectionPool.create(HikariCPModule.scala:54)
at play.api.db.PooledDatabase.createDataSource(Databases.scala:199)
at play.api.db.DefaultDatabase.dataSource$lzycompute(Databases.scala:123)
at play.api.db.DefaultDatabase.dataSource(Databases.scala:121)
Caused by: java.lang.AbstractMethodError: com.ibm.as400.access.AS400JDBCConnection.isValid(I)Z
at com.zaxxer.hikari.pool.PoolBase.checkDriverSupport(PoolBase.java:400)
at com.zaxxer.hikari.pool.PoolBase.setupConnection(PoolBase.java:375)
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:346)
at com.zaxxer.hikari.pool.HikariPool.checkFailFast(HikariPool.java:506)
at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:105)
at com.zaxxer.hikari.HikariDataSource.<init>(HikariDataSource.java:71)
at play.api.db.HikariCPConnectionPool$$anonfun$1.apply(HikariCPModule.scala:58)
at play.api.db.HikariCPConnectionPool$$anonfun$1.apply(HikariCPModule.scala:54)
at scala.util.Try$.apply(Try.scala:192)
at play.api.db.HikariCPConnectionPool.create(HikariCPModule.scala:54)
I'm able to connect in other java-based projects using something like:
try {
Class.forName("com.ibm.as400.access.AS400JDBCDriver");
Connection con = DriverManager.getConnection("jdbc:as400://" +
ApplicationAuthentication.server + "/" +
ApplicationAuthentication.library,
ApplicationAuthentication.user,
ApplicationAuthentication.password
);
} catch (Exception e) {
System.err.println(e);
throw new WebApplicationException(genericError, Response.Status.UNAUTHORIZED);
}

Guessing from the stacktrace, it appears that the connection returned from your driver is not playing well with the connection Hikari Connection Pool. Hikari is default connection pool in playframework.
Specifically, your exception trace shows that the Hikari CP is attempting to call isValid method on the connection object returned by your JDBC driver and then failing with java.lang.AbstractMethodError.
You can try switching to BoneCP connection pool and see if it helps. You can also check comments on this issue on hikari github issue list

Try adding the following to application.config
db.default.hikaricp.connectionTestQuery="SELECT 1"
Not tested in Play Framework but I had similar issue on spring framework and solved in that way.

Use liquibase datasource like below with connection-test-query
#Bean
#LiquibaseDataSource
public DataSource liquibaseDataSource() {
HikariDataSource dataSource = (HikariDataSource) DataSourceBuilder.create().url("url")
.username("username")
.password("password")
.type(HikariDataSource.class).build();
dataSource.setConnectionTestQuery("select 1 from sysibm.sysdummy1");
return dataSource;
}

Has LocateRegistry.createRegistry(int port) changed in java 1.7?

We have several server side components in our architecture. Each component uses JMX to expose various internal attributes. Initialization is done as follows:
try {
Registry registry = null;
for(int i = _serverInfo.getJMXStartPort(); i <= _serverInfo.getJMXEndPort(); i++) {
try {
registry = LocateRegistry.createRegistry(i);
if(registry != null) {
_statusPort = i;
logger.info("Using JMX port: "+_statusPort);
break;
}
} catch (Exception e) {
_statusPort++;
}
}
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
_abstractServiceController = new AbstractServiceController(this);
ObjectName mbeanName = new ObjectName("MyServer:name=MyServer Service");
mbs.registerMBean(_abstractServiceController, mbeanName);
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://:"+_statusPort+"/jmxrmi");
JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(url, System.getenv(), mbs);
cs.start();
} catch (Throwable e) {
logger.error("Unable to register MBean with JMX");
e.printStackTrace();
}
I guess I have two questions.
Does this look right?
The bigger question is, while this runs fine on java 1.6 (each subsequent server on a host uses the next available port, since LocateRegistry.createRegistry(i) throws an exception if the port is unavailable), not so on 1.7. As a result, we get the following exception when the second server attempts to JMXConnectorServer.start(). Does anyone know if the behavior changed for createRegistry? If so, is there something else we should do?
2013-02-07 15:34:28,451 INFO [main] Using JMX port: 9500
2013-02-07 15:34:28,929 ERROR [main] Unable to register MBean with JMX
java.io.IOException: Cannot bind to URL [rmi://:9500/jmxrmi]: javax.naming.NameAlreadyBoundException: jmxrmi [Root exception is java.rmi.AlreadyBoundException: jmxrmi]
at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServe.java:826)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:431)
at com.theatre.services.framework.AbstractService.run(AbstractService.java:306)
at com.theatre.services.reporttree.TreeServerImpl.run(TreeServerImpl.java:690)
at com.theatre.services.framework.Launcher.main(Launcher.java:99)
Caused by: javax.naming.NameAlreadyBoundException: jmxrmi [Root exception is java.rmi.AlreadyBoundException: jmxrmi]
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:139)
at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:226)
at javax.naming.InitialContext.bind(InitialContext.java:419)
at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643)
at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426)
... 3 more
Caused by: java.rmi.AlreadyBoundException: jmxrmi
at sun.rmi.registry.RegistryImpl.bind(RegistryImpl.java:131)
at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:390)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:377)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:137)
... 7 more

Does this look right?
No. Creating a Registry can fail for several reasons, not just because the port is in use.
registry cannot be null after createRegistry(), so testing for it is pointless.
If you're trying to find a free port, just open (and close) a ServerSocket(). Then create the Registry on that port if it worked.
The bigger question is, while this runs fine on java 1.6 (each subsequent server on a host uses the next available port, since LocateRegistry.createRegistry(i) throws an exception if the port is unavailable), not so on 1.7.
See above. Creating a Registry can also fail if there is already one running on that port, in any JDK. In earlier JDKs it would fail if there was one running on any port in the same JVM.

Java email - Exception Server is not trusted

I'm using apache commons mail to send emails. Unfortunately I'm getting following Exception:
org.apache.commons.mail.EmailException: Sending the email to the following server failed : mail.xxx.com:25
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1242)
at org.apache.commons.mail.Email.send(Email.java:1267)
at com.xxx.UserBean.sendMail(UserBean.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
.
.
.
Caused by: javax.mail.MessagingException: Could not convert socket to TLS;
nested exception is:
java.io.IOException: Server is not trusted: mail.xxx.com
at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1880)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:648)
at javax.mail.Service.connect(Service.java:317)
at javax.mail.Service.connect(Service.java:176)
at javax.mail.Service.connect(Service.java:125)
at javax.mail.Transport.send0(Transport.java:194)
at javax.mail.Transport.send(Transport.java:124)
at org.apache.commons.mail.Email.sendMimeMessage(Email.java:1232)
... 85 more
Caused by: java.io.IOException: Server is not trusted: mail.xxx.com
at com.sun.mail.util.SocketFetcher.startTLS(SocketFetcher.java:443)
at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1875)
... 92 more
And here is my java code:
public void sendMail(){
try {
SimpleEmail mail = new SimpleEmail();
mail.setTLS(true);
mail.setAuthenticator(new DefaultAuthenticator("user","xyxyxyxy"));
mail.setHostName("mail.xxx.com");
mail.getMailSession().getProperties().put("mail.smtps.auth", true);
mail.getMailSession().getProperties().put("mail.debug", true);
mail.getMailSession().getProperties().put("mail.smtps.port", "587");
mail.getMailSession().getProperties().put("mail.smtp.starttls.enable", true);
mail.getMailSession().getProperties().put("mail.smtp.ssl.trust", "smtpserver");
mail.addTo("user#server.com", "user");
mail.setFrom("info#xxx.com");
mail.setSubject("Bla Bla");
mail.setMsg("Bla Bla again");
mail.send();
} catch (Exception ex) {
logger.info("Senden der Email ist gescheitert!", ex);
}
}
I've already read many threads and tried many hints. I'm stuck here!
I should mention that I'm able to send emails with another method using "javax.mail". But I'd like to move to apache.
I'm thankful for any help.

setTLS (Transport layer security) to false. If you are not using. When it is true its expected to be mail.xxx.com trusted server.
mail.setTLS(false);

Finally Solved. I tried everything to get authenticated at my exchange server.
use the code below:
Properties props = (Properties)System.getProperties().clone();
props.put("mail.smtp.host", host);
props.setProperty("mail.smtp.port", "587");
props.put("mail.smtp.auth", true);
//Bypass the SSL authentication
props.put("mail.smtp.ssl.enable", false);
props.put("mail.smtp.starttls.enable", false);

If you're using Spring-Boot-Mail, try adding this line to you .properties file:
spring.mail.properties.mail.smtp.ssl.trust=smtp.mandrillapp.com

Problems programmatically connecting to AD

I'm developing a Java EE 6 application that uses AD to help with logging in. My authenticator is simple and looks like this:
#Singleton
#TransactionManagement(TransactionManagementType.BEAN)
public class ADAuthenticator{
private static final String ldapHost = "ldap://domainname.mycompany.com:389";
private static final String domain = "domainname";
public ADAuthenticator() {
}
public void authenticate(String user, String pass) throws NamingException{
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, ldapHost);
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, user + "#" + domain);
env.put(Context.SECURITY_CREDENTIALS, pass);
LdapContext ctxGC = new InitialLdapContext(env, null);
}
}
This has worked well for some time, but lately I'm getting the following exception (except some times where it magically works):
javax.naming.CommunicationException: mydomain.mycompany.com:389 [Root exception is java.net.ConnectException: Connection timed out: connect]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:210)
at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)
at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1580)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2652)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
at com.xdin.competence.util.ADAuthenticator.authenticate(ADAuthenticator.java:35)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at <ejb stuff omitted>
Caused by: java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at com.sun.jndi.ldap.Connection.createSocket(Connection.java:352)
at com.sun.jndi.ldap.Connection.<init>(Connection.java:187)
... 101 more
Nothing has changed with the code, and according to IT-support, no configuration regarding AD has been changed either.
I seperated the relevant code into a simple console application, and it works perfectly with the exact same settings. So the problem seems related to Java EE or the webserver. Any ideas?

The packets for the TCP/IP connection do not arrive in time. This may have multiple reasons, but from what you describe, this may simply be a network congestion between your Java code and the LDAP server which in turn causes package loss. There might also be a firewall blocking that port inbetween.
You need to learn about the ping, traceroute and telnet host port tools to troubleshoot your network layer. I would suggest you team up with a network guy from IT-support and ask him nicely to help finding out where your package loss is.