> The JMS producer delay feature isn’t usually practically viable anyway.
Can you elaborate on this point?
Justin
On Fri, Jan 17, 2025 at 10:48 AM Matt Pavlovich <mattr...@gmail.com> wrote:
> 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
>
>
>
