Jesus M. Rodriguez wrote:
On Tue, Jan 27, 2009 at 5:30 PM, Justin Sherrill <[email protected]> wrote:
Jesus Rodriguez wrote:
On Tue, Jan 27, 2009 at 04:12:43PM -0500, Jason Dobies wrote:
[snip]
Outside of what we track for a request, the big question is how to
thread off the work.
One possibility is taskomatic, which I'm not entirely familiar with. I
do see from the wiki that we have tasks scheduled for once a minute,
which I think is an acceptable delay before one of these SSM actions
begins to process.
taskomatic can run tasks that poll in any configuration. i.e. once a
minute, daily, etc.
I think we have to be able to allow more than one of these SSM actions
to take place concurrently, however there is a definite upper limit to
how many we should allow at once. We'll also need a mechanism to time
out these actions and potentially a way for a user-initiated cancel. I'm
not sure if it's possible to exercise this sort of set up through
taskomatic/quartz. Anyone familiar care to comment?
You can start a job using the MessageQueue. :) It was originally
written to send out emails, but we also used it to calcuate the errata cache
during login. It's as simple creating an appropriate Event class and
an Action (NOT a Struts Action) class.
I would vote against the MessageQueue because if you restart tomcat
you've lost all of your scheduling. Whereas if you were using
taskomatic, you still would have all the queued actions left in the DB.
Does that mean that the MessageQueue can't be enhanced to use
a database? Just because it doesn't right now doesn't mean it can't.
I was merely suggesting the MessageQueue as a starting point to avoid
inventing yet another threading system. It wouldn't be difficult
to back the queue with a db table.
And how often do you restart tomcat? on a dev system all the time sure.
But in a production server? and what happens if you lose all of the items
in the queue? what's the worse that has to happen? you restart them all?
all of that is annoying if the number is large and the process is cumbersome.
so let's not dismiss it entirely.
Good points, and I agree we should consider serializing the queue items.
We already have a table for Tasks that can be used with this:
rhnTaskQueue
Name Null? Type
----------------------------------------- --------
----------------------------
ORG_ID NOT NULL NUMBER
TASK_NAME NOT NULL VARCHAR2(64)
TASK_DATA NUMBER
PRIORITY NUMBER
EARLIEST NOT NULL DATE
this table is mapped nicely in Hibernate with the class "Task".
Right now this is used by taskomatic to pickup certain rows that have
the right "task_name" value but there isn't anything saying we couldn't
have the MessageQueue handle other types of tasks with different values
in "task_name" and use this table to track if it has work todo.
The other nice thing about using the MessageQueue is that is running
*within* tomcat so if we wanted to show status in the GUI we can talk
straight to the queue in memory without having to go out over xmlrpc or
to a DB table in a polling mechanism to track progress.
Taskomatic is great for 'scheduled' events that need to happen outside
the scope of a user's GUI action, but we did build the MessageQueue
specifically for projects just like what we are describing here.
Mike
--
Mike McCune
mmccune AT redhat.com
Engineering | Portland, OR
RHN Satellite | 650.567.9039x79248
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
