Just a quick followup, from my reading Quartz does seem to support a lot of these needs, including thread pooling and canceling tasks. I'm willing to bet they support timeouts too.
I'm not sure how much of this we expose in Taskomatic, such as the ability to schedule a task without having it pre-defined in the rhn conf files, so I'd still like to hear back from our resident taskomatic guru on initial thoughts of how feasible this would be. On Tue, 2009-01-27 at 16:12 -0500, Jason Dobies wrote: > As I was working on the performance enhancements for the SSM bulk > channel subscription change > (https://bugzilla.redhat.com/show_bug.cgi?id=469984) I started to wonder > if our approach to the SSM in general could use a little work. Given the > fact that there can potentially be a large number of servers selected, I > think the whole setup lends itself towards an asynchronous model. > > I see it going something like the following: > - At least for the first pass, use the workflow of the existing SSM > pages as they are today (ported to Java, and we can reevaluate each > instance as needed). > > - After selecting to confirm whatever action is being done, instead of > waiting for the action to finish before returning, drop the user to a > generic "SSM Action History" (action may be a bad choice of words here, > but I'm open) page. > > - This page contains a list of each thing the user did against systems > in the SSM. The list can contain: > -- Rough description of what the action was (e.g. "Change channel > subscriptions" or "Delete servers"). Perhaps even editable by the user > at the time of confirming the action. > -- Current status of the action (e.g. "In Progress", "Completed", "Timed > Out", "Cancelled") > -- Timestamp of when started and/or completed and/or last updated. > -- Progress complete. Even if this is just done in increments of, say, > 5%, I'd like to be able to show that the action is at least doing > something. Chunking the updates to this will prevent an update per > server in the set and be able to provide feedback without adding too > much extra load to the DB. > -- Some sort of link to the individual event scheduled on each server, > if applicable. We might even be able to have some logic that looks at > the individual events so when viewing the details of one of these SSM > actions, we can see which servers ran into errors. I think with a little > extra effort this sort of thing can provide much more visibility into > SSM operations than currently provided. This would also be pretty > important given the volatility of the servers in the SSM; since they > aren't named (in other words, reasonably static) groups, I think it'd be > helpful to keep the association of which SSM actions go with which > servers. > > We could even throw a quick status near the SSM "Manage" and "Clear" > buttons to indicate how many actions are currently in progress, so as > the user continues to navigate around they have a quick indicator of if > an action completes. > > 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. > > 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? > > Otherwise, outside of EJBs, I'm not sure of any other options (besides > just spinning off my own threads, but I doubt we want to go that > route). > > Thoughts? > > - J > > > -- Jason Dobies ([email protected]) RHN Satellite & Spacewalk RHCE# 805008743336126 Freenode: jdob @ #spacewalk, #spacewalk-devel _______________________________________________ Spacewalk-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-devel
