[Red5] FLVReader improvement (?)
justin at jrcorps.com
Fri May 4 13:11:26 EDT 2007
I would go with some sort of cache locking... So when one file opens the
cache, it locks it for read (and write) access. Then when the second one
arrives, it says "oh it's locked" and sleeps, then checks again and
again until the cache "unlocks". In theory, this means that if two
people hit the unpopulated cache at the same time, they will both have
to wait the same amount of time... But anyone after that will only have
to wait up to the length it takes to load in the data from the cache.
Hope that helps,
Rob Schoenaker wrote:
> Hi all,
> As I am progressing quite well on the C# implementation, I run into some
> issues. One of the issues I face has to do with the FLVReader class. I
> decided to implement caching for the keyframe tags and here is where the
> problem starts:
> When someone requests an FLV, the file is analyzed. This takes a lot of
> resources, so I don't want this for every request to the same stream.
> Therefore I use the cache to store the keyframe maps.
> However, when 2 connections request the same file at the same time, the
> cache is not yet populated with the keyframe data, so both threads start
> analyzing the file...
> Now, what I would want is to have 1 analyzer and the other ones waiting
> for the first to finish and then get the data from cache (provided it is
> in there)
> How could I accomplish this at best in Java?
> One thing that crossed my mind is a locked list of 'in the works'
> analyzers - a kind of pre-cache, implemented in the FLVReader class that
> gets notified when the first analyzer finishes.
> Any thought anyone?
> Red5 mailing list
> Red5 at osflash.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 284 bytes
Desc: not available
Url : http://osflash.org/pipermail/red5_osflash.org/attachments/20070504/a12ae85b/justin.vcf
More information about the Red5