Queue Messages are not listed in QueueBrowser when in 'wait-

[upankar]

We have a JMS Queue configured with a MDB listening to it in jboss-4.0.2 . In onMessage() of MDB, I am throwing a runtime exception at the end of the method which makes the msg to be redelivered. But during that time (before redelivering), if i use QueueBrowser , i dont get to see the item. In Jmx-Console also, QueueDepth shows 0. But in fact, this is not the case since item is getting redelivered as expected.

This, I think, is a serious bug if not supported. We do need to see items which are being redelivered. Not obviously during the time when it is being re-processed, but during the time when it is waitiing to be redelivered.

[adrian.brock]

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHelp
Asked so many times before.

[upankar]

Sorry.. but i still dont find the answer in the help link.. My specific question is ....
Is there a way to view the scheduled messages ( i.e. scheduled for redelivery) ?

Because i could see that anything that is not acked by the MDB in CLIENT_ACK mode increases the scheduledMessageCount by 1 while decrementing the QueueDepth by 1. And since standard queue browser is not picking up scheduled items when i attempt to browse the queue, is there any other way to view them ?

Could you help point me to exact answer ?

[adrian.brock]

"upankar" wrote:

Could you help point me to exact answer ?

No, because I am not a search engine. I gave you a link to the search engines.

[adrian.brock]

I can tell you I remember a similar question was asked within the last month.
Go find it.

[shafieksavahl]

Hello upankar

I was the one who posted a similar question last month and after much searching I was unable to find a solution to my problem. I was told that there might be a patch, but I am unable to find it. Not sure if you have to have a subscription to access it. I did find a reference to a post made a couple of years ago, but have not seen any solutions. I have been thinking about creating my own patch, but have been waiting to see if others have a better solution.

I have been thinking about adding code to the browse method of the BasicQueue.

public SpyMessage[] browse(String selector) throws JMSException {
.
.
.

SpyMessage [] list ....

for (Iterator i = events.keySet().iterator(); i.hasNext(); ) {
MessageReference message = (MessageReference)iter.next();
list[XXX] = message.hardReference; // may need to do a clone here
}

return list;
}


Some feedback would be great.

All I havve to do now is to figure out how to compille up my changes.

Thanks

Shafiek

[shafieksavahl]

Hi upankar

I hgave tried the following code in BasicQueue.java and it seems to work. Not sure of the implications in a clustered environment. Still to add some thread safe locks if necessary.

 public SpyMessage[] browse(String selector) throws JMSException
 {
 if (selector == null)
 {
 SpyMessage list[];
 synchronized (messages)
 {
 list = new SpyMessage[messages.size() + events.size()];
 Iterator iter = messages.iterator();

 int i = 0;
 for (; iter.hasNext(); i++)
 list =
 ((MessageReference) iter.next()).getMessageForDelivery();

 Iterator eventsIter = events.keySet().iterator();
 for(; eventsIter.hasNext(); i++) {
 list =
 ((MessageReference)
 eventsIter.next()).getMessageForDelivery();
 }
 }
 return list;
 }
 else
 {
 Selector s = new Selector(selector);
 LinkedList selection = new LinkedList();

 synchronized (messages)
 {
 Iterator i = messages.iterator();
 while (i.hasNext())
 {
 MessageReference m = (MessageReference) i.next();
 if (s.test(m.getHeaders()))
 selection.add(m.getMessageForDelivery());
 }
 }

 SpyMessage list[];
 list = new SpyMessage[selection.size()];
 list = (SpyMessage[]) selection.toArray(list);
 return list;
 }
 }

Shafiek

[upankar]

Thanks for your answer. I do appreciate. But i have some apprehensions modifying the source code - I think Jboss controlls all code changes , patch etc, and doing on our own probably might not be legal.

Hence, we have implemented a work-around. When we need re-delivery, we add the message back to queue as a new new one with a property called STATUS and value as REDELIVER. Another property called REDELIVERY_TIME is set which is equal to = current time (in milliseconds) + redelivery delay. Then, we start a sychronous consumer thread which runs every sometime and looks for items with status RETRY and REDELIVERY_TIME <= current time ( uses message selector). The main MDB is modified to use a message selector for items with status PENDING. This way, MDB doesnt get RETRY status items.

[adrian.brock]

"upankar" wrote:
Thanks for your answer. I do appreciate. But i have some apprehensions modifying the source code - I think Jboss controlls all code changes , patch etc, and doing on our own probably might not be legal.

Truly the blind leading the blind. :-)

Yes, JBoss Inc. and its employess own the copyright to about 70-80% of the codebase
but we license it to everybody to distribute AND MODIFY under the LGPL.
Unlike some other licenses, you don't need the LGPL to USE the software.

[adrian.brock]

Other "blindness"

* Not reading the spec to understand what is guaranteed behaviour and avoid writing
non-portable code (practically nothing is guaranteed if you have active listeners on a queue you are trying to browse concurrently)
* Using selectors on Queues (I am bored of repeating myself already)
* etc.

[adrian.brock]

Another one.

"MDB in CLIENT_ACK"

Explain how you use client acknowledgement with an MDB?
There is no such configuaration!

[adrian.brock]

And the real FAQ of this thread is browsing scheduled messages
and claiming a BUG

If you can show me where in the spec it even mentioned scheduled messages
and their behavour I will gladly concede this is a bug.

Going back to the LGPL comment.
The code for scheduled messages was contributed by a non JBoss employee.
He obviously didn't have a need for browsing scheduled messages since he
didn't add code for it.

So your choices are simple;
* Add the code yourself and keep it to yourself
* Add the code yourself and contribute it back for others to use
* Raise a feature request and wait for somebody else to do it for you

[adrian.brock]

And the final FAQ is CLIENT_ACK and browsers.
If you receive under CLIENT_ACK, the message belongs to session
NOT the QUEUE. So it is invisible to any browser.