Resubmitted to devel. Regards,
Alejandro 2009/10/25 Nikos Balkanas <[email protected]> > 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 <[email protected]> > *To:* Nikos Balkanas <[email protected]> > *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 <[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 >>> >>> Β >>> >>> Β >>> >> >> >
