Re: caching and 500 errors
So let me summarize.
1) The NO_CACHE RenderParam does not appear to affect makeRequest. From what
I’ve seen this would require a patch to io.js (as suggested at
http://markmail.org/message/535kwx47svi626om). I’ve found several projects
that branch from shindig that have applied this patch.
2) Ideally it would be nice to do this on a per request basis with a new
RequestParameters.NO_CACHE flag. Nuxeo did this.
http://hg.nuxeo.org/nuxeo/nuxeo-features/rev/46feb3f6ce5e
3) When doing an OUTH2 flow the first request to the service that returns the
oauthApprovalUrl probably shouldn’t be cached or set in the staleResponse,
because then it could possibly be used on the response for the ACTUAL request
if it returns a 500 (my scenario). Thus an endless loop of display the
approval url and making the service call.
For now I am using my patched RequestPipleline which turns off caching for all
oauth2 request.
public HttpResponse execute(HttpRequest request) throws GadgetException {
if (request.getAuthType() == AuthType.OAUTH2) {
request.setIgnoreCache(true);
}
return super.execute(request);
}
I can submit a patch for 1 or 2 (or both) if it’s agreed that’s desired
functionality. For #3 it might be outside my shindig knowledge scope, but I
can try.
doug
On Aug 21, 2014, at 10:56 AM, Davies,Douglas wrote:
> I found this issue
>
> http://markmail.org/message/535kwx47svi626om
>
> I wonder if this is my issue as well. I am setting the nocache (even
> appended &nocache=1 to my service call) and it still doesn’t work.
>
> It really would be nice I could specify NO_CACHE on the RequestParameters.
> Or is the Pipeline changes I suggested earlier (only for the oauth2 flow) the
> right way to go?
>
> doug
>
> On Aug 21, 2014, at 9:58 AM, Davies,Douglas wrote:
>
>> Stanton,
>>
>> Thanks for pointing me in the right direction. It does appear I have a
>> problem with my NO_CACHE setting.
>>
>> I do the following when rendering the gadget.
>>
>> renderParams[osapi.container.RenderParam.NO_CACHE] = true;
>> container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams,
>> function(gadgetInfo)
>>
>> However I’m not seeing it set in MakeRequestHandler.java where it does
>>
>> req.setIgnoreCache("1".equals(getParameter(request,
>> Param.NO_CACHE.getKey(), null)));
>>
>> Looking into this. From looking at the code it does seem like all this
>> staleResponse and caching mumbo-jumbo should be bypassed if I get this set
>> right.
>>
>> Thanks,
>> doug
>
>
Re: caching and 500 errors
I found this issue
http://markmail.org/message/535kwx47svi626om
I wonder if this is my issue as well. I am setting the nocache (even appended
&nocache=1 to my service call) and it still doesn’t work.
It really would be nice I could specify NO_CACHE on the RequestParameters. Or
is the Pipeline changes I suggested earlier (only for the oauth2 flow) the
right way to go?
doug
On Aug 21, 2014, at 9:58 AM, Davies,Douglas wrote:
> Stanton,
>
> Thanks for pointing me in the right direction. It does appear I have a
> problem with my NO_CACHE setting.
>
> I do the following when rendering the gadget.
>
> renderParams[osapi.container.RenderParam.NO_CACHE] = true;
> container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams,
> function(gadgetInfo)
>
> However I’m not seeing it set in MakeRequestHandler.java where it does
>
>req.setIgnoreCache("1".equals(getParameter(request,
> Param.NO_CACHE.getKey(), null)));
>
> Looking into this. From looking at the code it does seem like all this
> staleResponse and caching mumbo-jumbo should be bypassed if I get this set
> right.
>
> Thanks,
> doug
Re: caching and 500 errors
Stanton,
Thanks for pointing me in the right direction. It does appear I have a problem
with my NO_CACHE setting.
I do the following when rendering the gadget.
renderParams[osapi.container.RenderParam.NO_CACHE] = true;
container.navigateGadget( gadgetSite, gadget.appUrl, {}, renderParams,
function(gadgetInfo)
However I’m not seeing it set in MakeRequestHandler.java where it does
req.setIgnoreCache("1".equals(getParameter(request,
Param.NO_CACHE.getKey(), null)));
Looking into this. From looking at the code it does seem like all this
staleResponse and caching mumbo-jumbo should be bypassed if I get this set
right.
Thanks,
doug
On Aug 20, 2014, at 4:44 PM, Davies,Douglas wrote:
> The response code on the first request is a 200 and I see an access token
> created in the db. Then the next call is the one that returns the 500. I
> tried the “nocache” but wasn’t successful. Let me try again.
>
> What I ended up doing was this (just to test — not necessarily the solution).
> I extended DefaultRequestPipeline and then bound to it with Guice.
>
> @Singleton
> public class PlatformDefaultRequestPipeline extends DefaultRequestPipeline {
>
>@Inject
>public PlatformDefaultRequestPipeline(HttpFetcher httpFetcher,
> HttpCache httpCache,
> Provider oauthRequestProvider,
> Provider
> oauth2RequestProvider,
> @RewriterRegistry(rewriteFlow =
> ResponseRewriterList.RewriteFlow.REQUEST_PIPELINE)
> ResponseRewriterRegistry
> responseRewriterRegistry,
> InvalidationService invalidationService,
> @Nullable HttpResponseMetadataHelper
> metadataHelper) {
>
>super(httpFetcher, httpCache, oauthRequestProvider,
> oauth2RequestProvider, responseRewriterRegistry,
>invalidationService, metadataHelper);
>}
>
>protected HttpResponse fixFetchedResponse(HttpRequest request,
> HttpResponse fetchedResponse,
> @Nullable HttpResponse
> invalidatedResponse, @Nullable HttpResponse staleResponse)
>throws GadgetException {
>
>// Don't touch OAUTH2 requests (for now!!!)
>
>if (request.getAuthType() == AuthType.OAUTH2) {
>
>return fetchedResponse;
>}
>
>return super.fixFetchedResponse(request, fetchedResponse,
> invalidatedResponse, staleResponse);
>}
>
> }
>
> It just bypasses the fixFetchedResponse for oauth2 calls. When I do this my
> gadget behaves as desired. Maybe that helps shed some more light on it.
>
> doug
>
>
>
> On Aug 20, 2014, at 4:30 PM, Stanton Sievers
> mailto:ssiev...@apache.org>> wrote:
>
> Hey Doug,
>
> What's the HTTP response code on the first request that returns the
> oauthApprovalUrl? From what I can tell, if the cachedResponse has a status
> code >=400, we won't use it as the staleResponse in the case of a 500 error
> on the subsequent request.
>
> Regarding not caching your service calls at all, you can use the "nocache"
> in the render parameters but that will result in ALL calls bypassing the
> cache and not just your particular service calls.
>
> Regards,
> -Stanton
>
>
> On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas
> mailto:davi...@oclc.org>> wrote:
>
> Hi Guys,
>
> It’s Doug Davies. Been a while since I’ve been active on the shindig mail
> list. We are getting back into our shindig implementation. We have
> upgraded our container to the latest release.
>
> We are having an issue that I think I brought up in the past, but I can’t
> find the thread in the archives.
>
> Here’s the scenario…
>
> We have an oauth2 gadget that makes a request to one of our internal
> services. That service happens to return a 500 error for a bad parameter
> that gets passed in (I know probably not the right response, but I don’t
> have control over that). When it makes the first call to the service it
> gets back an oauthApprovalUrl like it should. I then present the UI for
> that link to initiate the oauth2 handshake. Once it’s done the gadget then
> makes the request again, this time with an access token. However, since
> the service returns a 500 it seems the DefaultRequestPipeline code uses the
> “staleResponse” (the last successful response that had the oauthApprovalUrl
> in it) and so I get into an infinite loop.
>
> I tried setting
>
> params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;
>
> but that doesn’t seem to matter. Ideas on how to solve this? Even if a
> 500 error isn’t the right response to be returning, it still seems like I’d
> want to detect that this happened rather than the response looking like the
> oauth flow needs to be initiated again.
>
> In fact, I don’t know that I want any of my service calls being cached.
>
> Thanks,
> Doug Davies
>
Re: caching and 500 errors
The response code on the first request is a 200 and I see an access token
created in the db. Then the next call is the one that returns the 500. I
tried the “nocache” but wasn’t successful. Let me try again.
What I ended up doing was this (just to test — not necessarily the solution).
I extended DefaultRequestPipeline and then bound to it with Guice.
@Singleton
public class PlatformDefaultRequestPipeline extends DefaultRequestPipeline {
@Inject
public PlatformDefaultRequestPipeline(HttpFetcher httpFetcher,
HttpCache httpCache,
Provider oauthRequestProvider,
Provider oauth2RequestProvider,
@RewriterRegistry(rewriteFlow =
ResponseRewriterList.RewriteFlow.REQUEST_PIPELINE)
ResponseRewriterRegistry
responseRewriterRegistry,
InvalidationService invalidationService,
@Nullable HttpResponseMetadataHelper
metadataHelper) {
super(httpFetcher, httpCache, oauthRequestProvider,
oauth2RequestProvider, responseRewriterRegistry,
invalidationService, metadataHelper);
}
protected HttpResponse fixFetchedResponse(HttpRequest request, HttpResponse
fetchedResponse,
@Nullable HttpResponse
invalidatedResponse, @Nullable HttpResponse staleResponse)
throws GadgetException {
// Don't touch OAUTH2 requests (for now!!!)
if (request.getAuthType() == AuthType.OAUTH2) {
return fetchedResponse;
}
return super.fixFetchedResponse(request, fetchedResponse,
invalidatedResponse, staleResponse);
}
}
It just bypasses the fixFetchedResponse for oauth2 calls. When I do this my
gadget behaves as desired. Maybe that helps shed some more light on it.
doug
On Aug 20, 2014, at 4:30 PM, Stanton Sievers
mailto:ssiev...@apache.org>> wrote:
Hey Doug,
What's the HTTP response code on the first request that returns the
oauthApprovalUrl? From what I can tell, if the cachedResponse has a status
code >=400, we won't use it as the staleResponse in the case of a 500 error
on the subsequent request.
Regarding not caching your service calls at all, you can use the "nocache"
in the render parameters but that will result in ALL calls bypassing the
cache and not just your particular service calls.
Regards,
-Stanton
On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas
mailto:davi...@oclc.org>> wrote:
Hi Guys,
It’s Doug Davies. Been a while since I’ve been active on the shindig mail
list. We are getting back into our shindig implementation. We have
upgraded our container to the latest release.
We are having an issue that I think I brought up in the past, but I can’t
find the thread in the archives.
Here’s the scenario…
We have an oauth2 gadget that makes a request to one of our internal
services. That service happens to return a 500 error for a bad parameter
that gets passed in (I know probably not the right response, but I don’t
have control over that). When it makes the first call to the service it
gets back an oauthApprovalUrl like it should. I then present the UI for
that link to initiate the oauth2 handshake. Once it’s done the gadget then
makes the request again, this time with an access token. However, since
the service returns a 500 it seems the DefaultRequestPipeline code uses the
“staleResponse” (the last successful response that had the oauthApprovalUrl
in it) and so I get into an infinite loop.
I tried setting
params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0;
but that doesn’t seem to matter. Ideas on how to solve this? Even if a
500 error isn’t the right response to be returning, it still seems like I’d
want to detect that this happened rather than the response looking like the
oauth flow needs to be initiated again.
In fact, I don’t know that I want any of my service calls being cached.
Thanks,
Doug Davies
Re: caching and 500 errors
Hey Doug, What's the HTTP response code on the first request that returns the oauthApprovalUrl? From what I can tell, if the cachedResponse has a status code >=400, we won't use it as the staleResponse in the case of a 500 error on the subsequent request. Regarding not caching your service calls at all, you can use the "nocache" in the render parameters but that will result in ALL calls bypassing the cache and not just your particular service calls. Regards, -Stanton On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas wrote: > Hi Guys, > > It’s Doug Davies. Been a while since I’ve been active on the shindig mail > list. We are getting back into our shindig implementation. We have > upgraded our container to the latest release. > > We are having an issue that I think I brought up in the past, but I can’t > find the thread in the archives. > > Here’s the scenario… > > We have an oauth2 gadget that makes a request to one of our internal > services. That service happens to return a 500 error for a bad parameter > that gets passed in (I know probably not the right response, but I don’t > have control over that). When it makes the first call to the service it > gets back an oauthApprovalUrl like it should. I then present the UI for > that link to initiate the oauth2 handshake. Once it’s done the gadget then > makes the request again, this time with an access token. However, since > the service returns a 500 it seems the DefaultRequestPipeline code uses the > “staleResponse” (the last successful response that had the oauthApprovalUrl > in it) and so I get into an infinite loop. > > I tried setting > > params[gadgets.io.RequestParameters.REFRESH_INTERVAL] = 0; > > but that doesn’t seem to matter. Ideas on how to solve this? Even if a > 500 error isn’t the right response to be returning, it still seems like I’d > want to detect that this happened rather than the response looking like the > oauth flow needs to be initiated again. > > In fact, I don’t know that I want any of my service calls being cached. > > Thanks, > Doug Davies > > >
