There may be a possibility on the lack of ram on your machine maybe? On our production machine, there are times during high traffic hours where apache plus kannel was eating up almost everything in terms of ram and cpu. Pushing close to the kind of traffic you are talking about as well. Didn't run into the too many concurrent allocations issue after using a --malloc=native flag since we went live on May 31st.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bruno David Rodrigues Sent: Wednesday, June 12, 2002 4:23 PM To: Aarno Syv?en Cc: Paul Keogh; [EMAIL PROTECTED] Subject: Re: EMI: Serious Problem PANIC: Too many concurrent allocations On Wed, 2002-06-05 at 09:39, Aarno Syv�nen wrote: > 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 I've been looking at the code and I can't find what I've been looking for :((( On May 3, as I told you, I've sent 200k messages through emi2 (30msg/sec I think). On that day I've tryed my post-xml code. As 100k per post gave me http timeout, I've send 10k at a time, 20 posts. At the end, I've lost 25% of the messages (smsbox logs vs bearerbox logs). Could it be from this code ? I did got store.lock with 30 or 40 MB. As I saw in the code, even if this code is activated, we get a DROPPED in logs, right ? I didn't care much at the time, but there's somewhere a bug looking for us.....
