[Opensource] RE: JobRefactoring [WAS Future Code for Expresso 5.1 and beyond]

[Michael Rimov]

At 08:24 AM 11/7/2002 -0700, you wrote:
> > >
> > > I have worked with RMI in the past and found it unsatisfying
> > and would like
> > > to recommend a JMS server solution but to be fair in my vote, I
> > have never
> > > worked with JMS before so it might be just as much or more of a
> > pain then
> > > RMI.  Any comments from folks who have done a JMS
> > implementation, would this
> > > be a good use of JMS?
> > >
> > > Kris
> >
> > A JMS solution would presuppose the existance of open source JMS Provider
> > solution. JMS is rather like J2EE application server somebody has to
> > write the back end solution, because JMS is just a standard
> > API wrapper to enterprise information systems.
> >
> > However if the JobHandler was refactered to use a plugable implementation,
> > using an interface, as described in the new design above,
> > then I can not  see why JMS Job Handler would not work for those
> > software houses with the ££££$$$$.
>
>Whether it is refactored into a plugable implementation or not, this team
>will still have to come up with at least one implementation and from what I
>have seen so far and with my own experience I would suggest an RMI
>implementation.

True.  But distributed job serving presents its own problems and thus, if 
we can get an in-VM job server that works correctly, we will be a step in 
the right direction to get a proper distributed Job server.  That's why I 
proposed the steps earlier.


>But I'm not so concerned with debating which implemenation we go with, seems
>like we should focus on what this API might look like for that
>implemenation..... along with general refactoring/fixing of the current Job
>Handler.

Yes, I agree that at this point, a proper system would be most helpful.

I had a couple of thoughts:

Job refactoring:
-Instead of a class derived from Job... how about making it ANY 
java.lang.Object class?  Its metadata would be such:
         method name="whatever method name"
         number of parameters:  0-*
         for each parameter:
                 parameter type
                 parameter value

This would be virtually identical to how Digester works, and dealing with 
it has been fantastic.  This gives us typesafe parameters at the job level, 
and gives us the flexibility to make anything with a method a job.  Could 
be pretty slick.  If we declare the class in the Schema object, then we 
still provide the same security services as we have before.  So I don't see 
us losing any functionality.

We could then provide a 'job' service component that provides all the 
functionality such as finish() that we would normally want for any job.  So 
we'd go with an 'aggregate-ish' like pattern rather than derivation.

What do you think?

Components:

I think we're looking at a few components that we could break things into:

JobQueue:  Where we add the job parameters, add new jobs.  Etc.  This would 
be the interface that we talk to to get a job started.  This would take 
place of the Job DBObjects that we now know.  [The underlying 
implementation might be a dbobject, but that is separate]  Number of 
instances:  1 queue per context if the context wants jobs available.

JobRunner:  This is the object that actually acts as the 'processing 
container' where the job is actually run.  JobRunner implementations can be 
in-VM or outside the virtual machine.  Number of instances:  Possibly 
Many.  Depends on how many job runners you want on how many machines.  Job 
Runner would signal its own status to Job Server. [Report errors, report 
completion, etc]

Job Server: This object would be in charge of the persistence of the 
objects in the Job Queue [so in case of power failure, the queued jobs are 
not lost].  It would delegate jobs to the JobRunners, notify the Admin if 
it hadn't received a 'completed' signal from a JobRunner if there were 
sudden terminations/power failures in the server. Job server would also be 
responsible for scheduling algorithms for scheduled jobs.


>Where can we find a list of the known Job Handler bugs?

The ones that I am aware of. [And yes, these are vague, because I haven't 
been able to gather better information]

1 - Race conditions with multiple job servers.  That's because everything 
can talk with the queue and underlying persistence store.  Using the above 
component architecture will actually fix this issue.

2 - Startup Race condition.  Intermittent:  Error Field 'Status Code' does 
not exist. [It does exist, and I can't figure out why this is happening so far]

3 - Scheduling not working properly.  People are encountering lost jobs on 
the schedule.  It looks like Expresso 5.1 can require JDK 1.3+, so we could 
possibly switch to JDK 1.3's Timer mechanisms.  But haven't investigated this.

4 - Jobs failing to execute.  Some people are saying that their 
non-scheduled jobs are getting lost and not executing.  I haven't been able 
to replicate this unless the JobHandler fails to start due to bug #2 listed 
here.

That's all that I am aware of at this point.


>How do we divide
>the work on this component?

Good question. I'm working on the component architecture of Expresso for 
5.1, so I'm booked right now.  What I'm working on will make our Job 
refactoring much easier.  So bear with me for a bit :)

If you first want to see if you can figure out what's going on with Bugs 
2-4, perhaps that will give us better insight into the refactoring design.

The components that are going to need the highest priority are: Job Runner 
and Job Server.  JobQueue will be optional anyway since from an API 
standpoint, we  shouldn't remove the JobQueue dbobject until version 5.2 
[We would deprecate it for 5.1].  So Job Server will have to work with the 
JobQueue dbobject initially anyway.  And splitting it into a situation like 
this will fix Bug #1 anyway.

Sorry it took me so long to reply, you wrote a thoughtful message, and I 
thought it deserved a thoughtful response :)
                                                         -Mike