ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Review Requested -- IGNITE-15077
Date Thu, 29 Jul 2021 13:55:49 GMT
Hello!

We now have 2 schedulers under the hood, whereas the optimal number is zero.

I would very like to see a commit where the whole ignite-schedule package
is sunsetted. With prior discussion on dev list, of course.
I don't see the value of having local scheduling as part of Apache Ignite
at all. It's very spotty and does not integrate with the rest of features.
I know that GridGain makes use of the existing scheduling code, but since
they do that on a separate code base they probably won't object to removal.

If you plan on improving the Schedule module, instead of removing it, I
would ask you to post a roadmap of that feature on the developers list,
where you describe what you are planning to implement and why.

Right now it is totally not obvious why I would use the new scheduleLocal
methods instead of just adding Quartz to the project and calling that.
Apache Ignite is not an universal middleware like Spring, it's a database.

Regards,
-- 
Ilya Kasnacheev


чт, 29 июл. 2021 г. в 14:45, Andrey Mashenkov <andrey.mashenkov@gmail.com>:

> Atri.
>
> I think Ilya means IgniteCombinedSchedulerProcessor that delegates calls to
> 2 different Scheduler implementations.
> And the logic may not be enough clear for a user.
>
> 1. You added a new mandatory dependency on Quartz.
> We are trying to avoid this as much as possible, because this may lead to
> the jar-hell issue on the user-side.
> E.g in case the user uses the same library of the other version for other
> purposes.
>
> Is it possible to move scheduler implementation based on Quartz to a
> separate module and make the module optional?
> Or maybe move it to Ignite extensions?
>
> 2. Does it make sense to split Combined scheduler into 2 separate
> implementations?
> It looks ok if they will have slightly different capabilities on API if all
> the limitations will be well-documented.
> I mean Javadoc in implementation class must provide this information, along
> with the common interface methods describe possible errors in a "@throw"
> section in javadoc.
>
>
> On Thu, Jul 29, 2021 at 1:15 PM Atri Sharma <atri@apache.org> wrote:
>
> > Hi Ilya,
> >
> > Following up on this please.
> >
> > On Tue, 27 Jul 2021, 22:20 Atri Sharma, <atri@apache.org> wrote:
> >
> > > Hi Ilya,
> > >
> > >
> > > > Frankly speaking, I do not see the value of having an extra layer of
> > > > indirection around *local* Quartz-based scheduler in Ignite. Can you
> > > > elaborate?
> > >
> > > I didnt quite understand that. Are you referring to the
> > > IgniteCombinedSchedulerProcessor?
> > > >
> > > > Our guidelines also recommend having issue description to document
> the
> > > whys
> > > > and hows, and not just issue title.
> > >
> > > Sure, I will update the issue with more details.
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > Apache Concerted
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message