Hey folks,
My understanding is that the scheduler requires temporary storage (message
persistence). I would like to advocate that this situation requires some
additional consideration from the administrator of the broker to plan ahead for
the corresponding storage. Hence, keeping it optional will help the users to be
intentional with its usage/implications, and hopefully avoid unnecessary
escalations.
Best regards,
Sam
> On Jan 10, 2025, at 10:06 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
> contenu ne présente aucun risque.
>
>
>
> 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
>
>
