Invalidating in-memory http request cache (Java)

[Marijn Speelman <ma...@hyves.nl>]

Is there a way to refresh the http response cache (which caches manifest 
files, rewritten content, internal js feature files, proxy requests), 
without restarting Shindig? Or what could be the best place to build 
this in?

I don't think nocache=1 works for refreshing everything. For instance, 
when using nocache=1 the in-memory GadgetSpec cache is refreshed, but as 
far as I can see the entry in the http response cache is not (it's 
bypassed completely). Could this theoretically result in two different 
versions of same gadgetspec?

Thanks,

Marijn

Re: Invalidating in-memory http request cache (Java)

[Louis Ryan <lr...@google.com>]

Marijn

For what use-case do you want to flush the cache? We haven't added the
ability for gadget developers/end-users to do this on demand but there has
been some dicussion of this on the spec list. Your observation about
nocache=1 is correct and is implemented that way to allow the gadget to
continue to be served if the HTTP request for the gadget spec fails as we
can still use the one on the cache in the interim and forcibly flushing it
would have prevented this.

-Louis

On Wed, Aug 6, 2008 at 6:53 AM, Marijn Speelman <ma...@hyves.nl> wrote:

> Is there a way to refresh the http response cache (which caches manifest
> files, rewritten content, internal js feature files, proxy requests),
> without restarting Shindig? Or what could be the best place to build this
> in?
>
> I don't think nocache=1 works for refreshing everything. For instance, when
> using nocache=1 the in-memory GadgetSpec cache is refreshed, but as far as I
> can see the entry in the http response cache is not (it's bypassed
> completely). Could this theoretically result in two different versions of
> same gadgetspec?
>
> Thanks,
>
> Marijn
>

Re: Invalidating in-memory http request cache (Java)

[Marijn Speelman <ma...@hyves.nl>]

I was wondering if there is anyone with the same problem we're having
(as described below in the earlier e-mails).

We deploy/host the container specific feature.xml javascript files
seperate from Shindig, which means we want to be able to refresh these
files in the Shindig cache without completely restarting Shindig.

Any input is appreciated.

Thanks!

Marijn Speelman wrote:
> We want to flush the cache for specific URL's, for instance when a
> gadgetspec XML should be refreshed (by the developer or by us) because
> an update was released.
> 
> But our main issue has to do with our container specific container.js,
> defined in opensocial-current/feature.xml. We host this file and others
> separate from Shindig on our static content servers. When deploying a
> new version of our main website we want to be able to refresh these
> Javascript files which are being caching in Shindig.
> 
> I did notice the 'inline' attribute, but because the static content
> servers have an expire header that is far in the future and we normally
> use unique names per file version in the website to deal with this, I
> don't really see a way to make users or shindig download the new
> container.js now. (And if I remember correctly it also gave us some
> problems with the right order of loading the scripts.)
> 
> Maybe we're doing this the wrong way? Any help is appreciated.
> 
> Thanks.
> 
> ps. Sorry for my late response. I had trouble with my e-mail.
> 
>> Marijn
>>
>> For what use-case do you want to flush the cache? We haven't added the
>> ability for gadget developers/end-users to do this on demand but there
>> has
>> been some dicussion of this on the spec list. Your observation about
>> nocache=1 is correct and is implemented that way to allow the gadget to
>> continue to be served if the HTTP request for the gadget spec fails as we
>> can still use the one on the cache in the interim and forcibly
>> flushing it
>> would have prevented this.
>>
>> -Louis
>>
>> On Wed, Aug 6, 2008 at 6:53 AM, Marijn Speelman <ma...@hyves.nl> wrote:
>>
>>> Is there a way to refresh the http response cache (which caches manifest
>>> files, rewritten content, internal js feature files, proxy requests),
>>> without restarting Shindig? Or what could be the best place to build
>>> this
>>> in?
>>>
>>> I don't think nocache=1 works for refreshing everything. For
>>> instance, when
>>> using nocache=1 the in-memory GadgetSpec cache is refreshed, but as
>>> far as I
>>> can see the entry in the http response cache is not (it's bypassed
>>> completely). Could this theoretically result in two different
>>> versions of
>>> same gadgetspec?
>>>
>>> Thanks,
>>>
>>> Marijn
>>>
> 
> 

Re: Invalidating in-memory http request cache (Java)

[Marijn Speelman <ma...@hyves.nl>]

We want to flush the cache for specific URL's, for instance when a 
gadgetspec XML should be refreshed (by the developer or by us) because 
an update was released.

But our main issue has to do with our container specific container.js, 
defined in opensocial-current/feature.xml. We host this file and others 
separate from Shindig on our static content servers. When deploying a 
new version of our main website we want to be able to refresh these 
Javascript files which are being caching in Shindig.

I did notice the 'inline' attribute, but because the static content 
servers have an expire header that is far in the future and we normally 
use unique names per file version in the website to deal with this, I 
don't really see a way to make users or shindig download the new 
container.js now. (And if I remember correctly it also gave us some 
problems with the right order of loading the scripts.)

Maybe we're doing this the wrong way? Any help is appreciated.

Thanks.

ps. Sorry for my late response. I had trouble with my e-mail.

> Marijn
> 
> For what use-case do you want to flush the cache? We haven't added the
> ability for gadget developers/end-users to do this on demand but there has
> been some dicussion of this on the spec list. Your observation about
> nocache=1 is correct and is implemented that way to allow the gadget to
> continue to be served if the HTTP request for the gadget spec fails as we
> can still use the one on the cache in the interim and forcibly flushing it
> would have prevented this.
> 
> -Louis
> 
> On Wed, Aug 6, 2008 at 6:53 AM, Marijn Speelman <ma...@hyves.nl> wrote:
> 
>> Is there a way to refresh the http response cache (which caches manifest
>> files, rewritten content, internal js feature files, proxy requests),
>> without restarting Shindig? Or what could be the best place to build this
>> in?
>>
>> I don't think nocache=1 works for refreshing everything. For instance, when
>> using nocache=1 the in-memory GadgetSpec cache is refreshed, but as far as I
>> can see the entry in the http response cache is not (it's bypassed
>> completely). Could this theoretically result in two different versions of
>> same gadgetspec?
>>
>> Thanks,
>>
>> Marijn
>>