Re: EMI: Serious Problem PANIC: Too many concurrent allocations

Paul Keogh kirjoittaa tiistaina, 4. kesäkuuta 2002, kello 14:51:

> Yes, but when this is triggered bb_smscconn_receive () logs the event 
> and
> returns -1. All the SMSC drivers except HTTP ignore the return code from
> bb_smscconn_receive (). Therefore, the message is silently dropped from
> the application and the SMSC point of view. This is IMHO a bad thing and
> not something you could use in a production environment. I think a
> better solution would be to;
>
> * When possible, map the queue full event to an SMSC protocol error
> indicating a temporary resource shortage; otherwise fail the message
> with the most appropriate error code.
>
> * Introduce a flow control admin. message to tell the SMS box (and any 
> other
> clients using the SMS box interface) to stop/start sending messages. 
> The SMS
> box could in turn signal to the various sendsms applications that a 
> temporary
> resource shortage event has occurred (HTTP 503 maybe ?)
>
> * Use high and low watermark variables instead of maximum-queue-length. 
> This prevents
> thrashing around the maximum-queue-length value. A sort of SMS 
> hysteresis curve :-).

Maximum-queue-length is supposed to prevent crashing caused by too long 
queues.
Congestion control is used to *prevent* long queues. It is, of course, 
something Kannel
can use.

Aarno