[Spacewalk-devel] SSM Asynchronous Actions
Jesus M. Rodriguez
jmrodri at gmail.com
Wed Jan 28 10:41:26 EST 2009
On Wed, Jan 28, 2009 at 10:09 AM, Justin Sherrill <jsherril at redhat.com> wrote:
> Jesus M. Rodriguez wrote:
>> On Tue, Jan 27, 2009 at 5:30 PM, Justin Sherrill <jsherril at redhat.com> wrote:
>>> Jesus Rodriguez wrote:
>>>> On Tue, Jan 27, 2009 at 04:12:43PM -0500, Jason Dobies wrote:
>>>>> 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
*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 :)
More information about the Spacewalk-devel