A bit of caution: make sure that you're actually facing that problem. My patch could degrade performance if you're sustaining heavy traffic. Specially if you get a lot of unmatched DLR's: The patch will cause the receiving thread to sleep for the number of milliseconds you configured. During that time the thread won't do anything else.
If you have low traffic (a few msgs/second) this shouldn't be an issue, but if you're on the hundreds-per-second MO's, I wouldn't recommend you to use it. If in doubt, try it and sniff the network: if you see "buffer full" or "zero window" errors on the wire, disable it. Regards, Alex On Mon, Sep 13, 2010 at 12:14 PM, Jarratt Ingram < jarr...@ambientmobile.co.za> wrote: > Hi Alex, > > Thank you, I have seen your patch I thought it was related to sql db > related messages only. > I will compile the latest version from svn and add our two DLR patches as I > need the throttling patch and DB DLR functionality which is not in the > current Fedora rpm as far as i know. > > I will let everybody know once completed > > Kind Regards > Jarratt > > > > > On 09/13/2010 11:55 AM, Alejandro Guerrieri wrote: > > Some aggregators have issues with the "timeline" of DLR's. > > It happened to us with one of them, the DLR's arrive before the > submit_sm_resp, so when the delivery receipt arrives, the DLR is not yet > stored on the DB, thus it fails. > > Check the logs to see if that's the case. The entry writing the DLR to > the DB should be _before_ the "got DLR but could not find message..." error. > > If that's the case, I've a small patch to retry the DLR's later, but > should be used with caution (if you set the delay too high, under heavy > traffic the retries would hold the thread for extra time and will degrade > performance) > > Hope it helps, > > Alex > > > On Mon, Sep 13, 2010 at 11:37 AM, Jarratt Ingram < > jarr...@ambientmobile.co.za> wrote: > >> Good Morning All, >> >> I am experiencing some small issues with the DLR mechanism in my current >> Kannel configuration, >> >> RPM version of Kannel on Fedora 13 64bit >> DLR is currently set to internal storage, >> msg-id-type is default as it is not explicitly set. >> >> I have two SMPP connections to a provider both have the same smsc-id and >> are both setup with transceiver-mode = 1 >> The DLR processing works for 90% of the time and every now and again i get >> the following in the logs >> >> 2010-09-13 11:11:13 [7277] [6] ERROR: SMPP[3]: got DLR but could not find >> message or was not interested in it id<27/00/4d599338/1127829048804> >> dst<27829048804>, type<2> >> >> This then leaves the message in an ACK/ state and never gets updated to >> sent or undelivered, based on the message above does this mean i should >> rather set the msg-id-type = 0x02 ? i am assuming that Kannel is able to >> correctly determine the DLR's 90% of the time and gets stuck every now and >> again ? >> >> Also does the Kannel status page EG: DLR: 1247 queued, using internal >> storage >> directly relate to this i.e id a DLR is not found does the DLR queue get >> reduced by 1 ? As i have had over 1k DLR's pending for a few days now >> >> Any help would be appreciated, >> >> Kind regards >> Jarratt >> >> >> > >
