One thing that might be nice would be a limit to the number of items allowed in a queue. We might want to jsut start dropping the oldest at a certain point. The only problem with this is that remove requests to auxiliaries can be very important. However, the possibility of runnnig out of memory is worse.
Most appliations cannot perform fast enough to swamp the cache queues, but I can make a test program do it. We should have some sort of cap on the queue size and then just start dropping the eldest when full. There is no other good solution. (We might want to add some parameter like, removeall fom the auxiliary when then point it reached. I'm not sure where this kind of thing should be configured though.) Aaron --- Aaron Smuts <[EMAIL PROTECTED]> wrote: > The queue works nicely as is. If we make radical > changes it should be in the experiemental section. > > The problem you are addressing the that each region > will get its own queue with its own thread. I guess > we want to be able to limit the number of threads > used. > > We could have one thread polling all the queues and > then giving what it takes to the pooled executor. > This > might be the easiest conversion. > > What exactly do you have in mind. > > By the way, my idea for converting the grouping > functionality will not work. I'm going to leave it > as > is until we come up with something better. We > should > try to decide what needs to be done before we move > for > a release. > > Aaron > > > The problem is that each region will gets its own > > --- Travis Savo <[EMAIL PROTECTED]> wrote: > > We discussed in the past a Thread Throttle to > limit > > the number of Threads > > for EventQueues. > > > > Really I think the right solution is a Thread > Pool, > > (and/or a Runnable > > Queue). If we convert the EventQueue to a Runnable > > and pull threads from the > > pool as they become available (and/or stick the > > Runnables in a queue for > > processing, either way we achieve the same effect: > > The threads, of which > > there are a limited number, get reused), this > > eliminates the need for a > > throttle, and makes much better reuse of Threads, > so > > 'keeping it alive for a > > minute' is no longer necessary: The life of the > > unused Thread itself can be > > handled by the Pool. > > > > Does this sound like the right solution to you? Or > > at least headed in the > > direction of the right solution? > > > > I just wanted to check with you before I start > down > > a path that won't lead > > to everyone's consent. > > > > -Travis Savo <[EMAIL PROTECTED]> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > __________________________________ > Do you Yahoo!? > Vote for the stars of Yahoo!'s next ad campaign! > http://advision.webevents.yahoo.com/yahoo/votelifeengine/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
