On 05/27/2011 01:28 PM, Earle, Erik wrote:
>
> Is there a good starting point for looking at plugging into the
> internals of ATS.
>
> For example, suppose I wanted to replace the default caching mechanism
> with memcache or add a full http client (like libcurl) without
> blocking in a continuation callback thread.
>
You'd want to implement that as a 'server intercept' plugin I think Then
your plugin acts as the "origin", and you have to implement all access
to either the memcache storage, or HTTP yourself. You then have the
option to make the "response" cached in the normal ATS HTTP cache (i.e.
if you use TSHttpTxnIntercept() it would not be cacheable, while if you
use TSHttpTxnServerIntercept() it will go through the HTTP SM, and
therefore potentially could be cached).
This would be a fair amount of work, but I've seen it done at least
once, and it worked very well (it used a distributed FS as the "backend"
cache). There's no way, currently at least, to implement a replacement
HTTP cache as a plugin (so, an intercept plugin is the only way to do it).
Cheers,
-- Leif
|