Logging to one process from thousands: How does it work?

[Richard Cameron]

On 3 Jan 2006, at 20:02, David Hopwood wrote:

> Raimo Niskanen wrote:
>> A process that sends to a
>> receiver having a large receive queue gets punished
>> with a large reduction (number of function calls)
>> count for the send operation
>
> This makes the problem less likely to occur, but it isn't  
> necessarily enough
> to prevent a message backlog in all cases.

If the amount of punishment a sender received increased with the  
queue length, would the maximum backlog asymptotically tend to a  
finite limit in the worst case?

That's probably only true if you assume that the per-timeslice  
production and service rates are constant, which might very well be  
complete rubbish. I'm guessing the cost of pattern matching to do the  
"receive" on the message queue is going to increase with the queue  
length too. So, maybe it comes down to making sure that the  
punishments grow faster than the cost of performing the receives?

Any idea what that cost is? Is the worst case linear, or can the  
virtual machine optimise for all cases?

> In principle, the right way to
> handle this is to provide back-pressure to the message sources,  
> i.e. to allow
> the logging operation to block in each source. The simplest way to  
> do that is
> to use bounded queues.

Sounds like the reduction count punishment is a good way of providing  
that back-pressure, but still having "soft realtime" properties which  
more gradually degrade under load.

I think with bounded queues it might also be possible to dream up  
scenarios where deadlocks can occur. What about a simple client/ 
server arrangement where the client sends a message to the server  
then happens to receive some other external (and unrelated) message  
which fills up its queue before the server responds. The server can't  
reply (its ! now blocks?) and the client can't process its message  
queue as it's sitting waiting for a reply from the server.

Richard.