A machine-dependent problem with JBossMQ.

[arabin]

I am running JBoss 3.2.3 on my Linux machine (ip address 192.168.1.21), java version 1.4.2_01-b06, mixed mode

I am also running java client on my windows xp machine, the same JVM version.

Here is my program:

/////////////////////////////////// Start /////////////////////////////////////////

import javax.naming.Context;

import javax.naming.InitialContext;

import javax.jms.*;

import java.util.Properties;



public class exampleMessageSender

{

public static final String DELIMITER = ":";

public static final String NAMING_CONTEXT_FACTORY = "org.jnp.interfaces.NamingContextFactory";

public static final String URL_PKG_PREFIXES = "org.jboss.naming:org.jnp.interfaces";

public static final String JNP = "jnp://";

public static final String QUEUE_CONNECTION_FACTORY = "UIL2XAConnectionFactory";

public static String PORT_INE = "1099";

public static void main (String args [])

{

Properties prop = new Properties ();

String ip = "192.168.1.21";

String port = PORT_INE;



prop.put (Context.INITIAL_CONTEXT_FACTORY, NAMING_CONTEXT_FACTORY);

prop.put (Context.PROVIDER_URL, JNP + ip + DELIMITER + port);

prop.put (Context.URL_PKG_PREFIXES, URL_PKG_PREFIXES);



try

{

InitialContext initCtx = new InitialContext (prop);

QueueConnectionFactory qfactory =

(QueueConnectionFactory)initCtx.lookup(QUEUE_CONNECTION_FACTORY);

QueueConnection qcon = qfactory.createQueueConnection();

QueueSession qses = qcon.createQueueSession (false, Session.AUTO_ACKNOWLEDGE);

Queue queue = (Queue) initCtx.lookup ("queue/A");

QueueSender qsender = qses.createSender(queue);

TextMessage tm = qses.createTextMessage();

System.out.println("Sending");

qsender.send (tm, DeliveryMode.NON_PERSISTENT,

Message.DEFAULT_PRIORITY, 1500000);

System.out.println("Sent");

}

catch (Exception ex)

{

ex.printStackTrace();

}

}

}

/////////////////////////////////// End /////////////////////////////////////////

In the java console http://192.168.1.21:8080/jmx-console/HtmlAdaptor I am trying to see what is going on after I execute the program on the client.

I am looking at the domain jboss.mq.destination, Queue queue/A (Name A, jndiName queue/A, that is the standard destination from the jboss setup, I did not change it)

I see that there are no receivers attached to the queue (that is what I need), using the operation on MBean in jmx-console:

listReceivers
java.util.ArrayList
MBean Operation.

Also I see that QueueDepth is still 0, even though I sent the message and the client finished OK.

At the same time operations

listMessageCounterHistory
java.lang.String
MBean Operation.

And

listMessageCounter
java.lang.String
MBean Operation.

Show me that there is a message in the queue.

How can that be?

Also, if I setup a listener to that queue, the callback onMessage of the listener is never called. I put a print statement there and I perfectly see that.

Can you tell me what is going on?

It looks the problem is perfectly reproducible with this Linux machine. However, if I use another Linux machine for JBoss server, it behaves as I expect –

QueueDepth becomes 1, when the listener is not set to the queue, and when the listener is set to the queue, the callback onMessage is called.

The same problem can be seen on the earlier version of JBoss 3.2.2RC3

Any comments?

[adrian.brock]

Most likely it is a problem with your network configuration.
See the FAQ forum for something like "Cannot connect to localhost"
for common problems and solutions.

Regards,
Adrian

[arabin]

Does not look like this.

I do not see any exceptions - everything looks fine, just the QueueDepth is not increasing, and callback is not called if the listener is set.

I have the following contents of /etc/hostname:

127.0.0.1 localhost.localdomain localhost
192.168.1.21 edge1.west.com

command "hostname" gives me edge1.west.com

ping to both 192.168.1.21 and edge1.west.com perfectly works from external machine and from the machine itself.

I tried running Jboss using -Djava.rmi.server.hostname=192.168.1.21

Also, I tried running Jboss using -Djava.rmi.server.hostname=edge1.west.com

Neither one worked correctly - the QueueDepth did not increase, but the counter increased.

The same thing with the same /etc/hosts on another Linux machine perfectly works with QueueDepth increasing by 1.

I also tried changing the line
prop.put (Context.PROVIDER_URL, JNP + ip + DELIMITER + port);
to line
prop.put (Context.PROVIDER_URL, JNP + ip + DELIMITER + port + "/");

No effect, both do not work in the same way.

As far as I can see there are no more ideas. Or do you have any?

[arabin]

As I said, both Linux machines have the same version of JVM, and have the same version of Linux kernel. And /etc/hosts contains they same type of information. But the same version of Jboss is able to accept messages correctly from a windows java client on one of those Linux machines and is not able to do the same on the other of those two Linux machines.

[arabin]

Actually, it looks like there are two groups of machines.
Window machines and some linux machines are in the first group. Other Linux machines are in the second group.

Everything works fine for all machines within the first group. Everything looks OK also within machines in the second group as well.

If Jboss (server) is working on a machine in the second group, the client on a machine from the first group does not deliver message in a correct way (queue depth on the server is not increased), but the client on a machine from the second group works OK.

If Jboss (server) is working on a machine from the first group, everything works OK regardless where client works.

[arabin]

I got the answer to the problem. I wonder if it's documented anywhere that the time on the machines should be synchronized.

When I synchronized the machines with NTP they all started working correctly!!!!!

Can you give an explanation for that, please?

[adrian.brock]

You had set a time-to-live on the message?

Regards,
Adrian

[arabin]

Yes. Set to 1500000. Dissynchronization between machines was 2-3 minutes, definitely less than 20 minutes.