Non Durable Queue Cleanup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Non Durable Queue Cleanup

MichaelAndrePearce
Hi All,

I'm trying to find the logic that cleans up non durable queues (jms topic subscription).

I can find logic with regards to auto created and auto delete where message count == 0.

But nothing with regards to specific logic to clear up non durables.

Reason I'm asking is we are seeing non durable queues hang about after the jms topic subscriber is gone.

Cheers
Mike

Sent from my iPhone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Durable Queue Cleanup

andytaylor
Depends on the protocol Michael, which client are you using when you see
this occur?

On 11 July 2017 at 16:35, Michael André Pearce <[hidden email]>
wrote:

> Hi All,
>
> I'm trying to find the logic that cleans up non durable queues (jms topic
> subscription).
>
> I can find logic with regards to auto created and auto delete where
> message count == 0.
>
> But nothing with regards to specific logic to clear up non durables.
>
> Reason I'm asking is we are seeing non durable queues hang about after the
> jms topic subscriber is gone.
>
> Cheers
> Mike
>
> Sent from my iPhone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Durable Queue Cleanup

MichaelAndrePearce
We have been connecting both amqp (jms) and core clients connected to the address.

We have shutdown all, yet an amount of queues remain. We have checked the connected consumers = 0 and the queues that remain are def non durables.




Sent from my iPhone

> On 11 Jul 2017, at 17:28, Andy Taylor <[hidden email]> wrote:
>
> Depends on the protocol Michael, which client are you using when you see
> this occur?
>
> On 11 July 2017 at 16:35, Michael André Pearce <[hidden email]>
> wrote:
>
>> Hi All,
>>
>> I'm trying to find the logic that cleans up non durable queues (jms topic
>> subscription).
>>
>> I can find logic with regards to auto created and auto delete where
>> message count == 0.
>>
>> But nothing with regards to specific logic to clear up non durables.
>>
>> Reason I'm asking is we are seeing non durable queues hang about after the
>> jms topic subscriber is gone.
>>
>> Cheers
>> Mike
>>
>> Sent from my iPhone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Durable Queue Cleanup

MichaelAndrePearce
Just a little more digging, it seems when two separate topic subscriptions are made, one of the queues is made durable, and the other is not, even so both should be not durable, seems to occur on both core and amqp client.
No idea how this could be still, any pointers of code to check or put breakpoints in much appreciated.

> On 11 Jul 2017, at 18:05, Michael André Pearce <[hidden email]> wrote:
>
> We have been connecting both amqp (jms) and core clients connected to the address.
>
> We have shutdown all, yet an amount of queues remain. We have checked the connected consumers = 0 and the queues that remain are def non durables.
>
>
>
>
> Sent from my iPhone
>
>> On 11 Jul 2017, at 17:28, Andy Taylor <[hidden email]> wrote:
>>
>> Depends on the protocol Michael, which client are you using when you see
>> this occur?
>>
>> On 11 July 2017 at 16:35, Michael André Pearce <[hidden email]>
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to find the logic that cleans up non durable queues (jms topic
>>> subscription).
>>>
>>> I can find logic with regards to auto created and auto delete where
>>> message count == 0.
>>>
>>> But nothing with regards to specific logic to clear up non durables.
>>>
>>> Reason I'm asking is we are seeing non durable queues hang about after the
>>> jms topic subscriber is gone.
>>>
>>> Cheers
>>> Mike
>>>
>>> Sent from my iPhone

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Durable Queue Cleanup

MichaelAndrePearce
Ignore the last comment, its not true, i just can’t read a simple log line. but alas still stumped.

> On 11 Jul 2017, at 19:47, Michael André Pearce <[hidden email]> wrote:
>
> Just a little more digging, it seems when two separate topic subscriptions are made, one of the queues is made durable, and the other is not, even so both should be not durable, seems to occur on both core and amqp client.
> No idea how this could be still, any pointers of code to check or put breakpoints in much appreciated.
>
>> On 11 Jul 2017, at 18:05, Michael André Pearce <[hidden email]> wrote:
>>
>> We have been connecting both amqp (jms) and core clients connected to the address.
>>
>> We have shutdown all, yet an amount of queues remain. We have checked the connected consumers = 0 and the queues that remain are def non durables.
>>
>>
>>
>>
>> Sent from my iPhone
>>
>>> On 11 Jul 2017, at 17:28, Andy Taylor <[hidden email]> wrote:
>>>
>>> Depends on the protocol Michael, which client are you using when you see
>>> this occur?
>>>
>>> On 11 July 2017 at 16:35, Michael André Pearce <[hidden email]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm trying to find the logic that cleans up non durable queues (jms topic
>>>> subscription).
>>>>
>>>> I can find logic with regards to auto created and auto delete where
>>>> message count == 0.
>>>>
>>>> But nothing with regards to specific logic to clear up non durables.
>>>>
>>>> Reason I'm asking is we are seeing non durable queues hang about after the
>>>> jms topic subscriber is gone.
>>>>
>>>> Cheers
>>>> Mike
>>>>
>>>> Sent from my iPhone
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non Durable Queue Cleanup

Martyn Taylor
Michael,

As Andy mentioned it's protocol specific.

With CORE protocol, the client sends a DELETE QUEUE packet.
https://github.com/apache/activemq-artemis/blob/master/
artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/
ServerSessionPacketHandler.java#L376

In AMQP, the queue is deleted on link remote close PACKET:
https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/proton/ProtonServerSenderContext.java#L492

We also have failure handlers that take care of clean up if the client
disconnects unexpectedly.

Cheers

On Tue, Jul 11, 2017 at 7:50 PM, Michael André Pearce <
[hidden email]> wrote:

> Ignore the last comment, its not true, i just can’t read a simple log
> line. but alas still stumped.
>
> > On 11 Jul 2017, at 19:47, Michael André Pearce <
> [hidden email]> wrote:
> >
> > Just a little more digging, it seems when two separate topic
> subscriptions are made, one of the queues is made durable, and the other is
> not, even so both should be not durable, seems to occur on both core and
> amqp client.
> > No idea how this could be still, any pointers of code to check or put
> breakpoints in much appreciated.
> >
> >> On 11 Jul 2017, at 18:05, Michael André Pearce <
> [hidden email]> wrote:
> >>
> >> We have been connecting both amqp (jms) and core clients connected to
> the address.
> >>
> >> We have shutdown all, yet an amount of queues remain. We have checked
> the connected consumers = 0 and the queues that remain are def non durables.
> >>
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On 11 Jul 2017, at 17:28, Andy Taylor <[hidden email]> wrote:
> >>>
> >>> Depends on the protocol Michael, which client are you using when you
> see
> >>> this occur?
> >>>
> >>> On 11 July 2017 at 16:35, Michael André Pearce <
> [hidden email]>
> >>> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> I'm trying to find the logic that cleans up non durable queues (jms
> topic
> >>>> subscription).
> >>>>
> >>>> I can find logic with regards to auto created and auto delete where
> >>>> message count == 0.
> >>>>
> >>>> But nothing with regards to specific logic to clear up non durables.
> >>>>
> >>>> Reason I'm asking is we are seeing non durable queues hang about
> after the
> >>>> jms topic subscriber is gone.
> >>>>
> >>>> Cheers
> >>>> Mike
> >>>>
> >>>> Sent from my iPhone
> >
>
>
Loading...