[MAGNOLIA-6012] Ensure a page defined in 404-section of web.xml gets the channel Created: 03/Dec/14 Updated: 18/Aug/15 Resolved: 24/Feb/15 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | None |
| Affects Version/s: | 5.2.9, 5.3.6 |
| Fix Version/s: | 5.2.11, 5.3.8 |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Christoph Meier | Assignee: | Christoph Meier |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||
| Description |
|
If you have a (magnolia) page defined in the web.xml as the 404 error, it does not get the channel. This is a follow-up ticket of |
| Comments |
| Comment by Jan Haderka [ 10/Feb/15 ] |
|
Would need to dig bit deeper to confirm my suspicion, but right now, and after quick test (which by no mean guarantees what i saw), I think that reason for different behaviour is that jetty will always reuse same thread for sendError processing, but i seemed to have managed, at least once, get Tomcat to use different worker thread for processing error. So while request object is reused (hence Magnolia knows filters were already processed), same is not guaranteed for the worker thread used to process the request and thus also not for the associated ThreadLocal. I could also not find same guarantee in the spec. Only thing it says is that there is always only one thread processing the request or in some incarnations also that when a request arrives, it is handled by the thread receiving the request. Either way there is no guarantee that after calling sendError and having server process this against web.xml specified error page it will reuse same thread. It might (Jetty) or not (Tomcat). So, in essence, (and imho) it is not safe to rely on thread local to always match that what is set in request attribute and where possible we should use request attribute rather than thread local. As I see it right now (and above should still be confirmed by tests and more thorough read of the spec then my cursory glance) since we can't rely on ThreadLocal to match, we should either
... in summary, I don't have a silver bullet for this one either |
| Comment by Christoph Meier [ 12/Feb/15 ] |
|
When reviewing, check branch " |
| Comment by Mikaël Geljić [ 20/Feb/15 ] |
|
W/ Greg we decided to go for the "no longer a OncePerRequestAbstractMgnlFilter" approach.
|
| Comment by Christoph Meier [ 24/Feb/15 ] |
|
MultiChannelFilter now extends AbstractMgnlFilter to ensure channel is set on Tomcat container too. All commits on branch " |