On Tue, Jan 27, 2009 at 5:30 PM, Justin Sherrill <jsher...@redhat.com> 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. jesus _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
