On Wed, Jan 28, 2009 at 10:09 AM, Justin Sherrill <jsher...@redhat.com> wrote: > Jesus M. Rodriguez wrote: >> 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. >> > > We could do that, although after a restart something would have to kick > off the event in the message queue again (If i understand it correctly, > could be wrong here). > >> 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. > > usually not that often. But with some of our operations taking *days* > on 1,000s of systems it becomes very possible that a restart may be > needed.
*days*? that's just wrong and busted :) so engineering a solution that will allow operations that are taking days is the wrong thing to fix IMO :) jesus _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
