I think it would be better todo something like that for the fix:
byte[] content;
if (msg.getText== null) {
content = new byte[0];
} else {
content = msg.getText().getBytes("UTF-8");
}
command.setContent(content);
But I'm not to familiar with stomp..
Bye,
Norman
2011/2/1 anton <juc...@gmail.com>:
>
> We are using ActiveMQ 5.4.2 on CentOS 5.4 and also run into a "message stuck
> in a queue" scenario. In our case these stuck messages had no content.
> Here's an outline of what was happening:
>
> a) we were seeing a few empty messages submitted to the queue (our fault -
> there weren't really supposed to be empty, but because of a producer error
> they were)
> b) our consumer application (using STOMP) would never get these empty
> messages and would wait in perpetuity
> c) deleteing these empty messages from the queue and reconnecting the
> consumer would resume the flow of messages
> d) In ActiveMQ log, we noticed this stack trace:
>
> 2011-01-30 17:12:34,811 | ERROR | Failed to page in more queue messages |
> org.apache.activemq.broker.region.Queue | Queue:test66
> java.lang.NullPointerException
> at
> org.apache.activemq.transport.stomp.LegacyFrameTranslator.convertMessage(LegacyFrameTranslator.java:90)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.convertMessage(ProtocolConverter.java:610)
> at
> org.apache.activemq.transport.stomp.StompSubscription.onMessageDispatch(StompSubscription.java:93)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.onActiveMQCommand(ProtocolConverter.java:592)
> at
> org.apache.activemq.transport.stomp.StompTransportFilter.oneway(StompTransportFilter.java:58)
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:40)
> at
> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1249)
> at
> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:810)
> at
> org.apache.activemq.broker.TransportConnection.dispatchSync(TransportConnection.java:770)
> at
> org.apache.activemq.broker.region.PrefetchSubscription.dispatch(PrefetchSubscription.java:649)
> at
> org.apache.activemq.broker.region.PrefetchSubscription.dispatchPending(PrefetchSubscription.java:599)
> at
> org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:156)
> at
> org.apache.activemq.broker.region.Queue.doActualDispatch(Queue.java:1798)
> at org.apache.activemq.broker.region.Queue.doDispatch(Queue.java:1745)
> at
> org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:1898)
> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1425)
> at
> org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:98)
> at
> org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:36)
>
>
> e) Putting a try/catch block around that line in LegacyFrameTranslator.java
> (activemq-core/src/main/java/org/apache/activemq/transport/stomp/LegacyFrameTranslator.java:90)
> causes the messages to not be stuck any more: they now show up successfully
> on the consumer side. Here's the change we did:
>
>
> 90c90,94
> < command.setContent(msg.getText().getBytes("UTF-8"));
> ---
>> try {
>> command.setContent(msg.getText().getBytes("UTF-8"));
>> } catch (Throwable e) {
>> command.setContent(new byte[0]);
>> }
>
>
> Not sure if this is the "right" way to fix the problem.
> Hoping someone on this list could shed some light.
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Message-stuck-on-queue-tp3076607p3252992.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
