I think scheduler support should remain off by default. The JMS producer delay 
feature isn’t usually practically viable anyway.

-Matt Pavlovich

> On Jan 17, 2025, at 9:19 AM, Christopher Shannon 
> <christopher.l.shan...@gmail.com> wrote:
> 
> I know I rarely use scheduled messages so leaving it off by default is
> preferable to me as well, so it sounds like it was already decided to leave
> it off by default but I just wanted to add that I agree with keeping it off
> by default as well.
> 
> On Thu, Jan 16, 2025 at 9:22 PM Ken Liao <kenlia...@gmail.com> wrote:
> 
>> Thanks folks :) Makes sense.
>> 
>> Thanks,
>> Ken
>> 
>> On Sat, Jan 11, 2025 at 10:44 PM Jean-Baptiste Onofré <j...@nanthrax.net>
>> wrote:
>> 
>>> Hi Samir,
>>> 
>>> That's correct, but the storage doesn't necessarily mean an "external
>>> setup" of the broker (it's what I meant by "overhead" on the broker,
>>> especially on the store). That said, I agree with you: I know a bunch
>>> of users without the scheduler and it's fine.
>>> 
>>> Regards
>>> JB
>>> 
>>> On Sat, Jan 11, 2025 at 8:10 AM Samir Boudjebla
>>> <samboudje...@hotmail.com> wrote:
>>>> 
>>>> 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
>>>>> 
>>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> 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
>>> 
>>> 
>>> 
>> 


---------------------------------------------------------------------
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


Reply via email to