MySQL Bugs: #31768: TextTagAdaptor is not clearing the stack

Bug #31768	TextTagAdaptor is not clearing the stack - causing incorrect data display
Submitted:	23 Oct 2007 0:14	Modified:	26 Feb 2008 14:14
Reporter:	Sloan Childers	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Web	Severity:	S1 (Critical)
Version:	2.0	OS:	Any
Assigned to:	Joshua Ganderson	CPU Architecture:	Any

Description:
The logs and events pages are reusing struts actions causing old results to be displayed.

How to repeat:
Switch back and forth in the logs between log names and you get stale data displayed.

Suggested fix:
Copied from an email from MikeL who debugged the problem in the 2.0 branch.

Hey Guys,

First the good news: the problem is solved. Details below. I wonder however why I did not get Josh's email? I could only read his comments because you included them in your mail Sloan. I checked my inbox and the SPAM folder but no mail from Josh there.

>> I was unable to figure out why Dashboard instances seem to be reused and I've got to shift my attention to other tasks for the time being.
>> Based on these observations, my best guess is that something unrelated to my UI work made it into trunk and is causing the problem. I tried to compare my patch for 1.2.1 with the commit Oldag did for 2.0 from trunk but was unable to see any differences that look like likely candidates. However, given the type of error this is, there's still a strong likelyhood that it's something I've done, though I don't see how.

I also started with comparing patches but I gave up after 20mins. Josh, your patches are sometimes huge. Very hard to get through all of them. I really would appreciate if you could make smaller commits. It would also be easier to follow your work and, if necessary, take back a change.

Anyway, I had an interesting 2 hours debug session this morning going down deeply into how actions/proxies are created and handled, how they work with the struts action stack and their contexts etc. Finally I found what the problem was. Actually, it is two-folded. First part is a missing pop() call in TextTagAdaptor (where we push a text provider onto the action stack). This class is used everywhere in our code where we try to get localized text. No wonder that this grew the stack sometimes to more than 150 entries. Since the stack wasn't cleared properly it kept sometimes an outdated Dashboard instance, which then caused all the other trouble.

And here comes the second part of the problem. How can an old Dashboard instance appear? Where is it cached? The answer is: WidgetBodyTagSupport. Together with Paging.java (line 195, "contentBuffer.append(getAction().getTxt(...") the old Dashboard instance is retrieved and pushed onto the current action's (the new Dashboard instance) stack (via TextTagAdaptor) and since TextTagAdaptor did not clean the stack the old instance was used from now on until the action was destroyed.

I haven't followed the flow in WidgetBodyTagSupport further as this is not an urgent problem anymore. However, Josh, I suggest that you rework that code considering my findings. It might have other side effects in places we never foresee otherwise.

Mike

Patch sent to sloan for review with non-ideal solution of cleanup after each getTxt use and each widget use. Investigating cleanup at end of action lifecycle.

Are we sure this isn't a problem for 1.2.0 GA?

fixed in 1.3.0.8044.

Fixed in 1.3, reopening to fix in 2.0

This should be resolved in 2.0 though I would like to see something tied to the setup of a new action since the action instance used by tags should be valid for the lifecycle of the page, there's no reason to re-retrieve it after each tag render.

not seeing this is build 2.0.0.5948

Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.
Added to the changelog for version 2.