Seeing broken pages after invalidations is an interesting scenario. The broken page is in a way, proof that the invalidation was issued, yet the page failed to re-execute. In this post I discuss two main scenarios: The first one is when an error during the first execution (cache miss) leads to a broken page, and the second is a variation that happens due to a problem with the configuration of the cache fragments.
The page fails to execute
The invalidation is issued successfully, but then there are errors as the page is re-executed for the first time.
Start by comparing the generated HTML source code of a working page against the broken version. By comparing the HTML sources you might be able to narrow down the portion of the page that is not rendering correctly.
Depending on the error, it's possible that the broken version of the page gets cached, and served to all customers. For non-WXS caches, use the WebSphere Cache Monitor to find and open the JSP cache entries, again for a working and failing scenarios. When displaying a JSP cache in the Cache Monitor, the Cache Monitor includes information for all the JSP fragments that are consumed and included, and this should also help you narrow down the broken section of the page.
If the page is returned from cache and not executed, you wont be able to easily match executions to errors in the logs (the cached response does not produce errors). It's therefore important to know the time and server where the page was first executed (when and where). This could be done by adding the server and time as comments inside the html page. See this blog post: Where did that come from? Tips for finding when and where a page got generated. This should enable you to find the corresponding errors in the log.
If you still find no errors, the next step is to add additional tracing to the JSP as per the blog post, or to enable tracing. In a production environment, good lightweight traces to start with are:
- Fix Pack 1-8:
- Fix Pack 9+:
There are problems with dependencies between JSP fragments
JSP caches often include a number of independently cached fragments that are merged by the Dynacache runtime as the page is served. Although it shouldn't happen, sometimes fragments have dependencies on others. If a single fragment is invalidated, as it executes it might fail to find attributes or data that was supposed to be created by another fragment, and the page displays broken.
Ensure there are no dependencies between individually cached JSP fragment. The page should still render successfully after any of its sub-fragments is invalidated.
This testing is best done in a single user environment. Review the cachespec.xml and use the cache monitor to identify and invalidate the different JSP fragments while ensuring the page continues to render properly.
If a fragment has a dependency to a request attribute created by another fragment in the page, but in a subsequent execution the other fragment is returned from cache, the attribute wont be present and the executing fragment might result in an error or empty page.
If you identify you are running into this scenario, you must use one of these techniques to avoid it:
- Redesign your caching fragments so both pieces of code always execute together
- Have each fragment recreate the attribute if missing
- Save attributes with the top level cache entry so that they are always available for fragments. This technique is used in the out-of-the-box Aurora cachespec.xml as seen here. The following snippet indicates that attributes should not be cached, except the ones in the list:
Never configure to save all attributes as this could lead to performance and security problems