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