Ajit, I agree with Clebert's statement that the message, once delivered to the consumer, should not be within the broker's control to expire. Once it's been delivered, it's outside of the broker's control and is the client's responsibility to deal with appropriately.
However, I agree with your assessment that browsing from the admin console should not trigger behavior that the rest of the broker isn't otherwise enforcing; it's fine for the browse action to expire messages as a performance optimization when that will not otherwise change the behavior of connected JMS clients, but it's incorrect behavior for that action to remove messages that are not otherwise being expired by the broker. You can submit a bug in JIRA requesting that we change the broker's behavior in that case, though I can't say that I think it's likely to be at the top of anyone's to-do list unless you can provide a use case that's likely to be hit more frequently. What you've described is, though probably incorrect behavior, somewhat academic for how most users use the broker, so it may not be a high priority for anyone to fix. Tim On Tue, May 8, 2018 at 1:51 AM, ajitmahadik <ajit.mahadi...@gmail.com> wrote: > clebertsuconic wrote > > As long as the consumer is holding the queue, the message should not > > be expired. > > But then why when we browse the queue from ActiveMQ admin console the > message expired even though it was not acknowledged by the client? > > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
