Murali wrote:

> Hi:
>
> Using JMS API how can I get the length of the Queue(#of messages in
> the queue), for a given messageSelector...
>
> I can get this information by using the QueueBrowser.getEnumeration(),
> and iterating thru all the messages, BUT this is forcing me to read
> all the messages in the QUEUE into memory and then iterating over
> them, I am hoping there might be a better solution....

Not that I can think of, except
that many times an application can
partition different message types
into different queues - which
naturally solves the problem as
well as usually makes things
easier to manage.

Anyway, if performance is an issue,
I think you can speed it up considerably
by making sure that the enumerator code and
connection factory are running on the
same server as the JMS server. (Target
an EJB for the purpose.)

Tom

>
> Thanks for all your help...
> -Murali
>

Hi Tom:

Thanks for your reply, In all probability our customers will also partition different
messages types to different queues, there still might be a common queue for certain
message types... even so is there any way to get the queueDepth using JMS api,
if we dont consider the message selector...

If I have the enumerator code running on the same JMS Server, I still might run
into memory problems, if the JMS Queue has done paging, the QueueBrowser will
try to load all the messages into memory...

Thanks
-Murali
Tom Barnes
wrote:
>
>Murali wrote:
>
>> Hi:
>>
>> Using JMS API how can I get the length of the Queue(#of messages in
>> the queue), for a given messageSelector...
>>
>> I can get this information by using the QueueBrowser.getEnumeration(),
>> and iterating thru all the messages, BUT this is forcing me to read
>> all the messages in the QUEUE into memory and then iterating over
>> them, I am hoping there might be a better solution....
>
>Not that I can think of, except
>that many times an application can
>partition different message types
>into different queues - which
>naturally solves the problem as
>well as usually makes things
>easier to manage.
>
>Anyway, if performance is an issue,
>I think you can speed it up considerably
>by making sure that the enumerator code and
>connection factory are running on the
>same server as the JMS server. (Target
>an EJB for the purpose.)
>
>Tom
>
>>
>> Thanks for all your help...
>> -Murali
>>
>

Murali wrote:

> Hi Tom:
>
> Thanks for your reply, In all probability our customers will also partition different
> messages types to different queues, there still might be a common queue for certain
> message types... even so is there any way to get the queueDepth using JMS api,
> if we dont consider the message selector...

Via the standard management APIs (JMX). There are sample
programs on http://dev2dev.bea.com/technologies/jms/index.jsp, and,
if you using 8.1, there are helper methods for obtaining
references to JMX objects in weblogic.jms.extensions.JMSHelper (see
javadoc).

>
> If I have the enumerator code running on the same JMS Server, I still might run
> into memory problems, if the JMS Queue has done paging, the QueueBrowser will
> try to load all the messages into memory...

Will it? I'm fairly sure it only loads messages into memory as they
are accessed.

>
> Thanks
> -Murali
> Tom Barnes
> wrote:
>
>>Murali wrote:
>>
>>
>>>Hi:
>>>
>>>Using JMS API how can I get the length of the Queue(#of messages in
>>>the queue), for a given messageSelector...
>>>
>>>I can get this information by using the QueueBrowser.getEnumeration(),
>>>and iterating thru all the messages, BUT this is forcing me to read
>>>all the messages in the QUEUE into memory and then iterating over
>>>them, I am hoping there might be a better solution....
>>
>>Not that I can think of, except
>>that many times an application can
>>partition different message types
>>into different queues - which
>>naturally solves the problem as
>>well as usually makes things
>>easier to manage.
>>
>>Anyway, if performance is an issue,
>>I think you can speed it up considerably
>>by making sure that the enumerator code and
>>connection factory are running on the
>>same server as the JMS server. (Target
>>an EJB for the purpose.)
>>
>>Tom
>>
>>
>>>Thanks for all your help...
>>>-Murali
>>>
>>
>

Tom Barnes
wrote:
>
>
>Murali wrote:
>
>> Hi Tom:
>>
>> Thanks for your reply, In all probability our customers will also partition
>different
>> messages types to different queues, there still might be a common queue
>for certain
>> message types... even so is there any way to get the queueDepth using
>JMS api,
>> if we dont consider the message selector...
>
>Via the standard management APIs (JMX). There are sample
>programs on http://dev2dev.bea.com/technologies/jms/index.jsp, and,
>if you using 8.1, there are helper methods for obtaining
>references to JMX objects in weblogic.jms.extensions.JMSHelper (see
>javadoc).
>
Thanks for the info. looks like JMX might be my only alternative, and I cannot
use the messageSelector to filter the queuelength....

>>
>> If I have the enumerator code running on the same JMS Server, I still
>might run
>> into memory problems, if the JMS Queue has done paging, the QueueBrowser
>will
>> try to load all the messages into memory...
>
>Will it? I'm fairly sure it only loads messages into memory as they
>are accessed.
>
If I use the enumerator and iterate thru the messages to get the count, then all
the messages will be loaded into memory....


>>
>> Thanks
>> -Murali
>> Tom Barnes
>> wrote:
>>
>>>Murali wrote:
>>>
>>>
>>>>Hi:
>>>>
>>>>Using JMS API how can I get the length of the Queue(#of messages in
>>>>the queue), for a given messageSelector...
>>>>
>>>>I can get this information by using the QueueBrowser.getEnumeration(),
>>>>and iterating thru all the messages, BUT this is forcing me to read
>>>>all the messages in the QUEUE into memory and then iterating over
>>>>them, I am hoping there might be a better solution....
>>>
>>>Not that I can think of, except
>>>that many times an application can
>>>partition different message types
>>>into different queues - which
>>>naturally solves the problem as
>>>well as usually makes things
>>>easier to manage.
>>>
>>>Anyway, if performance is an issue,
>>>I think you can speed it up considerably
>>>by making sure that the enumerator code and
>>>connection factory are running on the
>>>same server as the JMS server. (Target
>>>an EJB for the purpose.)
>>>
>>>Tom
>>>
>>>
>>>>Thanks for all your help...
>>>>-Murali
>>>>
>>>
>>
>

Murali wrote:

>>Will it? I'm fairly sure it only loads messages into memory as they
>>are accessed.
>>
>
> If I use the enumerator and iterate thru the messages to get the count, then all
> the messages will be loaded into memory....

Correct - but you can free them up as they are read in, so the
message bodies won't all be in memory at once.

If you just need the total message count on MQ, try this:

int msgCount = java.util.Collections.list(queueBrowser.getEnumera tion()).size();

This gets the count, but doesnt load the msgs into the memory !!

- Hari