Re: Strange smsbox/bearerbox problem : SMS messages not being sent

Hi

We have a queue load balancer in front of Kannel, that through a 
"statusbox" monitors Kannel, and knows extended information about each 
gateway that kannel is connected to. This way we can control the throughput 
of any of the Kannel connections, as well as load balance them

If messages are going to throttle I would rather see the throttling 
happening before a messages is commited to a particular smsc, so one can 
reroute it if need be.

nisan

At 03:26 PM 6/19/03 +0000, Bruno Rodrigues wrote:
>Alexander Malysh <[email protected]> wrote:
> > Hi Bruno,
> >
> > Am Donnerstag, 19. Juni 2003 16:03 schrieb Bruno Rodrigues:
> >> Stipe Tolj <[email protected]> wrote:
> >> > Bruno Rodrigues wrote:
> >> >> You need to "sleep" right after sending the message for it to work.
> >> >> We can have configuration code in smsccon abstraction and only that
> >> >> "usleep" inside smsc_* modules.
> >> >
> >> > why not having the whole throttling mechanism inside the abstracted
> >> > layer?
> >> >
> >> > This would also help in AT2 module, because most GSM modems don't like
> >> > be hit by 100 msg/sec. ;)
> >>
> >> If I'm not mistaken, EMI has a list feed by SMSConn or something and
> >> smsc_emi reads it and feeds it into smsc, so you can't sleep before
> >> filling that list, you have to sleep right after sending the message (in
> >> emi case, sleep AFTER receives ack) to take in consideration received
> >> messages and  other particularities.
> >>
> >> As I told, sleep is one line, just copy/paste it into every module in
> >> the right place and move microsecond calculation and config file
> >> processing to smscconn.
> >
> > hmm, sleep is very bad (imho). In this sleep time you can maybe handle 100
> > delivery receipts instead just sleeping. It would be great to add 
> abstracted
> > bandwidth calculation code to kannel and then send only if bandwidth allow
> > this.
>
>EMI uses one thread for sending and another for receiving. This latter
>sends itself ACKs by managing locking with send thread.
>In this case, its ok to sleep in sending thread because it won't affect
>receiving one.
>
>I even once needed something to limit incoming messages because I was
>receiving more messages than the other java service could handle, and
>store.lock was growing madly with mt-reply messages. If we have some
>kind of throthling in input, we can let them stay in smsc queue instead
>of kannel queue. Maybe a automatic throtling in smsc if queue-out larger
>than something. I don'tknow...
>
> >