DO NOT REPLY [Bug 40108] New: - cross context includes don't reference correct session when page from differnt contect is included

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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: [EMAIL PROTECTED]


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.

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

When the second thread dispatches the request, it is again unwrapped and a new 
wrapper is inserted:

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

This reflects the request in the first thread.

As a result because [EMAIL PROTECTED] object is common the 
outermost wrappers will use one and the same [EMAIL PROTECTED] 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40109] New: - Memory leak on Repeated simultaneous requests from same browser without waiting for a response

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40109

   Summary: Memory leak on Repeated simultaneous requests from same
browser without waiting for a response
   Product: Tomcat 4
   Version: 4.1.29
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P1
 Component: Connector:Coyote HTTP/1.1
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I am tomcat 4.1.29 as standalone web server with the CoyoteConnector and the 
configuration as follows

 



 

I noticed the memory leak if there are multiple repeated requests from same 
browser simultaneously without waiting for response. It is keep accumulating 
the memory and not releasing for eve r(even after the session timeout). 

 

Similar test case with 100 requests ( ran to completion) one after other is 
not leaking any memory.

 

We are using Synchronized Token while submitting the forms but we are not 
using the same in other cases like HTTP/GET.

 

I ran the tomcat with JProfiler and noticed that the memory leak is pointing 
to org.apache.coyote.http11.InternalInputBuffer.

 

I used the Tomcat 4.1.31 and still has same problem.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r425399 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina: core/ApplicationContext.java session/ManagerBase.java session/StandardManager.java session/StandardSession.java

[remm]

Author: remm
Date: Tue Jul 25 07:19:32 2006
New Revision: 425399

URL: http://svn.apache.org/viewvc?rev=425399&view=rev
Log:
- Experiment with using concurrent maps in places which may be concurrently 
accessed.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/ManagerBase.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardManager.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=425399&r1=425398&r2=425399&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
Tue Jul 25 07:19:32 2006
@@ -1,5 +1,5 @@
 /*
- * Copyright 1999,2004 The Apache Software Foundation.
+ * Copyright 1999,2004-2006 The Apache Software Foundation.
  * 
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -24,9 +24,10 @@
 import java.net.URL;
 import java.util.ArrayList;
 import java.util.Enumeration;
-import java.util.HashMap;
 import java.util.Iterator;
+import java.util.Map;
 import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
 
 import javax.naming.Binding;
 import javax.naming.NamingException;
@@ -87,13 +88,13 @@
 /**
  * The context attributes for this context.
  */
-private HashMap attributes = new HashMap();
+private Map attributes = new ConcurrentHashMap();
 
 
 /**
  * List of read only attributes for this context.
  */
-private HashMap readOnlyAttributes = new HashMap();
+private Map readOnlyAttributes = new ConcurrentHashMap();
 
 
 /**
@@ -118,7 +119,7 @@
 /**
  * The merged context initialization parameters for this Context.
  */
-private HashMap parameters = null;
+private Map parameters = null;
 
 
 /**
@@ -172,9 +173,7 @@
  */
 public Object getAttribute(String name) {
 
-synchronized (attributes) {
-return (attributes.get(name));
-}
+return (attributes.get(name));
 
 }
 
@@ -185,9 +184,7 @@
  */
 public Enumeration getAttributeNames() {
 
-synchronized (attributes) {
-return new Enumerator(attributes.keySet(), true);
-}
+return new Enumerator(attributes.keySet(), true);
 
 }
 
@@ -258,9 +255,8 @@
 public String getInitParameter(final String name) {
 
 mergeParameters();
-synchronized (parameters) {
-return ((String) parameters.get(name));
-}
+return ((String) parameters.get(name));
+
 }
 
 
@@ -271,9 +267,7 @@
 public Enumeration getInitParameterNames() {
 
 mergeParameters();
-synchronized (parameters) {
-   return (new Enumerator(parameters.keySet()));
-}
+return (new Enumerator(parameters.keySet()));
 
 }
 
@@ -688,17 +682,15 @@
 boolean found = false;
 
 // Remove the specified attribute
-synchronized (attributes) {
-// Check for read only attribute
-   if (readOnlyAttributes.containsKey(name))
-return;
-found = attributes.containsKey(name);
-if (found) {
-value = attributes.get(name);
-attributes.remove(name);
-} else {
-return;
-}
+// Check for read only attribute
+if (readOnlyAttributes.containsKey(name))
+return;
+found = attributes.containsKey(name);
+if (found) {
+value = attributes.get(name);
+attributes.remove(name);
+} else {
+return;
 }
 
 // Notify interested application event listeners
@@ -754,15 +746,13 @@
 boolean replaced = false;
 
 // Add or replace the specified attribute
-synchronized (attributes) {
-// Check for read only attribute
-if (readOnlyAttributes.containsKey(name))
-return;
-oldValue = attributes.get(name);
-if (oldValue != null)
-replaced = true;
-attributes.put(name, value);
-}
+// Check for read only attribute
+if (readOnlyAttributes.containsKey(name))
+return;
+oldValue = attributes.get(name);
+if (oldValue != null)
+replaced = true;
+attributes.put(name, value);
 
 // Notify interested application event listeners
 Object listeners[] = context.getApplicationEventListeners();
@@ -822,11 +812,9 @@
 
 // Create l

Re: [VOTE] Releasing Tomcat Connectors 1.2.18

[Rainer Jung]

Hello,

since we've already got 4 "stable" votes I would like to close the vote
early and publish the release.

So if anyone is still testing and wants to participate in the vote,
please let me know. Otherwise I'll post the results tomorrow at about 5
p.m. GMT and publish the release.

Thank's for your participation in the vote!

Rainer

Rainer Jung schrieb:
> Hello to all Tomcat project members,
> 
> after 2 unsuccessful release attempts for mod_jk it looks like 1.2.18
> doesn't get any bug reports. All known bugs related to 1.2.16 and 1.2.17
> have been fixed in 1.2.18. About 20 users downloaded 1.2.16 and 1.2.17
> each, and 11 downloads happened for 1.2.18 (until yesterday). I think we
> got good feedback from the community.
> 
> Although I announced the availability of the 1.2.18 release candidate
> only 4 days ago (see
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115336261231270&w=2 ), I
> would like to start a release vote. Somehow I partially count the days
> of 1.2.16 and 1.2.17 testing, because changes for 1.2.18 have been very
> small.
> 
> If you want to take a look, the source distribution can be downloaded from:
> 
> http://tomcat.apache.org/dev/dist/
> 
> The updated documentation can be found at
> 
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/
> 
> Please see
> 
> http://tomcat.apache.org/dev/docs/tomcat-connectors-1.2.18/changelog.html
> 
> for a complete list of changes.
> 
> So here's the vote, which will be open until Friday July 28th, 24:00 GMT.
> 
> Apache Tomcat Connectors 1.2.18 is:
> [ ] Stable - no major issues, no regressions
> [ ] Beta - at least one significant issue -- tell us what it is
> [ ] Alpha - multiple significant issues -- tell us what they are
> 
> Thank you,
> 
> Rainer
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40107] - JK should handle EAGAIN in jk_is_socket_connected()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40107





--- Additional Comments From [EMAIL PROTECTED]  2006-07-25 21:05 ---
(In reply to comment #2)

> http://www.codecomments.com/archive286-2005-10-641948.html

That whole discussion is utterly bizarre and pointless - the thread drifts off
into arguing about how to handle situations where EWOULDBLOCK is not defined. 

The issue here is that on some OSes, the two constants have different values,
and read() can return either value depending on the circumstances of how the
socket was set up. (But from a semantic point of view, what it's saying in both
cases is that there is a need to retry the operation, which is the important
thing to take away. See
http://devrsrc1.external.hp.com/STKS/cgi-bin/man2html?manpage=/usr/share/man/man2.Z/send.2
- the link in the quoted thread)

On other OSes, the two constants are the same value.  Are there any on which
EWOULDBLOCK is not even defined? I don't think so. 

In any case, the code could be fixed as:

  if (errno == EAGAIN
#if defined(EWOULDBLOCK) && EWOULDBLOCK != EAGAIN
  || errno == EWOULDBLOCK
#endif
 )
  {
 // try again later
  }


-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/24/06, David Rees <[EMAIL PROTECTED]> wrote:

On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
> David Rees wrote:
> > Thanks that should work around my issue quite nicely. I'll check out
> > SVN and give a whirl (unless a new tag is to be rolled again shortly?)
>
> Try 1.2.18.

1.2.18 works much better, thanks!


I spoke too soon. I've been testing 1.2.18 further, and recover time
while appearing to change, I can not get mod_jk to actually recover
any faster than 60 seconds, even when recover time is set to 1.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk 1.2.17+ Recover time

[David Rees]

On 7/25/06, David Rees <[EMAIL PROTECTED]> wrote:

On 7/24/06, David Rees <[EMAIL PROTECTED]> wrote:
> On 7/19/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
> > David Rees wrote:
> > > Thanks that should work around my issue quite nicely. I'll check out
> > > SVN and give a whirl (unless a new tag is to be rolled again shortly?)
> >
> > Try 1.2.18.
>
> 1.2.18 works much better, thanks!

I spoke too soon. I've been testing 1.2.18 further, and recover time
while appearing to change, I can not get mod_jk to actually recover
any faster than 60 seconds, even when recover time is set to 1.


OK, It seems that the docs could use some clarification (can't be good
if the devs seem to be a bit confused as well as to what they do), but
you also need to set worker.maintain to a low value as well. mod_jk
acts like it uses the minimum of either worker.maintain or the
lb_worker's recover_time to determine the minimum amount of time a
worker should be down.

By setting worker.maintain to 10 and lb_worker's recover_time to 10 I
can get a reasonable recovery time for a worker.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40110] New: - org.apache.jasper.JasperException: Unable to compile class for JSP

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40110

   Summary: org.apache.jasper.JasperException: Unable to compile
class for JSP
   Product: Tomcat 5
   Version: 5.0.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


org.apache.jasper.JasperException: Unable to compile class for JSP

Generated servlet error:
C:\Program\Apache Software Foundation\Tomcat 5.0
\work\Catalina\localhost\exense\org\apache\jsp\index_jsp.java:7: cannot access 
java.lang.Object


Generated servlet error:
bad class file: C:\Program\Java\jdk1.5.0_05\jre\lib\rt.jar
(java/lang/Object.class)
class file has wrong version 49.0, should be 48.0
Please remove or make sure it appears in the correct subdirectory of the 
classpath.
public final class index_jsp extends org.apache.jasper.runtime.HttpJspBase
 ^
1 error

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40111] New: - HttpSession's getLastAccessedTime() does not always return previous request's access time

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40111

   Summary: HttpSession's getLastAccessedTime() does not always
return previous request's access time
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I noticed a difference in behaviour between Tomcat 4.1 and Tomcat 5.5.17, of the
getLastAccessedTime() method of HttpSession.
In Tomcat 5.5.17, this method returns the time of the last request (before the
current one) that actually accesses the session.
In Tomcat 4.1, it returns the time of the last request that was part of the 
session.

This means, that if you create a session in servlet A, the user then calls a
servlet B that does not call the getSession method, and then goes to a servlet C
to check getLastAccessedTime()'s value, it will get the time of the request to
servlet A in Tomcat 5.5.17, and B in Tomcat 4.1.


The getLastAccessedTime method of the HttpSession interface allows a servlet to
determine the last time the session was accessed before the current request. The
session is considered to be accessed when a request that is part of the session
is first handled by the servlet container.


Based on the first sentence I'd expect to get the access time of servlet A, but
with the definition of "to be accessed" in the second sentence I'd expect to get
the access time of servlet B.

Either way, if I use the response.encodeURL method in servlet B, Tomcat 5.5.17
will give me the same result as Tomcat 4.1. Therefore I think this is a bug and
not a change of interpretation of the spec.
#encodeURL leads to an update of the lastAccessed field:
StandardSession.access() line: 608  
Request.doGetSession(boolean) line: 2203
Request.getSessionInternal(boolean) line: 2169  
Response.isEncodeable(String) line: 1362
Response.encodeURL(String) line: 1092   
ResponseFacade.encodeURL(String) line: 363  
MySession.doGet(HttpServletRequest, HttpServletResponse) line: 35   

I will try to attach my test application, which also includes a png image of a
sequence diagram in which I try to explain what I am doing.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]