You see the dlr arrived before kannel created it. If you have log-level on 0, on the smsc logs you will probably see the deliver_sm with the dlr before the submit_sm_resp.
Try my patch, it should solve your problem... Regards, Alejandro On Sun, Oct 25, 2009 at 1:52 AM, Nicolas Dagnet <[email protected]> wrote: > More precisions, with date/time added in dlr table : > > > > For one precise SMS with DLR stuck, log shows : > > 2009-10-25 01:02:33 [16033] [7] DEBUG: DLR[mysql]: Looking for DLR > smsc=smppft, ts=2015262914, dst=33679261445, type=4 > > 2009-10-25 01:02:33 [16033] [7] ERROR: SMPP[smppft]: got DLR but could not > find message or was not interested in it id<2015262914> dst<33679261445>, > type<4> > > 2009-10-25 01:02:33 [16033] [7] DEBUG: DLR[mysql]: Looking for DLR > smsc=smppft, ts=2015262914, dst=33679261445, type=1 > > 2009-10-25 01:02:33 [16033] [7] ERROR: SMPP[smppft]: got DLR but could not > find message or was not interested in it id<2015262914> dst<33679261445>, > type<1> > > 2009-10-25 01:02:33 [16033] [6] DEBUG: DLR[mysql]: Adding DLR smsc=smppft, > ts=2015262914, src=97531, dst=33679261445, mask=31, boxc= > > > > And in dlr table for ts=2015262914, the date/time is : 2009-10-25 01:02:34 > > > > This time, for 20 000 SMS campaign, I have 41 DLR stuck. > > > > Keep going on… and stop spamming the list ;-) > > > > BR, > > Nicolas > > > > *De :* Alejandro Guerrieri [mailto:[email protected]] > *Envoyé :* dimanche 25 octobre 2009 00:38 > *À :* Nikos Balkanas > > *Cc :* Alvaro Cornejo; Nicolas Dagnet; [email protected] > *Objet :* Re: Strange behaviour handling DLR > > > > Well, it's probably because of the way data is handled at the > aggregators... I can tell you it happens: we've checked the timestamps at > the moment and concluded that the reason was that dlrs arrived before the > submit_sm_resp. Since we started using the patch we've never had that > problem again. > > > > What my patch do is, if the dlr is not found, to sleep an amount of time > (configurable) and retry the db query up to N times (configurable as well) > to see if it's available. > > > > Regards, > > > > Alejandro > > 2009/10/24 Nikos Balkanas <[email protected]> > > Wow! Talking about deliveryΒ faster thanΒ the speed of light! It should ran > backwards in time :-) > > Β > > Is the SMS actually delivered to the destination mobileΒ while > submit_sm_resp is still pending? > > Β > > Timestamps would really help clear if this is the case. > > Β > > In your patch there is a thread delay while implementing this sleep. I've > noticed that you wake up when you receive something from the thread, but it > could be another PDU for another SMS, not necessarily the submit_sm_resp you > are waiting. Are these PDUs routed correctly? Given that there is a single > thread for each smsc connection, is there a performance penalty to the > thread? > > Β > > Your patch seems essential, why it was not incorporated in the CVS? > > Β > > BR, > > Nikos > > ----- Original Message ----- > > *From:* Alejandro Guerrieri <[email protected]> > > *To:* Nikos Balkanas <[email protected]> > > *Cc:* Alvaro Cornejo <[email protected]> ; Nicolas > Dagnet<[email protected]>; > [email protected] > > *Sent:* Saturday, October 24, 2009 6:11 PM > > *Subject:* Re: Strange behaviour handling DLR > > > > We had that very same problem. It happened to us with some aggregators: on > some cases, they've sent the DLR _before_ the submit_sm_resp arrived, so > when the DLR hits kannel the record is not yet created on the DB and it's > ignored. > > > > When the submit_sm_resp finally arrives and the DLR record is created (only > a few milliseconds later usually) it remains there forever. > > > > I've made a simple patch time ago to deal with this problem (posted it to > the list as well). > > > > Check here: > > > > http://www.blogalex.com/archives/132 > > > > I've been using it since then with no issues at all. > > > > Regards, > > > > Alejandro > > 2009/10/24 Nikos Balkanas <[email protected]> > > Hi, > > This is rather a question for Mysql administration. If inserts (same server > or LAN) delay more than WAN tcp/ip + delivery from your SMSc, then you have > some serious MySQL issues. > > However, you are only guessing about the cause. It could be something > entirely different, i.e. Mysql downtime when inserting, dropped connections, > etc. To verify your hypothesis, do a query after a few minutes and if the > insert is slow, mismatched DLRs should still be in the database (status 0). > If you also add a column with a timestamp, you could compare timestamp with > DLR delivery from logs. > > I have just submitted a patch that increases database warning logging, > which might be helpful. > > To benchmark your mysql installation, run the same 20K SMS over fakesmsc. > It is expeted to loose a few there, since DLRs are instantaneous, but it > should give you an idea of your handling capacity. > > BR, > Nikos > ----- Original Message ----- From: "Alvaro Cornejo" < > [email protected]> > To: "Nicolas Dagnet" <[email protected]> > Cc: <[email protected]> > Sent: Saturday, October 24, 2009 5:11 PM > Subject: Re: Strange behaviour handling DLR > > > > > It is/(was?) a known issue. Some time ago there were a thread about it > > but couldΞžβ€žnt remember the final. > > > > Search the mailing list. > > It might be a issue with an overloaded mysql also. > > In any case, post your configs/version/logs > > Regards > > Alvaro > > On Sat, Oct 24, 2009 at 9:00 AM, Nicolas Dagnet <[email protected]> wrote: > > Hello, > > I have a very strange behavior when dealing with sending a 20k SMS campaign > (for example). > Sometimes, DLR are stuck in MySQL, even if these DLR are really sent by my > operator (Mblox). > > In fact, it seems that the DLR are incoming before kannel has enough time > to > insert the DLR in MySQL (see log below). > > I tried with dlr-storage = internal, but the situation is equal. > Number of SMS concerned : about 0.3 to 0.6% in the few tests I made. > > Does anyone had to deal with such a problem ? > > Thanks > > Log : > Here is a dump for a DLR stuck in DB : > > 2009-10-23 13:29:04 [2399] [7] DEBUG: data: 69 64 3a 32 32 34 30 34 32 > 33 36 36 35 20 73 75 id:2240423665 su > 2009-10-23 13:29:04 [2399] [7] DEBUG: DLR[mysql]: Looking for DLR > smsc=smppft, ts=2240423665, dst=33679261445, type=4 > 2009-10-23 13:29:04 [2399] [7] ERROR: SMPP[smppft]: got DLR but could not > find message or was not interested in it id<2240423665> dst<33679261445>, > type<4> > 2009-10-23 13:29:05 [2399] [7] DEBUG: data: 69 64 3a 32 32 34 30 34 32 > 33 36 36 35 20 73 75 id:2240423665 su > 2009-10-23 13:29:05 [2399] [7] DEBUG: DLR[mysql]: Looking for DLR > smsc=smppft, ts=2240423665, dst=33679261445, type=1 > 2009-10-23 13:29:05 [2399] [7] ERROR: SMPP[smppft]: got DLR but could not > find message or was not interested in it id<2240423665> dst<33679261445>, > type<1> > 2009-10-23 13:29:06 [2399] [8] DEBUG: DLR[mysql]: Adding DLR smsc=smppft, > ts=2240423665, src=13579, dst=33679261445, mask=31, boxc= > > > > > > > > > -- > > |-----------------------------------------------------------------------------------------------------------------| > > EnvΞžΒ½e y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier > celular y Nextel > en el PerΞŸ , MΞžΞ‰xico y en mas de 180 paises. Use aplicaciones 2 vias via > > > > SMS y GPRS online > Ξ’Β Ξ’Β Ξ’Β Ξ’Β Ξ’Β Ξ’Β Visitenos en www.perusms.NET > www.smsglobal.com.mx y > www.pravcom.com > > > > >
