org.jboss.mq.SpyJMSException: Cannot authenticate user

[sonwh98]

This exception is thrown using Jboss3.2.2 when writing to a JMS queue from a JMS client that is not on the same host as Jboss.
If the client is on the same host as JBoss, then writing to the queue is successful.

%java test.ejb.SimpleQueueSender queue/testQueue

Queue name is queue/testQueue
Exception occurred: org.jboss.mq.SpyJMSException: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused)

SimpleQueueSender.java just simply writes a TextMessage to the specified queue. It worked under jboss3.2.1 but not on jboss3.2.2

any idea whats wrong?

thanks,
son

[adrian.brock]

Connection refused is a network problem

For the nth time, enable TRACE logging on the client to
see where the client is trying to connect to.

Most likely, jboss thinks its host name is localhost or its
ip address is 127.0.0.1 which will cause problems when
this info is passed to the client.

Regards,
Adrian

[jachildress]

Adrian,

but what is the diff between RC4 and the final release?

This problem was not is RC4, but was in the final prod release....

John

[adrian.brock]

The only thing I can think is relevent is the explicit
configuration of the bind address using a system property.

This was to allow easier configuration on a specific NIC

See oil-service.xml

Regards,
Adrian

[jachildress]

Thank you for that information. I'll double check and see if that is causing the "issue"...

If so, I doubt I'll be able to check all of my client machines.... and modify/correct/update thier network settings...

Guess I'll either stick with RC4 or modify oil-service.xml in the prod release.

thanks again,

John

[ekazaltzis]

I have the same problem. What system property do I need to set so that when creating the queue connection JBOSS client knows to which server to connect.

I though it depended on the
java.naming.provider.url
and
the QueueConnectionFactory with JNDI name ConnectionFactory.

E

[ekazaltzis]

What has this to do with the client side ?

It is the client that cannot connect to the JBOSS MQ

E

[adrian.brock]

The client is trying to connect, but the server is not listening.

Regards,
Adrian

[ekazaltzis]

adrian,

Can you please help me because I have no idea what to do to get client to connect to server.

I have a JBOSS started on PC A and I'm trying to connect from a client application on PC B.

What do I need to specify on the CLIENT PC so that the createQueueConnection connects to the OILService on PC A

Thx
E

[adrian.brock]

You are asking the question. the wrong way.

Show me what you know what you are doing,
and prove you have debugged it yourself. I don't hold hands.

I re-iterate this is a network problem.

Regards,
Adrian

[ekazaltzis]

Well after debugging I came to the conclusion that it is a configuration problem and the solution was already provided by adrian (suppose my english at times is not good enough to understand everything)

I replaced the ${jboss.bind.address} in the oil-service.xml by the server address, restarted the server and retried successfully. I suppose when you start JBOSS you could add a -Djboss.bind.address to the JAVA_OPTS environment variable.

If you don't specify the jboss.bind.address the listener is started using address 0.0.0.0 in my case and therefore the client cannot connect.


Hope this helps,
E

[afyoung]

I attempted to pass -Djboss.bind.address=myhost via the JAVA_OPTS in run.sh and this did not work. Is there a file where jboss.bind.address can be successfully set?

Thanks
Andrew

[adrian.brock]

Which java version and OS are you using?

You can start jboss with
./run.sh -Djboss.bind.address=myhost.com

You should see where it binds in the boot sequence.

Also check /etc/hosts for

127.0.01 localhost.localdomain myhost.com

Regards,
Adrian

[markoh]

FreeBSD 5.1-RELEASE
Java HotSpot(TM) Server VM 1.4.1-p4
JBoss 3.2.2

It doesn't work. But it's all ok if I manually change all jboss.bind.address to selected ip.

Regards,
Eugene.

[adrian.brock]

That's bizarre.
It works for me using linux and windows.

Maybe there is some problem with run.sh on BSD?

Regards,
Adrian