Sorry Alej, this begs 1 more question: It cannot be the receiving thread, since it wakes up whenever a PDU comes in, but it doesn't handle it and expects the receiving SMSc thread to process it. Otherwise the submit_resp_sm would never be processed and the dlr would never be created in the table. So, the delay should be happening at the main bb thread affecting all SMScs.
But I am happy with it since this is configurable. However, to handle this properly, it should be commited to the CVS, so that people do not branch off. Can you try resubmitting? Last time I am afraid I was not involved with SMS and didn't pay much attention to it. BR, Nikos ----- Original Message ----- From: Alejandro Guerrieri To: Nikos Balkanas Cc: [email protected] Sent: Sunday, October 25, 2009 8:32 AM Subject: Re: Strange behaviour handling DLR 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 To: Nicolas Dagnet 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… 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 To: Nikos Balkanas Cc: Alvaro Cornejo ; Nicolas Dagnet ; [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 Β Β
