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:
1. Look for a new server socket, add 1 new server socket to the list of
file descriptors if a new socket found
2. Poll given the list of FD
3. Handle data
4. 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
>
