1) The patch modifies dlr.c and impacts dlr_find, which is called each time a dlr is fetched. I think it is the receiving thread and yes, if the dlr is not found there's a slight performance penalty since the thread would take longer than usual to process the MO (deliver_sm if we're speaking SMPP. This works for all kind of smscs supporting dlrs). However, if you set the parameters to something reasonable like 100ms and 3 retries it shouldn't be a big concern (this usually happens on a small amount of messages only).
2) May 2 2009 to dev list, http://www.nabble.com/-PATCH--dlr-retries-td23345908.html Regards, Alejandro 2009/10/25 Nikos Balkanas <[email protected]> > Yeah, I am a believer. But you didn't answer my questions: > > 1) This cannot be the SMSc receiving thread. What thread is it? Are there > any performance penalties due to the sleep/retries in the patch? > 2) When was this submitted, and why it didn't make it to the CVS? > > BR, > Nikos > > ----- Original Message ----- > *From:* Alejandro Guerrieri <[email protected]> > *To:* Nicolas Dagnet <[email protected]> > *Cc:* [email protected] > *Sent:* Sunday, October 25, 2009 2:58 AM > *Subject:* Re: Strange behaviour handling DLR > > 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β EURO | and stop spamming the list ;-) >> >> Β >> >> BR, >> >> Nicolas >> >> Β >> >> *DeΒ :* Alejandro Guerrieri [mailto:[email protected]] >> *EnvoyΓ(c)Β :* dimanche 25 octobre 2009 00:38 >> *Γ EURO Β :* 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Ξ ΕΎΞ'Β 1/2 e y Reciba Datos y mensajes de Texto (SMS) hacia y desde >> cualquier >> celular y Nextel >> en el PerΞ ΕΈ , MΞ ΕΎΞ β EURO °xico y en mas de 180 paises. Use aplicaciones >> 2 >> vias via >> >> >> SMS y GPRS online >> Ξ β EURO (tm)Ξ'Β Ξ β EURO (tm)Ξ'Β Ξ β EURO (tm)Ξ'Β Ξ β EURO (tm)Ξ'Β Ξ β >> EURO (tm)Ξ'Β Ξ β EURO (tm)Ξ'Β Visitenos en >> www.perusms.NET www.smsglobal.com.mx y >> www.pravcom.com >> >> Β >> >> Β >> > >
