Re: Blocked ports for MO (generic http smsc)

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
> 
> 
>