geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: GBeans representing separately persistent data
Date Thu, 15 Jun 2006 04:35:18 GMT
Once again, if managing a massive number of jobs, then a specialized
tool set makes sense.

However, if dealing with a small number of jobs for a single
application, what part of this is too complex for an administrator to
handle?

deployer.sh deploy my-app-jobs.jar
deployer.sh stop MyAppJobs
deployer.sh start MyAppJobs
deployer.sh redeploy my-app-jobs.jar
...

You can do that against a remote machine, redeploy a newer JAR with
updated code for the jobs, etc.  I think that's going to be a lot
easier to work with than trying to figure out how to set the classpath
and send updated code for a job stored in a database!

Thanks,
    Aaron

P.S. Recall that no one needs to *write* a GBean in this scenario --
you write a *Job* and the deployer handles the rest under the covers.

On 6/15/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> Thinking about this from an operational model (not a developer) I think the database
approach makes
> a lot of sense.  If the jobs are hosted in a DB they can be managed directly from a GUI
that would
> make more sense to the operators or other folks that aren't developers.   It strikes
me as a bit
> heavy to have each job as a GBean in the config.xml.
>
> Based on what I know it seems to make a lot of sense that there is a GBean that boostraps
the
> scheduler container and that container manages the jobs.  I was thinking back to the
premise you
> outlined in another e-mail thread Aaron that said we should be as easy as a Mac.  I think
the one
> GBean per job is not quite in line with the simple premise (I'm thinking of non-developers
here).
>
> The people that will be adding and removing jobs are most likely not developers and will
not have
> their same skill set.
>
> Does this make sense?
>
> Matt
>
> Aaron Mulder wrote:
> > Yeah, I'm not imagining using this approach for "thousands" of jobs.
> > Though in truth, it shouldn't take an XML parser an unreasonable
> > amount of time to write a thousand (or ten thousand) elements, so I'm
> > not sure there would be a huge problem in having more entries in
> > config.xml.
> >
> > Anyway, if you have thousands of jobs, I'd recommend a dedicated tool
> > or GUI.  If you have an application with "some" but not "thousands" of
> > jobs, I imagine it would be nice to have a convenient way to deploy
> > and manage them through Geronimo.  To me, these are not overlapping
> > use cases.  I don't know where to draw the line in between, but I
> > think we can clarify what we're tageting with each approach and let
> > the developer decide which to take.
> >
> > Thanks,
> >    Aaron
> >
> > On 6/14/06, Dain Sundstrom <dain@iq80.com> wrote:
> >> On Jun 12, 2006, at 8:11 PM, John Sisson wrote:
> >>
> >> > How scalable would this be?  I would imagine there would be
> >> > applications that may create thousands of jobs (possibly per day).
> >> > Wouldn't startup be slow if we had to de-serialize thousands of
> >> > jobs at startup in the process of loading all the GBeans that
> >> > represent the jobs.  Not having looked at quartz myself, it seems
> >> > it would be much better to have jobs in a database.  For example,
> >> > thousands of Jobs could be created that aren't to be executed until
> >> > next year.   I would expect that a job management engine would
> >> > optimize processing, e.g. only read jobs from the database into
> >> > memory that are to be executed today or in the next hour.
> >>
> >>
> >> And that config.xml file is going to get mighty large, so every time
> >> someone makes a small change we are writing out all the jobs...
> >>
> >> -dain
> >>
> >
> >
> >
>

Mime
View raw message