Re: [VOTE] Proposed API change to the Manager interface
Hmm, I think that Remy's patch is working correct. But I think we must controll the jvmRoute from those client sessions id's (ManagerBase include this at a comment :-)). I must check my cluster failover szenarios. I can to that tomorrow. Peter Rainer Jung schrieb: Both Cluster Managers (Delta and SimpleTcpReplication) extend ManagerBase but override createSession(). Maybe Filip or Peter can check how to make them long-time compatible with your proposal? Managers extending ManagerBase should work and compile as before with no changes unless they override the createSession method. - 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]
Re: [VOTE] Proposed API change to the Manager interface
Peter Rossbach wrote: Hmm, I think that Remy's patch is working correct. But I think we must controll the jvmRoute from those client sessions id's (ManagerBase include this at a comment :-)). I must check my cluster failover szenarios. I can to that tomorrow. Yes, I don't know if it is needed or not, so testing is useful. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util SystemLogHandler.java
remm2005/02/08 04:21:18
Modified:util/java/org/apache/tomcat/util/log SystemLogHandler.java
jasper2/src/share/org/apache/jasper/util
SystemLogHandler.java
Log:
- 33368: fix leak in swallowOutput.
- Submitted by Rainer Jung.
- I still don't know the purpose of the stack which is used in one of the
swallow output.
Revision ChangesPath
1.6 +14 -13
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log/SystemLogHandler.java
Index: SystemLogHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/log/SystemLogHandler.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- SystemLogHandler.java 2 Sep 2004 18:48:47 - 1.5
+++ SystemLogHandler.java 8 Feb 2005 12:21:18 - 1.6
@@ -18,7 +18,7 @@
import java.io.IOException;
import java.io.PrintStream;
-import java.util.Hashtable;
+import java.util.EmptyStackException;
import java.util.Stack;
/**
@@ -58,7 +58,7 @@
/**
* Thread - CaptureLog associations.
*/
-protected static Hashtable logs = new Hashtable();
+protected static ThreadLocal logs = new ThreadLocal();
/**
@@ -75,19 +75,20 @@
*/
public static void startCapture() {
CaptureLog log = null;
-
-// Synchronized for Bugzilla 31018
-synchronized(reuse) {
-log = reuse.isEmpty() ? new CaptureLog() :
(CaptureLog)reuse.pop();
+if (!reuse.isEmpty()) {
+try {
+log = (CaptureLog)reuse.pop();
+} catch (EmptyStackException e) {
+log = new CaptureLog();
+}
+} else {
+log = new CaptureLog();
}
-
-Thread thread = Thread.currentThread();
-Stack stack = (Stack)logs.get(thread);
+Stack stack = (Stack)logs.get();
if (stack == null) {
stack = new Stack();
-logs.put(thread, stack);
+logs.set(stack);
}
-
stack.push(log);
}
@@ -96,7 +97,7 @@
* Stop capturing thread's output and return captured data as a String.
*/
public static String stopCapture() {
-Stack stack = (Stack)logs.get(Thread.currentThread());
+Stack stack = (Stack)logs.get();
if (stack == null || stack.isEmpty()) {
return null;
}
@@ -118,7 +119,7 @@
* Find PrintStream to which the output must be written to.
*/
protected PrintStream findStream() {
-Stack stack = (Stack)logs.get(Thread.currentThread());
+Stack stack = (Stack)logs.get();
if (stack != null !stack.isEmpty()) {
CaptureLog log = (CaptureLog)stack.peek();
if (log != null) {
1.5 +8 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util/SystemLogHandler.java
Index: SystemLogHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util/SystemLogHandler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SystemLogHandler.java 17 Mar 2004 19:23:05 - 1.4
+++ SystemLogHandler.java 8 Feb 2005 12:21:18 - 1.5
@@ -19,7 +19,6 @@
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.PrintStream;
-import java.util.Hashtable;
/**
@@ -55,13 +54,13 @@
/**
* Thread - PrintStream associations.
*/
-protected static Hashtable streams = new Hashtable();
+protected static ThreadLocal streams = new ThreadLocal();
/**
* Thread - ByteArrayOutputStream associations.
*/
-protected static Hashtable data = new Hashtable();
+protected static ThreadLocal data = new ThreadLocal();
// - Public
Methods
@@ -76,9 +75,8 @@
*/
public static void setThread() {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
-PrintStream ps = new PrintStream(baos);
-data.put(Thread.currentThread(), baos);
-streams.put(Thread.currentThread(), ps);
+data.set(baos);
+streams.set(new PrintStream(baos));
}
@@ -87,12 +85,12 @@
*/
public static String unsetThread() {
ByteArrayOutputStream baos =
-(ByteArrayOutputStream) data.get(Thread.currentThread());
+(ByteArrayOutputStream) data.get();
if (baos == null) {
return null;
}
-streams.remove(Thread.currentThread());
DO NOT REPLY [Bug 33368] - swallowOutput causes memory leak
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=33368. 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=33368 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 13:26 --- I have applied the patch. Thanks. -- 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]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/02/08 05:45:28 Modified:webapps/docs changelog.xml Log: - Changelog update. Revision ChangesPath 1.231 +34 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.230 retrieving revision 1.231 diff -u -r1.230 -r1.231 --- changelog.xml 1 Feb 2005 21:07:29 - 1.230 +++ changelog.xml 8 Feb 2005 13:45:28 - 1.231 @@ -32,6 +32,9 @@ fix bug33204/bug: Fixed SSL HowTo page. (yoavs) /fix + fix +bug33351/bug: Fix silent uninstallation. (remm) + /fix /changelog /subsection @@ -69,11 +72,36 @@ fix bug26135/bug: Workaround for memory leak when reloading Struts based web applications by clearing the bean instrospector cache of the JVM on -classloader stop, submitted by Tobias Löfstrand (remm) +classloader stop, submitted by Tobias Lofstrand. (remm) /fix fix Ensure that if CLASSPATH is declared on startup - it is not used. (funkman) /fix + fix + Add back use of deployOnStartup in HostConfig (remm) + /fix + docs + Ant tasks docs patches, submitted by Gabriele Garuglieri. (remm) + /docs + update + Use NIO for the raw copying operation, as it is faster (a little under 30%), + and decreases a little the impact of antResourceLocking. (remm) + /update + fix + bug33357/bug: Fix connection leaks with the DataSourceRealm, as well + as improve efficiency, submitted by Dominik Drzewiecki. (remm) + /fix + update + Improve a little logging of servlet exceptions, which should all log the root cause. (remm) + /update + update + Add new Manager.createSession(sessionId) method, allowing the client to specify the session id which should be used using a cookie + when using emptySessionPath=true. This fixes session tracking in this case. (remm) + /update + fix + bug33368/bug: Fix memory leak in swallowOutput feature which occurred when the thread pool size is + reduced, submitted by Rainer Jung. (remm) + /fix /changelog /subsection @@ -88,6 +116,11 @@ add JkMX: make log4j mbean configureable with attribute log4jEnabled /add + fix + When Tomcat runs on Windows and IE is uploading data to the server, the first read + must be at least 8KB, otherwise upload speed is extremely low, submitted by Noel + Rocher (remm) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
remm2005/02/08 06:06:36
Modified:jasper2/src/share/org/apache/jasper JspC.java
Log:
- 33373: Fix handling of context classloader in jspc. The loader classLoader
must be set on each compilation.
Revision ChangesPath
1.91 +4 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -r1.90 -r1.91
--- JspC.java 22 Nov 2004 14:44:55 - 1.90
+++ JspC.java 8 Feb 2005 14:06:36 - 1.91
@@ -837,9 +837,11 @@
clctxt.setServletPackageName(targetPackage);
}
+originalClassLoader =
Thread.currentThread().getContextClassLoader();
if( loader==null ) {
-originalClassLoader = initClassLoader( clctxt );
+initClassLoader( clctxt );
}
+Thread.currentThread().setContextClassLoader(loader);
clctxt.setClassLoader(loader);
clctxt.setClassPath(classPath);
@@ -1096,7 +1098,7 @@
* @return The original classloader before modifying
* @throws IOException If an error occurs
*/
-private ClassLoader initClassLoader(JspCompilationContext clctxt)
+private void initClassLoader(JspCompilationContext clctxt)
throws IOException {
classPath = getClassPath();
@@ -1174,10 +1176,6 @@
urls.toArray(urlsA);
loader = new URLClassLoader(urlsA, this.getClass().getClassLoader());
-ClassLoader originalClassLoader =
Thread.currentThread().getContextClassLoader();
-Thread.currentThread().setContextClassLoader(loader);
-
-return originalClassLoader;
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33373] - jspc precompiling jsp with absolute uri in taglib fails
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=33373. 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=33373 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 15:08 --- That's a good example. This should be fixed now. -- 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 33445] New: - suspect that http session expiration fails in Tomcat
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=33445. 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=33445 Summary: suspect that http session expiration fails in Tomcat Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Running our application we get reports like this in catalina.out: SEVERE: An exception or error occurred in the container during the request processing java.util.NoSuchElementException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:785) at java.util.HashMap$KeyIterator.next(HashMap.java:818) at java.util.AbstractCollection.toArray(AbstractCollection.java:174) at org.apache.catalina.session.StandardSession.keys(StandardSession.java:1527) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:709) at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:569) at org.apache.coyote.tomcat5.CoyoteRequest.doGetSession(CoyoteRequest.java:2256) at org.apache.coyote.tomcat5.CoyoteRequest.getSession(CoyoteRequest.java:2116) at org.apache.coyote.tomcat5.CoyoteRequestFacade.getSession(CoyoteRequestFacade.java:526) at org.apache.catalina.authenticator.AuthenticatorBase.getSession(AuthenticatorBase.java:692) at org.apache.catalina.authenticator.AuthenticatorBase.getSession(AuthenticatorBase.java:675) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:423) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) Following this, we see evidence that objects bound to http session state are not getting their automatic expiration unbound calls, thus messing up our application. -- 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]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/02/08 07:45:56 Modified:webapps/docs changelog.xml Log: - Changelog update. Revision ChangesPath 1.232 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.231 retrieving revision 1.232 diff -u -r1.231 -r1.232 --- changelog.xml 8 Feb 2005 13:45:28 - 1.231 +++ changelog.xml 8 Feb 2005 15:45:56 - 1.232 @@ -130,6 +130,9 @@ bug33223/bug: pageContext.forward and jsp:include result in StringIndexOutOfBoundsException (luehe) /fix + fix +bug33373/bug: Fix handling of context classloader in jspc (remm) + /fix /changelog /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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 33448] New: - wrong policy in $CATALINA_BASE/conf/catalina.policy
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=33448.
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=33448
Summary: wrong policy in $CATALINA_BASE/conf/catalina.policy
Product: Tomcat 5
Version: 5.5.7
Platform: All
OS/Version: All
Status: NEW
Severity: trivial
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
$CATALINA_BASE/conf/catalina.policy, line 82:
grant codeBase file:${catalina.home}/webapps/balancer/...
should be replaced by
grant codeBase file:${catalina.base}/webapps/balancer/...
--
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: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address,
and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and
never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
- Original Message -
From: Rainer Jung [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]
-
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]
Re: [VOTE] Proposed API change to the Manager interface
Filip Hanik - Dev wrote: its not at all that complicated. This is how a big5 load balancer does it. A) it sets a cookie, and based on the cookie it load balances. B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way. No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for AOL users who can change gateway between HTTP and HTTPS I don't think it's that complicated either, but it would still require an upgrade of mod_jk to work, so it's probably not an option :( Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposed API change to the Manager interface
I don't fully agree: we use F5 too, but:
1) I know many commercial sites (in germany), which do not use Cookies
(privacy reasons).
2) IP based stickyness does not work very well. In many scenarios you
will only be able to correctly route most of your clients. If you rely
on exact routing, IP-based will not suffice.
3) These are the reasons why I assume, that all balancers will support
routing decisions based on the jsessionid in the URI. So they already
have to support extracting routing information from the session id string.
So using the same jessionid string in the standard cookie will work in
most (all ?) situations / for most products.
Example: mod_jk does it like that:
/* Retrieve session id from the cookie or the parameter
*/
static char *get_sessionid(jk_ws_service_t *s)
{
char *val;
val = get_path_param(s, JK_PATH_SESSION_IDENTIFIER);
if (!val) {
val = get_cookie(s, JK_SESSION_IDENTIFIER);
}
return val;
}
and after that it does no longer matter, where the info comes from.
On the other hand: what's wrong about embedding the jmvRoute as a suffix
in the session id?
Rainer
Filip Hanik - Dev wrote:
its not at all that complicated.
This is how a big5 load balancer does it.
A) it sets a cookie, and based on the cookie it load balances.
B) if a cookie is not supported, it does a calculation based on the IP address,
and stays sticky that way.
No need to exchange any info in this scenario and very straight forward, and
never goes wrong. The only time it goes wrong is for
AOL users who can change gateway between HTTP and HTTPS
Filip
- Original Message -
From: Rainer Jung [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Tuesday, February 08, 2005 10:39 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
I'm afraid that change will have negative implications: The jvmRoute is
used to enable routing decisions by balancing components. All these
components usually support routing either COOKIE-based or URI-based.
In the URI-based case it is more or less the only clean way to include
the jvmRoute in the jsessionid, since the jsessionid is standardized, so
all common balancing products know how to handle it.
But then it is pretty common to assume the jsessionid and the cookie to
have the same value. They are sort of two different ways to transport
the same session information. So most balancer providers implement the
routing decision features the same way, independant of the source of the
session string.
Splitting the jvmRoute from the session id in the cookie case will most
likely make the situation for all implementers of balancers more complex
and instable (e.g.: mod_jk).
Of course we would all profit, if some JSR would standardize the way,
distributed applications exchange routing information with the
clients/balancers. As long as that's not the case it is very likely,
that jvmRoute as a suffix of the session id has much better support from
balancer providers.
Rainer
Filip Hanik - Dev wrote:
Remy Wrote:
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
That would have been the obvious solution, the jvmRoute must have come from a
dark basement somewhere :)
Whatever the change you decide on, I'll be happy to implement it and test it
for the cluster stuff
Filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List tomcat-dev@jakarta.apache.org
Sent: Monday, February 07, 2005 11:34 AM
Subject: Re: [VOTE] Proposed API change to the Manager interface
@@ -744,15 +747,17 @@
session.setValid(true);
session.setCreationTime(System.currentTimeMillis());
session.setMaxInactiveInterval(this.maxInactiveInterval);
-String sessionId = generateSessionId();
+if (sessionId == null) {
+sessionId = generateSessionId();
+}
I just noticed my patch needs something for jvmRoute handling
(basically, the session id which is recieved must be edited for the
right route). I'll fix that.
BTW, wouldn't it be better to set the route as a separate cookie, which
would be a lot cleaner ? Was this ever considered ?
Rémy
-
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL
Re: [VOTE] Proposed API change to the Manager interface
Upgrading mod_jk would be possible (not too complicated), but I'm afraid we are going to break other products we don't control the way we do with mod_jk. mod_jk is a good example to see, why it's not unlikely that changes would be needed for other balancers. Rainer Remy Maucherat wrote: Filip Hanik - Dev wrote: its not at all that complicated. This is how a big5 load balancer does it. A) it sets a cookie, and based on the cookie it load balances. B) if a cookie is not supported, it does a calculation based on the IP address, and stays sticky that way. No need to exchange any info in this scenario and very straight forward, and never goes wrong. The only time it goes wrong is for AOL users who can change gateway between HTTP and HTTPS I don't think it's that complicated either, but it would still require an upgrade of mod_jk to work, so it's probably not an option :( Rémy - 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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
kinman 2005/02/08 10:03:58
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- More fine-tuning on smap for jsp:element, making sure that the java
line range is at least one.
Revision ChangesPath
1.239 +4 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.238
retrieving revision 1.239
diff -u -r1.238 -r1.239
--- Generator.java8 Feb 2005 00:23:58 - 1.238
+++ Generator.java8 Feb 2005 18:03:58 - 1.239
@@ -1825,9 +1825,6 @@
out.print((String)map.get(attrName));
}
-// Smap should not include the body
-n.setEndJavaLine(out.getJavaLine());
-
// Does the jsp:element have nested tags other than
// jsp:attribute
boolean hasBody = false;
@@ -1844,6 +1841,9 @@
if (hasBody) {
out.println( + \\););
+// Smap should not include the body
+n.setEndJavaLine(out.getJavaLine());
+
// Visit tag body
visitBody(n);
@@ -1853,6 +1853,7 @@
out.println( + \\););
} else {
out.println( + \/\););
+n.setEndJavaLine(out.getJavaLine());
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util SystemLogHandler.java
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 4:21 AM Subject: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util SystemLogHandler.java remm2005/02/08 04:21:18 Modified:util/java/org/apache/tomcat/util/log SystemLogHandler.java jasper2/src/share/org/apache/jasper/util SystemLogHandler.java Log: - 33368: fix leak in swallowOutput. - Submitted by Rainer Jung. - I still don't know the purpose of the stack which is used in one of the swallow output. The stack is to accommodate the geniuses who have a Servlet in /appA that includes one in /appB which in turn includes another in /appA. This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/util SystemLogHandler.java
Bill Barker wrote: The stack is to accommodate the geniuses who have a Servlet in /appA that includes one in /appB which in turn includes another in /appA. In that case the servlet gets called directly by the request dispatcher, without going through StdWrapperValve.invoke. So there isn't any extra wrapping that I can see. Using the call hierarchy feature in Eclipse, I see it could be stacked if loading the servlet as a result of a request dispatcher call. Swallowing output during servlet lifecycle operations is, IMO, not really worth adding all that complexity (although I don't care: I'm not using the feature). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 20:56 --- When packaged right JCL will only use java.util.logging, isn't that a fact? Remy, have your *ever* used Tomcat with log4j in a production environment? I guess that the people using commons-logging probably do not realize how badly JCL is broken. Given that you yourself admit not having being familiar with the JCL implementation, you apparently do not understand that JCL is much more complicated than UGLI. -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 21:48 --- (In reply to comment #22) When packaged right JCL will only use java.util.logging, isn't that a fact? Remy, have your *ever* used Tomcat with log4j in a production environment? I use Tomcat with log4j in production all the time. It works very well, when packaged right ;-). I guess that the people using commons-logging probably do not realize how badly JCL is broken. Given that you yourself admit not having being familiar with the JCL implementation, you apparently do not understand that JCL is much more complicated than UGLI. Of course JCL is much more complicated than UGLI, since UGLI expects you to create a properties file on the CP, and is useless if you forget (you don't even get log4j :). However, IMHO, that complication is necessary for logging in a container environment. I'm also -1 on having UGLI Tomcat code, and +0 for having an optional example of j.u.l.LogManager. -- 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 33307] - jspInit() method is throwing an NamingException when extracting a factory object from a JNDI context
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=33307. 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=33307 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:05 --- You have uploaded a .tar file but given it a .zip extension. Now I have figured this out, I'll take a look. For future reference, when you upload a file give it the right extension. It makes it so much easier for the people who are trying to help you. -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:07 --- What makes you think that UGLI needs a properties file on the classpath? How did you come up with that? As for packaged right, do you have an example of what you mean by that? -- 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]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
luehe 2005/02/08 13:08:39 Modified:jasper2/src/share/org/apache/jasper JspC.java Log: Removed return tag from initClassLoader() javadocs, because this method was changed back to 'void' Revision ChangesPath 1.92 +0 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java Index: JspC.java === RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java,v retrieving revision 1.91 retrieving revision 1.92 diff -u -r1.91 -r1.92 --- JspC.java 8 Feb 2005 14:06:36 - 1.91 +++ JspC.java 8 Feb 2005 21:08:39 - 1.92 @@ -1095,7 +1095,6 @@ * compilation context. * * @param clctxt The compilation context - * @return The original classloader before modifying * @throws IOException If an error occurs */ private void initClassLoader(JspCompilationContext clctxt) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:21 --- (In reply to comment #24) What makes you think that UGLI needs a properties file on the classpath? How did you come up with that? http://cvs.apache.org/viewcvs.cgi/logging- log4j/src/java/org/apache/ugli/LoggerFactory.java?rev=1.2view=markup As for packaged right, do you have an example of what you mean by that? http://jakarta.apache.org/tomcat/faq/logging.html#commonsLoggingConfiguration -- 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 32424] - Redirecting directiories with missing trailing slash breaks web applications
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=32424. 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=32424 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:22 --- (In reply to comment #4) In this case, Tomcat will indeed issue a redirect right away. Please do not reopen the issue. Why does Tomcat redirect right away? Shouldn't the filter be given a chance to process the original (no slash) request? I have an application that was previously deployed using Jetty and I'm currently looking at moving over to Tomcat 5.5 but this is a show stopper for me. I can't rename the directories and the end users expect the original (no slash) paths to work. The application does not do directory listings so adding the slash doesn't help us in the least. Is there a way to disable this? It seems to me that this redirect should be sent by the default servlet *after* any user filters/servlet have had a chance to process the request but then I assume this behaviour is according to the spec? If so where is it specified? -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:22 --- I am still +1 for using LogManager, but where do we put it ? We would also need companion loggers for java.util.logging to be a viable solution, such as a rotatable logger. Yoav didn't want us to have anything to do with logging inside Tomcat (I think he's right), as he mentioned in #5 when this bug report was still on topic. This leads to the need of a full fledged project to host the code, or at least a commons component. -- 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 33307] - jspInit() method is throwing an NamingException when extracting a factory object from a JNDI context
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=33307. 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=33307 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:36 --- I did the following: - renamed your war to case.war and placed it in $CATALINA_HOME/webapps - added Resource name=bean/MyBeanFactory auth=Container type=com.mycompany.MyBean/ ResourceParams name=bean/MyBeanFactory parameter namefactory/name valueorg.apache.naming.factory.BeanFactory/value /parameter parameter namebar/name value23/value /parameter /ResourceParams to the default context element of my server.xml - restarted tomcat (to pick up the server.xml changes) - noted the following in standard out: Getting InitialContext Doing initContext lookup Extracting factory bean object foo = Default Foo, bar = 23 This test was with the latest code from CVS. There were many bug fixes in 4.1.31. You might want to try your test case with 4.1.31. Also, test with a clean, unmodified installation. -- 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 32424] - Redirecting directiories with missing trailing slash breaks web applications
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=32424. 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=32424 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:39 --- The behavior is not specified anywhere, but the idea is that in the case of a physical folder or the root of a context, the trailing '/' is not relevant. Since this causes recurrent path resolution issues (which made servlets like our default servlet needlessly more complex), we always present the servlet with a training '/' in all cases. It is also the most efficient, so that's the the implementation which is currently used. I regret it would prevent you from using Tomcat, but there's nothing that I will change here. -- 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 33453] New: - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 Summary: Jasper should recompile JSP files whose datestamps change in either direction (not just newer) Product: Tomcat 5 Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: minor Priority: P3 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I've noticed that Tomcat won't recompile a JSP file if the date stamp is changed to go back in time. This may seem like a strange case, but if you check an older copy of a JSP page out of version control, it's different, and needs to be recompiled. The assumption that all changes to a file involve a newer file datestamp is an invalid one. I think I found the code that makes this decision, in org.apache.jasper.compiler.Compiler, in the isOutDated(boolean) method. The condition is if (targetLastModified jspRealLastModified) but it should be if (targetLastModified != jspRealLastModified) in my opinion. After all, the logic should be that the file has changed, not that it's newer. I don't think it's reasonable to expect that Jasper check the size and do an MD5 checksum to *really* see if the file has changed. :) Obviously the workaround is to just to touch the file but this adds a lot of overhead (and one more thing to remember), compared to changing a to a !=. -- 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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:55 --- Changes to a file that make the change timestamp older instead of newer seems like a special (if not outright wrong) use-case. I'm not sure Tomcat should worry about this at all. -- 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 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 22:58 --- The ugli.properties file is not specified on the class path. It is bundled with each version of ugli-xxx.jar. In a class loader following the child-first delegation model (as in WebAppClassLoader in Tomcat) the factory used will be the correct one whereas in a class loader following the parent-first delegation model the factory used will be that of the parent. It's not perfect but at least UGLI won't blow up and crash your application. Moreover, the intent is to perform the factory binding at compile time. -- 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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:03 --- (In reply to comment #1) Changes to a file that make the change timestamp older instead of newer seems like a special (if not outright wrong) use-case. I don't agree that using version control is a special or wrong use case. In fact, I think the opposite is true. Example: 1) Check out a JSP file from VC and deploy it where Tomcat can see it 2) Access the JSP file via a web browser, so it gets compiled 3) Change it locally, deploy the changed version (newer timestamp) 4) Access it via a web browser; Tomcat correctly shows the updated version. 5) Revert to an older version from VC and deploy that. 6) Access it via a web browser; Tomcat ignores the changes and shows the output of a nonexistent JSP page -- 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 33457] New: - 1.2.8 jk: cache size set to incorrect value
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=33457. 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=33457 Summary: 1.2.8 jk: cache size set to incorrect value Product: Tomcat 5 Version: Unknown Platform: Sun OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I keep seeing these errors in the jk log file: [Sat Feb 05 05:28:27 2005] [info] ajp_done::jk_ajp_common.c (1947): could not find empty cache slot from 1 for worker myUBC. Rise worker cachesize After poking around in the code for a bit I discovered that the 1 referred to the cache size. What I couldn't figure out is why it was 1 when httpd.conf had: ThreadLimit 250 StartServers 1 MaxClients 400 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 100 MaxRequestsPerChild 0 After adding some log calls I discovered that the call to jk_set_worker_def_cache_size() in jk_child_init() happens after the call to ajp_init() which is why the cache size is 1. Here is the log file entries (including the extra ones I added): [Tue Feb 08 14:17:42 2005] [24646:1] [debug] uri_worker_map_open::jk_uri_worker_map.c (461): rule map size is 0 [Tue Feb 08 14:17:42 2005] [24646:1] [debug] build_worker_map::jk_worker.c (196): creating worker myUBC [Tue Feb 08 14:17:42 2005] [24646:1] [debug] wc_create_worker::jk_worker.c (120): about to create instance myUBC of ajp13 [Tue Feb 08 14:17:42 2005] [24646:1] [debug] wc_create_worker::jk_worker.c (133): about to validate and init myUBC [Tue Feb 08 14:17:42 2005] [24646:1] [debug] ajp_validate::jk_ajp_common.c (1721): worker myUBC contact is localhost:7090 [Tue Feb 08 14:17:42 2005] [24646:1] [error] ajp_init::jk_ajp_common.c (1755): ajp_init [Tue Feb 08 14:17:42 2005] [24646:1] [error] ajp_init::jk_ajp_common.c (1758): def cache size 1 [Tue Feb 08 14:17:42 2005] [24646:1] [error] ajp_init::jk_ajp_common.c (1762): new cache size 1 ... [Tue Feb 08 14:17:42 2005] [24646:1] [debug] ajp_init::jk_ajp_common.c (1856): setting connection cache size to 1 [Tue Feb 08 14:17:42 2005] [24646:1] [error] init::jk_ajp13_worker.c (53): init [Tue Feb 08 14:17:42 2005] [24646:1] [debug] build_worker_map::jk_worker.c (208): removing old myUBC worker [Tue Feb 08 14:17:44 2005] [24647:1] [debug] uri_worker_map_open::jk_uri_worker_map.c (461): rule map size is 0 [Tue Feb 08 14:17:44 2005] [24647:1] [debug] build_worker_map::jk_worker.c (196): creating worker myUBC [Tue Feb 08 14:17:44 2005] [24647:1] [debug] wc_create_worker::jk_worker.c (120): about to create instance myUBC of ajp13 [Tue Feb 08 14:17:44 2005] [24647:1] [debug] wc_create_worker::jk_worker.c (133): about to validate and init myUBC [Tue Feb 08 14:17:44 2005] [24647:1] [debug] ajp_validate::jk_ajp_common.c (1721): worker myUBC contact is localhost:7090 [Tue Feb 08 14:17:44 2005] [24647:1] [error] ajp_init::jk_ajp_common.c (1755): ajp_init [Tue Feb 08 14:17:44 2005] [24647:1] [error] ajp_init::jk_ajp_common.c (1758): def cache size 1 [Tue Feb 08 14:17:44 2005] [24647:1] [error] ajp_init::jk_ajp_common.c (1762): new cache size 1 ... [Tue Feb 08 14:17:44 2005] [24647:1] [debug] ajp_init::jk_ajp_common.c (1856): setting connection cache size to 1 [Tue Feb 08 14:17:44 2005] [24647:1] [error] init::jk_ajp13_worker.c (53): init [Tue Feb 08 14:17:44 2005] [24647:1] [debug] build_worker_map::jk_worker.c (208): removing old myUBC worker [Tue Feb 08 14:17:44 2005] [24649:1] [error] jk_child_init::mod_jk.c (2198): thread limit is 100 [Tue Feb 08 14:17:44 2005] [24649:1] [debug] jk_child_init::mod_jk.c (2202): Initialized mod_jk/1.2.8 [Tue Feb 08 14:17:44 2005] [24649:1] [error] jk_child_init::mod_jk.c (2203): Cache size 100 -- 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 33457] - 1.2.8 jk: cache size set to incorrect value
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=33457. 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=33457 --- Additional Comments From [EMAIL PROTECTED] 2005-02-08 23:53 --- Created an attachment (id=14221) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14221action=view) httpd.conf -- 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]
Custom load balancing algorithm and mod_jk???
Hi, We need to use Apache to load balance a set of Tomcat servers. However, we need to use a custom load-balancing algorithm, based on the usage of those servers. Is this possible with mod_jk? Would it be easy to extend it? Any other suggestions? Many thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33143] - [PATCH] Java 1.4 loggers per context
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=33143. 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=33143 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:00 --- (In reply to comment #26) This leads to the need of a full fledged project to host the code, or at least a commons component. Commons would be a good place for it, since it isn't really Tomcat specific. It would also let you learn the joys of svn ;-). Otherwise I'd vote for j-t-c so that it is available for TC 34 as well. Putting it in catalina/modules also works for me. -- 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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 [EMAIL PROTECTED] changed: What|Removed |Added Severity|minor |enhancement --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:04 --- This is an enhancement at best. (That I would be -0 to) -- 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]
cvs commit: jakarta-tomcat-4.0/catalina build.xml
markt 2005/02/08 15:06:30
Modified:catalina build.xml
Log:
Fix bug 10982. include o.a.naming.resources.jndi.Handler in
naming-resources.jar
Revision ChangesPath
1.137 +1 -1 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.136
retrieving revision 1.137
diff -u -r1.136 -r1.137
--- build.xml 27 Dec 2004 00:05:41 - 1.136
+++ build.xml 8 Feb 2005 23:06:30 - 1.137
@@ -1173,7 +1173,7 @@
!-- Naming - Resources JAR File --
jar jarfile=${catalina.deploy}/common/lib/naming-resources.jar
fileset dir=${catalina.build}/server/classes
-include name=org/apache/naming/resources/* /
+include name=org/apache/naming/resources/** /
/fileset
/jar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10982] - JNDI URL Handler class is missing in naming-resources.jar
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=10982. 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=10982 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version||All Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:09 --- This has been fixed in CVs for TC4.1.x TC5.5.x already includes this class. You will still need to add the package to the java.protocol.handler.pkgs system property as per http://java.sun.com/j2se/1.4.2/docs/api/java/net/URL.html to make this handler visible to java.net.URL -- 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]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaManager.java
fhanik 2005/02/08 15:15:06
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
DeltaManager.java
Log:
Set the context class loader while doing a state transfer, otherwise static
struts classes fail loading
Revision ChangesPath
1.38 +70 -60
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java
Index: DeltaManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/DeltaManager.java,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- DeltaManager.java 7 Feb 2005 21:56:32 - 1.37
+++ DeltaManager.java 8 Feb 2005 23:15:06 - 1.38
@@ -357,52 +357,28 @@
ObjectInputStream ois = null;
Loader loader = null;
ClassLoader classLoader = null;
+ClassLoader originalLoader =
Thread.currentThread().getContextClassLoader();
try {
-fis = new ByteArrayInputStream(data);
-BufferedInputStream bis = new BufferedInputStream(fis);
-if (container != null)
-loader = container.getLoader();
-if (loader != null)
-classLoader = loader.getClassLoader();
-if (classLoader != null) {
-ois = new CustomObjectInputStream(bis, classLoader);
-} else {
-ois = new ObjectInputStream(bis);
-}
-} catch (IOException e) {
-log.error(sm.getString(standardManager.loading.ioe, e), e);
-if (ois != null) {
-try {
-ois.close();
-} catch (IOException f) {
-;
-}
-ois = null;
-}
-throw e;
-}
-
-// Load the previously unloaded active sessions
-synchronized (sessions) {
+
try {
-Integer count = (Integer) ois.readObject();
-int n = count.intValue();
-for (int i = 0; i n; i++) {
-DeltaSession session = getNewDeltaSession();
-session.readObjectData(ois);
-session.setManager(this);
-session.setValid(true);
-session.setPrimarySession(false);
-//in case the nodes in the cluster are out of
-//time synch, this will make sure that we have the
-//correct timestamp, isValid returns true, cause
accessCount=1
-session.access();
-//make sure that the session gets ready to expire if
needed
-session.setAccessCount(0);
-sessions.put(session.getId(), session);
+fis = new ByteArrayInputStream(data);
+BufferedInputStream bis = new BufferedInputStream(fis);
+if (container != null)
+loader = container.getLoader();
+if (loader != null)
+classLoader = loader.getClassLoader();
+if (classLoader != null) {
+log.debug(
+\n\n\n[CLUSTER] Loading the object data with a
class loader.\n\n\n);
+ois = new CustomObjectInputStream(bis, classLoader);
+
Thread.currentThread().setContextClassLoader(classLoader);
+} else {
+log.debug(
+\n\n\n[CLUSTER] Loading the object data without a
class loader.\n\n\n);
+ois = new ObjectInputStream(bis);
}
-} catch (ClassNotFoundException e) {
- log.error(sm.getString(standardManager.loading.cnfe, e), e);
+} catch (IOException e) {
+log.error(sm.getString(standardManager.loading.ioe, e), e);
if (ois != null) {
try {
ois.close();
@@ -412,27 +388,61 @@
ois = null;
}
throw e;
-} catch (IOException e) {
- log.error(sm.getString(standardManager.loading.ioe, e), e);
-if (ois != null) {
+}
+// Load the previously unloaded active sessions
+synchronized (sessions) {
+try {
+Integer count = (Integer) ois.readObject();
+int n = count.intValue();
+for (int i = 0; i n; i++) {
+DeltaSession session = getNewDeltaSession();
+
DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:46 --- Although not allowed to vote I have an opinion: The dynamic update feature for JSPs comes from the need to dynamically manage content without a heavy weight administrative action. But every now and then one has to roll back a change. With static content you would just put back the original files. It would be very nice, if it would work the same way with JSPs, especially because that's unsually the unplanned case (roll back) where you need to have a simple procedure. I know, you could touch the old file. Myself I always tell Sysadmins to make backup copies and roll back file changes with cp -p, so that the files keep their original timestamp, which is a nice low-level approximation of checksums. Any higher level tool (like CVS) will most liekely also roll back including file timestamps. There seems to be very little risk in the change and some not neglectable benefit. -- 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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 01:02 --- Please test this *really* well. Also, you should test with a similar change made to the dependent files near the end of the isOutDated method (otherwise, touch would still be required in some cases). -- 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 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 01:08 --- I'm not sure why this issue remains open, given that #26372 has been closed. Whenever there is a ThreadDeath thrown from WebappClassLoader.loadClass() during a webapp restart, it is due to Tomcat invalidating the webapp's ClassLoader while threads are still executing a (long-running) service() method (or even lifecycle method). Tomcat waits 2 seconds, then invalidates the ClassLoader and restarts the app, resulting in a ThreadDeath thrown by the ClassLoader if new class load requests occur. See my comment in #26372 . Given that #26372 has been marked invalid (read as -1 for a configurable [or perhaps longer] wait-time for current requests to complete, prior to invalidating the ClassLoader and restarting the webapp), I think that this issue should now be closed. This is a Tomcat issue for restartable webapps, not a log4j issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
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=27371. 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=27371 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 00:42 --- Hi! I'm also experiencing ThreadDeath with Log4j on Tomcat 5.0.28 (bundled with NetBeans 4.0) when restarting applications. I understand you've already seen a lot of stack traces in this discussion. So I'll just give a part of mine: == Caused by: java.lang.ThreadDeath at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1229) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1189) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at org.apache.log4j.NDC.get(NDC.java:201) at org.apache.log4j.spi.LoggingEvent.getNDC(LoggingEvent.java:229) etc... == Seems like NDC is arranging its instances in a Hashtable with key being the current thread. That might be the reason of such behaviour. Have you thought of switching to ThreadLocal? I'm not sure about how it may affect the performance though. Thanks -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 02:03 --- Thanks for your hint. I do like the use case, but I should have thought better about the implementation suggestion of Jamie. His idea to just compare for timestamps for not being equal will not work! In most cases the timestamps of the class files will of course be younger than the source file (source file has some old installation date but class file is only generated on first access). So this change would make the compiler compile on every test :( It would only work by saving the last JSP timestamp for any JSP and then comparing to the saved value insted of comparing to the timestamp of the generated files. I leave it up to Jamie to suggest a working patch - I don't knw enough about Jasper details. -- 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 33453] - Jasper should recompile JSP files whose datestamps change in either direction (not just newer)
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=33453. 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=33453 --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 04:03 --- Fair enough; that's not the place to make that change. The servlet .class or .java file will be slightly newer than the JSP file. It's the JSP file's date that should be compared to the cached last-modified time, regardless of how many ms it took to get around to generating and compiling the actual servlet. -- 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]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
mturk 2005/02/08 23:39:08
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Move jk_set_worker_def_cache_size to post config hook, so that
it is set before the jk configuration is parsed.
Revision ChangesPath
1.122 +12 -12jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.121
retrieving revision 1.122
diff -u -r1.121 -r1.122
--- mod_jk.c 7 Feb 2005 19:07:38 - 1.121
+++ mod_jk.c 9 Feb 2005 07:39:08 - 1.122
@@ -2225,7 +2225,6 @@
static void jk_child_init(apr_pool_t * pconf, server_rec * s)
{
jk_server_conf_t *conf;
-int mpm_threads = 1;
apr_status_t rv;
int rc;
@@ -2239,15 +2238,6 @@
JK_TRACE_ENTER(conf-log);
-/* Set default connection cache size for worker mpm */
-#if APR_HAS_THREADS
-#ifndef AS400
-ap_mpm_query(AP_MPMQ_MAX_THREADS, mpm_threads);
-#endif
-#endif
-if (mpm_threads 0)
-jk_set_worker_def_cache_size(mpm_threads);
-
if ((rc = jk_shm_attach(jk_shm_file)) == 0) {
if (JK_IS_DEBUG_LEVEL(conf-log))
jk_log(conf-log, JK_LOG_DEBUG, Attached shm:%s,
@@ -2277,10 +2267,11 @@
server_rec * s)
{
int rc;
+int mpm_threads = 1;
+
/* jk_map_t *init_map = NULL; */
jk_map_t *init_map = conf-worker_properties;
-;
if ((rc = jk_shm_open(jk_shm_file)) == 0) {
if (JK_IS_DEBUG_LEVEL(conf-log))
jk_log(conf-log, JK_LOG_DEBUG, Initialized shm:%s,
@@ -2292,6 +2283,15 @@
jk_log(conf-log, JK_LOG_ERROR, Initializing shm:%s errno=%d,
jk_shm_name(), rc);
+/* Set default connection cache size for worker mpm */
+#if APR_HAS_THREADS
+#ifndef AS400
+if (ap_mpm_query(AP_MPMQ_MAX_THREADS, mpm_threads) != APR_SUCCESS)
+mpm_threads = 1;
+#endif
+#endif
+ jk_set_worker_def_cache_size(mpm_threads);
+
if (!uri_worker_map_alloc((conf-uw_map),
conf-uri_to_context,
conf-log)) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33457] - 1.2.8 jk: cache size set to incorrect value
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=33457. 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=33457 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-09 08:41 --- Fixed in the CVS. Thanks for spotting that. This is not a critical bug, because you can always set the cache size to a proper value inside workers.properties for each worker. -- 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]
