I meant the Boolean property saying auto remove address. I didn’t realize
that was the issue.

On Tue, Oct 26, 2021 at 9:27 AM Clebert Suconic <clebert.suco...@gmail.com>
wrote:

> I did not realize there was a management operation in the mix. I agree
> with Robbie
>
> @Havret let me know if that’s the issue please ?
>
>
> On Tue, Oct 26, 2021 at 6:05 AM Robbie Gemmell <robbie.gemm...@gmail.com>
> wrote:
>
>> If the management API has a queue deletion operation that takes an
>> 'auto delete address' boolean then I would consider it a bug if it
>> doesnt actually [eventually] delete a previously
>> auto-created-by-management address when that boolean is true,
>> regardless of the broker config.
>>
>> If it doesnt delete the address then it seems effectively useless; if
>> it only does anything if auto-delete-address was set true in the
>> broker config then why does the management boolean even exist at all?
>> It then seems to do nearly or absolutely nothing (unless setting the
>> management boolean false will somehow prevent the address being
>> auto-deleted by the broker even if its auto-delete config is set
>> true...seems unlikely)?
>>
>> Personally I think this is a bug and the explicit management boolean
>> should be respected, it and the broker auto deletion are not even
>> really the same form of auto-deletion. The general auto-deletion
>> mechanism is a sweep recognising unused auto-created things. The
>> management operation is an explicit command that 'im deleting the
>> queue, also auto delete its address now, the one that you auto-created
>> earlier, so that I dont have to go do that separately'. It is
>> essentially a shortcut to avoid needing to perform another management
>> operation.
>>
>> At the very least if it is to be considered not-a-bug it should throw
>> an exception when the value is true if it isnt actually going to work,
>> e.g an IllegalStateException, alerting the user to their folly of
>> expecting it to work in the obvious way it previously seems to have.
>>
>> In reverse, I would also expect/assume an 'auto create address'
>> management boolean on queue creation to work, even when the 'auto
>> create addresses' broker config is set false. If not, again it should
>> throw.
>>
>> On Tue, 26 Oct 2021 at 06:39, Havret <h4v...@gmail.com> wrote:
>> >
>> > It seems I was assuming that calling destroy queue via management API
>> has
>> > greater precedence than configuration setting. With that being said I
>> will
>> > just update the client docs, so the API doesn't confuse users anymore.
>> >
>> > To summarize:
>> > If you create a queue with *auto-create-address *flag set to true, and
>> then
>> > try to destroy it, the flag *autoDeleteAddress *will work only, and
>> only if
>> > the broker configuration has *auto-delete-addresses* flag set to true.
>> >
>> > On Tue, Oct 26, 2021 at 12:31 AM Clebert Suconic <
>> clebert.suco...@gmail.com>
>> > wrote:
>> >
>> > > If auto-delete is disabled, the address should not be removed.
>> > >
>> > > If you had a case where it was removed, it was a bug.
>> > >
>> > > The flag was respected before.. but perhaps there was a situation it
>> was
>> > > not.
>> > >
>> > >
>> > > You telling me to disrespect the flag and always remove it.. would be
>> > > an oxymoron.. I would just pretty much ignore the setting.
>> > >
>> > > On Mon, Oct 25, 2021 at 4:56 PM Havret <h4v...@gmail.com> wrote:
>> > > >
>> > > > This particular queue is not defined in broker.xml. I'm not sure if
>> 2.19
>> > > is
>> > > > semantically correct, as having the same configuration I'm getting
>> > > > different results than with 2.18 and previous versions. I
>> understand that
>> > > > removing the address was decoupled from removing the queue, but in
>> this
>> > > > particular case the address is never deleted.
>> > > >
>> > > > I'm gessing that changes related to
>> > > > https://issues.apache.org/jira/browse/ARTEMIS-3502,
>> > > auto-delete-addresses
>> > > > flag, and management API delete queue (with autoDeleteAddress set to
>> > > true)
>> > > > don't play nice together.
>> > > >
>> > > > My expectation would be that the address will be eventually deleted
>> even
>> > > > though the auto-delete-addresses flag is disabled in broker
>> > > configuration.
>> > > > This is an imperative API call, at least from the client
>> perspective.
>> > > >
>> > > > On Mon, Oct 25, 2021 at 5:46 AM Clebert Suconic <
>> > > clebert.suco...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > I believe 2.19 is semantically correct to the configuration you
>> are
>> > > > > showing.
>> > > > >
>> > > > > We also had another change related to not delete queues defined on
>> > > > > broker.xml.  Perhaps that’s the problem ?
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Sun, Oct 24, 2021 at 9:38 AM Havret <h4v...@gmail.com> wrote:
>> > > > >
>> > > > > > Hi Clebert,
>> > > > > >
>> > > > > > I had the same broker configuration for 2.18.0 and the test
>> passed
>> > > just
>> > > > > > fine, so I don't think that the matter of new defaults. The
>> queue is
>> > > > > > removed just fine (
>> > > > > >
>> > > > > >
>> > > > >
>> > >
>> https://github.com/Havret/dotnet-activemq-artemis-client/blob/6cee91547c18194330062a48c3b02c7c385457ff/test/ArtemisNetClient.IntegrationTests/TopologyManagement/DeleteQueueSpec.cs#L68
>> > > > > > ),
>> > > > > > the problem is that the management api seems to ignore
>> > > autoDeleteAddress
>> > > > > > parameter and the second assertion fails (
>> > > > > >
>> > > > > >
>> > > > >
>> > >
>> https://github.com/Havret/dotnet-activemq-artemis-client/blob/6cee91547c18194330062a48c3b02c7c385457ff/test/ArtemisNetClient.IntegrationTests/TopologyManagement/DeleteQueueSpec.cs#L70
>> > > > > > )
>> > > > > >
>> > > > > > Thanks,
>> > > > > > Havret
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Oct 21, 2021 at 2:54 AM Clebert Suconic <
>> > > > > clebert.suco...@gmail.com
>> > > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > The answer for that is in your configuration:
>> > > > > > >
>> > > > > > > <auto-delete-queues>false</auto-delete-queues>
>> > > > > > > <auto-delete-addresses>false</auto-delete-addresses>
>> > > > > > > <auto-delete-created-queues>false</auto-delete-created-queues>
>> > > > > > >
>> > > > > > >
>> > > > > > > if you create a new broker configuration now, these
>> auto-deletes
>> > > are
>> > > > > > > turned off.
>> > > > > > >
>> > > > > > >
>> > > > > > > I did that because I have been recommending people in
>> production to
>> > > > > > > turn them off.. so I thought I should just turn'em off by
>> > > default...
>> > > > > > >
>> > > > > > > I couldn't change the default default, but I added these to
>> new
>> > > > > > > configurations...
>> > > > > > >
>> > > > > > >
>> > > > > > > if you need to test auto-delete, you need to set them true.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > Notice that since 2.19 now these will perform a scan before an
>> > > actual
>> > > > > > > delete would happen.
>> > > > > > >
>> > > > > > > This is because I had seen a production issue where a
>> consumer that
>> > > > > > > was up to date, disconnected (connection failure), the close
>> > > deleted
>> > > > > > > the queue immediately, while immediately it caused to another
>> > > queue to
>> > > > > > > be created... in one cirtcunstance the queue was created but
>> not
>> > > the
>> > > > > > > address, creating a mess..
>> > > > > > >
>> > > > > > >
>> > > > > > > I tried to fixing it properly without adding the delays, but I
>> > > could
>> > > > > > > not come up with a scenario that would always work perfectly..
>> > > because
>> > > > > > > the client will query for the queue, and then issue a create
>> > > > > > > separately.. there's always an issue between the queue and
>> > > create...
>> > > > > > > so... the best is to not remove the queue immediately any
>> more...
>> > > > > > >
>> > > > > > > On Wed, Oct 20, 2021 at 4:33 PM Havret <hav...@apache.org>
>> wrote:
>> > > > > > > >
>> > > > > > > > Hi,
>> > > > > > > >
>> > > > > > > > I'm trying to update the test suite of ArtemisNetClient to
>> use
>> > > > > ActiveMQ
>> > > > > > > > Artemis 2.19.0, but one of the tests starts failing on
>> 2.19.0:
>> > > > > > > > Should_delete_queue_alongside_with_auto_created_address -->
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > >
>> https://github.com/Havret/dotnet-activemq-artemis-client/pull/300/checks?check_run_id=3943848841
>> > > > > > > >
>> > > > > > > > The test creates a queue using the management api and then
>> > > removes it
>> > > > > > > with
>> > > > > > > > flag autoDeleteAddress set to true. The queue is removed
>> but the
>> > > > > > address
>> > > > > > > > isn't. I've looked over the release notes, but I didn't spot
>> > > anything
>> > > > > > > that
>> > > > > > > > could indicate this change of behavior. Is this a
>> regression, or
>> > > was
>> > > > > > it a
>> > > > > > > > deliberate change?
>> > > > > > > >
>> > > > > > > > Robbie suggested that it might be related to
>> > > > > > > > https://issues.apache.org/jira/browse/ARTEMIS-3502
>> > > > > > > >
>> > > > > > > > I tried to adjust the test:
>> > > > > > > > - I set *address-queue-scan-period* to 100
>> > > > > > > > - I wait up to 5 seconds until the address is removed
>> > > > > > > >
>> > > > > > > > But the test still is failing. My broker configuration is as
>> > > follows:
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > >
>> https://github.com/Havret/dotnet-activemq-artemis-client/blob/fc256b2a3784447fa4feadea58b62f58d1fcabfd/test/artemis/broker.xml
>> > > > > > > > Is it possible that this new setting interferes with
>> > > > > > > > *auto-delete-addresses *set to *false*?
>> > > > > > > >
>> > > > > > > > Thanks,
>> > > > > > > > Havret
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Clebert Suconic
>> > > > > > >
>> > > > > >
>> > > > > --
>> > > > > Clebert Suconic
>> > > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Clebert Suconic
>> > >
>>
> --
> Clebert Suconic
>
-- 
Clebert Suconic

Reply via email to