[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: Messages Never Arrive At Broker
From:       Bojan Rajkovic <severedcross () gmail ! com>
Date:       2011-01-24 22:03:05
Message-ID: EF53C85D-E355-48DF-A416-D13010FCE22A () gmail ! com
[Download RAW message or body]


On Jan 24, 2011, at 4:36:23PM, Timothy Bish wrote:

> On Mon, 2011-01-24 at 16:29 -0500, Bojan Rajkovic wrote:
> > On Jan 24, 2011, at 4:04:56PM, Timothy Bish wrote:
> > 
> > > On Mon, 2011-01-24 at 15:36 -0500, Bojan Rajkovic wrote:
> > > > Hi all, 
> > > > 
> > > > Apologies for potential double-posts—Nabble doesn't seem to be working right, \
> > > > so I decided to try the ML directly. 
> > > > I'm using ActiveMQ 5.4.2, with queues and non-persistent messaging. The \
> > > > operating system is SLES 10 (Linux 2.6.18), JVM 1.6, running a 64-bit server \
> > > > VM. I'm not using any application server on the producer end, just creating a \
> > > > connection factory manually. 
> > > > A Java producer is being used to send messages to STOMP-based consumers \
> > > > (primarily Flex/Flash, but maybe also JavaScript in the future). The STOMP \
> > > > clients also produce some messages, and those arrive fine, and the Java \
> > > > consumer is able to pick them up and react to them (including sending a \
> > > > message back—this happens on a different queue than the problem queue \
> > > > though). However, when the Java producer begins to send messages, no messages \
> > > > arrive in the problem queue. The pending count never increases, and the STOMP \
> > > > consumers never get any messages. Producer flow control is turned off, and as \
> > > > mentioned earlier, messages are not persistent. They're also set to expire \
> > > > after 2.5 seconds. 
> > > > My code looks like this: 
> > > > Message m;
> > > > 
> > > > try {
> > > > m = sess.createTextMessage(inputMessage);
> > > > } catch (JMSException e) {
> > > > l.error("Error creating ActiveMQ message. Error message: ", e);
> > > > return;
> > > > }
> > > > 
> > > > try {
> > > > producer.send(m);
> > > > l.info ("Message sent to broker.");
> > > > } catch (JMSException e) {
> > > > l.error("Error sending ActiveMQ message. Error message: ", e);
> > > > return;
> > > > }
> > > > l is a log4j Logger, and sess is a session obtained from an \
> > > > ActiveMQConnectionFactory. The factory is set up as such: \
> > > > ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory(brokerUrl), \
> > > > and async dispatch/sending is disabled (though having it enabled didn't help \
> > > > either).  
> > > > A different queue (with a different producer) works just fine—the JMS \
> > > > producer is able to send a message to the queue, and it's received on the \
> > > > STOMP end. Is there any reason why my JMS producer wouldn't work on one \
> > > > queue, and would work for another, when STOMP works fine for both producing \
> > > > and consuming? I was getting some dead letter queue errors earlier, but \
> > > > resolved them by telling the dead letter queue to not handle messages that \
> > > > expire. If my messages are going to the dead letter queue, how can I \
> > > > establish why, so that I can fix the issue? 
> > > > Cheers,
> > > > Bojan Rajkovic
> > > 
> > > Can you post all of the JMS producer code, showing how you create the
> > > Connection / Session / Producer, there's not quite enough to go on here.
> > > 
> > > Regards
> > > 
> > > 
> > > -- 
> > > Tim Bish
> > > ------------
> > > FuseSource
> > > Email: tim.bish@fusesource.com
> > > Web: http://fusesource.com
> > > Twitter: tabish121
> > > Blog: http://timbish.blogspot.com/
> > 
> > Here's the code, modulo error handling/logging noise:
> > 
> > > ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory(brokerUrl);
> > > Connection conn = null;
> > > 
> > > conn = factory.createConnection(userName, passWord);
> > > conn.start();
> > > 
> > > MessageProducer producer = null;
> > > Session sess = null;
> > > 
> > > sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
> > > 
> > > Queue dataQueue = null;
> > > 
> > > dataQueue = sess.createQueue(messageQueueName);
> > > 
> > > producer = sess.createProducer(dataQueue);
> > > producer.setTimeToLive(messageExpirationTime);
> > > producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> > > 
> > > Socket localSocket = null;
> > > BufferedReader in = null;
> > > 
> > > localSocket = new Socket("localhost", 9090);
> > > in = new BufferedReader(new InputStreamReader(localSocket.getInputStream()));
> > > 
> > > String inputMessage;
> > > 
> > > while (doRun) {
> > > inputMessage = in.readLine();
> > > Message m;
> > > 
> > > m = sess.createTextMessage(inputMessage);
> > > producer.send(m);
> > > }
> > 
> > I can reliably reproduce the lack of messages anytime that messageExpirationTime \
> > is non-zero (that is, anytime the messages are given a TTL). If I set the message \
> > expiration time to 0, messages go through. However, this is not desirable, \
> > because I need messages to expire—I'd rather not have to filter stale messages on \
> > the frontend if I don't have to. I did find out in the meantime that I can fairly \
> > reliably detect when the frontend (a web app) is going away, so I can send my \
> > producer a STOP message and only have a few stale messages at most. However, I'd \
> > still like to figure out why giving messages a TTL causes them to not be \
> > received, just in case there's an ActiveMQ bug. 
> > Thanks for your help!
> > 
> > Cheers,
> > Bojan Rajkovic
> 
> 
> Either your TTL is to short and therefore not making it past the broker
> or, the clocks are not sync'd between the producer machine and the
> machine that's running the broker.  If the clocks are out of sync then
> the messages could be timed out early.
> 
> Regards
> 
> -- 
> Tim Bish
> ------------
> FuseSource
> Email: tim.bish@fusesource.com
> Web: http://fusesource.com
> Twitter: tabish121
> Blog: http://timbish.blogspot.com/
> 
> 

Indeed, you're right about the clocks being out of sync—in fact, they're way out of \
sync. The broker machine is almost 20 minutes late. After fixing the clocks (not sure \
why ntpd isn't running), things work as expected.

Thanks for your help!

Cheers,
Bojan Rajkovic


[prev in list] [next in list] [prev in thread] [next in thread]