I think we're arguing different points here. I agree with basically everything you're saying. Is it a waste? Yes. Is there anybody who actually uses it? Probably not (although we don't know for sure). Can folks change their stuff to adjust if necessary? Almost certainly. All things being equal, should it be off by default? At this point, yes.
That said, my argument is based on our policy to avoid breaking changes whenever possible. This is an important policy. It protects us and our users from making mistakes and unintended consequences which make the lives of both users and developers more difficult. We actually ran into this recently with the change to the output of the 'queue stat' command. To be clear, I'm not an absolutist on this policy. However, in order to set aside this policy there needs to be very clear and very compelling evidence and then a consensus among the developers. Previously I came up with a hypothetical use-case off the top of my head to demonstrate this point. However, there are lots of use-cases I _can't_ imagine. Users do all kinds of unexpected things. That's one of the funnest (and most vexing) things about software development. And this is one of the reasons why this policy is so important. Ultimately, we agree on if the change should be made. We only disagree on when the change should be made. Based on our policy I think it should be made in the next major version since that's where breaking changes are allowed. Lastly, I don't understand the urgency here. You mention wasting resources, but you could make that argument about lots of default settings (e.g. JVM heap size). Ultimately, the default settings are not meant to minimize waste. They're supposed to be a happy medium between convenience and performance for the broadest set of common use-cases. Folks who really care about waste will customize the default, and in this case there's already a flag to eliminate the HornetQ acceptor when the broker is created. Justin On Wed, Aug 7, 2024 at 10:29 AM Clebert Suconic <clebert.suco...@gmail.com> wrote: > I think it's a total waste of resources to keep adding hornetq after 9 > years since Artemis 1.0.0 release. We are making *everybody* to have a > default hornetq acceptor for the hypothetical one user that is still > using it and keeps upgrading every release we make. So, that's a total > inexistent case... > > > You're concerned about an automated script to create the release for a > hornetq older client.. if such user was that careful on automating the > upgrade from hornetq every time, why he just didn't upgrade > everything.. > > > I think it's a total waste and non issue... I think it should be off by > default. > > On Wed, Aug 7, 2024 at 11:05 AM Justin Bertram <jbert...@apache.org> > wrote: > > > > It seems pretty black & white to me. Forcing application clients to > change > > their code or configuration for an upgrade is the definition of a > breaking > > change. Forcing admins to change their commands or scripts to get the > same > > configuration as before is also a breaking change. Am I missing > something? > > > > The behavioral (and sometimes breaking) changes enumerated in > versions.adoc > > for each release are about unavoidable changes resulting from fixing bugs > > or minor changes from adding new features. Those cases seem categorically > > different from this one. > > > > > > Justin > > > > On Wed, Aug 7, 2024 at 9:48 AM Clebert Suconic < > clebert.suco...@gmail.com> > > wrote: > > > > > @Justin Bertram I will agree to disagree with you on that one :) > > > > > > If we stick with that policy, we wouldn't be able to do anything.. we > > > have the versions.adoc for that particular reason... and we always > > > have specific instructions in there. > > > > > > > > > the 61616 acceptor will still accept hornetQ connections, you just > > > need to configure the host and port from clients..so anyone still > > > using hornetq clients can still connect to artemis with a slight URI > > > modification. > > > > > > On Wed, Aug 7, 2024 at 10:45 AM Justin Bertram <jbert...@apache.org> > > > wrote: > > > > > > > > As far as I can tell, the fact that one would need to change what > one was > > > > doing previously to get the same behavior technically makes this a > > > > "breaking change." We really don't know how folks are using the > "create" > > > > command and how that relates to their migration or upgrade processes. > > > Also, > > > > the fact that there is a flag to disable it means that folks who > really > > > > care are almost certainly disabling it already. > > > > > > > > We have a policy of no breaking changes in minor releases. I think we > > > > should stick to it regardless of how unlikely it may be that folks > are > > > > using the functionality in question. I think it's good practice and > helps > > > > give our users confidence in the upgrade process which is important > > > because > > > > we want them to upgrade since it makes our jobs easier. > > > > > > > > > > > > Justin > > > > > > > > On Wed, Aug 7, 2024 at 9:11 AM Clebert Suconic < > > > clebert.suco...@gmail.com> > > > > wrote: > > > > > > > > > it's not a breaking change.. they can always do : > > > > > > > > > > ./artemis create --enable-hornetq-adapter... > > > > > > > > > > that will only affect new servers... new configurations created > from > > > > > now on will not have hornetQ. if you migrate a previous > configuration > > > > > with upgrade, it will still be there. > > > > > > > > > > > > > > > it's been 37 versions since HornetQ (even more if you count the . > > > > > release and the 1.0 releases)... I doubt anyone would be using it > at > > > > > this point. Keep adding the acceptor for HornetQ at this point > it's a > > > > > waste of resources for everybody. > > > > > > > > > > On Wed, Aug 7, 2024 at 9:52 AM Justin Bertram <jbert...@apache.org > > > > > wrote: > > > > > > > > > > > > Generally speaking I agree, but I'm not sure we can make that > change > > > in a > > > > > > minor release since it changed the default behavior and it's not > > > > > > technically a bug. Maybe wait until 3.0? > > > > > > > > > > > > > > > > > > Justin > > > > > > > > > > > > On Tue, Aug 6, 2024 at 11:01 PM Clebert Suconic < > > > > > clebert.suco...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > I just realized we still create the following acceptor on every > > > server > > > > > we > > > > > > > start: > > > > > > > > > > > > > > > > > > > > > <!-- HornetQ Compatibility Acceptor. Enables HornetQ > Core > > > > > > > and STOMP for legacy HornetQ clients. --> > > > > > > > > > > > > > > <acceptor > > > > > > > name="hornetq">tcp:// > > > > > > > > > > > > > > > > 0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true > > > > > > > </accept > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And I think we should stop. 61616 would still respond to > HornetQ > > > > > > > protocol. It just don't make sense (for a few. years already .. > > > don't > > > > > > > know how we missed) to keep this acceptor. > > > > > > > > > > > > > > > > > > > > > I think we should switch the defaults on the CLI create to > have it > > > off > > > > > > > by default, and add a new parameter as > --enable-hornetq-acceptor. > > > > > > > > > > > > > > -- > > > > > > > Clebert Suconic > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > > > > For further information, visit: > > > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Clebert Suconic > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > > For further information, visit: > https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Clebert Suconic > > > > > > > > > > -- > Clebert Suconic > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > For additional commands, e-mail: dev-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > > >
