Re: EMI: Serious Problem PANIC: Too many concurrent allocations
Jari Juslin wrote: > Further question: In general situation, does this really correct > problems or just hide them? Ok, I was a bit hasty once again. By reading the mailing list archive and code I came to this asumption: if I want to run Kannel under heavy load, I need to increase MAX_TAB_SIZE in gwlib/gwmem-check.c significantly. If I still run to these panics, there is propably some bad memory leak that should be hunted down. So, panic to "Too many concurrent allocations" can happen if a) Kannel just has so high load, that is needs huge amounts of memory or b) if Kannel leaks too much memory. Am I right? The last version of Kannel I have run without it reportin non-freed areas on exit was 1.1.5.. I think I should do some memory leak investigation and get back to you, if I fail to repair them myself.
RE: Daily patch: gateway
On Fri, 2002-05-31 at 11:49, Harrie Hazewinkel wrote: > > > --On Friday, May 31, 2002 12:07 PM +0200 Angel Fradejas > <[EMAIL PROTECTED]> wrote: > > > Harrie please, > > > > Would you be so kind as to comment these changes in ChangeLog? > > Done. > > > > They're somewhat described in a post from May 25 (subject: changes to the > > heartbeat code.) > > The message is the same as the commit message. > I personally, would prefer if the CVS-message during commit > is used for this. >From our former architecture, Lars: (I hope everything is ok with ex-wapit people) ChangeLog We use the file called `ChangeLog' to log changes, not CVS commit entries. CVS entries are not usable by people who don't have CVS access (e.g., they are off-line at the moment, which happens often for laptop users), and are also harder to browse than a single file. When writing an entry, please try to make sure the entry is at least somewhat understandable without referring to the actual patch it reflects. This helps immensely those who want to follow Kannel development without having to wade through millions of lines of patches per year. > > > Harrie > > Internet Management Consulting > mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ > >
Re: EMI: Serious Problem PANIC: Too many concurrent allocations
On Sat, 2002-06-01 at 02:11, Jari Juslin wrote: > Kalle Marjola wrote: > > >On 24 May 2002, Abd Rahman Johari wrote: > > > > > >>I'm trying to send out SMS Broadcast and after a while kannel just die > >>because of PANIC: Too many concurrent allocations > >> > >> > > > >You need to compile Kannel with non-checking malloc, i.e. use native > >malloc. ./configure --with-defaults=speed or --with-malloc=native should > >help. > > > > > Further question: In general situation, does this really correct > problems or just hide them? I though that the checking malloc spots > errors and making error messages to go away by just not checking anymore > sounds quite hazard.. Or is it so, that this "Too many concurrent > allocations" checking failing does not always mean there is an error? I > have got the smsbox to panic this way when put under too heavy load and > bearerbox when restoring big enough store file (1000+ messages), and > these sound like this message would occur more often when Kannel is put > under high pressure (and possibly making much concurrent allocations for > some good reason?). The concurrent allocations are relative to the checking malloc, that is limited (or configured somewhere in the code) to 1 or 2 MB. If you use native malloc, the limit should be the memory available. I've sent 200K (10k at once, with post-xml) messages and had the store.lock as bigger than 40MB, with 30k messages in queue. I don't recall now the exact values, but I were always expecting to see kannel crashing somewhere, but it worked out ok.
Re: [patch] smsbox memory leaks and service header
On Fri, 2002-05-31 at 17:08, Angel Fradejas wrote: > Hi all, > > here's a patch for smsbox.c > > 1) a couple of memory leaks (msg->sms.udhdata and accepted_chars) thanks, could someone else apply this ? > 2) allow to change msg->sms.service via X-Kannel-Service header or xml tag Why should you change the sms.service ? sms.service is the name field in configuration, for sms-service and sendsms-user, so you can identify the service or username used, in bearerbox_access.log. We shouldn't give access to clients connecting through http. I vote -1 for this part > > Cheers. > > Angel Fradejas > Mediafusión España, S.A. > [EMAIL PROTECTED] > www.mediafusion.es > Tel. +34 91 252 32 00 > Fax +34 91 572 27 08 > > >
Re: EMI: Serious Problem PANIC: Too many concurrent allocations
Kalle Marjola wrote: >On 24 May 2002, Abd Rahman Johari wrote: > > >>I'm trying to send out SMS Broadcast and after a while kannel just die >>because of PANIC: Too many concurrent allocations >> >> > >You need to compile Kannel with non-checking malloc, i.e. use native >malloc. ./configure --with-defaults=speed or --with-malloc=native should >help. > Further question: In general situation, does this really correct problems or just hide them? I though that the checking malloc spots errors and making error messages to go away by just not checking anymore sounds quite hazard.. Or is it so, that this "Too many concurrent allocations" checking failing does not always mean there is an error? I have got the smsbox to panic this way when put under too heavy load and bearerbox when restoring big enough store file (1000+ messages), and these sound like this message would occur more often when Kannel is put under high pressure (and possibly making much concurrent allocations for some good reason?). Example of bearerbox log when latter happens: 2002-05-31 14:17:28 [0] INFO: Loading store file /var/log/kannel/kannel.store 2002-05-31 14:17:28 [0] INFO: Store-file size 386359, starting to unpack (may take awhile) 2002-05-31 14:17:28 [17] DEBUG: sms_router: time to sleep 2002-05-31 14:17:28 [17] DEBUG: sms_router: list_len = 0 2002-05-31 14:17:28 [0] INFO: Retrieved 1012 messages, non-acknowledged messages: 1001 2002-05-31 14:17:28 [0] PANIC: Too many concurrent allocations.
[patch] smsbox memory leaks and service header
Hi all, here's a patch for smsbox.c 1) a couple of memory leaks (msg->sms.udhdata and accepted_chars) 2) allow to change msg->sms.service via X-Kannel-Service header or xml tag Cheers. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 smsbox_service.patch Description: Binary data
Re: [BUG] wsp_strings.def
Paul Keogh kirjoittaa perjantaina, 31. toukokuuta 2002, kello 18:14:
> The
>
> /* Table 40. Content Type Assignments */
> LINEAR(content_type,
>
> data structure includes the entry
>
> ...
> STRING("application/vnd.wap.sia")
> STRING("application/vnd.wap.mms-message")
>
> as the last element in the data structure. This is wrong because
> this content type is from v1.4 of the spec and the table stops at
> v1.2, so the content types from v1.3 and v1.4 of WSP are missing.
> As the entries in the table are assigned their encoding value
> from their index, the WBXML encoding is wrong for MMS content types.
>
> I think this table should be amended to;
>
> ...
> STRING("application/vnd.wap.sia")
> STRING("text/vnd.wap.connectivity-xml")
> STRING("application/vnd.wap.connectivity-wbxml")
> STRING("application/pkcs7-mime")
> STRING("application/vnd.wap.hashed-certificate")
> STRING("application/vnd.wap.signed-certificate")
> STRING("application/vnd.wap.cert-response")
> STRING("application/xhtml+xml")
> STRING("application/wml+xml")
> STRING("text/css")
> STRING("application/vnd.wap.mms-message")
> )
Yes. I will correct this next week.
Aarno
[BUG] wsp_strings.def
The
/* Table 40. Content Type Assignments */
LINEAR(content_type,
data structure includes the entry
...
STRING("application/vnd.wap.sia")
STRING("application/vnd.wap.mms-message")
as the last element in the data structure. This is wrong because
this content type is from v1.4 of the spec and the table stops at
v1.2, so the content types from v1.3 and v1.4 of WSP are missing.
As the entries in the table are assigned their encoding value
from their index, the WBXML encoding is wrong for MMS content types.
I think this table should be amended to;
...
STRING("application/vnd.wap.sia")
STRING("text/vnd.wap.connectivity-xml")
STRING("application/vnd.wap.connectivity-wbxml")
STRING("application/pkcs7-mime")
STRING("application/vnd.wap.hashed-certificate")
STRING("application/vnd.wap.signed-certificate")
STRING("application/vnd.wap.cert-response")
STRING("application/xhtml+xml")
STRING("application/wml+xml")
STRING("text/css")
STRING("application/vnd.wap.mms-message")
)
Paul Keogh
ANAM Wireless Internet Solutions
http://www.anam.com
+353 1 284 7555 (wired) +353 86 234 6047 (wireless)
Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland
Re: doc building bug
>On Fri, May 31, 2002 at 11:10:20AM +0200, Andreas Fink wrote: >> jade:doc/userguide/userguide.tmp:5551:7:E: end tag for "SECT3" >> omitted, but OMITTAG NO was specified > >Odd, it builds without errors on my Debian Woody machine. > >I checked in a new version. Can you try it again, please? seems to be ok now -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: doc building bug
On Fri, May 31, 2002 at 11:10:20AM +0200, Andreas Fink wrote: > jade:doc/userguide/userguide.tmp:5551:7:E: end tag for "SECT3" > omitted, but OMITTAG NO was specified Odd, it builds without errors on my Debian Woody machine. I checked in a new version. Can you try it again, please? Dave -- David Holland =*= Systems Manager =*= tel: +44 01223 478900 http://www.3glab.com/ =*= 3G Lab, UK =*= fax: +44 01223 478901 "My Installation Crashes Randomly Or Some Operations Fail Totally."
Re: question regarding the configuration implementation
--On Friday, May 31, 2002 9:38 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Harrie Hazewinkel wrote: >> I was wondering if someone could tell me the reason why putting it >> in a dictionary first as a very general configuration representation >> and later search into it for only those parts needed?? > > I'm not sure, but is the dictionary needed for faster lookups later > when the groups are needed. OK, but what is fast, you only do this at startup. :-) The thing I merely was wondering of is why a 2 step phase. First loading it all in the process and that as a second phase look into the values of it. See also below. > >> Another question I have is why one would have all configuration tokens >> known to each process and depending on the process totally ignore it?? >> The main reason is maybe that this way a single configuration file >> can be used for all, but I guess there is more. > > Hmm, I didn't understand the question Harrie. I will explain it again. The cfg.def, cfg.c and cfg.h file in the gwlib are the core of the configuration handling. All tokens are known there. Those who are not will cause an error while reading the configuration file. All others are put into a list/dictionary for later use. The later use by the process is just to call the ones it needs from the list/dictionary. All others are basically ignored. One could make it like this. Each process only knows those tokens it will use. All other tokens will generate an error. This as oppose to read all possible tokens of any of the processes and just ignore those not used by that process. Therefore, my question 'why should each process know all possible tokens for all processes of the package and those not needed being ignored by the process'?? I believe this is done so only one configuration file is needed for the complete system (bearebox and wap/smsbox). Howevr, this would make a more module system problematic, since not all processes need the same module and thus do not know all the same tokens. Hope this explains it better. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
Re: version 1.1.6 processing limits
Harrie Hazewinkel kirjoittaa perjantaina, 31. toukokuuta 2002, kello 12:36: > > --On Friday, May 31, 2002 9:57 AM +0200 Stipe Tolj systems.de> wrote: >> >> yep, that may be. Aarno, what do you mean of this? Did you recognize >> anything at your benchmark testings? > > I understood the others were thinking of some malloc function. > Those are system calls and probably locked for exclusive use in > a process. Meaning the many multiple threads have to wait on each > other. > > This is just theory, nothing I tested or so. Therefore, I used > 'just a thought'. This is an idea Lars had during Wapit time. Yes, it would help, dark though then that best way to boost Kannel performance is making it do less memory allocations. If this is handled by a new memory wrapper, so that there is no need to change code outside this module, the change is even practical. Aarno
RE: Daily patch: gateway
--On Friday, May 31, 2002 12:07 PM +0200 Angel Fradejas <[EMAIL PROTECTED]> wrote: > Harrie please, > > Would you be so kind as to comment these changes in ChangeLog? Done. > > They're somewhat described in a post from May 25 (subject: changes to the > heartbeat code.) The message is the same as the commit message. I personally, would prefer if the CVS-message during commit is used for this. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Daily patch: gateway
Our mails crossed, sorry Harrie. -Mensaje original- De: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Enviado el: viernes 31 de mayo de 2002 11:41 Para: Stipe Tolj; Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway --On Friday, May 31, 2002 10:17 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Angel, > >> > File gateway/gw/bb.h changed from revision 1.5 to 1.6 >> > File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >> > File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >> > File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >> > File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >> > File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >> > File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 >> >> All this files have been changed without documentation on ChangeLog. Some of those, I chnaged and I did not edit ChangeLog, since I thought that was updated automatically with the CVS message provided at commit. I will put the same message in ChangeLog. Sorry about that. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Daily patch: gateway
Harrie please, Would you be so kind as to comment these changes in ChangeLog? They're somewhat described in a post from May 25 (subject: changes to the heartbeat code.) Thanks. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: viernes 31 de mayo de 2002 10:18 Para: Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway Angel, > >File gateway/gw/bb.h changed from revision 1.5 to 1.6 > >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 > >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 > >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 > >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 > >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 > >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 > > All this files have been changed without documentation on ChangeLog. > > Please, this is important as we have to follow potential problems to keep > using HEAD of CVS. right, I agree. Could you please lookup who did the commits and post the request directly to hin/her (ehmmm, we don't have a 'her' yet, do we ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: version 1.1.6 processing limits
--On Friday, May 31, 2002 9:57 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Harrie Hazewinkel wrote: >> >> --On Thursday, May 30, 2002 10:14 AM +0300 Oded Arbel <[EMAIL PROTECTED]> >> wrote: >> >> > I'm not sure how "native" malloc works, but the checking malloc (which >> > we use always) has an upper limit on the number of allocations >> > allowed. if you want to use more memory you will have to recompile. >> > >> >> Just a thought, but is the amount of system-call casuing some problems. >> Not knowing how much there are, but malloc is one of them. > > yep, that may be. Aarno, what do you mean of this? Did you recognize > anything at your benchmark testings? I understood the others were thinking of some malloc function. Those are system calls and probably locked for exclusive use in a process. Meaning the many multiple threads have to wait on each other. This is just theory, nothing I tested or so. Therefore, I used 'just a thought'. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
Re: Daily patch: gateway
--On Friday, May 31, 2002 10:17 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Angel, > >> > File gateway/gw/bb.h changed from revision 1.5 to 1.6 >> > File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >> > File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >> > File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >> > File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >> > File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >> > File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 >> >> All this files have been changed without documentation on ChangeLog. Some of those, I chnaged and I did not edit ChangeLog, since I thought that was updated automatically with the CVS message provided at commit. I will put the same message in ChangeLog. Sorry about that. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
Re: When Kannel 1.2 is likely to be released?
On Fri, 2002-05-31 at 08:47, Stipe Tolj wrote: > Mauricio Ramos wrote: > > > > Hi Everybody > > I'm curious to know when Kannel 1.2 is likely to be release. Accordingly to > > the Roadmap, it should be released within April or early May of 2002. > > Right, we originally had a (major) feature freeze time to give people > a chance to report major bugs before releasing 1.2.0. I guess this > time is over know?! > > >From the STATUS file I see at least one pending release showstopper: > > * DLRs crash smsbox using CIMD2 > octstr_copy_real() throughs len >= 0 assert exception, maybe in > smsbox.c:obey_request_thread() > Posted by: Stefan Cars <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Status: > > Stefan, can you provide us with more input in this issue? What's the > status? > > If this can be cleaned out and no one sees major bugs (i.e. > segmentation faults) I'd vote +1 for releasing a stable 1.2.0 starting > next week. +1 for me. I couldn't find the bugs I've reported some time ago, but I'll keep hunting for them. If nobody else complain, there's no bug. Let's then have a 1.2.0 branch and a HEAD > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Münsterstr. 248 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are > > >
doc building bug
Title: doc building bug sed "s/#FIGTYPE#/.png/;s/#VERSION#/cvs-20020530/;s/#DATE#/`date +%Y.%m.%d`/;s/#DRAFTS#/IGNORE/" doc/alligata/alligata.xml > doc/alligata/alligata.tmp jade -V nochunks -t sgml -d /usr/share/sgml/docbook/dsssl-stylesheets/html/docbook.dsl doc/alligata/alligata.tmp > doc/alligata/alligata.html rm -f doc/alligata/alligata.tmp sed "s/#FIGTYPE#/.png/;s/#VERSION#/cvs-20020530/;s/#DATE#/`date +%Y.%m.%d`/;s/#DRAFTS#/IGNORE/" doc/arch/arch.xml > doc/arch/arch.tmp jade -V nochunks -t sgml -d /usr/share/sgml/docbook/dsssl-stylesheets/html/docbook.dsl doc/arch/arch.tmp > doc/arch/arch.html rm -f doc/arch/arch.tmp sed "s/#FIGTYPE#/.png/;s/#VERSION#/cvs-20020530/;s/#DATE#/`date +%Y.%m.%d`/;s/#DRAFTS#/IGNORE/" doc/userguide/userguide.xml > doc/userguide/userguide.tmp jade -V nochunks -t sgml -d /usr/share/sgml/docbook/dsssl-stylesheets/html/docbook.dsl doc/userguide/userguide.tmp > doc/userguide/userguide.html jade:doc/userguide/userguide.tmp:5551:7:E: end tag for "SECT3" omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:5404:0: start tag was here make: *** [doc/userguide/userguide.html] Error 1 -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: Daily patch: gateway
Angel, > >File gateway/gw/bb.h changed from revision 1.5 to 1.6 > >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 > >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 > >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 > >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 > >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 > >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 > > All this files have been changed without documentation on ChangeLog. > > Please, this is important as we have to follow potential problems to keep > using HEAD of CVS. right, I agree. Could you please lookup who did the commits and post the request directly to hin/her (ehmmm, we don't have a 'her' yet, do we ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Patch submission and release policy
Oded Arbel wrote: > > > -Original Message- > > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > > > > Changelog is generated from the cvs commit messages or is it > > neccessary > > to do it by hand?? Just wondering, since I thought ChangeLog can be > > generated from CVS itself. (I could be wrong) > > The ChangeLog is written by hand. theoreticly it's possible to generate it from the >CVS commit messages, but I would still recomend not to do it : writing the ChangeLog >by hand forces the developer to submit clearly described patches. +1 on this from me too. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: CVS usage question??
Harrie Hazewinkel wrote: > > --On Wednesday, May 29, 2002 5:41 PM +0200 Angel Fradejas > <[EMAIL PROTECTED]> wrote: > > > Maybe line-feed format has been changed from unix-like to dos-like. > > > > This could happen if you use Windows based tools to edit, etc. > > that could be it, see also my other email in which I mentioned the '^M'. > However, I noticed also that many files have a '^M' at the end. > So what would we prefer? If you use WinCVS 1.2 (like I do) please make sure of 2 things: a) you set the flag inside WinCVS to checkout in UNIX line ending mode b) use an editor which is capable of opening, processing and re-saving again files in UNIX line ending mode, I use WinEdit 2000. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: MMS Proxy-Relay support
> Todd Keen wrote: > > I am establishing a test environment for WAP and also need to > include MMS messages within the test environment. What are the > plans & timeframes for adding support to the WAP Gateway to act as > an MMS Proxy-Relay? Also will fakewap have added support for MMS? you have to implement WTP-SAR (segmenation and reassembly) to handle MMS types. There are no schedules to implement this in Kannel yet. But there is a chance it will be implemented in the upcoming future. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: version 1.1.6 processing limits
Harrie Hazewinkel wrote: > > --On Thursday, May 30, 2002 10:14 AM +0300 Oded Arbel <[EMAIL PROTECTED]> > wrote: > > > I'm not sure how "native" malloc works, but the checking malloc (which we > > use always) has an upper limit on the number of allocations allowed. if > > you want to use more memory you will have to recompile. > > > > Just a thought, but is the amount of system-call casuing some problems. > Not knowing how much there are, but malloc is one of them. yep, that may be. Aarno, what do you mean of this? Did you recognize anything at your benchmark testings? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: version 1.1.6 processing limits
Oded Arbel wrote: > > I'm not sure how "native" malloc works, but the checking malloc (which we use >always) has an upper limit on the number of allocations allowed. if you want to use >more memory you will have to recompile. and this information should *definitly* go into our FAQ file as first item -- as soon as we have one ;) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: version 1.1.6 processing limits
Cold Feet wrote: > > hi all, > > for the first month of being up on kannel 1.1.6 development release it has its ups >and downs on its live run. on its first week several times it went down by itself... >and so i recompiled it with additional flags and now have remained up and running and >i can say i am to the point that i may say, the system and compilation issue is now >stable for my server. however, i need a gauge on its processing limits. the system is >handling sms only data and wap is disabled. and so far just a few number of sms is >being received and replied to. i am hitting about 6,000 received sms in a day. all i >know that this is just a small number to speak with. i would like to ask your input >then, how much data can kannel process at any given time whereby it is really pushed >to the limits. how many messages can it process in a given second or minute? to >process a huge number of sms data, i need to have a good amount of RAM. i am using >redhat linux 7.2 on an intel pentium III 866 mhz with 256MB of SDRAM. > what do you think is a good server configuration to setup kannel. you should provide us with bug reports or log tails if processes go down without obvious reason, this will help us make things better. Aarno has benchmarked an sms based installation to handle around 300-350 msg/sec, which would result in a day total limit of almost half a million. Usually your smsc connections will never reach that kind of limits. 256 MB RAM should be suitable if the machine is not handling to much "other" things. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: When Kannel 1.2 is likely to be released?
Mauricio Ramos wrote: > > Hi Everybody > I'm curious to know when Kannel 1.2 is likely to be release. Accordingly to > the Roadmap, it should be released within April or early May of 2002. Right, we originally had a (major) feature freeze time to give people a chance to report major bugs before releasing 1.2.0. I guess this time is over know?! >From the STATUS file I see at least one pending release showstopper: * DLRs crash smsbox using CIMD2 octstr_copy_real() throughs len >= 0 assert exception, maybe in smsbox.c:obey_request_thread() Posted by: Stefan Cars <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Status: Stefan, can you provide us with more input in this issue? What's the status? If this can be cleaned out and no one sees major bugs (i.e. segmentation faults) I'd vote +1 for releasing a stable 1.2.0 starting next week. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: first draft and patch for module oriented API.
Harrie Hazewinkel schrieb: > > Attached is a document slightly explaining a module oriented API > and a patch assoicated for it. > > I would people like to invite to make comments and in perticular those > who made additional modules that need always patching the core. > I understand it is not complete yet, but that is why I invite comments. Harrie, first of all thanks a *lot* for the contribution. I'll check and will comment on it, as I hope others from the developers will do so too. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: question regarding the configuration implementation
Harrie Hazewinkel wrote: > > HI all, > > Maybe someone could help me out in order to confirm how > I think the configuration file is hanndled. > I believe this is the scheme: > > A programm > 1- opens the configuration file > 2- reads it as a huge octet_string > 3- splits is into a list of lines (octet_string) > 4- parser the all lines of the list which could be >a- a comment line (ignore) >b- an include line (which inserts the to be included as a >list of lines again steps 1,2,3) >c- processes a lines (splits is at the '=', makes a name > value pair and adds it in a dictionary) > (NOW ALL CONFFILE READING IS DONE) > 5- initializes the needed process >a- it starts for looking of groups in the dictionary >b- depending on the group it looks for parameters. yep, that's the way it does. > I was wondering if someone could tell me the reason why putting it > in a dictionary first as a very general configuration representation > and later search into it for only those parts needed?? I'm not sure, but is the dictionary needed for faster lookups later when the groups are needed. > Another question I have is why one would have all configuration tokens > known to each process and depending on the process totally ignore it?? > The main reason is maybe that this way a single configuration file > can be used for all, but I guess there is more. Hmm, I didn't understand the question Harrie. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
