No more feedback from you guys since one week.
Which solution do you consider better? The chunk validity bitmap, the
start/end span scheme or maybe another idea?
On Wed, Sep 12, 2012 at 1:30 AM, Bogdan Graur wrote:
>
> > Can we also consider the other way: make the request to t
> > Can we also consider the other way: make the request to the origin server
> > with a larger range so that we may 'join' two disjoint parts of the data?
> > (try to avoid having many empty chunks in between filled chunks)
>
> We can consider it but I think it won't work. It would require, among
> Your write up seems basically accurate to me. I would note again that
> reading the earliest Doc of an alternate is an historical artifact of the
> implementation and not at all a functional requirement.
>
I see. I'm glad you cleared this out too. Initially I thought you planned
to store the fra
your change to move the
fragment table from the first Doc to the alternate entries?
Best regards,
Bogdan Graur
On Thu, Sep 6, 2012 at 4:15 AM, Alan M. Carroll wrote:
> Wednesday, September 5, 2012, 4:16:42 PM, you wrote:
>
> > Are all Doc structures of the same size?
>
> Mos
>
>
> No. The keys are computationally linked. Given a key for a fragment, the
> key for the next fragment is computed, not read.
OK, I think I found the way the next_key is computed from a given key.
> Therefore you can compute the key for fragment i from the key for fragment
> 0 without I/O.
there is currently no bitfield to say which chunks are valid
Are these "fragments inside a fragment" currently used for anything else
than range request acceleration?
Best regards,
Bogdan Graur
Thanks!!
Works fine now!
On Tue, Sep 4, 2012 at 11:45 PM, vijay mamidi wrote:
> you can run just the traffic_server process alone
>
> -Vijay
>
> On Tue, Sep 4, 2012 at 12:55 PM, Bogdan Graur wrote:
> > Hello,
> >
> > I'm trying to do some debug sessions w
Hello,
I'm trying to do some debug sessions with traffic_server but it seems that
something is killing my process.
I assume it is the traffic_cop when my process is not answering some
heartbeat request.
If that is the case can somebody tell me how can I disable the traffic_cop
or maybe change th
ble to the
alternate information. But it is not clear to me where are these offsets
pointing into currently? Where is data with offset zero held?
Best regards,
Bogdan Graur
On Wed, Aug 29, 2012 at 2:58 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Kinda sorta of. I have ma
This model of representing a cached object indeed allows holding only
partial data for the resource.
Is this the current way a cached object is currently represented in TS?
On Fri, Aug 24, 2012 at 2:19 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Thursday, August 23, 2012, 9:00
Thanks for this answer. At least now I have the chance of getting on the
right track finally.
I will switch to the other thread: "Partial object caching".
On Tue, Aug 28, 2012 at 3:38 AM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Monday, August 27, 2012, 4:25:14 PM, you wrote:
>
I don't know if you were sarcastic in your last email so I will continue on
the same idea.
TS-974 (https://issues.apache.org/jira/browse/TS-974) talks about the same
thing I was trying to describe: hold partial objects in the cache for a
large file.
What I was trying to determine in my last posts
> I can't see that being viable. What would be the benefit of caching only
part of the content received by ATS from the origin server? I understand
the benefit of caching part of an object because that is all the origin
server sent but dropping part of data available seems a bit odd.
The purpose o
>There is a huge amount of logic about deciding what to cache with quite a
lot of tunable parameters. In addition most serious users develop their own
plugins to control caching logic (all the clients I have worked for have
done so). You could start with looking through the documentation for
cache.
equests so we maximize our
chances of getting our enhancements accepted back into the mainline project.
Best regards,
Bogdan Graur
On Mon, Aug 20, 2012 at 6:21 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Monday, August 20, 2012, 10:54:31 AM, you wrote:
>
> >>
cache in the documentation, <
> http://trafficserver.apache.org/docs/trunk/admin>.
>
The only reference about range requests there was in the "records.config"
and it was about how to enable the range requests lookup in the cache:
*>> proxy.config.http.cache.range.lookup*
Best regards,
Bogdan Graur
as I could notice latest release notes mention
support for this.
Any pointers on what documents to read first/which source code modules are
of most interest are much appreciated.
Best regards,
Bogdan Graur
17 matches
Mail list logo
