It seems ok to me. why not put it in the TS-1339, so that we all can
reviews and test it.

On Mon, 2012-08-20 at 11:31 -0500, Alan M. Carroll wrote:
> As we're on the subject of supporting range requests, I have a substantive 
> patch at
> 
> https://github.com/SolidWallOfCode/trafficserver/tree/range
> 
> which attempts to fix the current range issue with alternates. This patch 
> moves the fragment offset table from the Doc header to the alternate info. 
> This means the offsets are stored per alternate and therefore there is no 
> longer a potential mismatch between that data and the actual alternate 
> content. It works for me, but I have the magic dev box where everything 
> works. I will be doing further testing but if anyone else wants to take a 
> look ...
> 
> Beyond normal clean up (e.g., remove the debug "amc" messages) my primary 
> concern is that ats_malloc is used. This is how the current implementation 
> works but it seems suboptimal. OTOH ats_malloc is called only during writes 
> on objects larger than 4 segments (>5M total length in the default 
> configuration). It's not clear how much performance is relatively impacted by 
> the call for objects that large. There is a heap associated with the 
> alternate info object which may be usable instead, which I hope to be able to 
> investigate although as always hints are appreciated.
> 



Reply via email to