Jesus M. Rodriguez wrote: > On Wed, Jan 28, 2009 at 10:09 AM, Justin Sherrill <[email protected]> wrote: >> 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. >>> >> 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 >
You have to be doing a lot of systems, but some actions can take a minute or more per system on a loaded satellite. There's some pl/sql that needs optimizing me thinks... > _______________________________________________ > Spacewalk-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/spacewalk-devel _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
