Great idea too. Only concern and i noted this on the PR is accidental
regressions due to test cases also being modified.Can i ask we have this as a
two stage change, one without any test changes, as theoretically if refactor
and full compatiblity there should be no need for changes. And thus we get a
full regression, i would also suggest that a release level of testing us
completed running the FULL tests suite. Once that is done then separate PR to
tidy up test cases.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Francesco Nigro <[email protected]>
Date: 05/04/2020 17:57 (GMT+00:00) To: [email protected] Subject: Re:
[DISCUSS] Refactor queue creation in Artemis (ARTEMIS-2692) +100 for meLovely
the reduction in code complexity to favour maintainabiliity: justwell done!Il
giorno dom 5 apr 2020 alle ore 17:28 Justin Bertram <[email protected]>ha
scritto:> In theory, creating a queue in Artemis is pretty straightforward. If
you're> on a client you can use:>> -
org.apache.activemq.artemis.api.core.client.ClientSession>> If you're on the
broker then you could use:>> -
org.apache.activemq.artemis.core.server.ServerSession (e.g. if you're> creating
a queue on behalf of a client)> -
org.apache.activemq.artemis.core.server.impl.ActiveMQServer (e.g. if> you're
creating a queue for the broker's internal use or for a test)>> In Artemis 1.0
there were a handful of methods on each of these classes to> create queues with
different configurations. Here's the breakdown of the> number of overloaded
methods:>> - org.apache.activemq.artemis.api.core.client.ClientSession> -
createQueue: 6> - createSharedQueue: 4> - createTemporaryQueue: 2> -
org.apache.activemq.artemis.core.server.ServerSession> - createQueue: 1>
- createSharedQueue: 1> -
org.apache.activemq.artemis.core.server.impl.ActiveMQServer> - createQueue:
3> - createSharedQueue: 1> - deployQueue: 1> - updateQueue: 0>>
Here's a breakdown of those same methods in 2.11.0 (i.e. the latest>
release):>> - org.apache.activemq.artemis.api.core.client.ClientSession (over
200%> increase)> - createQueue: 21> - createSharedQueue: 6> -
createTemporaryQueue: 10> -
org.apache.activemq.artemis.core.server.ServerSession (700% increase)> -
createQueue: 11> - createSharedQueue: 5> -
org.apache.activemq.artemis.core.server.impl.ActiveMQServer (500%> increase)>
- createQueue: 18> - createSharedQueue: 4> - deployQueue: 2> -
updateQueue: 6>> Almost every time a new queue parameter was added then a
collection of> corresponding overloaded methods were added as well to support
the new> parameter. As the number of parameters in these methods has increased
the> usability has decreased. For example, if you wanted to create a queue
with> all the default parameters but with a custom ring-size then you would
have> to call a createQueue method with *26* parameters.>> Furthermore, there
are multiple places in the code-base where all the queue> configuration
parameters are encapsulated:>> -
org.apache.activemq.artemis.api.core.QueueAttributes> -
org.apache.activemq.artemis.core.server.QueueConfig> -
org.apache.activemq.artemis.core.server.QueueConfig.Builder> -
org.apache.activemq.artemis.core.config.CoreQueueConfiguration>> When a new
parameter is added then all of these objects need to be updated> as well.>> In
short, maintainability here is a bit of a nightmare.>> I've sent a PR [1] to
address these usability and maintainability issues.> The PR itself describes
the solution(s) so I won't repeat that information> here.>> There's no rush on
merging this except that I think it should be merged> with plenty of time
before 3.0 (whenever that will be) so users can migrate> from the deprecated
methods before they are removed completely.>>> Justin>> [1]
https://github.com/apache/activemq-artemis/pull/3063>
