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 <davi...@oclc.org> 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<OAuthRequest> oauthRequestProvider,
> Provider<OAuth2Request>
> 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
> <ssiev...@apache.org<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
> <davi...@oclc.org<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
>
>
>
>
