On Mon, Feb 23, 2009 at 11:34:40AM +0300, Лавкин Михаил wrote:
Subject: Bug
Hello all.
After some time of work (6-10 hours) getstream is using more and more CPU.
4001 port is's getstream http port.
In netstat i see
tcp 0 1268 91.195.130.31:4001 10.14.6.1:1377 ESTABLISHED tcp 0 0 91.195.130.31:4001 91.195.130.6:58613 CLOSE_WAIT tcp 0 0 91.195.130.31:4001 91.195.130.6:60152 CLOSE_WAIT tcp 0 0 91.195.130.31:4001 91.195.130.6:57914 CLOSE_WAIT tcp 0 0 91.195.130.31:4001 91.195.130.6:60662 CLOSE_WAIT tcp 0 0 91.195.130.31:4001 91.195.130.6:57871 CLOSE_WAIT
Thats interesting - What client are you using for taking content from the http port? This really sounds like a bug in getstream not beeing able to detect some odd way to close the http connection but it should take more cpu cycles as tcp connections which do not take data should be dropped after HTTP_MAX_QUEUED bytes and HTTP_MAX_OVERFLOW trys to write something to it ... Did getstream mention something that it closed/dropped the http connection? It should do so when started with -d or something ... I retried both ways to drop the connection by using: wget -O /dev/null http://stream2:8001/radio/einslive And then either pressing ctrl-c which is a tcp-fin which immediatly lets the connection drop or by pressing ctrl-z which simply doesnt ack any packets anymore - this takes a little longer to drop as libhttp.c/output_http start queueing data a little after which it drops the connection because of buffer overflow. In both bases getstream successfully closes the tcp socket so no CLOSE_WAIT sockets show up ... You might want to set DEBUG in libhttp.c (right at the top) and try around until you get a CLOSE_WAIT socket and show the output. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin