Hi Ken
The scheduler is already required if you want to use the redelivery
policy. It's also required if the producer uses AMQ_SCHEDULED_DELAY or
AMQ_SCHEDULED_CRON properties (and related).
The reason for the optional scheduler is because it brings a little
"overhead" (especially on the storage, when using JDBC backend, etc)
on the broker whereas it's not an "always" feature. I know a bunch of
users running brokers for ages without the need of the scheduler
enabled.
Imho, the message delivery delays we will support from Jakarta
Messaging 3.1 is similar ("in concept") to the current redelivery
policy. Not sure it needs to change the "optional" state of the
schedule for that. If a user plans to use message delivery delays then
he will have to enable the scheduler (like we do for redelivery policy
today).
I'm not against it, but I don't think message delivery delays support
is "THE" justification :)
Regards
JB
On Fri, Jan 10, 2025 at 7:49 PM Ken Liao <kenlia...@gmail.com> wrote:
>
> Hi folks, happy new year!
>
> I am wondering if we should always enable scheduler support in ActiveMQ
> classic? Right now it is default false, I am curious about the rationale
> behind it being default false. Because:
> 1. Seems like it is a very useful feature.
> 2. Jakarta Messaging 3.1 supports message delivery delays
> <https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#message-delivery-delay>,
> I would assume the implementation will reuse the current scheduler logic?
> If that is the case, the broker engine needs to always enable the scheduler
> for that feature to work.
>
> Let's say we want to always enable the scheduler, should such a change go
> into ActiveMQ 6.2 or ActiveMQ 7?
>
> Thanks,
> Ken
---------------------------------------------------------------------
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
