On 25 Feb 2015, at 00:16, Jacob Champion <jacob.champ...@ni.com> wrote:
> I've been working with mod_websocket [1] for a few weeks now. Things > were going very well until we ran into crashes under heavy load. I > _think_ they are related to the threading model used by mod_websocket -- > it spins up a new thread and a new bucket brigade to write to the > connection, while the original thread and brigade block to read > messages. Unfortunately I don't know enough about the brigade system to > know whether that's kosher or even fixable. Yes. I've seen this. There were once some issues with the brigade allocators. You may want to look at my fork here: https://github.com/abligh/apache-websocket In there you'll find 'vncproxy' which is actually a generic tcp proxy. Despite my fixes, it still dies occasionally, normally because one of the bucket brigades becomes corrupt. I spent many many hours on this, ultimately unsuccessfully (I've moved to mod_proxy_wstunnel plus a libwebsockets C based thing). FWIW if I hadn't made the above move, my plan was to eliminate doing most of the work in the apache thread by using a bucket brigade thate ended in a socketpair (I can't remember the correct apache terminology here, but the point was to have apache do the read/write from one end of the socketpair), then set up two new threads to read and write from the other end of the socketpair, encoding/decoding as we go. This means that once the connection is live the module code itself wouldn't actually touch any apache memory-managed data. IE: Apache <==> Socket+Socket <===> Decode/Encode <===> Whatever I'm sure that's not particularly efficient, but it would work. I was idly thinking about swapping the encode/decode function for libwebsockets, but the "LGPL2+ static link exception" bit may create an issue. TBH I never had any issues with the actual encode/decode code. -- Alex Bligh
