Re: smsbox to bearerbox ack / nack
"Alexander Malysh" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, no you miss the point. ack_success and ac_failed are the final states and therefor bearerbox drops these messages from the store and queue. When I commited this patch I told that it misses ack_failed_tmp that is used for the purpose you describe. That means when bearerbox receive ack with ack_failed_tmp (temporarely) bearerbox will then do retry for this message. I will try to merge this bit this week. Am 02.11.2006, 12:56 Uhr, schrieb Ben Suffolk <[email protected]>: > Hi, > > I have been doing some investigation into tighter integration of my > application with kannel. As such I have been writing some applications > that communicate directly with bearerbox, connecting to the smsbox port. > For sake of simplicity lets call my app mysmsbox. > > What I noticed was that when a message is sent from bearebox it stays in > the storefile until an ack is sent back. This is great if mysmsbox dies > before it has done processing the message. > > But I also notice that if you send ack_success or ack_failed back to > bearerbox it seems to make no difference. > > Ideally I think it would be better if you sent back ack_failed for > bearebox to requeue the message (possibly after some small time delay). > This way if you were unable to process the message for some reason a > different mysmsbox has the chance to do it. Under the current situation > you have to wait for the current box to be in a situation where it can > now process the message, or it needs to restart in order to allow > another mysmsbox a chance. > > In the situation where you only have 1 smsbox type app connected it > really makes no difference. But if you are looking for a more resilient > solution then multiple smsbox apps on different servers is the way > forward, but only if you have a way of failing messages over from one > smsbox to another. > > I'd be interested in peoples comments, and how easy they think it will > be to implement. > > Regards > > Ben > > > -- Thanks, Alex