Sorry for the spam guys. Last one.... I found the resolution. This is fixed in 1.5.0, bug #525 See more details @ https://redmine.kannel.org/issues/525
Lessons learned... always checks latest code changes! ________________________________ From: Brian McCavour <[email protected]> To: Andreas Fink <[email protected]> Cc: devel Devel <[email protected]> Sent: Tuesday, July 23, 2013 8:52:24 AM Subject: Re: Blocked ports for MO (generic http smsc) I'm still not able to reproduce it with generic http smsc's. I think it must be just a racing condition somewhere when the loading time for smsc is long. I just checked the 1.5.0 source, and someone has made one of the 2 changes I made. (To pickup all new server ports instead of 1 per loop iteration.) So I'm going to try and remove my other change and maybe this 1 change is enough.... Either way I'm running out of time for this unfortunately :( so if it works fine for me after the fix and no one else has this issue... so be it :D Thanks again for your thoughts. == Brian ________________________________ From: Brian McCavour <[email protected]> To: Andreas Fink <[email protected]> Cc: devel Devel <[email protected]> Sent: Tuesday, July 23, 2013 7:59:22 AM Subject: Re: Blocked ports for MO (generic http smsc) Each SMSC has its own port.I forgot to mention, this is working off of 1.4.3. Maybe the http implementaiton has changed since then? I only see 1 server thread starting for all http ports. (including the admin port) I'm going to go back and try and reproduce it on release 1.4.3 with debug logs, then I can post the config. ________________________________ From: Andreas Fink <[email protected]> To: Brian McCavour <[email protected]> Cc: devel Devel <[email protected]> Sent: Tuesday, July 23, 2013 2:07:11 AM Subject: 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: > > 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 >> > > >
