inline On 18 July 2012 16:13, Alistair Young <alistair.yo...@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 > topic. > If you are using durable subs, there is already a browse method on org.apache.activemq.broker.jmx.DurableSubscriptionView#browse 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 > > > Alistair > > > > mov eax,1 > mov ebx,0 > int 80h > >>>> Gary Tully <gary.tu...@gmail.com> 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.yo...@uhi.ac.uk> wrote: >> Perhaps getting at the prefetch buffer would prolly be better in that >> case. >> 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 >> if >> an account is in the 'queue', i.e. it's been sent to the broker but not >> been >> consumed yet. The query will be based on a userid which is contained in >> the >> message body. Of course I might have missed an entirely easier way of >> doing >> 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 >> rarely >> slows down and logging thousands of usernames seems a bit over the top on >> the off chance one might be queried. >> >> >> Alistair >> >> >> >> mov eax,1 >> mov ebx,0 >> int 80h >> >>>>> Gary Tully <gary.tu...@gmail.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.yo...@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 >>> the >>> pending messages and their content and properties? Or is iterating >>> PendingMessageCursor expensive? >>> >>> >>> Alistair >>> >>> >>> mov eax,1 >>> mov ebx,0 >>> int 80h >>> >>>>>> Gary Tully <gary.tu...@gmail.com> 18/07/12 1:16 PM >>> >>> >>> that feature does not exist, it would require some extension to >>> org.apache.activemq.broker.jmx.TopicSubscriptionView >>> >>> On 18 July 2012 11:21, Alistair Young <alistair.yo...@uhi.ac.uk> wrote: >>>> Is there a way to find a particular message in a topic, either via a >>>> header >>>> name/value or based on message content? e.g. if I have a message I know >>>> may >>>> 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 >>>> find >>>> it and therefore verify it's in the topic, i.e. it's in the backlog >>>> waiting >>>> to be consumed? >>>> >>>> thanks, >>>> >>>> Alistair >>>> >>>> >>>> mov eax,1 >>>> mov ebx,0 >>>> int 80h >>>> >>> >>> >>> >>> -- >>> http://fusesource.com >>> http://blog.garytully.com >> >> >> >> -- >> http://fusesource.com >> http://blog.garytully.com > > > > -- > http://fusesource.com > http://blog.garytully.com -- http://fusesource.com http://blog.garytully.com
