Document module long-term cache (or: I've got a head scratcher of a bug that I don't understand)

Benjamin Anderson

##The new feature We recently added a new feature into napa (Practitioner Insights) where we provide a drop down menu during doc display that lets you jump from the current document to corresponding documents in other jurisdictions. This is done by issuing a novus search and adding the resulting docs to the xml that is passed as input to the xsl. ... ... ... ... ... ## The problem The implementation can be found in NovusDocumentProviderWLN.cs (the GetOtherNapaJurisdictionsXml method). This worked fine while testing and mostly works fine now except for intermittent cases where the xml does not contain our new "otherJurisdictions" element. This seems to happen only the first time you request a napa document in a particular environment for a particular user. The problem occurs just once and upon refresh it works as expected. After that, we can't repeat it unless we don't use that environment for a few hours. ## What I've tried and discovered I added some debugging code to make sure novus was returning the correct results and I'm nearly certain it is. I've also inspected the novus logs and it turns out that in that novus isn't being queried at all in our "bad" rendering cases. I'm pretty sure that what's happening is that NovusDocumentProviderWLN.BuildXmlFromNovus is not being called at all and thus the xml doesn't contain our new "otherJurisdictions" element. Upon that first (bad) rendering, though, some side effect occurs that makes the code take a different path the next time through. I have not been able to recreate the problem locally which has made this especially difficult. ## My current hypothesis My completely ignorant guess at this point is that the data is somehow becoming stale at which point it caches part of the xml, but not "otherJurisdictions". That first rendering uses this stale data, but also somehow flushes the xml from the cache. Then the next request starts from scratch and follows the path I'd expect, querying novus and adding "otherJurisdictions" to the xml. I've spent some time traversing various paths in the Document code to see if this might be the case. For example, I had a suspicion that somehow it might be evaluating true at line 86 in XmlComponentBase.cs (in the AddXmlToDocumentContent method), but I can't seem to find any scenarios where that's the case. IOW, I was thinking maybe NovusDocumentProvider.BuildXml was being called directly and thus cutting out NovusDocumentProviderWLN.BuildXmlFromNovus altogether. ## Any ideas or information (no matter how remote) would be appreciated While this issue is rather specific to napa, I'm wondering if someone might be able to explain how caching works or know of any quirkiness around it… or any ideas really. Is there just one cache or is there a backup/longer-term cache as well? I'm open to anything as I'm to the point where I'm grasping at straws.

Benjamin Anderson

assistance was provided on the CO_Document_TECH list by Chris Heuer, Rick Preston, and Shawn Ellis - thank you! ## I recreate the problem by... 1. rendering a doc 2. clearing the cache by issuing a DELETE to http://localhost:200/Cache/v1 3. reissue the request to http://localhost:203/Document/v2/FullText/{guid}... (I used fiddler to do so) This recreated the problem and got me to line 88 of XmlComponentBase, which indeed was the problem. (for future reference - that's the code block you get to when this line evaluates to true) if (!string.IsNullOrEmpty(metadata) && !string.IsNullOrEmpty(body)) ## I fixed the problem by... I overrode NovusDocumentProviderWLN.buildXml and moved my napa specific code there (as opposed to NovusDocumentProviderWLN.buildXmlNovus). The change set is here: [
http://tfsnpt.int.thomson.com:8080/tfs/web/UI/Pages/Scc/
ViewChangeset.aspx?changeset=294176][1] [1]:
http://tfsnpt.int.thomson.com:8080/tfs/web/UI/Pages/Scc/
ViewChangeset.aspx?changeset=294176