Help: memory leak of kannel1.2.0
Dear sir, When I test PPG (kannel1.2.0) using 'test_ppg' tools, I find that memory leak is serious. Would you pls tell me how to solve it? or When will you overcome it? Best Regards, Guanghua Hou UTStarCom Beijing R&D
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Agreed. I was just strict to an exponential backoff alghorithm. > -Original Message- > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > Sent: terça-feira, 27 de agosto de 2002 12:58 > To: Mauricio Ramos; Damjan; [EMAIL PROTECTED] > Subject: RE: [PATCH] Kannel resending old unsuccessful messges after a > box restart.BUG? > > > Currently it'll continue to double the wait time with no > upper limit. since I assume that eventually the SMPP server > will agree to send a message w/o responding with a throttling > error, and the double type can hold enough data to represent > time length much longer then a year ( ;-> ) then I don't > think it's a problem. > > -- > Oded Arbel > m-Wise mobile solutions > [EMAIL PROTECTED] > > +972-9-9581711 (116) > +972-67-340014 > > ::.. > When I was 16, I thought there was no hope for my father. By > the time I was > 20, he had made great improvement. > > > > -Original Message- > > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 27, 2002 4:06 PM > > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > > Subject: RE: [PATCH] Kannel resending old unsuccessful > > messges after a box restart.BUG? > > > > > > Hi Oded, > > > > A backoff alghorithm would be nice! It sounds like Postifx MTA. > > > > But, is there a limit or Kannel would be backing off until forever? > > > > Regards. > > > > > -Original Message- > > > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > > > Sent: domingo, 25 de agosto de 2002 14:58 > > > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > > > Subject: [PATCH] Kannel resending old unsuccessful messges > > after a box > > > restart.BUG? > > > > > > > > > Hi list. > > > > > > Attached is a patch to introduce configurable throttling > > > delay with backoff. the patch adds another configuration > > > option: 'throttling-delay' that is used as the base delay for > > > a simple backoff mechanism that will simply double the last > > > sleep time and sleep again, if it after sleeping and sending > > > it received another throttling error. > > > > > > Warning - this patch is _not_ tested ! it simply compiles. I > > > would like to have comments on the code, the solution methods > > > and the new configuration option name. testing would be nice > > > too :-) I'll try to find time to upload the changes to a test > > > platform tommorow. > > > > > > -- > > > Oded Arbel > > > m-Wise mobile solutions > > > [EMAIL PROTECTED] > > > > > > +972-9-9581711 (116) > > > +972-67-340014 > > > > > > ::.. > > > In shallow waters, shrimps make fools of dragons. > > > -- Chinese Proverb > > > > > > > > > > -Original Message- > > > > From: Oded Arbel > > > > > > > > >>Current CVS version does handle 'Throttling Error' properly > > > > by stoping > > > > >>to send messages for a predetrmind time - 15 seconds > currently. > > > > >> > > > > >> > > > > > > > > > >Thats too much, I'm using my own scripts with a perl > SMPP driver, > > > > >usually I can send some 4 messages as fast as I can send them, > > > > >and then I get the "Throttling Error", I then wait some 0.8 > > > > >seconds and then continue to send. Actually it depends of the > > > > >settings your SMPP provider has set-up for your connection. > > > > > > > > > > > > > > Currently it's set as a compile time option, which you can > > > > change - 15 > > > > seconds is what O2 required of us in their credentials > > tests. but I > > > > agree it's not the best course. Here at m-Wise we usually do > > > > that, since > > > > most time we don't think about other people's needs as > much as we > > > > should, as Andreas Fink pointed out, and we usually put in > > > > new features > > > > with a compile time option, thinking - "If we ever find a > > > > provider that > > > > requires a different setting - we'll add a configuration > > > > option, as it's > > > > simple enough". I assure you that it is pure laziness and not > > > > because we > > > > are bad people :-) > > > > > > > > If the developers have no objections, I'll implement a run-time > > > > configuration option which will default to the compile > > time option > > > > (currently 15 seconds), first thing sunday morn. alternativly > > > > - do you > > > > think its possible/needed/interesting implementing some kind of > > > > exponential backoff mechanism that will start at a small > > delay and > > > > increase it as long as it gets consecutive 'Throttling Errors' ? > > > > > >
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Currently it'll continue to double the wait time with no upper limit. since I assume that eventually the SMPP server will agree to send a message w/o responding with a throttling error, and the double type can hold enough data to represent time length much longer then a year ( ;-> ) then I don't think it's a problem. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. When I was 16, I thought there was no hope for my father. By the time I was 20, he had made great improvement. > -Original Message- > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 4:06 PM > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > Subject: RE: [PATCH] Kannel resending old unsuccessful > messges after a box restart.BUG? > > > Hi Oded, > > A backoff alghorithm would be nice! It sounds like Postifx MTA. > > But, is there a limit or Kannel would be backing off until forever? > > Regards. > > > -Original Message- > > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > > Sent: domingo, 25 de agosto de 2002 14:58 > > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > > Subject: [PATCH] Kannel resending old unsuccessful messges > after a box > > restart.BUG? > > > > > > Hi list. > > > > Attached is a patch to introduce configurable throttling > > delay with backoff. the patch adds another configuration > > option: 'throttling-delay' that is used as the base delay for > > a simple backoff mechanism that will simply double the last > > sleep time and sleep again, if it after sleeping and sending > > it received another throttling error. > > > > Warning - this patch is _not_ tested ! it simply compiles. I > > would like to have comments on the code, the solution methods > > and the new configuration option name. testing would be nice > > too :-) I'll try to find time to upload the changes to a test > > platform tommorow. > > > > -- > > Oded Arbel > > m-Wise mobile solutions > > [EMAIL PROTECTED] > > > > +972-9-9581711 (116) > > +972-67-340014 > > > > ::.. > > In shallow waters, shrimps make fools of dragons. > > -- Chinese Proverb > > > > > > > -Original Message- > > > From: Oded Arbel > > > > > > >>Current CVS version does handle 'Throttling Error' properly > > > by stoping > > > >>to send messages for a predetrmind time - 15 seconds currently. > > > >> > > > >> > > > > > > > >Thats too much, I'm using my own scripts with a perl SMPP driver, > > > >usually I can send some 4 messages as fast as I can send them, > > > >and then I get the "Throttling Error", I then wait some 0.8 > > > >seconds and then continue to send. Actually it depends of the > > > >settings your SMPP provider has set-up for your connection. > > > > > > > > > > > Currently it's set as a compile time option, which you can > > > change - 15 > > > seconds is what O2 required of us in their credentials > tests. but I > > > agree it's not the best course. Here at m-Wise we usually do > > > that, since > > > most time we don't think about other people's needs as much as we > > > should, as Andreas Fink pointed out, and we usually put in > > > new features > > > with a compile time option, thinking - "If we ever find a > > > provider that > > > requires a different setting - we'll add a configuration > > > option, as it's > > > simple enough". I assure you that it is pure laziness and not > > > because we > > > are bad people :-) > > > > > > If the developers have no objections, I'll implement a run-time > > > configuration option which will default to the compile > time option > > > (currently 15 seconds), first thing sunday morn. alternativly > > > - do you > > > think its possible/needed/interesting implementing some kind of > > > exponential backoff mechanism that will start at a small > delay and > > > increase it as long as it gets consecutive 'Throttling Errors' ? > > >
RE: AT2 sender numbers.
this is very weird. I'm currently using AT2 w/o any problem, for receiving messages from all providers. possibly you have a unified prefix that messes up the phone numbers, but this is inconsistant with the AT driver working. Could you please send me some logs of messages being received by the AT2 module that exhibit this problem ? --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..Work is of two kinds: first, altering the position of matter at or near the earth'ssurface relatively to other matter; second, telling other people to do so. The first kind is unpleasant and ill-paid, the second is pleasant and highly paid. -- Bertrand Russell -Original Message-From: Anarchy [mailto:[EMAIL PROTECTED]]Sent: Tuesday, August 27, 2002 2:08 PMTo: [EMAIL PROTECTED]Subject: (no subject) i recently started using the at2 modems group in my config and i notice that i'm not receiving some senders' number correctly... previously with the at smsc, the numbers from the local operators will either contain the country prefix with a plus (+XX) or not at all however, with at2, numbers from operators other than the sim's will show up with a plus followed by the number itself (no country code, just +)... this is obviously incorrect and replies to such numbers are not possible the problem goes away when i switched back to at but since at is supposed to be obsolete, what gives? is this a bug or do i have to modify something like unified-prefix? many thanks for any advice... i'm running 1.2.0 on mandrake 8.2 and my config is plain vanilla: group = smscsmsc = atmodemtype = wavecomdevice = /dev/ttyS2 group = modemsid = wavecomname = Wavecomdetect-string = "WAVECOM" Do You Yahoo!?Yahoo! Finance - Get real-time stock quotes
RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?
Hi Oded, A backoff alghorithm would be nice! It sounds like Postifx MTA. But, is there a limit or Kannel would be backing off until forever? Regards. > -Original Message- > From: Oded Arbel [mailto:[EMAIL PROTECTED]] > Sent: domingo, 25 de agosto de 2002 14:58 > To: Oded Arbel; Damjan; [EMAIL PROTECTED] > Subject: [PATCH] Kannel resending old unsuccessful messges after a box > restart.BUG? > > > Hi list. > > Attached is a patch to introduce configurable throttling > delay with backoff. the patch adds another configuration > option: 'throttling-delay' that is used as the base delay for > a simple backoff mechanism that will simply double the last > sleep time and sleep again, if it after sleeping and sending > it received another throttling error. > > Warning - this patch is _not_ tested ! it simply compiles. I > would like to have comments on the code, the solution methods > and the new configuration option name. testing would be nice > too :-) I'll try to find time to upload the changes to a test > platform tommorow. > > -- > Oded Arbel > m-Wise mobile solutions > [EMAIL PROTECTED] > > +972-9-9581711 (116) > +972-67-340014 > > ::.. > In shallow waters, shrimps make fools of dragons. > -- Chinese Proverb > > > > -Original Message- > > From: Oded Arbel > > > > >>Current CVS version does handle 'Throttling Error' properly > > by stoping > > >>to send messages for a predetrmind time - 15 seconds currently. > > >> > > >> > > > > > >Thats too much, I'm using my own scripts with a perl SMPP driver, > > >usually I can send some 4 messages as fast as I can send them, > > >and then I get the "Throttling Error", I then wait some 0.8 > > >seconds and then continue to send. Actually it depends of the > > >settings your SMPP provider has set-up for your connection. > > > > > > > > Currently it's set as a compile time option, which you can > > change - 15 > > seconds is what O2 required of us in their credentials tests. but I > > agree it's not the best course. Here at m-Wise we usually do > > that, since > > most time we don't think about other people's needs as much as we > > should, as Andreas Fink pointed out, and we usually put in > > new features > > with a compile time option, thinking - "If we ever find a > > provider that > > requires a different setting - we'll add a configuration > > option, as it's > > simple enough". I assure you that it is pure laziness and not > > because we > > are bad people :-) > > > > If the developers have no objections, I'll implement a run-time > > configuration option which will default to the compile time option > > (currently 15 seconds), first thing sunday morn. alternativly > > - do you > > think its possible/needed/interesting implementing some kind of > > exponential backoff mechanism that will start at a small delay and > > increase it as long as it gets consecutive 'Throttling Errors' ? >
RE: SMPP query message: Is Kannel able to do this?
Ops! Some of my clients doens't do that in their SMSCs (resource saving reasons), ie, they don't retry deliver_sm as frequent as needed sometimes. It can get me in trouble when dealing with high-volatily (expiration) messages, for example, when a sms expires in 10 minutes and the SMSC's delivery_sm doesn't come fast enough. Any suggestion? Tnx. > -Original Message- > From: Andreas Fink [mailto:[EMAIL PROTECTED]] > Sent: segunda-feira, 26 de agosto de 2002 18:53 > To: Mauricio Ramos > Subject: Re: SMPP query message: Is Kannel able to do this? > > > >Hi SMPPers, > > > >My concern is regarding the delivery notification. Is > Kannel able to query > >the message state in SMSC in a time interval in case SMSC is > too lazy to > >notify de delivery through deliver_sm? > > > >Tnx! > > no. Yous SMSC should deliver reports in a timewhise manner. > > > -- > Andreas Fink > Global Networks, Inc. > > -- > > Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 > Address:Global Networks, Inc., Schwarzwaldallee 16, 4058 > Basel, Switzerland > Web: http://www.global-networks.ch/ e-mail: > [EMAIL PROTECTED] > -- > > Member of the GSM Association >
(no subject)
i recently started using the at2 modems group in my config and i notice that i'm not receiving some senders' number correctly... previously with the at smsc, the numbers from the local operators will either contain the country prefix with a plus (+XX) or not at all however, with at2, numbers from operators other than the sim's will show up with a plus followed by the number itself (no country code, just +)... this is obviously incorrect and replies to such numbers are not possible the problem goes away when i switched back to at but since at is supposed to be obsolete, what gives? is this a bug or do i have to modify something like unified-prefix? many thanks for any advice... i'm running 1.2.0 on mandrake 8.2 and my config is plain vanilla: group = smscsmsc = atmodemtype = wavecomdevice = /dev/ttyS2 group = modemsid = wavecomname = Wavecomdetect-string = "WAVECOM"Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes
RE: SMPP query message: Is Kannel able to do this?
Not currently. its not easy to implement as Kannel will have to "remember" all the messages it sent through and query on them. it'll also probably load the connection a bit more, which would be a problem for high-load connections. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. QUOTATION, n. The act of repeating erroneously the words of another. -- the Devil's Dictionary / Ambrose Bierce > -Original Message- > From: Mauricio Ramos [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 10:52 PM > To: '[EMAIL PROTECTED]' > Subject: SMPP query message: Is Kannel able to do this? > > > Hi SMPPers, > > My concern is regarding the delivery notification. Is Kannel > able to query > the message state in SMSC in a time interval in case SMSC is > too lazy to > notify de delivery through deliver_sm? > > Tnx! > >
RE: Possible race condition in gwlib/protected.c [version 1.1]
> -Original Message- > From: Kieran [mailto:[EMAIL PROTECTED]] > The glibc version _is_ documented as thread-safe, while the Solaris 8 > man page for the function isn't documented. > Is it worth working on? I could have it activated via ./configure > --with-getaddrinfo (so that the default isn't affected) if you'd like? How about detecting in configure if we have a glibc, and enabling it, and not using it otherwise ? This way modern uptodate systems with glibc will take advantage of it, while not hurting other systems, and no need for extra configuration options. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. "The ships hung in the sky in much the same way that bricks don't." -- Douglas Adams
