I am not comparing it to queues. I am comparing both possible performance
solutions to the original code.

Also: A combination of these codes is not possible. I either I ack later
(slow), or I ack with a dummy status. This is not "how it should be", but it
does speed things up.

== Rene


-----Original Message-----
From: Nikos Balkanas [mailto:nbalka...@gmail.com] 
Sent: Sunday, 22 August, 2010 23:16
To: Rene Kluwen; devel@kannel.org
Subject: Re: smppbox bulk sms: slow reception from a client

Looks good. This is how it should be. But you need queues to implement this,

otherwise if bb goes down you will loose the SMS, while reporting to the 
ESME that it was accepted.

Besides it is unrelated to queue functionality, so why do you compare it to 
queues?

Nikos
----- Original Message ----- 
From: "Rene Kluwen" <rene.klu...@chimit.nl>
To: <devel@kannel.org>
Sent: Sunday, August 22, 2010 10:03 PM
Subject: FW: smppbox bulk sms: slow reception from a client


> Sorry, forgot to copy the list.
>
> -----Original Message-----
> From: Rene Kluwen [mailto:rene.klu...@chimit.nl]
> Sent: Sunday, 22 August, 2010 20:53
> To: 'Hillel Bilman'; 'Davit Mirzoyan'; 'Alvaro Cornejo'; 'Nikos Balkanas';
> 'ad...@impexrur.pl'
> Subject: RE: smppbox bulk sms: slow reception from a client
>
> For the ones who are worried about smppbox performance. Here is something
> that I believe in better than the queue implementation (like in my earlier
> post of today).
>
> At some point in time, I made smppbox wait for a bearerbox ack before
> acknowledging the message back to the ESME and vice versa. In the 
> following
> patch, I turned that back again. I immediately acknowledge the message,
> irregardless what it's relaying status later is going to be.
>
> If you have problems with smppbox and/or slow performance, this patch 
> might
> be for you. I made the patch in such a manner that it is easy to make a
> configuration option for this, in a later stage.
>
> Please test.
>
> == Rene
>
>
> -----Original Message-----
> From: Hillel Bilman [mailto:hbil...@ecommunicate.biz]
> Sent: Sunday, 22 August, 2010 18:59
> To: rene.klu...@chimit.nl
> Cc: devel@kannel.org
> Subject: RE: smppbox bulk sms: slow reception from a client
>
> Thanks for the update and to Chimit for smppbox in general.
>
> To take up the discussion from the user group, you mentioned a great idea 
> to
> have another set of queues that smppbox only uses.
> To add to this, it would be great to have the same set of queues where you
> can set priority and range 0-3 is allowed.  Then this prevents your 
> smppbox
> flooding bearer box and also you can far more easily isolate problems from
> smppbox.
>
> Regards
>
>
>
> 




Reply via email to