httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Bligh <>
Subject Re: Debugging mod_websocket -- any others out there?
Date Wed, 25 Feb 2015 08:31:13 GMT

On 25 Feb 2015, at 00:16, Jacob Champion <> 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:

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.


Apache <==> Socket+Socket <===> Decode/Encode <===> Whatever

I'm sure that's not particularly efficient, but it would

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

View raw message