Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of alex@alex.org.uk designates
 89.16.176.221 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Debugging mod_websocket -- any others out there?
From: Alex Bligh <alex@alex.org.uk>
In-Reply-To: <54ED1473.1060604@ni.com>
Date: Wed, 25 Feb 2015 08:31:13 +0000
Cc: Alex Bligh <alex@alex.org.uk>
Content-Transfer-Encoding: 7bit
Message-Id: <F188D1B8-3B93-4455-8229-1AA5596422FA@alex.org.uk>
References: <54ED1473.1060604@ni.com>
To: modules-dev@httpd.apache.org


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