Re: A new queue has come

> My DynamicArrayBlockingQueue should be very effecient in situation 
> without a lot of contention.

I don't see how. Could you pass that by me again?
...unless you're still thinking about saving arraycopies,
because then I don't wanna know ;) I use a drum list.


> So, we could create a mecanism where Sandstorm detect dynamically the 
> queue contention and change on the fly the queue implementation to 
> improve performance.  (Sandstorm will do this operation only rarely)

General comment on dynamic behaviors and predicitability:
Although it looks cool, it kinda add 'zeros' (Laplace maths) in the system's transfer function.
These zeros may get dangerously close to the right side of the plane when combined.
That's the kind of assemly that create oscillations in memory/gc and CPU throughput once they are
in synergy with the remaining components. Also, systems that change behavior according to load
tend to sync all together of course, leading to a disastrous mega oscillation between good and bad
throughput, unless careful dampening of those behavioral changes is coded (i.e. changing behavior
at slower pace than the longest response time to any behavior change, the goal being to let the
system stabilise before changing behaviors).Given such complexity, engineers tend to let the cool
stuff behind and code it simple and linear.

Sandstorm has a lot of dynamic behaviors: thread pool sizes, thread priority, rate controllers,
batch controllers (which already oscillates between 90 and 98 % of max throughput).

I'm not saying queue switching/proxying is not a good idea. Just keep the above in mind. Beside
keeping it simple (which I keep forgetting time to time!), we should protect predictability.



> I have already thinking about that.  Why don't create methods 
> QueueIF.dequeue_all(List list) and EventHandlerIF.handleEvents(List 
> list).  We could specify in the EventHandlerIF specification that this 
> list cannot be cached by user.  Like this, we could reuse our list 
> (ArrayList) and don't create QueueElementIF array all the time.  Seem a 
> good idea.

If I would rather lend an array/offset/length to handlers than a list, 
unless the list is reused, cleared and refilled efficiently (upon dequeue(n)).
Same difference, both list and array can be reused.

The difference between lending and giving the list/array is a major semantic change.
Stages were allowed to use the array as is, and even ship it as one single object to perform work,
even pass this to other threads/sinks. That is a lot of handlers to refactor...

I chose not to reuse the array, because handlers would create an new array anyway it they needed
their own. I guess a handler could have a 'boolean giveNewArray()' method to tell the TM how to
pass events. Just as good a tip as the current SingleThreadedEventHandlerIF marker interface.




		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/