yaws revproxy, socket leak - CLOSE_WAIT

[andrey-google]

Hi!
Have anybody used yaws revproxy for Javascript XMPP client over
HTTP-BOSH-XMPP (like JWChat, JsJAC)?
In idle state of connected client, I see a leak of socket descriptors.
Those sockets are hanging in CLOSE_WAIT state, and soon descriptor are
exhausted causing yaws crash and session break.

Some info:
1)revproxy is necessary, because Javascript client cannot send AJAX
request directly to host(port) of BOSH server, which is differ from
web-page's host.
2) Javascript client sends BOSH requests and waits the response. At idle
state, response is absent and client repeats request after client timeout.
3) yaws keepalive_timeout is a bit longer then client timeout to save
BOSH session.

Have anybody resolved this issue with CLOSE_WAIT sockets?
Or, could it be a problem with OS settings?
Or, could it be a bug in revproxy implementation?
Any thoughts?

For example, I have yaws <server> on 8003 port with revproxy to 5280
port of BOSCH-XMPP server.

Then, with time, I saw following leaked sockets (lsof -n -p output):

beam    4667 user_yaws  195u  IPv4  45421      0t0    TCP
127.0.0.1:53922->127.0.0.1:5280 (CLOSE_WAIT)
beam    4667 user_yaws  196u  IPv4  45466      0t0    TCP
127.0.0.1:35734->127.0.0.1:8003 (CLOSE_WAIT)
beam    4667 user_yaws  197u  IPv4  45437      0t0    TCP
127.0.0.1:38553->127.0.0.1:5280 (CLOSE_WAIT)
beam    4667 user_yaws  198u  IPv4  45482      0t0    TCP
127.0.0.1:33266->127.0.0.1:8003 (CLOSE_WAIT)
beam    4667 user_yaws  199u  IPv4  45453      0t0    TCP
127.0.0.1:41014->127.0.0.1:5280 (CLOSE_WAIT)
beam    4667 user_yaws  200u  IPv4  45501      0t0    TCP
127.0.0.1:36008->127.0.0.1:8003 (CLOSE_WAIT
.... lot of after awhile ...


Thanks for reading.

Andrew.


------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[Steve Vinoski-2]

On Thu, May 5, 2011 at 5:50 PM, Andrew <buricchio@...> wrote:

> Hi!
> Have anybody used yaws revproxy for Javascript XMPP client over
> HTTP-BOSH-XMPP (like JWChat, JsJAC)?
> In idle state of connected client, I see a leak of socket descriptors.
> Those sockets are hanging in CLOSE_WAIT state, and soon descriptor are
> exhausted causing yaws crash and session break.
>
> Some info:
> 1)revproxy is necessary, because Javascript client cannot send AJAX
> request directly to host(port) of BOSH server, which is differ from
> web-page's host.
> 2) Javascript client sends BOSH requests and waits the response. At idle
> state, response is absent and client repeats request after client timeout.
> 3) yaws keepalive_timeout is a bit longer then client timeout to save
> BOSH session.
>
> Have anybody resolved this issue with CLOSE_WAIT sockets?
> Or, could it be a problem with OS settings?
> Or, could it be a bug in revproxy implementation?
> Any thoughts?

The rev_proxy code is experimental. I think some have used it
successfully but YMMV.

Klacke and I recently chatted about this code. He has no time to work
on it at present, and I don't have any use cases for it myself that
would help me improve it. However, if people are willing to submit
test cases for it, especially cases that should work but don't, I'd
definitely fix any problems those cases cover.

Andrew, any chance you could whittle your code down to a minimal test
case that shows the problem?

--steve

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[andrey-google]

Hi!

Many thanks for reply!
I have attached the test.
Probably this simple pure YAWS+AJAX test behaves quite similar.
At least, the test shows  gradual CLOSE_WAIT sockets leak till crash on
revproxy and no such a leak without revproxy.
There is more info in README file.

At the tests, I've used FireFox browser, don't know if the script will
work on other browser.

Andrew.


On 5/6/2011 6:10 AM, Steve Vinoski wrote:

> On Thu, May 5, 2011 at 5:50 PM, Andrew<buricchio@...>  wrote:
>> Hi!
>> Have anybody used yaws revproxy for Javascript XMPP client over
>> HTTP-BOSH-XMPP (like JWChat, JsJAC)?
>> In idle state of connected client, I see a leak of socket descriptors.
>> Those sockets are hanging in CLOSE_WAIT state, and soon descriptor are
>> exhausted causing yaws crash and session break.
>>
>> Some info:
>> 1)revproxy is necessary, because Javascript client cannot send AJAX
>> request directly to host(port) of BOSH server, which is differ from
>> web-page's host.
>> 2) Javascript client sends BOSH requests and waits the response. At idle
>> state, response is absent and client repeats request after client timeout.
>> 3) yaws keepalive_timeout is a bit longer then client timeout to save
>> BOSH session.
>>
>> Have anybody resolved this issue with CLOSE_WAIT sockets?
>> Or, could it be a problem with OS settings?
>> Or, could it be a bug in revproxy implementation?
>> Any thoughts?
> The rev_proxy code is experimental. I think some have used it
> successfully but YMMV.
>
> Klacke and I recently chatted about this code. He has no time to work
> on it at present, and I don't have any use cases for it myself that
> would help me improve it. However, if people are willing to submit
> test cases for it, especially cases that should work but don't, I'd
> definitely fix any problems those cases cover.
>
> Andrew, any chance you could whittle your code down to a minimal test
> case that shows the problem?
>
> --steve
>

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list

[Steve Vinoski-2]

Hi Andrew, great, thanks very much for the test. I'll dig into this
later today and see what's going on.

--steve

On Sun, May 8, 2011 at 9:13 AM, Andrew <buricchio@...> wrote:

> Hi!
>
> Many thanks for reply!
> I have attached the test.
> Probably this simple pure YAWS+AJAX test behaves quite similar.
> At least, the test shows  gradual CLOSE_WAIT sockets leak till crash on
> revproxy and no such a leak without revproxy.
> There is more info in README file.
>
> At the tests, I've used FireFox browser, don't know if the script will work
> on other browser.
>
> Andrew.
>
>
> On 5/6/2011 6:10 AM, Steve Vinoski wrote:
>>
>> On Thu, May 5, 2011 at 5:50 PM, Andrew<buricchio@...>  wrote:
>>>
>>> Hi!
>>> Have anybody used yaws revproxy for Javascript XMPP client over
>>> HTTP-BOSH-XMPP (like JWChat, JsJAC)?
>>> In idle state of connected client, I see a leak of socket descriptors.
>>> Those sockets are hanging in CLOSE_WAIT state, and soon descriptor are
>>> exhausted causing yaws crash and session break.
>>>
>>> Some info:
>>> 1)revproxy is necessary, because Javascript client cannot send AJAX
>>> request directly to host(port) of BOSH server, which is differ from
>>> web-page's host.
>>> 2) Javascript client sends BOSH requests and waits the response. At idle
>>> state, response is absent and client repeats request after client
>>> timeout.
>>> 3) yaws keepalive_timeout is a bit longer then client timeout to save
>>> BOSH session.
>>>
>>> Have anybody resolved this issue with CLOSE_WAIT sockets?
>>> Or, could it be a problem with OS settings?
>>> Or, could it be a bug in revproxy implementation?
>>> Any thoughts?
>>
>> The rev_proxy code is experimental. I think some have used it
>> successfully but YMMV.
>>
>> Klacke and I recently chatted about this code. He has no time to work
>> on it at present, and I don't have any use cases for it myself that
>> would help me improve it. However, if people are willing to submit
>> test cases for it, especially cases that should work but don't, I'd
>> definitely fix any problems those cases cover.
>>
>> Andrew, any chance you could whittle your code down to a minimal test
>> case that shows the problem?
>>
>> --steve
>>
>
>

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Erlyaws-list mailing list
Erlyaws-list@...
https://lists.sourceforge.net/lists/listinfo/erlyaws-list