[icecast-dev] Icecast's YP bugs

[oddsock]

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 
> support
> > 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>oddsock

<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.