You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2006/07/25 14:13:24 UTC
DO NOT REPLY [Bug 40108] New: - cross context includes don't reference correct session when page from differnt contect is included
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40108>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40108
Summary: cross context includes don't reference correct session
when page from differnt contect is included
Product: Tomcat 5
Version: Unknown
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: diyan.yordanov@gmail.com
Hi,
I�ve discovered a problem, that sessions are mixed, if the application makes
cross context includes. I�m using Tomcat 5.5.17.
Here is the scenario:
1) Servlet A in context �X� wants to include page B from context �Y� and
page C from context �X�;
2) Servlet A starts two threads to include page B and C;
3) Servlet A pass the request and response object to these threads and
corresponding ServletContexts to context Y an Z (to get RequestDispatcher);
4) Each thread dispatches (using RequestDispatcher) to the corresponding
page (B or C)
5) While in the page B and C these pages set and get attributes from the
session object.
According to Servlet spec 2.4 (SRV.7.3 Session Scope) � �if a servlet uses the
RequestDispatcher to call a servlet in another Web application, any sessions
created for and visible to the servlet being called must be different from
those visible to the calling servlet.� This means that the session in the
different pages (B and C) must be different.
However they are mixed � sometimes B sees session for C and vice versa.
The problem here is that one and the same request object is processed in two
different threads simultaneously.
Servlet specification does not forbid request object to be passed to multiple
threads and to be processed concurrently by those threads. It just says that
the application should wrap the request in order to synchronize the access to
it. (Servlet spec 2.4 SRV.8.2)
But in practice this is impossible. Wrapping the request only can ensure safe
access but could not prevent changing of session.
I�ve checked the Tomcat sources. When a request has to be dispatched it is
unwrap until container request object is reached. Then a new wrapper
(ApplicationHttpRequest) is inserted there. This wrapper has the request
parameters according the new context.
HttpServletRequestWrapper@be49e0
HttpServletRequestWrapper@8b8a47
ApplicationHttpRequest@e41bc3
RequestFacade@1682598
When the second thread dispatches the request, it is again unwrapped and a new
wrapper is inserted:
HttpServletRequestWrapper@4204
HttpServletRequestWrapper@8b8a47
ApplicationHttpRequest@1bb9a58
ApplicationHttpRequest@e41bc3
RequestFacade@1682598
This reflects the request in the first thread.
As a result because HttpServletRequestWrapper@8b8a47 object is common the
outermost wrappers will use one and the same ApplicationHttpRequest@1bb9a58.
This is the cause for mixed session.
Current implementation only works the first time the request is wrapped. But if
it is wrapped several times (by some filters) this architecture will fail.
I think that this has to be changed in order to allow the application to be
able to process request in multiple threads in different contexts.
Similar scenario is valid for JSR168 Portlet applications, when the portlets
are depoyed as separate webapps. Then the portal can trigger multiple threads
to render the portlets from the portal page. This is equivalent to the case
where a single request is processed in different context in parallel.
Regards,
Diyan
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40108] - cross context includes don't reference correct session when page from differnt contect is included
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40108>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40108
remm@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From remm@apache.org 2006-07-26 13:05 -------
Servlet spec 2.4 SRV.8.2 actually reads: "The Container Provider should ensure
that the dispatch of the request to a target servlet occurs in the same thread
of the same JVM as the original request.".
What is it you have trouble understanding ?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40108] - cross context includes don't reference correct session when page from differnt contect is included
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40108>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40108
remm@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DO NOT REPLY [Bug 40108] - cross context includes don't reference correct session when page from differnt contect is included
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=40108>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40108
diyan.yordanov@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Additional Comments From diyan.yordanov@gmail.com 2006-07-26 14:58 -------
(In reply to comment #1)
Hi Remy,
I do understand your statement. But you have to have in mind that this is not a
must.
The requirement in Servlet 2.4 is changed from �must� to �should� on contarast
to Servlet 2.3.
Here is the extract from the spec (SRV.S.17):
� It is now a recommendation, instead of a requirement, that the reference to
the
request and response object should not be given to the object in other threads -
based on the requirement from JSR-168. Warnings are added when the thread
created by the application uses the objects managed by the container.(2.3.3.3)
� It is now a recommendation, that the dispatch should occur in the same thread
of the same JVM as the original request - based on the requirement from JSR-
168(8.2)
This in practice allows the request to be dispatched to servlet in a thread
that is different than the thread of the original request. And in my scenario
the request dispatching occurs inside the new thread and not before that.
So I think that my question has its reason. Tomcat does have a bug. There is a
test case that can simulate it. If you need more details or examples in order
to understand the issue, please tell and I'm ready to send it.
Regards,
Diyan
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org