But of all the solutions here, I think it would be easier for us to just
reuse rhnServerAction and that infrastructure.. Config* stuff is built
in ... We could probably reuse the Event History UI to do the
failed/pending actions/ rescheduling, all that is built in. Its almost
like 1
I dunno if its the longest but changing the base channel for a System
used to take ~30 secs per system.. So if the user asked the base channel
to be changed for 100 systems its almost 50 min to get that done easily
timing out the request..
Partha
Miroslav Suchý wrote:
Jason Dobies wrote:
As
On Wed, Jan 28, 2009 at 5:43 AM, Miroslav Suchý msu...@redhat.com wrote:
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
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
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
On Tue, Jan 27, 2009 at 05:11:19PM -0500, 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
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
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.
+1
I jsherrill were dicussing how we'd implement this
I started with
Table Queue -
On Tue, Jan 27, 2009 at 4:45 PM, Jason Dobies jason.dob...@redhat.com wrote:
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
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,
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
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
12 matches
Mail list logo
