DO NOT REPLY [Bug 4612] New: - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4612.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4612
Thread which extracts Session object obtained from HttpSessionBindingEvent queries
the session object hangs
Summary: Thread which extracts Session object obtained from
HttpSessionBindingEvent queries the session object
hangs
Product: Tomcat 4
Version: 4.0.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Code example:
public void valueUnbound(HttpSessionBindingEvent parm1) {
HttpSession session = parm1.getSession();
log.debug(SessionBindingListener::valueUnbound:Name:+parm1.getName()
+ :Session+session.getId());
System.out.println(1);
// THE FOLLOWING CALL HANGS AFTER THE FOLLOWING CALL ***
User user = (User) session.getAttribute(PTLConstants.USER_KEY);
// THE THREAD NEVER EXECUTES THE NEXT STATEMENT
System.out.println(2);
if (user == null) {
System.out.println(3);
// log him off anyway
log.warn(Could not find User object in session+session.getId());
log.debug(user object was null);
return;
}
System.out.println(4);
}
Works OK! in Tomcat 3.2.3, but the User object cannot be found in the session
in Tomcat 3.2.3 too. User object was placed in the session which should have
been available here.
I believe this is the same problem of the thread hanging in HttpSessionListener
too on sessionDestroyed() method.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4613] New: - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613
Thread which extracts Session object obtained from HttpSessionBindingEvent queries
the session object hangs
Summary: Thread which extracts Session object obtained from
HttpSessionBindingEvent queries the session object
hangs
Product: Tomcat 4
Version: 4.0.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Code example:
public void valueUnbound(HttpSessionBindingEvent parm1) {
HttpSession session = parm1.getSession();
log.debug(SessionBindingListener::valueUnbound:Name:+parm1.getName()
+ :Session+session.getId());
System.out.println(1);
// THE FOLLOWING CALL HANGS AFTER THE FOLLOWING CALL ***
User user = (User) session.getAttribute(PTLConstants.USER_KEY);
// THE THREAD NEVER EXECUTES THE NEXT STATEMENT
System.out.println(2);
if (user == null) {
System.out.println(3);
// log him off anyway
log.warn(Could not find User object in session+session.getId());
log.debug(user object was null);
return;
}
System.out.println(4);
}
Works OK! in Tomcat 3.2.3
I believe this is the same problem of the thread hanging in HttpSessionListener
too on sessionDestroyed() method.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4612] - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4612. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4612 Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2001-11-03 01:32 --- *** This bug has been marked as a duplicate of 4613 *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4613] - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613 Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs --- Additional Comments From [EMAIL PROTECTED] 2001-11-03 01:32 --- *** Bug 4612 has been marked as a duplicate of this bug. *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4615] New: - jsp compilation problem in iplanet version 4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4615. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4615 jsp compilation problem in iplanet version 4.1 Summary: jsp compilation problem in iplanet version 4.1 Product: Tomcat 3 Version: Unknown Platform: Sun OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] IPlanet 4.1 when configured to support jsp with some protection(iplanet's obj.conf configuration file modified to do some initial activity before the request goes to jspengine using a nsapi plugin), and when accessed for the first time gives the compilation error. The request to the jsp is fired 2 times automatically and in the second request gives the following error msg. [01/Nov/2001:19:57:06] info ( 1753): JSP: JSP1x compiler threw exception java.io.FileNotFoundException: /dispatch.jsp at org.apache.jasper.compiler.JspReader.pushFile(JspReader.java, Compile d Code) at org.apache.jasper.compiler.JspReader.pushFile(JspReader.java, Compile d Code) at org.apache.jasper.compiler.JspReader.init(JspReader.java, Compiled Code) at org.apache.jasper.compiler.JspReader.createJspReader(JspReader.java, Compiled Code) at org.apache.jasper.compiler.Compiler.compile(Compiler.java, Compiled C ode) at com.netscape.server.http.servlet.NSServletEntity.load(NSServletEntity .java, Compiled Code) at com.netscape.server.http.servlet.NSServletEntity.update(NSServletEnti ty.java, Compiled Code) at com.netscape.server.http.servlet.NSServletRunner.Service(NSServletRun ner.java, Compiled Code) [01/Nov/2001:19:57:06] warning ( 1753): Internal error: Failed to get GenericSer vlet. (uri=/dispatch.jsp,SCRIPT_NAME=/dispatch.jsp) The same is working fine if the protection(nsapi plugin component) is removed or if the protection is put in place after the jsp's are compiled into servlets. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
patch to jk_uri_worker_map.c ApacheConfig.java
Here are my diffs to allow mod_jk to understand URIs of the form
/context/*whatever
and for ApacheConfig to write entries to mod_jk.conf-auto of the form
/context/*j_security_check
Combined, these patches should allow form-based authentication to work with
Apache+tomcat
If anyone sees any glaring problems with the modifications, please
let me know and I'll try and fix it.
-Mike Jennings
- Original Message -
From: Michael Jennings [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 6:38 PM
Subject: Re: patch to jk_uri_worker_map.c - slightly more sophisticated
string matching
Hi Costin Larry,
I'll apply my change to jakarta-tomcat-connectors then send the diff as an
attachment.
-Mike
- Original Message -
From: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 12:08 PM
Subject: Re: patch to jk_uri_worker_map.c - slightly more sophisticated
string matching
Mike,
Thanks for the patch and your interest. One small problem: the
development
of jk moved to jakarta-tomcat-connectors. We should do only 'major' bug
fixes in j-t/src/native.
Of course, all rules have exceptions - but it is extremely painfull to
merge and track 2 codebases.
Costin
On Fri, 2 Nov 2001, Michael Jennings wrote:
If anyone sees any glaring problems with the following modification to
mod_jk
please let me know.
-Mike Jennings
Index: jakarta-tomcat/src/native/jk/jk_uri_worker_map.c
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/native/jk/Attic/jk_uri_worker_map.c,v
retrieving revision 1.3.2.1
diff -r1.3.2.1 jk_uri_worker_map.c
75,77c75,78
#define MATCH_TYPE_EXACT(0)
#define MATCH_TYPE_CONTEXT (1)
#define MATCH_TYPE_SUFFIX (2)
---
#define MATCH_TYPE_EXACT(0) /* match an exact pattern */
#define MATCH_TYPE_CONTEXT (1) /* match all URIs in a given
context
*/
#define MATCH_TYPE_SUFFIX (2) /* match all URIs of the form
*.ext
*/
#define MATCH_TYPE_GENERAL_SUFFIX (3) /* match all URIs of the form
*ext
*/
231c232
---
236,237c237,238
jk_log(l, JK_LOG_ERROR,
jk_uri_worker_map_t::uri_worker_map_open, malloc failed\n);
---
jk_log(l, JK_LOG_ERROR,
jk_uri_worker_map_t::uri_worker_map_open, malloc failed\n);
244,245c245,246
* we need to have a '/' then a '*' and
the a
'.' or a
* '/' then a '*'
---
* we need to have a '/' then a '*' and
the a
'.' or a
* '/' then a '*'
247c248,252
asterisk--;
---
asterisk--; /* point to char before
asterisk
*/
/* asterisk[0]='/'
asterisk[1]='*'
asterisk[2]='.' or asterisk[2]='\0'
or
asterisk[2]!='\0'
*/
248a254
asterisk[1] = '\0'; /* terminate the
uri
pattern at the asterisk */
251c257
asterisk[1] = asterisk[2] =
'\0';
---
asterisk[2] = '\0';
252a259,260
/* uri-pattern will now contain
context only
since asterisk[1]='\0' */
256,258c264,276
jk_log(l, JK_LOG_DEBUG,
Into
jk_uri_worker_map_t::uri_worker_map_open, suffix rule %s.%s=%s was
added\n,
uri, asterisk + 3,
worker);
---
jk_log(l, JK_LOG_DEBUG,
Into
jk_uri_worker_map_t::uri_worker_map_open, suffix rule %s.%s=%s was
added\n,
uri, asterisk + 3,
worker);
j++;
} else if ('\0' != asterisk[2]) {
/* general suffix rule */
uw_map-maps[j].worker_name =
worker;
uw_map-maps[j].context = uri;
uw_map-maps[j].suffix =
asterisk
+
2;
uw_map-maps[j].match_type =
MATCH_TYPE_GENERAL_SUFFIX;
jk_log(l, JK_LOG_DEBUG,
Into
jk_uri_worker_map_t::uri_worker_map_open, general suffix rule %s*%s=%s
was
added\n,
uri, asterisk + 2,
AW: serious problem with Tomcat JVM running out of memory
Hi, We are facing serious problems with the above problem when running jsp on tomcat/linux. Could anyone please update me on the current status of handling this problem. It is extremely critical for us. Please reply ASAP. Manjunath
Re: AW: serious problem with Tomcat JVM running out of memory
manju at [EMAIL PROTECTED] wrote: Hi, We are facing serious problems with the above problem when running jsp on tomcat/linux. Could anyone please update me on the current status of handling this problem. It is extremely critical for us. Please reply ASAP. As far as I know there are no memory leaks in the latest releases of Tomcat in Tomcat. Please verify your application because 99% sure there is your problem. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: serious problem with Tomcat JVM running out of memory
We are facing serious problems with the above problem when running jsp on tomcat/linux. Could anyone please update me on the current status of handling this problem. If your application has lots of JSPs which need to get compiled, the VM may run out of memory because javac leaks memory each time it compiles a page. There's an article about the problem in the release notes for 4.0.1, but it exists in all Tomcat versions. If your application doesn't use many JSPs, then I have no explanation, as Tomcat has no known memory leaks. To get around this, you can either: - precompile the JSPs - stop and restart Tomcat when it starts to happen; after a while, all the JSPs will get compiled - join the crusade to open-source the JDK, so that we're able to fix that kind of feature Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Meta Refresh and jsessionid - a proposal
That works perfectly! I feel like a monkey for not trying that. Sorry to bother you guys. --- Ignacio J. Ortega [EMAIL PROTECTED] wrote: Why not simply encoding the url ? See http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=1482 Saludos , Ignacio J. Ortega -Mensaje original- De: craigmcc@localhost [mailto:craigmcc@localhost]En nombre de Craig R. McClanahan Enviado el: viernes 2 de noviembre de 2001 22:59 Para: Robert Lucier Cc: [EMAIL PROTECTED] Asunto: Re: Meta Refresh and jsessionid - a proposal On Fri, 2 Nov 2001, Robert Lucier wrote: Date: Fri, 2 Nov 2001 13:44:20 -0800 (PST) From: Robert Lucier [EMAIL PROTECTED] To: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: Meta Refresh and jsessionid - a proposal I understand, and that bothers me. Has there been any talk of modifying that portion of the spec to be compatible with the meta-refresh tag? The problem shows up on this and other lists fairly frequently. I don't recall any such discussion -- the best way to make sure it at least gets paid attention to is to submit feedback to the Servlet Spec feedback address ([EMAIL PROTECTED]). It may also be that the expert group doesn't consider compatible with the meta-refresh tag to be a very compelling argument: - Refresh is not a standard HTTP header - Browsers that misinterpret this kind of thing: meta http-equiv=refresh content=2;URL=http://foo/bar;jsessionid=12345; sound like they are broken in the first place -- they should be parsing on the first semicolon, not the second one. Craig --- Craig R. McClanahan [EMAIL PROTECTED] wrote: The servlet spec is pretty clear about where the session id is supposed to be. I don't think it is a good idea to introduce something that violates those requirements (and which would trap unwary developers into dependence on a non-standard implementation of this functionality). Craig On Fri, 2 Nov 2001, Robert Lucier wrote: Date: Fri, 2 Nov 2001 13:22:58 -0800 (PST) From: Robert Lucier [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Meta Refresh and jsessionid - a proposal I'm having a seemingly common problem where I can't use url-rewriting with the META HTTP-EQUIV=Refresh tag because the semi-colon in the rewritten URL is confused with the delimiter in the meta tag. I didn't see a solution or workaround, so here's mine. I'd like to modify the HttpProcessor.parseRequest method to look for jsessionid= in the query string if ;jsessionid is not found in the uri. That way the existing encodeURL method will still work, but those who need the refresh method can put the jsessionid in the query string parameters. Please let me know if this is acceptable or if there is a better way to solve this problem __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4613] - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613
Thread which extracts Session object obtained from HttpSessionBindingEvent queries
the session object hangs
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2001-11-03 11:50 ---
It is far more likely that an uncaught exception occurs on that line. Try
replacing it with:
try {
User user = (User) session.getAttribute(PTLConstants.USER_KEY);
} catch (Throwable t) {
t.printStackTrace();
}
to see what's happening. The most likely is a ClassCastException when casting
to the 'User' type.
If I'm wrong and no exception is thrown on that line, please reopen the bug.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4592] - Tomcat exits/dies without warning or messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4592. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4592 Tomcat exits/dies without warning or messages --- Additional Comments From [EMAIL PROTECTED] 2001-11-03 18:48 --- In general, we will not attempt to fix VM crash bugs (since it's a VM bug, not a Tomcat bug), and they will be closed with either 'WONTFIX' or 'INVALID'. Your description really looks like a VM crash. The problem may be with the JDBC driver Poolman uses. It may contain native code, which in turn may crash the VM. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4613] - Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4613 Thread which extracts Session object obtained from HttpSessionBindingEvent queries the session object hangs --- Additional Comments From [EMAIL PROTECTED] 2001-11-03 21:15 --- Most likely what is happening is that it is throwing an InvalidStateException due to the fact that the session has expired, and calls to getAttribute are no longer allowed. This is exactly what the 2.3 servlet spec specifies (it was unspecified in the 2.2 spec), so Remy (and Tomcat) are right. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4615] - jsp compilation problem in iplanet version 4.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4615. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4615 jsp compilation problem in iplanet version 4.1 --- Additional Comments From [EMAIL PROTECTED] 2001-11-03 21:30 --- This looks very much like a bug in iPlanet, but I haven't used iPlanet enough to change the status. However, you could try using Tomcat 3.x (3.3 has the best configuration support) with the Netscape plugin (which I am told works with iPlanet). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
