thank you - that's been a helpful exchange. Looks like the JMX route should be fine for my needs.
>>> Gary Tully <email@example.com> 18/07/12 4:51 PM >>>
On 18 July 2012 16:13, Alistair Young <Alistair.Young@uhi.ac.uk> wrote:
> From what I've read a durable queue keeps all the messages from day 1 so any
> new subscriber will get all messages ever sent to the queue,
With a virtual topic, a new subscriber will create a new queue and
only get messages
from that point on.
> which I'd
> rather not do, so I use durable topics and durable subscribers for each
If you are using durable subs, there is already a browse method on
I have not used that but It is part way to what you want. which seems
to be what you say below :-)
> I'm actually not that sure where something like jconsole interacts with
> activemq, e.g. when you perform the browse messages operation, where could I
> hook JPDA to in the activemq class hierarchy to see how JMX gets hold of the
> messages still in the topic, e.g. while the consumer is offline. That would
> seem to be a possible option. I can see message content in jconsole so I
> suppose a JMX based client could do the querying using browse messages.
Peek at org.apache.activemq.broker.jmx.DurableSubscriptionView
> mov eax,1
> mov ebx,0
> int 80h
>>>> Gary Tully <firstname.lastname@example.org> 18/07/12 4:01 PM >>>
> For a topic subscription, the prefetch buffer is not maintained in
> memory by the broker, so you would need prefetch=0 which is a little
> odd for a topic.
> Would a queue not be better for this use case? Or a virtual topic,
> where each consumer gets its own queue.
> On 18 July 2012 15:17, Alistair Young <Alistair.Young@uhi.ac.uk> wrote:
>> Perhaps getting at the prefetch buffer would prolly be better in that
>> Would you have a pointer on how to access it?
>> Use case is a consumer that populates Active Directory and uses auto
>> acknowledge. If the AD bit slows down for any reason the topic should fill
>> up with messages and I need to provide a way for the support team to see
>> an account is in the 'queue', i.e. it's been sent to the broker but not
>> consumed yet. The query will be based on a userid which is contained in
>> message body. Of course I might have missed an entirely easier way of
>> it. It's in conjunction with Camel routing so I could prolly do something
>> with a Processor or fancy logging but for the most part the consumer
>> slows down and logging thousands of usernames seems a bit over the top on
>> the off chance one might be queried.
>> mov eax,1
>> mov ebx,0
>> int 80h
>>>>> Gary Tully <email@example.com> 18/07/12 3:05 PM >>>
>> you would be on the right track.
>> you will need to lock the pending cursor for the duration of the
>> iteration so that will be a little expensive.
>> the pending cursor only gets filled when the prefetch buffer is
>> filled, so you would need a low prefetch and a slow consumer if you
>> expect to find messages in there.
>> What is the use case here?
>> On 18 July 2012 14:46, Alistair Young <Alistair.Young@uhi.ac.uk> wrote:
>>> would I be on the right path if I implemented it in TopicSubscriptionView
>>> and making use of PendingMessageCursor from TopicSubscription to get at
>>> pending messages and their content and properties? Or is iterating
>>> PendingMessageCursor expensive?
>>> mov eax,1
>>> mov ebx,0
>>> int 80h
>>>>>> Gary Tully <firstname.lastname@example.org> 18/07/12 1:16 PM >>>
>>> that feature does not exist, it would require some extension to
>>> On 18 July 2012 11:21, Alistair Young <Alistair.Young@uhi.ac.uk> wrote:
>>>> Is there a way to find a particular message in a topic, either via a
>>>> name/value or based on message content? e.g. if I have a message I know
>>>> be in the topic and it has a message body that would match a particular
>>>> regex, or has a header name with a particular value, is it possible to
>>>> it and therefore verify it's in the topic, i.e. it's in the backlog
>>>> to be consumed?
>>>> mov eax,1
>>>> mov ebx,0
>>>> int 80h