Bruno David Rodrigues wrote:

 > 2001-11-29 07:49:27 [0] DEBUG: Started thread 5
 > (gwlib/http.c:write_request_thread)
 > ........
 >
 > 2001-11-29 07:49:31 [6] INFO: Starting to service <key> from <number> to
 > <number>
 > 2001-11-29 07:49:31 [5] DEBUG: HTTP: Sending request:
 > 2001-11-29 07:49:31 [5] DEBUG: Octet string at 0x404032f8:
 > 2001-11-29 07:49:31 [5] DEBUG:   len:  123
 > 2001-11-29 07:49:31 [5] DEBUG:   size: 124
 > 2001-11-29 07:49:31 [5] DEBUG:   immutable: 0
 > 2001-11-29 07:49:31 [5] DEBUG:   data: 47 45 54 20 2f 53 4d 53   GET /SMS
 > ..... (Normal request)
 >
 > 2001-11-29 07:49:31 [5] DEBUG:   data: 0a 55 73 65 72 2d 41 67   .User-Ag
 > 2001-11-29 07:49:31 [5] DEBUG:   data: 65 6e 74 3a 20 4b 61 6e   ent: Kan
 > 2001-11-29 07:49:31 [5] DEBUG:   data: 6e 65 6c 20 63 76 73 0d   nel cvs.
 > 2001-11-29 07:49:31 [5] DEBUG:   data: 0a 0d 0a                  ...
 > 2001-11-29 07:49:31 [5] DEBUG: Octet string dump ends.
 > 2001-11-29 07:49:31 [5] PANIC: mutex_unlock: Mutex failure!
 > 2001-11-29 07:49:31 [5] PANIC: System error 22: Invalid argument
 >
 > Please note that I'm receiving more than 10k messages/hour and sending
 > +- 15k



 > BTW: I have another problem using two smsboxes, I'll send in other 
message.


I run into this a week ago while developing a new http-smsc-interface to
a client of mine. The problem was that the program at the other end was
much less stable than Kannel. And soon Kannel started to have similar
problems, that is panicking time to time and that System error 22 in the
logs.

I traced the problem down to the *_parse_reply-function, which happens
to be almost similar to the kannel_parse_reply, except the way of
deciding whether the response was what it was supposed to be for an OK
status. And the bug was in the other path anyway. (The program in the
other end was a script, so when it chrashed I got an HTTP-error back!)

So this bug occurs when the sending through the http-interface failed.
This bug doesn't occur if there's _no_other_SMSC-connection_open!
Therefore my fast patch solution to my customer was to put up two
Kannels in their server so that one will handle the SMSC-connections and
other the HTTP-connection.

Unfortunately, I'm not able to reproduce this bug right now, but I hope 
this helps.


-- 
Tuomas Luttinen
      Application Developer -- Reach U
          **************



Reply via email to