Re: What you get is what you want

Quartz wrote:
>>we could add 
>>a blocking_enqueue method to QueueIF that will guarantee that the 
>>enqueued event will be delivered, or at least, will not be dropped. 
> 
> 
> Not only that, but that is the only viable back-pressure mecanism I know of.
> 
> I defined a sub interface of SinkIF, so that stages are not forced to have a blocking_enqueue
> capable queue.
> 

I'm agree with you.  I think also that it's a good idea for 
compatibility reason to define a BlockingSinkIF that extends SinkIF. 
There is many classses that actually implements SinkIF like 
ATcpConnection, aTLSConnection, GnutellaConnection, etc; thus we will 
not have to modify these classes (it would not be true if we modify 
instead SinkIF).

> 
>>This mean that others ThreadManager must be created, because actuals TM 
>>are not conceived with this in mind and will not perform efficiently.
> 
> 
> The queue imlementation NEEDS to see the thread manager in order to ask it to perform blocking
> actions 

Maybe.  I think that there is many ways to arvertise the TM that a 
thread is blocked in an enqueue operation.

Another possibility, is that we create a class SandstormThread or 
SandstormThreadGroup that have a field backPressureFlag.  This flag is 
set to true when we invoke method blocking_enqueue and the queue is 
full.  TM and/or ThreadPoolController could check this flag before 
allocating a new thread.

A more elaborate possibility could be to use the graph (with the help of 
StageGraph and StageEdge) of all stages to determine exactly where 
allocate and schedule our threads.  Contrary to other proposed 
solutions, this one is proactive instead of reactive.  That is, it could 
be possible to balance the system ressources before a queue become full.

(the tm would take note of the blocking thread and not adjust priority 
nor thread pool or
> anything else, because the stage actually isn't that heavy loaded (given it's queue would fill
> up))

Exactly.

> [...]
> Hope this hint helps. Because to me, all these are mandatory to have blocking_enqueue (beside the
> timeout implementation in it, of course...).

Thanks for you help.  Like I already said, there is many ways to achieve 
that.  Now, knowing that all is a question of compromise, I am wondering 
what solution is the more appropriate...

Jean





-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click