in this context the key question is if your smsc configs for http smsc's shares the same receive port because for every http-smsc sending is a http client while receiving is a http server. Every http-smsc must have its own http-server as they dont know of each other. If you have two http-smscs with the same receive port, the described outcome could very well be as one http-smsc receiver thread would steal tasks from the other.
could that be your issue? On 22.07.2013, at 22:12, Brian McCavour <[email protected]> wrote: > > Hi Andreas, > > Thanks for your response. Sorry I was not more clear :) > I only have 1 http server. The modifications I've done is to add custom types > of http smsc. I never touched any of the underlying code however, I just copy > pasted the generic implementation (in smsc_http.c), and made new send/receive > functions per type. Then I added a few other configuration options for the > smsc. So all of the threading / networking code is unmodified (except what > I've added to try and fix this issue) > > From what I can understand, this 1 http server thread in kannel will do: > Look for a new server socket, add 1 new server socket to the list of file > descriptors if a new socket found > Poll given the list of FD > Handle data > Check if we need to close any sockets > During startup as we're looping through SMSC in CFG (bb_smscconn > smsc2_start), for each http smsc it calls http_open_port_if, which should (I > believe?) wakeup the server thread, basicaly restarting back at 1. again. > > So what I expect to see, when I have 4 http smsc in my .conf is 1, 2, 1, 2, > 1, 2, 1, 2, which each new socket connection interupting and adding its > socket to the list of FD, before going back to polling. > > What I am actually seeing through, is that it will block during the poll, and > the new sockets being added still in the main thread get added to the > "new_server_sockets" correctly, but the polling thread never wakes up to > pickup this new socket. So the fix that I did was just to move the start of > the http server from attempting to start it everytime you try and open an > http port, to just openeing it 1 time after reading in all the smsc from CFG. > The I changed from adding 1 socket per itteration, to add all new server > sockets to the FD list in 1 iteration. > > Maybe I am just really misunderstanding what is happening, but my "hack" did > fix the problem, so it must somehow be related. > > What are your thoughts? > > thx, > Brian > > > > From: Andreas Fink <[email protected]> > To: Brian McCavour <[email protected]> > Cc: devel Devel <[email protected]> > Sent: Monday, July 22, 2013 3:37:17 PM > Subject: Re: Blocked ports for MO (generic http smsc) > > If I understand you right, you have some code to run virtually multiple http > servers which do different things? > You must be aware that gwlib is build the way that it runs multiple threads > polling of the same incoming port. In other words if you run on port 80 a min > webserver to serve documents, then every thread waits on something to happen > and if an incoming data arrives any of the worker thread catches it and > processes it. > As in many places inside kannel/gwlib this is done using internal pipes where > the waiting threads are sitting inside a poll and the thread who discovered > there's work to do actually writes a byte into this pipe and thus waking up > any or all of the waiting threads. > > Now if you run multiple servers, lets say on port 80 and port 443, you need > to separate this mechanism. Which means every group of listening threads for > either port must have its own pipe its listening to. If I guess correctly, > you have an extension built which runs multiple http servers and does > something with it > > I have used gwlib with multiple http servers without a problem. I believe > gwlib is doing the right thing but you might need to create a second > instance. But without seeing your code modifications, its impossible to > answer that. > > On 22.07.2013, at 21:20, Brian McCavour <[email protected]> wrote: > >> Hi, >> >> I was investigating an issue I had on my customized Kannel where only the >> first Http SMSC, of many http smsc, would be able to receive MO. The other >> sockets would simply hang (or so it appeared). >> >> I discovered that basically the http server thread was getting blocked on >> the thread poll, and until I send a message through to a port that is >> already in the list, it ill never pickup any of those requests. >> Basically, in http.c, the function server_thread() picks up the first http >> SMSC, adds it to struct pollfd tab[MAX_SERVERS]; >> Then if ((ret = gwthread_poll(tab, n, -1.0)) == -1) will block >> waiting for data on the socket. >> >> But if there is another server to be added afterwards, this gets called from >> http.c: int http_open_port_if(int port, int ssl, Octstr *interface); >> Now it looks like this should wake up that polling thread, and add the new >> port to "tab" data structure above, and go back to waiting state again. but >> waiting on more sockets now.. >> >> The doc says: >> /* If the other thread is currently in gwthread_pollfd or gwthread_sleep, >> * make it return immediately. Otherwise, make it return immediately, the >> * next time it calls one of those functions. */ >> void gwthread_wakeup(long thread); >> >> But I see many calls to gwthread_pollfd and its never unblocking. >> >> I've done a really dirty hack to make it work temporarily. I removed the >> call to start_server_thread from http_open_port_if, so its not called after >> creating each SMSC. >> Now I just call it manualy after loading all over the SMSC from CFG. Then I >> changed the server_thread to instead of adding 1 socket per itteration, it >> loops (in server_thread()): >> while (n < MAX_SERVERS && gwlist_len(new_server_sockets) > 0) >> >> It seems to be working fine for now, but it is really not a clean solution >> at all. >> Has anyone bumped into this before, or knows a good solution? >> >> Thanks, >> Brian > > >
