smsbox blocks HTTP response - Re: Latest CVS problem

Alejandro Guerrieri alejandro.guerrieri at gmail.com
Wed Apr 4 23:43:03 CEST 2007


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 <afink at mac.com> 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 <st at tolj.org> 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



More information about the devel mailing list