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
