On Wed, Jan 28, 2009 at 1:01 AM, Partha Aji <[email protected]> wrote: > >>> 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...
If the schema needs changing, I'm ok with making the necessary changes. > 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.. -1 let's not throw in the sledgehammer yet. :) > > 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,. ) Sounds reasonable, definitely worth looking into. _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
