RE: Kannel automatic compilation test for SunOS
Hi list. The definitions for the gw_mem calls in malloc=native mode result in lots of compilation warning - would it be possible to #define those in such a way as to completly be ignored by the compiler ? as gcc doesn't like the meaningles statements created by the current #defines. -- Oded Arbel m-Wise Mobile Solutions [EMAIL PROTECTED] Mobile: +972-67-340014 Tel: +972-9-9581711 (ext: 116) ::.. The best defense against logic is ignorance. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 7:10 AM > To: [EMAIL PROTECTED] > Subject: Kannel automatic compilation test for SunOS > > > Kannel compilation test. > > Host: SunOS wapme.vs 5.6 Generic_105181-31 sun4u sparc SUNW,Ultra-250 > > Kannel compilation had warnings or failed. > > Output of 'make -s': > gw/bb_boxc.c: In function `read_from_box': > gw/bb_boxc.c:82: warning: statement with no effect > gw/shared.c: In function `read_from_bearerbox': > gw/shared.c:127: warning: statement with no effect > gwlib/conn.c: In function `conn_read_everything': > gwlib/conn.c:1041: warning: statement with no effect > gwlib/conn.c: In function `conn_read_fixed': > gwlib/conn.c:1062: warning: statement with no effect > gwlib/conn.c: In function `conn_read_line': > gwlib/conn.c:1088: warning: statement with no effect > gwlib/conn.c: In function `conn_read_withlen': > gwlib/conn.c:1136: warning: statement with no effect > gwlib/conn.c: In function `conn_read_packet': > gwlib/conn.c:1171: warning: statement with no effect > --- > > Output of 'CFLAGS='-Wall -O2 -g' ./configure': > creating cache ./config.cache > checking cvs checkout date... 20020612 > > Configuring for Kannel gateway version cvs-20020612 ... > > Running system checks ... > checking host system type... sparc-sun-solaris2.6 > checking for gcc... gcc > checking whether the C compiler (gcc -Wall -O2 -g -DSunOS=1 ) > works... yes > checking whether the C compiler (gcc -Wall -O2 -g -DSunOS=1 ) > is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for a BSD compatible install... /usr/local/bin/ginstall -c > checking for ranlib... ranlib > checking for bison... bison -y > checking for flex... flex > checking for yywrap in -lfl... no > checking for convert... no > checking for perl... /usr/bin/perl > checking for log in -lm... yes > checking for accept in -lsocket... yes > checking for inet_ntoa in -lnsl... yes > checking for inet_ntop in -lresolv... yes > checking for inet_ntop in -lbind... no > checking for pthread_exit in -lpthread... yes > checking for pthread_exit in -lc_r... no > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/ioctl.h... yes > checking for sys/time.h... yes > checking for sys/types.h... yes > checking for unistd.h... yes > checking for sys/poll.h... yes > checking for pthread.h... yes > checking for getopt.h... no > checking for syslog.h... yes > checking for gettimeofday... yes > checking for select... yes > checking for socket... yes > checking for strdup... yes > checking for getopt_long... no > checking for getopt... yes > checking for socklen_t in ... no > checking for getopt in ... yes > checking for getopt in ... no > > Checking POSIX threads support ... > checking for working pthreads... yes > > Checking for libxml2 support ... > checking for xml2-config... /users/local/bin/xml2-config > checking libxml version... 2.4.10 > > Configuring DocBook support ... > checking for jade... : > checking for jadetex... : > checking for pdfjadetex... : > checking for dvips... : > checking for fig2dev... : > checking for convert... : > checking for > /usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/html/docbook.dsl... no > checking for > /usr/lib/sgml/stylesheets/nwalsh-modular/html/docbook.dsl... no > checking for > /usr/share/sgml/docbook/dsssl-stylesheets-1.59/html/docbook.dsl... no > checking for > /usr/share/sgml/docbook/dsssl-stylesheets/html/docbook.dsl... no > checking for > /usr/share/sgml/docbook/dsssl/modular/html/docbook.dsl... no > checking for > /usr/local/lib/sgml/stylesheet/dsssl/docbook/nwalsh/html/docbo > ok.dsl... no > checking for > /usr/local/lib/sgml/stylesheets/nwalsh-modular/html/docbook.dsl... no > checking for > /usr/local/share/sgml/docbook/dsssl-stylesheets-1.59/html/docb ook.dsl... no > checking for > /usr/local/share/sgml/docbook/dsssl-stylesheets/html/docbook.dsl... no > checking for > /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl... no > checking for > /usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/print/docbook.dsl... no > checking for > /usr/lib/sgml/stylesheets/nwalsh-modular/print/docbook.dsl... no > checking for > /usr/share/sgml/docbook/dsssl-stylesheets-1.59/print/docbook.dsl... no > checking for > /usr/share/sgml/docbook/dsssl-stylesheets/print/docbook.dsl... no > checking
[bug] : Released too many threads - 1 now 1 originally
Anyone seen this condition occuring on receiving an inbound SMS message with AT2? Looks like the first time it happens it originates in the bearerbox and then follows into the smsbox, and then only the smsbox on the 2nd time. Kannel appears to survive fine but I'd prefer it didn't happen Alex 2002-06-13 11:05:28 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] [from:+1] [to:1234] [flags:0:1:0:0:0] [msg:2:73] [udh:0:] 1523547439 [unknown (0x1F0)] bearerbox 1684 pthread_cond::Signal: Released too many threads - 1 now 1 originally 1523315038 [main] smsbox 1652 pthread_cond::Signal: Released too many threads - 1 now 1 originally 2002-06-13 10:38:12 [4] INFO: Starting to service <187> from <+2> to <1234> 1523356635 [unknown (0x5E4)] smsbox 1652 pthread_cond::Signal: Released too many threads - 1 now 1 originally 2002-06-13 11:38:12 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] [from:+2] [to:1234] [flags:0:1:0:0:0] [msg:3:187] [udh:0:]
Re: [bug] : Released too many threads - 1 now 1 originally
Alex Judd wrote: > > Anyone seen this condition occuring on receiving an inbound SMS message with > AT2? Looks like the first time it happens it originates in the bearerbox and > then follows into the smsbox, and then only the smsbox on the 2nd time. > > Kannel appears to survive fine but I'd prefer it didn't happen > > Alex > > 2002-06-13 11:05:28 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] [from:+1] > [to:1234] [flags:0:1:0:0:0] [msg:2:73] [udh:0:] > 1523547439 [unknown (0x1F0)] bearerbox 1684 pthread_cond::Signal: Released > too many threads - 1 now 1 originally > 1523315038 [main] smsbox 1652 pthread_cond::Signal: Released too many > threads - 1 now 1 originally > 2002-06-13 10:38:12 [4] INFO: Starting to service <187> from <+2> to > <1234> > 1523356635 [unknown (0x5E4)] smsbox 1652 pthread_cond::Signal: Released too > many threads - 1 now 1 originally > 2002-06-13 11:38:12 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] [from:+2] > [to:1234] [flags:0:1:0:0:0] [msg:3:187] [udh:0:] Ups, never seen this on our systems. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: [bug] : Released too many threads - 1 now 1 originally
Haven't seen this in our systems, and I don't even know who generates this : log_sms() doesn't write this kind of format. -- Oded Arbel m-Wise Mobile Solutions [EMAIL PROTECTED] Mobile: +972-67-340014 Tel: +972-9-9581711 (ext: 116) ::.. Remember the... the... uhh. > -Original Message- > From: Alex Judd [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 1:50 PM > To: Kannel-devel (E-mail) > Subject: [bug] : Released too many threads - 1 now 1 originally > > > Anyone seen this condition occuring on receiving an inbound > SMS message with > AT2? Looks like the first time it happens it originates in > the bearerbox and > then follows into the smsbox, and then only the smsbox on the > 2nd time. > > Kannel appears to survive fine but I'd prefer it didn't happen > > Alex > > 2002-06-13 11:05:28 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] > [from:+1] > [to:1234] [flags:0:1:0:0:0] [msg:2:73] [udh:0:] > 1523547439 [unknown (0x1F0)] bearerbox 1684 > pthread_cond::Signal: Released > too many threads - 1 now 1 originally > 1523315038 [main] smsbox 1652 pthread_cond::Signal: Released too many > threads - 1 now 1 originally > 2002-06-13 10:38:12 [4] INFO: Starting to service <187> from > <+2> to > <1234> > 1523356635 [unknown (0x5E4)] smsbox 1652 > pthread_cond::Signal: Released too > many threads - 1 now 1 originally > 2002-06-13 11:38:12 Receive SMS [SMSC:Wavecom1] [SVC:] [ACT:] > [from:+2] > [to:1234] [flags:0:1:0:0:0] [msg:3:187] [udh:0:] > > >
Re: Kannel automatic compilation test for SunOS
Oded Arbel wrote: > > Hi list. > The definitions for the gw_mem calls in malloc=native mode result in lots of >compilation warning - would it be possible to #define those in such a way as to >completly be ignored by the compiler ? as gcc doesn't like the meaningles statements >created by the current #defines. Hmm, I played around a bit to solve this, but this seems to be more tricky then I thought of. Anyone having an idea for this one? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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: Message store (Was: EMI: Serious Problem PANIC: Too manyconcurrent allocations)
On Wed, 12 Jun 2002, Aarno Syvänen wrote: > Speaking of store files - After really looking into the store logic, it The better way to implement the store file (than the old way I did quickly use - you have to remember that original store file was just a quick hack to concentrate more on SMS side that almost-useless-WAP ;) - like earlier, write all messages and acks and nacks to file - keep copy of all non-acked messages in memory - when Kannel receives an ack (or nack), write a new store file out of still remaining (non-acked) messages to replace the old. Naturally only do this now and then, like if there has not been writing in last half a minute. (and of course first write to new file and then rename etc.) ..this way the store file normally keeps empty or only some odd messages, unless lots of messages do not get (n)acks. Of course this means that Kannel will grow in memory if messages do not get ackked, too. -- &kalle marjola
Re: [bug] : Released too many threads - 1 now 1 originally
This is one of my test boxes that I'm running with Cygwin - might well the not very happy conflict between the two.. - Original Message - From: "Oded Arbel" <[EMAIL PROTECTED]> To: "Alex Judd" <[EMAIL PROTECTED]>; "Kannel-devel (E-mail)" <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 1:28 PM Subject: RE: [bug] : Released too many threads - 1 now 1 originally > Haven't seen this in our systems, and I don't even know who generates this : log_sms() doesn't write this kind of format.
RE: Kannel automatic compilation test for SunOS
Hi. Just had a talk with my resident GCC guru, and his suggestion (which seems to work for me) is to #define the functions as nothing, i.e. #define func_name(a) thats it. nothing after that. now GCC is happy :-) -- Oded Arbel m-Wise Mobile Solutions [EMAIL PROTECTED] Mobile: +972-67-340014 Tel: +972-9-9581711 (ext: 116) ::.. The President publicly apologized today to all those offended by his brother's remark, "There's more Arabs in this country than there is Jews!". Those offended include Arabs, Jews, and English teachers. -- Baltimore, Channel 11 News, on Jimmy Carter > -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 3:00 PM > To: Oded Arbel > Cc: Kannel-devel (E-mail) > Subject: Re: Kannel automatic compilation test for SunOS > > > Oded Arbel wrote: > > > > Hi list. > > The definitions for the gw_mem calls in malloc=native mode > result in lots of compilation warning - would it be possible > to #define those in such a way as to completly be ignored by > the compiler ? as gcc doesn't like the meaningles statements > created by the current #defines. > > Hmm, I played around a bit to solve this, but this seems to be more > tricky then I thought of. > > Anyone having an idea for this one? > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Vogelsanger Weg 80 > 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: Message store (Was: EMI: Serious Problem PANIC: Too manyconcurrent allocations)
That sounds like a good idea. The thing is, that the messages are already kept in memory, in the SMSC driver, which then returns it to the bearerbox using bb_smsconn_sent() or bb_smsconn_send_failed(). maybe it's easier to use that, and modify the implementation of the drivers not to copy the message they received using the queue() call back, but only get a reference to it. then the bearerbox won't delete the message after sending it to the driver and keep it in said dictionary. when the driver is finished with the message and sends it back, using the sent (ack) or send_failed (nack) calls, it is then matched. that way no duplication of the message in memory is needed, and there is only one message structure for a single message in the entire process. of course - it also means that two threads (maybe more) are sharing the same memory structure (even though the bearebox doesn't do anything with it while it's in the driver control - simply storing it), so all need to play nice together. You also don't need to store acks in the store, as only unacked messages are stored there. -- Oded Arbel m-Wise Mobile Solutions [EMAIL PROTECTED] Mobile: +972-67-340014 Tel: +972-9-9581711 (ext: 116) ::.. "There's many a bestseller that could have been prevented by a good teacher." -- Flannery O'Connor > -Original Message- > From: Kalle Marjola [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 3:43 PM > Cc: [EMAIL PROTECTED] > Subject: Re: Message store (Was: EMI: Serious Problem PANIC: > Too manyconcurrent allocations) > > > On Wed, 12 Jun 2002, Aarno Syvänen wrote: > > > Speaking of store files - After really looking into the > store logic, it > > The better way to implement the store file (than the old way > I did quickly > use - you have to remember that original store file was just > a quick hack > to concentrate more on SMS side that almost-useless-WAP ;) > > - like earlier, write all messages and acks and nacks to file > - keep copy of all non-acked messages in memory > - when Kannel receives an ack (or nack), write a new store file out >of still remaining (non-acked) messages to replace the old. >Naturally only do this now and then, like if there has not > been writing >in last half a minute. (and of course first write to new > file and then >rename etc.) > > > ..this way the store file normally keeps empty or only some > odd messages, > unless lots of messages do not get (n)acks. Of course this means that > Kannel will grow in memory if messages do not get ackked, too. > > > -- > &kalle marjola > > >
Deliver Notification of concatenated msgs
This may not be the right platform to raise this question but am sure somebody out there can help. I wanted to know that when submitting concatenated short messages to a SMSC, how many Delivery Notifications do I expect from SMSC? Does SMSC reply with only one Delivery Notification or it replies with separate Delivery Notification for every slice? Does this depend on the capability of the Handset to display a concatenated short message as a single message? TIA, JS
Re: Deliver Notification of concatenated msgs
>This may not be the right platform to raise this question but am sure >somebody out there can help. > >I wanted to know that when submitting concatenated short messages to a >SMSC, how many Delivery Notifications do I expect from SMSC? Does SMSC >reply with only one Delivery Notification or it replies with separate >Delivery Notification for every slice? >Does this depend on the capability of the Handset to display a concatenated >short message as a single message? The code which splits SMS into individual SMS's puts the DLR request on the first segment but not on the following ones. This means if a user submits one SMS which gets split internally and invisibly inside Kannel and gets sent to the SMSC, the user gets one delivery notification on reception of the first message. -- 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: Deliver Notification of concatenated msgs
Hi all, our experience is a little different as we are not using Kannel to connect directly to SMSC. For e.g. EMS, it uses concatenated SMS. We get a deliver status report for each SMS. Hence we have to ensure that we receive all reports before generating CDR records. I am not sure if you mean delivery notification as the deliver status report to tell you that the handset receives the SMS successfully or the submission to SMSC is successful. It is then the job of the handset to intelligently assemble those SMS. > >This may not be the right platform to raise this question but am sure > >somebody out there can help. > > > >I wanted to know that when submitting concatenated short messages to a > >SMSC, how many Delivery Notifications do I expect from SMSC? Does SMSC > >reply with only one Delivery Notification or it replies with separate > >Delivery Notification for every slice? > >Does this depend on the capability of the Handset to display a concatenated > >short message as a single message? > > The code which splits SMS into individual SMS's puts the DLR request > on the first segment but not on the following ones. This means if a > user submits one SMS which gets split internally and invisibly > inside Kannel and gets sent to the SMSC, the user gets one delivery > notification on reception of the first message. > -- > > 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 See Chun Yan N2N Consulting Tel: 65 6337 0322 Fax: 65 6336 9245 HP: 65 9798 9119 www.n2nconsulting.com
Re: Deliver Notification of concatenated msgs
Inline as [JS] thanks. - Original Message - From: "See Chun Yan" <[EMAIL PROTECTED]> To: "Andreas Fink" <[EMAIL PROTECTED]>; "Jeetendra Singh" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, June 14, 2002 11:05 AM Subject: Re: Deliver Notification of concatenated msgs > Hi all, > >our experience is a little different as we are not using Kannel >to connect directly to SMSC. > >For e.g. EMS, it uses concatenated SMS. We get a deliver status >report for each SMS. Hence we have to ensure that we receive >all reports before generating CDR records. I am not sure >if you mean delivery notification as the deliver status report to >tell you that the handset receives the SMS successfully or the >submission to SMSC is successful. [JS] I think SUBMISSION to SMSC for each segment is ALWAYS acked by SMSC separately. What i was interested in is deliver status report for HANDSET??? > >It is then the job of the handset to intelligently assemble those SMS. > > > >This may not be the right platform to raise this question but am sure > > >somebody out there can help. > > > > > >I wanted to know that when submitting concatenated short messages to a > > >SMSC, how many Delivery Notifications do I expect from SMSC? Does SMSC > > >reply with only one Delivery Notification or it replies with separate > > >Delivery Notification for every slice? > > >Does this depend on the capability of the Handset to display a concatenated > > >short message as a single message? > > > > The code which splits SMS into individual SMS's puts the DLR request > > on the first segment but not on the following ones. This means if a > > user submits one SMS which gets split internally and invisibly > > inside Kannel and gets sent to the SMSC, the user gets one delivery > > notification on reception of the first message. [JS] Why should Kannel be doing anything of this sort? What happens to the deliver status report of other segments in such a case if SMSC provides separate deliver status reports for each segment (This was my question in first place. Can somebody please confirm the SMSC behaviour ?) > > -- > > > > 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 > > > See Chun Yan > N2N Consulting > Tel: 65 6337 0322 > Fax: 65 6336 9245 > HP: 65 9798 9119 > www.n2nconsulting.com
