[icecast-dev] Icecast's YP bugs
oddsock at oddsock.org
Thu Jun 26 07:01:00 PDT 2003
At 02:16 AM 6/26/2003 -0400, you wrote:
>On Wed, Jun 25, 2003 at 08:31:32AM -0500, oddsock wrote:
> > the problem is with the parsing of the source, it is looking for ice-* and
> > not the icy-* in the source header. The question is, do we want to
> > the icy headers from shoutcast ? I suppose we probably should, but it's a
> > bit irritating having to put shoutcast compatibility code in icecast.....
>Let's not loose sight of the other two bugs, which I personally think
>are more serious...
>1) The memory leak issue caused when Icecast has streams rejected from
>a YP server, reproduce either with a broken YP CGI or with a
>non-existant YP server.. with many streams getting rejected causes a
>Icecast server to consume over 100megs in less than an hour
I was hoping to get a valgrind report from you regarding what this memory
leak was...as I mentioned before, I did find a memory leak or two in
parts of the YP-related code...If you are experiencing a reproducable
memory leak, valgrind is the way to identify it...Providing a valgrind
report is a sure fire way to get a memory leak fixed, without that, we have
to try to reproduce it ourselves, which can be quite difficult sometimes
and take up alot of time...anyway, I just committed the memory leak fix, so
please let us know if you are still seeing leaks.
>2) Icecast continually (every 15 seconds or so, apparently) trying to
>re-publish rejected streams vs "holding off" for a reasonable amount of
>time before retrying. This is this causing the memory leak issue to
>grow much larger than it would otherwise, it could potentially cause an
>already overloaded YP server to get even more overloaded when it cant
>handle requests timely enough vs holding off until the server has had
>time to "cool off".
well, the logic in this respect is fairly simple and doesn't have any
knowledge of multiple types of failures....If you set it too high (the
retry interval) then you get complaints regarding it taking too long for
the stream to list when a problem arises (network or yp-server
related)....The current minimum touch interval is 30 seconds. Also note
that each stream/yp pair has it's own touch interval which is set by the yp
server on an successful yp-add. In the case of a yp-add failure, the touch
interval is set to 30 seconds, which means that every 30 seconds, icecast
will try to re-list that stream on that yp. Although, I'm not sure making
this configurable really is what we want, since if you are running into
trouble yp-adding and it's a YP server unavailablility problem, then you'd
want the server to continue to retry at a relatively fast interval...If you
are running into trouble yp-adding due to something that you are not
providing on your source client (not providing server name for instance),
then you should really fix this or turn off yp listing altogether.
<p>--- >8 ----
List archives: http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Icecast-dev