> -----Urspr�ngliche Nachricht----- > Von: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Gesendet: Montag, 25. Februar 2002 14:17 > An: Avalon Developers List > Betreff: Re: event queue improvment > > > Emperor wrote: > > hi, > > > > I had a look at the event queue implementation and I think a method > > that blocks until n elements can be enqueued could be very useful. > > > > For example, you could have a full queue of requests and an > > interceptor that adds requests to the queue. Using the > block method, > > the interceptor would stop intercepting request when the queue is > > full, which would be the logical behavior of an overloaded system. > > > Queue is an interface. If you want an implementation that > takes care of this semantic, more power to you. I don't > think it should be *Yet another method*. > > In a complex event routing system, you really don't want > blocking at all. The reason is that depending on your thread > manager, you may have fewer threads than Queues. In such a > case it is more efficient to use those finite amount of > threads to pull the events in a non-blocking manner. If > there are no events, move on to the next queue. >
I agree that blocking is bad in normal situations but I'm talking about event routing on an overloaded system (see example). How should the sender react when the queue is full? I think then blocking is the best method. Nils -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
