org.jboss.mq.SpyJMSException: Cannot authenticate user

[marcdevinci]

I am using JMS into a servlet but after some days : 2-3 days... depending on the sun ;-) I get the following error during my "JMS initialisation process" :

...
cat.debug("Initialize JMS...");
queueConnection = queueConnectionFactory.createQueueConnection();
queueSession = queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
QueueSender queueSender = queueSession.createSender(queueName);
cat.debug("... JMS successfully initialized.");
...

org.jboss.mq.SpyJMSException: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused)
at org.jboss.mq.Connection.authenticate(Connection.java:877)
at org.jboss.mq.Connection.(Connection.java:232)
at org.jboss.mq.Connection.(Connection.java:310)
at org.jboss.mq.SpyConnection.(SpyConnection.java:60)
at org.jboss.mq.SpyConnectionFactory.createQueueConnection(SpyConnectionFactory.java:116)
at com.rixxo.mapplications.pxgw.http.ReceiveAction.execute(Unknown Source)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.jboss.web.catalina.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:227)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1040)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1151)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:434)
at java.net.Socket.connect(Socket.java:384)
at java.net.Socket.(Socket.java:291)
at java.net.Socket.(Socket.java:147)
at javax.net.DefaultSocketFactory.createSocket(DashoA6275)
at org.jboss.mq.il.oil.OILServerIL.createConnection(OILServerIL.java:563)
at org.jboss.mq.il.oil.OILServerIL.checkConnection(OILServerIL.java:507)
at org.jboss.mq.il.oil.OILServerIL.authenticate(OILServerIL.java:289)
at org.jboss.mq.Connection.authenticate(Connection.java:870)
... 43 more

Does anyone know about this error? I would appreciate if anyone can help me here.

I read the topic http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t= but I think that it is not the same error? The TCP/IP layer returns another error, what is the differences?

I do not understand why it works some days and after I get a "Connection refused" error.... Can somebody say me where there could be an error?

Thanks

[stephanenicoll]

Check that your are closing your (JMS) connections.

Regards,

Stephane

[marcdevinci]

Thanks for your Answer Stephane!

I have for my "JMS code" a finaly block :

finally {
if (queueSession != null) {
try {
queueSession.close();
}
catch (Exception e) {
cat.error("Cannot close JMS queue session", e);
}
}
if (queueConnection != null) {
try {
queueConnection.close();
}
catch (Exception e) {
cat.error("Cannot close JMS queue connection: ", e);
}
}
}

Is something missing?

[stephanenicoll]

I am afraid no :/

Try running JMS in trace mode (have a look to server/XXX/conf/log4j.xml where XXX is the server you are running - default I assume - )

Regards,

Stephane

[marcdevinci]

Do you mean :





?

[stephanenicoll]

yes. You can even put that information into a separate file. For that copy / paste the appender name=FILE section

<appender name="JBOSSMQ"
.... change the server.log into jbossmq.log



and then



<appender-ref ref="JBOSSMQ"'/>


Regards,

Stephane

[adrian.brock]

Why dont you use java:/ConnectionFactory or even better
java:/JmsXA since if you are in the same VM and ignore the
network traffic altogether.

Regards,
Adrian

[marcdevinci]

Thanks Stephane,

Now my jboss generate trace logs, nice. After the next crash... I will post a new entry here ;-)

[marcdevinci]

Hi Adrian,

I use now the "ConnectionFactory" object. I don't understand the difference with java:/ConnectionFactory. Isn't it the same object?

Currently I use "ConnectionFactory" from my servlets and "java:/JmsXA" from my EJB's since I thought this factory is transaction-aware.

But maybe I misunderstand something?

Best regards
Marc

[stephanenicoll]

java:/ConnectionFactory will use IN-VM calls (that is direct access through the JVM), meaning your process must be in the same JVM as JBoss

ConnectionFactory uses Socket communication and is thus slower (this is the factory to use if you have a standalone/remote process

Regards,

Stephane

[marcdevinci]

Thanks for your answer!

Ok, I changed my lookup "ConnectionFactory" to "java:/ConnectionFactory" ... I saw in the trace logs (Thanks steph) of JMS that now it isn't the same object that handle the JMS request...

I m happy if I can "correct" one bug and in a same time win some performance! ;-)

Regards,
Marc

[adrian.brock]

The root cause of your problem is a network problem
(Connection refused)

ConnectionFactory (really OILConnectionFactory) makes
two sockets connection client->server, server->client

java:/ConnectionFactory makes no socket connections
it is just method invocations (does not work remotely).
java:/JmsXA is a pooled wrapper of java:/ConnectionFactory
that also does security and transaction integration.

Regards,
Adrian

[marcdevinci]

After two testing weeks, I did not encounter this problem any more. Excellent!

I do not know ever why it gives this problem, but you are true, this solution is better!

Thanks a lot!

[dharmon]

I just ran into this same issue running 3.0.7 on solaris 8. We are using the jms oil service which is running on port 8090. Surprisingly, a netstat showed that port 8090 was no longer in the listen state, however there were about 75 existing connections to port 8090. I restarted the OILServerILService from the jmx console which fixed the problem. Port 8090 was again in a listen state. Any thoughts on why 8090 was no longer accepting incoming connections? This is the first time I experienced this issue, and hope that it was just an anomoly.

[jachildress]

Adrian,

but how does this apply to a remote client... on a diff machine?

I was still unable to connect to the any of the default queues, using the Admin Dev example.

John