Let's see. On one hand you have a serial design, on the other a
multithreaded one. OK, not exactly multithreaded, but queued which will get
you ~80% of a true multithreaded design. Which one is faster, and more
robust under heavy traffic?
How much of a delay are you talking about? Any idea what is the offending
call(s)?
BR,
Nikos
----- Original Message -----
From: "Rene Kluwen" <rene.klu...@chimit.nl>
To: "'Hillel Bilman'" <hbil...@ecommunicate.biz>
Cc: <devel@kannel.org>
Sent: Sunday, August 22, 2010 9:15 PM
Subject: RE: smppbox bulk sms: slow reception from a client
I knew this wasn't a good idea. The overall performance is a lot slower
now.
Please find attached an smppbox implementation including queues (patch to
svn trunk).
I am myself -1 for this patch. But here you have it, for the ones that
want
to try.
== 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
