https://issues.apache.org/bugzilla/show_bug.cgi?id=50957
--- Comment #11 from Brad Plies <bpl...@bulliondirect.com> 2011-03-28 15:33:18 EDT --- (In reply to comment #10) > To address the isAsync() question I suspect that this is not the cause since: > - the issue is with static content where async state is not changing Yes and no. Even though it is static content being swapped & duplicated, static content is not the only resource in the request stream. For instance ImageA.gif & ImageB.gif are included in a page that contains a number of dynamic JSP elements as well. In post #1 I listed a scenario where a JS file was served instead of HTML. In that case, the page was a dynamic JSP. > - it doesn't explain why BIO is affected but NIO is not If indeed BIO & NIO share nearly identical isAsync() logic and if the real problem is a concurrency hazard within that logic then the unlucky timing would just happen to be more likely in BIO. NIO Protocol has notably less isAsync() calls. So for all I know NIO is affected also, we just haven't noticed yet. Maybe it is a Bohrbug or Heisenbug :) Maybe someone with exceptionally strong concurrency skills can review isAsync() and its usage for safety. Either it is a hazard or it isn't. > In the same way a failure to recycled an output buffer could cause this, so > could not recycling an input buffer. I have been reviewing the code and for a > single request there are multiple points where recycle is called. While I can > find a error conditions where I can skip one of the recycle calls, I can't > find > a code path that would allow all of them to be skipped. Good point on input v.s. output. Yet aren't those input recycle calls governed by the same suspect guard? Perhaps it is not necessary to skip all recycle calls in order to cause the behavior. > I'll tighten up the areas I can find for 7.0.12 but without a clear idea of > exactly how this issue is triggered I can't be sure that the issue will be > fixed. If no further reports appear post 7.0.12 then that would suggest that > the issue was fixed. I'm not exactly comfortable with that plan but barring a > reproducible test case or an explanation of how the error occurs I don't have > a > better plan right now. I can respect that. Given how long Tomcat 7.0 has been GA before this report was submitted, I would not expect additional reports to be as forthcoming even if it still is a bug. At least you and others are aware of this report and might be able to match it to future reports. Hopefully someone else will be able to do a better job defining a reproducible test case. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
