It's not a concurrency bug, your aggregator is probably sending the DLR's deliver_sm before sending the submit_sm_resp.
I've seen it happening on some aggregators (maybe because of their load-balancers processing the messages on different nodes? Can't tell for sure). I have a simple patch that retries the dlr-find a given number of times, but it poses a performance penalty and it's not intended to be used under heavy traffic. Regards, Alex On Wed, Feb 9, 2011 at 9:35 AM, Sayed Hadi Rastgou Haghi < [email protected]> wrote: > Dear Kannel Developers, > > I found a concurrency BUG in DLR Code. > > > 2011-02-09 11:30:26 [29361] [27] DEBUG: DLR[mysql]: Looking for DLR > smsc=mtn1, ts=1613732592, dst=989372474050, type=2 > 2011-02-09 11:30:26 [29361] [27] DEBUG: sql: SELECT mask, service, url, > source, destination, boxc FROM dlr WHERE smsc='SMSC' AND ts='1613732592'; > 2011-02-09 11:30:26 [29361] [27] ERROR: SMPP[SMSC]: got DLR but could not > find message or was not interested in it id<1613732592> dst<DST>, type<2> > 2011-02-09 11:30:26 [29361] [26] DEBUG: DLR[mysql]: Adding DLR smsc=SMSC, > ts=1613732592, src=SRC, dst=DST, mask=31, boxc=13013 > 2011-02-09 11:30:26 [29361] [26] DEBUG: sql: INSERT INTO dlr (smsc, ts, > source, destination, service, url, mask, boxc, status) VALUES (...); > > *dlr_find* method got calls before *dlr_add!* > > -- > Sincerely, > > Sayed Hadi Rastgou Haghi > >
