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".
One trouble we'll have with serializing using rhnTaskQueue table might
be with the 'type' of task data.
> TASK_DATA NUMBER
Lets take an example here.. Lets say I want to subscribe 100 config
channels to 100 systems. Now I 'd need task data to be a list of config
channels... For other operations I need task data to be something else
may be strings... One idea is to make task data a blob that stores json
ed value (I don't like this but it may be workable) in the DB...
I wonder if using something like MQ series or JMS where issues like
serialization to hard drive is taken care of is a better solution than a
home grown one..
In memory message queue is a good in the sense it'll let us pass in what
ever we want as TaskData. But I am not sure I like the temporary nature...
But of all the solutions here, I think it would be easier for us to just
reuse rhnServerAction and that infrastructure.. Config* stuff is built
in ... We could probably reuse the Event History UI to do the
failed/pending actions/ rescheduling, all that is built in. Its almost
like 1 query might to be changed for backend to ignore ssm-scheduled
task form rhnServerAction.. (I am sure I am trivializing by saying 1
query but it shouldn;t be too difficult to work around that,. )
Partha
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
