I've isolated the problem a little more and added my findings as a comment on the bugtracking system.
Looking on the smsbox.log, stored UUID and ACK does not match, so the key it's not found on client_dict and the client doesn't get retrieved, so no response is given. 2007-04-03 02:53:42 [14437] [3] DEBUG: Stored UUID 60225f41-f5d5-44bc-bc40-d5ec0adf5c35 ... 2007-04-03 02:53:42 [14437] [0] DEBUG: Got ACK (0) of 302d1d81-c96f-47ee-8c0f-db51d6a5a283 So, it looks like a thread syncronization problem or dictionary corruption (I'm just guessing here). Since the keys doesn't match, the client session it's lost for good. I've tried with file and spool storage engines to discard a bug there and I've achieved identical behaviour with both of them. Regards, Alejandro On 4/4/07, Andreas Fink <[EMAIL PROTECTED]> wrote:
I have a similar issue I'm hunting in my own application using gwlib. We have SMPP, EMI/UCP and two HTTP instances in our SMSC code (based on gwlib). We end up having a lockup in SMPP and HTTP on both instances. EMI does still answer but HTTP are both dead (one is for submission, one for admin). I currently have no idea what triggers it but it sounds similar. As we only use gwlib, it sounds like something in there triggers the issue. While trying to track this down I came a long the thread race issue I posted here a few days ago. My suspicion is that it could be triggered by some fake http sumit (virus scanning the network or such) that a lock is being added but because of error it jumps out and never got removed and this lock stops everything. However this is a very wild guess. What puzzle's me was that only SMPP was affected in our case but not EMI even though both drivers look very similar except that EMI is idle and SMPP is busy. On 04.04.2007, at 02:05, Alejandro Guerrieri wrote: > Filed issue #397 under "SMSBox" (shall I use HTTP instead?) > > Please let me know if you need me to conduct more tests or try some > code on my dev machine. > > Regards, > > Alejandro. > > On 4/3/07, Stipe Tolj <[EMAIL PROTECTED]> wrote: >> Stipe Tolj wrote: >> >> > now, this behaviour is now *confirmed* for a vanila CVS checkout >> and >> > fakesmsc usage via gw/smskannel.conf sample config on the following >> > hosts too: >> > >> > amd64, 2.6.20-1.2307.fc5 x86_64 >> > x86, 2.6.11-1.1369_FC4 i686 >> > >> > so this is considered as generic bug! (that's why I cross-post >> to devel@ >> > too). Please review Alejandro's post. >> > >> > @Alejandro: can you please file this issue to our bug tracking >> syetem at >> > http://bugs.kannel.org/, so we keep a clean track of resolving it. >> > >> > This needs to be cleaned and resolved before any new release can >> be done! >> >> this is pretty strange, since gwlib/http.c and gw/smsbox.c haven't >> been touched >> in cvs for some 2 months, and the issue has been arrising now. >> >> Checked if recent gwlib/octstr.c commits had some implications, >> but they have >> not. It's still the same behaviour for the missing smsbox's HTTP >> server response. >> >> Need to investigate more.... >> >> Stipe >> >> ------------------------------------------------------------------- >> Kölner Landstrasse 419 >> 40589 Düsseldorf, NRW, Germany >> >> tolj.org system architecture Kannel Software Foundation (KSF) >> http://www.tolj.org/ http://www.kannel.org/ >> >> mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org >> ------------------------------------------------------------------- >> > > > -- > Alejandro Guerrieri > Magicom > http://www.magicom-bcn.net/ > LinkedIn: http://www.linkedin.com/in/aguerrieri >
-- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri
