Eric's partially on to the problem... Essentially what's happening is in part of the workflow between the PortletRendererImpl and the CacheControlService.
At the beginning of the renderer's doServeResource( and doRender) the render asks the cacheControlService for any corresponding CachedPortletData objects that for the request. CachedPortletData is a simple bean to store things like the content, headers, cache storeTime and expirationTime, and the etag. In this case the CacheControlService finds CachedPortletData, but it's isExpired method predictably returns false. As a result the CacheControlService calls cache.remove for that CachedPortletData, and returns null. The null result gets viewed by the PortletRenderer as simply the CacheControlService has nothing cached, and tells the portlet do invoke doServeResource. >From the current logic, the only time the PortletRenderer will return a 304 is when the data is in the cache and not expired. The suggestion here is that the workflow change slightly: - The CacheControlService shouldn't remove CachedPortletDatas from the caches it manages, since by doing so the etag will disappear. - The PortletRenderer (and the portlet potentially) should be left to make the determination on what to do with expired cached content. - The PortletRenderer should alter it's workflow to slightly to open up the possibility of returning a 304 for expired cached content. A follow up question: - If the CacheControlService returns an expired CachedPortletData, the renderer will tell the portlet to execute (and will pass in the etag on the expired content). If the portlet says "useCachedContent," should the CachedPortletData's expirationTime be updated? On Fri, Oct 21, 2011 at 10:17 AM, Eric Dalquist <[email protected] > wrote: > So I'm guessing there is a bug in the portal's portlet cache management > logic. In the case you're describing, where a portlet returns content and > sets an expiration time and an etag the logic on following requests should > follow: > > 1. check if there is cached content for the request that matches the etag > 2. on cache miss call the portlet's render/resource method and provide the > etag > 3. if the portlet returns 'still valid' the portal should return a 304 > > I'm thinking the bug is in step 3 and the portal isn't handling the > 'content still valid' return from the portlet correctly. > > Your thinking is right and is what is currently intended, could you create > a jira issue with the summary here and assign it to Nick? > > Thanks, > -Eric > > > On 10/20/2011 04:58 PM, Jen Bourey wrote: > >> Hi all, >> >> I think I've encountered some misbehavior in uPortal 4's validation-based >> resource URL caching. To summarize, it looks like portlets send back blank >> responses when a portlet thinks the ETag matches, but the content itself has >> expired out of the portal's cache. >> >> I think I can currently demonstrate this behavior using the Jasig Test >> Portlet's Cache Control (CacheControl Validation Method) Test. If you click >> the "Get JSON content" button, the first request will appropriately send >> back a 200 OK response with content, and a subsequent click will result in a >> blank 304 Not Modified response. However, if I wait longer than two >> minutes, then click the button, I appear to get a 200 OK response with no >> content. >> >> First of all, I think we might want to update the functional test >> portlet's CacheTestController.**writeJsonContentWithValidation**Caching >> method to validate the ETag included in the request. It would be useful for >> the test case to be able to distinguish between requests that include a >> still-valid ETag and a request that has an Etag that doens't match our >> conception of "current". >> >> Beyond our test cases though, it seems that the portal needs to be able to >> respond to a request that has a still-valid ETag, but for which content has >> expired out of the portal's cache. In the case of resource URLs, it seems >> like it should be OK that the content is missing from the cache, since we >> don't actually want to send the content itself back. I think we just want >> to send back a 302 header and move on. >> >> Has anyone else encountered this behavior in the test case? Does my >> reading of the intended behavior for resource URLs sound correct? >> >> - Jen >> > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
