DO NOT REPLY [Bug 38814] New: - CGIServlet applies wrong charset

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38814

   Summary: CGIServlet applies wrong charset
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: All
Status: NEW
  Keywords: PatchAvailable
  Severity: major
  Priority: P1
 Component: Servlets:CGI
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Suppose the CGI header contains:

   content-type: text/plain; charset=shift_jis

This content type is exactly set to the header of the servlet response. However,
both the reader of the CGI output and the writer of the servlet output always
apply the platform's default character encoding, since InputStreamReader and
OutputStreamWriter are constructed without charset.

I've already written the patch. Please contact me by email, then I can send you
the revised CGIServlet (the source came from 5.5.15).

-- 
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 38814] - CGIServlet applies wrong charset

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38814





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 09:35 ---
Created an attachment (id=17811)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17811&action=view)
A revised CGIServlet based on Tomcat 5.5.15 source.


-- 
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 38814] - CGIServlet applies wrong charset

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38814





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 09:44 ---
The revised code was attached. In order to solve this problem, the following
steps are made.

(1) charset is extracted from the content-type in CGI header.

(2) servletContainerStdout is created for the specified charset if any.

(3) commandsStdOut is created for the specified charset if any.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r382005 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java

[fhanik]

Author: fhanik
Date: Wed Mar  1 04:44:37 2006
New Revision: 382005

URL: http://svn.apache.org/viewcvs?rev=382005&view=rev
Log:
Changed warnings to debug messages

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java?rev=382005&r1=382004&r2=382005&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
 Wed Mar  1 04:44:37 2006
@@ -36,14 +36,14 @@
 return 
loadRuleSet(prefix,"org.apache.catalina.cluster.ClusterRuleSet",ClusterRuleSetFactory.class.getClassLoader());
 } catch ( Exception x ) {
 //display warning
-if ( log.isWarnEnabled() ) log.warn("Unable to load 
ClusterRuleSet, falling back on context classloader",x);
+if ( log.isDebugEnabled() ) log.debug("Unable to load 
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), falling back on 
context classloader");
 }
 //try to load it from the context class loader
 try {
 return 
loadRuleSet(prefix,"org.apache.catalina.cluster.ClusterRuleSet",Thread.currentThread().getContextClassLoader());
 } catch ( Exception x ) {
 //display warning
-if ( log.isWarnEnabled() ) log.warn("Unable to load 
ClusterRuleSet, will try to load the HA cluster",x);
+if ( log.isDebugEnabled() ) log.debug("Unable to load 
ClusterRuleSet (org.apache.catalina.cluster.ClusterRuleSet), will try to load 
the HA cluster");
 }
 
 //NEW CLUSTER 2
@@ -52,17 +52,17 @@
 return 
loadRuleSet(prefix,"org.apache.catalina.ha.ClusterRuleSet",ClusterRuleSetFactory.class.getClassLoader());
 } catch ( Exception x ) {
 //display warning
-if ( log.isWarnEnabled() ) log.warn("Unable to load HA 
ClusterRuleSet, falling back on context classloader",x);
+if ( log.isDebugEnabled() ) log.debug("Unable to load HA 
ClusterRuleSet (org.apache.catalina.ha.ClusterRuleSet), falling back on context 
classloader");
 }
 //try to load it from the context class loader
 try {
 return 
loadRuleSet(prefix,"org.apache.catalina.ha.ClusterRuleSet",Thread.currentThread().getContextClassLoader());
 } catch ( Exception x ) {
 //display warning
-if ( log.isWarnEnabled() ) log.warn("Unable to load HA 
ClusterRuleSet, falling back on DefaultClusterRuleSet",x);
+if ( log.isDebugEnabled() ) log.debug("Unable to load HA 
ClusterRuleSet (org.apache.catalina.ha.ClusterRuleSet), falling back on 
DefaultClusterRuleSet");
 }
 
-
+log.info("Unable to find a cluster rule set in the classpath. Will 
load the default rule set.");
 return new DefaultClusterRuleSet(prefix);
 }
 



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

DO NOT REPLY [Bug 38795] - StandardContext doesn't always reset thread's contextClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38795





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 14:23 ---
I read with interest your report and wonder if some other infrequenct problems
that I've experienced in the past maybe related to this section of code.


Would it make sense to use code like:

try { filterStop(); } catch(Exception e) { e.printSomething(); }

try { listenerStop(); } catch(Exception e) { e.printSomething(); }

etc... the idea being that each invokation to web-application code (from TC
internal code) should not be able to upset TCs shutdown mechanism and should try
a best effort to do everything properly.  Then at the end of it all just cut
away the web-app and cleanup.

My suggestion above is making a huge presumption that filterStop() invokes all 
the active javax.servlet.Filter#destroy() filters under the context to shut them
down.  Looking briefly through that particular path I can't see any trapping of
web-app exceptions.

StandardContext#filterStop()
 ApplicationFilterConfig#release()
  javax.servlet.Filter#destroy()

In the absense of any mandated behaviour (from JSRs) I would think the
exceptions are best caught in ApplicationFilterConfig#release() so that other
filters within the same context get called (call it "best effort").  I dont
understand the org.apache.catalina.SecurityUtil stuff in the same place, maybe
there is other ways to invoke javax.servlet.Filter#destroy() that need the same
treatment.


Its very important that TCs internal accounting state can never be disrupted no
matter how badly a web-app behaves.  An audit of this code to wrap the whole
section with a suitable finally clause to ensure TCs internal state retains its
integrity makes perfect sense to me.  The two things together can only increase
robustness with minimal cost.


Possibily related bug reports discussing web-app generated Exceptions during
context shutdown:

Bug #37498

Bug #36250 => Comment #14
(http://issues.apache.org/bugzilla/show_bug.cgi?id=36250#c14)


-- 
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 38795] - StandardContext doesn't always reset thread's contextClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38795


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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 37498] - NPE in org.apache.catalina.core.ContainerBase.removeChild

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37498





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 15:26 ---
Created an attachment (id=17813)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17813&action=view)
Gracefully recover from Filter.destroy() web-app generated exceptions

Shoot from hip diff, based on listenerStop() logic but applied to
Filter.destroy().  Sorry I'm unable to build TC5 from SVN or the -src package.

I'm taking the thought here that I know I have active filters on my web-app and
the reason why it affects me is that when I renamed the directory I removed the
JVMs ability to find and load the Filter#destroy() function.

In any case this patch feels like the correct thing to do.


-- 
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 37356] - Tomcat does not invalidate sessions after session-timeout period has passed.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37356





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 15:51 ---
Has there been any update on this bug?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r382040 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: demos/ group/interceptors/ io/ mcast/

[fhanik]

Author: fhanik
Date: Wed Mar  1 06:54:35 2006
New Revision: 382040

URL: http://svn.apache.org/viewcvs?rev=382040&view=rev
Log:
Improved performance by reducing all the byte[] copy methods. The XByteBuffer 
can grow dynamically and utilizie its internal array for direct writes

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ClusterData.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/mcast/McastMember.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java?rev=382040&r1=382039&r2=382040&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 Wed Mar  1 06:54:35 2006
@@ -15,24 +15,16 @@
  */
 package org.apache.catalina.tribes.demos;
 
-import org.apache.catalina.tribes.Member;
-import org.apache.catalina.tribes.MembershipListener;
-import org.apache.catalina.tribes.ChannelListener;
 import java.io.Serializable;
-import org.apache.catalina.tribes.ManagedChannel;
-import java.io.Externalizable;
-import java.io.ObjectOutput;
-import java.io.IOException;
 import java.util.Random;
-import java.io.ObjectInput;
-import org.apache.catalina.tribes.io.XByteBuffer;
-import org.apache.catalina.tribes.tcp.ReplicationListener;
-import org.apache.catalina.tribes.group.GroupChannel;
-import org.apache.catalina.tribes.tcp.ReplicationTransmitter;
-import org.apache.catalina.tribes.mcast.McastService;
+
 import org.apache.catalina.tribes.ByteMessage;
-import org.apache.catalina.tribes.group.interceptors.GzipInterceptor;
 import org.apache.catalina.tribes.ChannelException;
+import org.apache.catalina.tribes.ChannelListener;
+import org.apache.catalina.tribes.ManagedChannel;
+import org.apache.catalina.tribes.Member;
+import org.apache.catalina.tribes.MembershipListener;
+import org.apache.catalina.tribes.io.XByteBuffer;
 
 
 /**
@@ -264,38 +256,39 @@
 }
 
 protected byte[] message = null;
-private int msgNr;
-
+protected int nr = -1;
 static {
 r.nextBytes(outdata);
+}
+
+public LoadMessage() {
 
 }
 
+public LoadMessage(int nr) {
+this.nr = nr;
+}
+
 public int getMsgNr() {
 return XByteBuffer.toInt(getMessage(),0);
 }
 
 public void setMsgNr(int nr) {
-byte[] data = XByteBuffer.toBytes(nr);
-System.arraycopy(data,0,getMessage(),0,4);
-setMessage(getMessage());
+XByteBuffer.toBytes(nr,getMessage(),0);
 }
 
 public byte[] getMessage() {
-byte[] data = new byte[size+4];
-XByteBuffer.toBytes(msgNr,data,0);
-if ( message != null ) {
-System.arraycopy(message, 0, data, 4, message.length);
-}else {
+if ( message == null ) {
+byte[] data = new byte[size+4];
+XByteBuffer.toBytes(nr,data,0);
 System.arraycopy(outdata, 0, data, 4, outdata.length);
+this.message = data;
 }
-return data;
+return message;
 }
 
 public void setMessage(byte[] data) {
-this.msgNr = XByteBuffer.toInt(data,0);
-this.message = new byte[data.length-4];
-System.arraycopy(data,4,message,0,message.length);
+this.message = data;
 }
 }
 

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java?rev=382040&r1=382039&r2=382040&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/

svn commit: r382061 - in /tomcat/container/tc5.5.x/modules/groupcom: etc/ src/share/org/apache/catalina/tribes/io/ src/share/org/apache/catalina/tribes/tcp/

[fhanik]

Author: fhanik
Date: Wed Mar  1 07:34:59 2006
New Revision: 382061

URL: http://svn.apache.org/viewcvs?rev=382061&view=rev
Log:
Modified the default rx and tx buf sizes, these make a huge difference in the 
speed of data transport

Modified:
tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/ReplicationListener.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/ReplicationTransmitter.java

Modified: tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml?rev=382061&r1=382060&r2=382061&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml Wed Mar  1 
07:34:59 2006
@@ -301,16 +301,16 @@
 tcpThreadCount="6"
 sendAck="true"
 synchronized="true"
-rxBufSize="4096"
-txBufSize="128"/>
+rxBufSize="43800"
+txBufSize="25188"/>
 
 
+rxBufSize="43800"
+txBufSize="25188"/>
 
 

svn commit: r382063 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java

[fhanik]

Author: fhanik
Date: Wed Mar  1 07:36:59 2006
New Revision: 382063

URL: http://svn.apache.org/viewcvs?rev=382063&view=rev
Log:
Change the default values to the speediest channel

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java?rev=382063&r1=382062&r2=382063&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 Wed Mar  1 07:36:59 2006
@@ -67,8 +67,8 @@
 String bind = "auto";
 int port = 4001;
 String mbind = null;
-boolean ack = true;
-boolean sync = true;
+boolean ack = false;
+boolean sync = false;
 boolean gzip = false;
 String sender = "pooled";
 int tcpseltimeout = 100;



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

Contexts and Wrappers in Catalina

[fcarrion]

Hi the list,

First sorry for my last post... It was not the right mailing list. At the 
end I solved my problem using an Arraylist and making this change :

Index: connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java
===
--- connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java 
(revision 382065)
+++ connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java 
(working copy)
@@ -945,7 +945,8 @@

 public static Object convert(String object, Class paramType) {
 Object result = null;
-if ("java.lang.String".equals(paramType.getName())) {
+if ("java.lang.String".equals(paramType.getName())
+|| "java.lang.Object".equals(paramType.getName())) {
 result = object;
 } else if ("java.lang.Integer".equals(paramType.getName())
 || "int".equals(paramType.getName())) {


It's quite useful. It permit to use the function add from a collection of 
objects on a text. Without this change, the digester can't convert the 
String object to an Object and that's why it can't call the add function. 
I'm not relly sure that I'm sending this patch on the right mailing 
list... Anyway I got an other doubt.

I don't understand why the Loader class (representing the classloader) is 
on the Wrapper class (representing a servlet) and not on the Context class 
(representing the web application) in Catalina. Can't it be different 
between two servlets for the same web application ?

Cheers

Fabien Carrion


-
La información transmitida mediante el presente correo es para la(s)
persona(s) cuya dirección aparece al calce, la información contenida es
estrictamente confidencial y para lectura exclusiva de la (s) persona
(s) mencionada(s) por lo que esta prohida la reproducción, distribución
o copia del presente. Si usted ha recibido este correo por error, favor
de contactar con el remitente y eliminarlo de todas las charolas de su
correo. The information transmitted by this e-mail is intended only for
the person or entity to which it is addressed and may contain
confidential and/or privileged material. If the reader of this message
is not the intended recipient, you are hereby notified that you have
received this message by error and that any review, dissemination,
distribution or copying of this message including any attachments is
strictly prohibited. If you received this by error, please contact the
sender and delete the information from any computer.

svn commit: r382068 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: demos/LoadTest.java io/ObjectReader.java

[fhanik]

Author: fhanik
Date: Wed Mar  1 08:05:24 2006
New Revision: 382068

URL: http://svn.apache.org/viewcvs?rev=382068&view=rev
Log:
The object reader buffer should be the same as the channel's receiver buffer to 
avoid having to grow the byte buffer
Added in the ability to control the size of the messages in the LoadTest

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ObjectReader.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java?rev=382068&r1=382067&r2=382068&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 Wed Mar  1 08:05:24 2006
@@ -41,6 +41,7 @@
  */
 public class LoadTest implements MembershipListener,ChannelListener, Runnable {
 protected static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory.getLog(LoadTest.class);
+public static int size = 1020;
 public static Object mutex = new Object();
 public boolean doRun = true;
 
@@ -240,7 +241,7 @@
 
 
 public static class LoadMessage extends ByteMessage implements 
Serializable  {
-public static int size = 1020;
+
 public static byte[] outdata = new byte[size];
 public static Random r = new Random(System.currentTimeMillis());
 public static int getMessageSize (LoadMessage msg) {
@@ -304,6 +305,7 @@
"[-stats statinterval]  \n\t\t"+
"[-pause nrofsecondstopausebetweensends]  \n\t\t"+
"[-threads numberofsenderthreads]  \n\t\t"+
+   "[-size messagesize]  \n\t\t"+
"[-break (halts execution on exception)]\n"+
"\tChannel options:"+
ChannelCreator.usage()+"\n\n"+
@@ -337,6 +339,9 @@
 } else if ("-stats".equals(args[i])) {
 stats = Integer.parseInt(args[++i]);
 System.out.println("Stats every "+stats+" message");
+} else if ("-size".equals(args[i])) {
+size = Integer.parseInt(args[++i])-4;
+System.out.println("Message size will be:"+(size+4)+" bytes");
 } else if ("-mode".equals(args[i])) {
 if ( "receive".equals(args[++i]) ) send = false;
 } else if ("-debug".equals(args[i])) {

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ObjectReader.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ObjectReader.java?rev=382068&r1=382067&r2=382068&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ObjectReader.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/ObjectReader.java
 Wed Mar  1 08:05:24 2006
@@ -19,6 +19,7 @@
 import java.nio.channels.Selector;
 import java.nio.channels.SocketChannel;
 import org.apache.catalina.tribes.ChannelMessage;
+import java.io.IOException;
 
 
 
@@ -32,11 +33,12 @@
  * for message encoding and decoding.
  *
  * @author Filip Hanik
- * @author Peter Rossbach
  * @version $Revision: 377484 $, $Date: 2006-02-13 15:00:05 -0600 (Mon, 13 Feb 
2006) $
  */
 public class ObjectReader {
 
+protected static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory.getLog(ObjectReader.class);
+
 private SocketChannel channel;
 
 private ListenCallback callback;
@@ -52,7 +54,13 @@
 public ObjectReader(SocketChannel channel, Selector selector, 
ListenCallback callback) {
 this.channel = channel;
 this.callback = callback;
-this.buffer = new XByteBuffer(true);
+try {
+this.buffer = new 
XByteBuffer(channel.socket().getReceiveBufferSize(), true);
+}catch ( IOException x ) {
+//unable to get buffer size
+log.warn("Unable to retrieve the socket channel receiver buffer 
size, setting to default 43800 bytes.");
+this.buffer = new XByteBuffer(43800,true);
+}
 }
 
 /**



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

svn commit: r382069 - /tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

[fhanik]

Author: fhanik
Date: Wed Mar  1 08:09:33 2006
New Revision: 382069

URL: http://svn.apache.org/viewcvs?rev=382069&view=rev
Log:
added in samples, to make this toolkit usable

Modified:
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: tomcat/container/tc5.5.x/modules/groupcom/to-do.txt
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=382069&r1=382068&r2=382069&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Wed Mar  1 08:09:33 2006
@@ -18,6 +18,8 @@
 9. CoordinatorInterceptor - manages the selection of a cluster coordinator
 10. Xa2PhaseCommitInterceptor - make sure the message doesn't reach the 
receiver unless all members got it
 
+11. Code a ReplicatedFileSystem example, package org.apache.catalina.tipis
+
 Tasks Completed
 ===
 1. True synchronized/asynchronized replication enabled using flags



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

Tomcat 6 source organisation part 2

[Remy Maucherat]

Hi,

Given the comments, I propose using a single repository with the 
following structure (based on our root "tomcat" repository):

- tc6.0.x/trunk:
  - src/share: all the relevant sources go there
  - webapps: all our current webapps, including the examples webapps 
(note: portions of the source of certain webapps could be included in 
the main source tree)

  - src/native: the current tcnative code
- tc6.0.x/branches
- tc6.0.x/tags

I suppose mod_jk will stay where it is right now. I was also thinking 
about merging commons-modeler in the tomcat.util packages, retaining the 
functionality that we use (AFAIK, there are commons-modeler users out 
there, I saw at least a couple articles over the years).


Any other ideas ?

Rémy

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

Re: Tomcat 6 source organisation part 2

[Yoav Shapira]

I've been meaning to ask this for years now: what's the purpose of the
"share" directory under src?  We share all our source by definition,
so it just seems like an extra layer...

Yoav

On 3/1/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Given the comments, I propose using a single repository with the
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>- src/share: all the relevant sources go there
>- webapps: all our current webapps, including the examples webapps
> (note: portions of the source of certain webapps could be included in
> the main source tree)
>- src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
>
> I suppose mod_jk will stay where it is right now. I was also thinking
> about merging commons-modeler in the tomcat.util packages, retaining the
> functionality that we use (AFAIK, there are commons-modeler users out
> there, I saw at least a couple articles over the years).
>
> Any other ideas ?
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

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

Re: Tomcat 6 source organisation part 2

[Remy Maucherat]

Yoav Shapira wrote:

I've been meaning to ask this for years now: what's the purpose of the
"share" directory under src?  We share all our source by definition,
so it just seems like an extra layer...


I have no idea what "share" means either ;)

So let's make it:
- tc6.0.x/trunk:
  - src: all the relevant sources go there
  - webapps: all our current webapps, including the examples webapps
  - resources: misc resources, such as configuration files 
(server.xml), readmes, etc


Rémy

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

Re: Tomcat 6 source organisation part 2

[Yoav Shapira]

> So let's make it:
> - tc6.0.x/trunk:
>- src: all the relevant sources go there
>- webapps: all our current webapps, including the examples webapps
>- resources: misc resources, such as configuration files
> (server.xml), readmes, etc

OK.

One other thing: can we put docs under trunk instead of under webapps?
 We can still package a docs webapp into the same place on the distro
as now, I like that part.  But for people navigating the repository or
downloading our source distros, it's not obvious to find docs under
webapps...

Yoav

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

Re: Tomcat 6 source organisation part 2

[Remy Maucherat]

Yoav Shapira wrote:

So let's make it:
- tc6.0.x/trunk:
   - src: all the relevant sources go there
   - webapps: all our current webapps, including the examples webapps
   - resources: misc resources, such as configuration files
(server.xml), readmes, etc


OK.

One other thing: can we put docs under trunk instead of under webapps?
 We can still package a docs webapp into the same place on the distro
as now, I like that part.  But for people navigating the repository or
downloading our source distros, it's not obvious to find docs under
webapps...


That's a good idea, I think.

Rémy

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

Re: Tomcat 6 source organisation part 2

[Ian Darwin]

So let's make it:
- tc6.0.x/trunk:
  - src: all the relevant sources go there
  - webapps: all our current webapps, including the examples webapps
  - resources: misc resources, such as configuration files 
(server.xml), readmes, etc

+1

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

Re: Tomcat 6 source organisation part 2

[Costin Manolache]

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res

and the docs webapp at top level, as Yoav suggested.

"share" has a long history - I think JDK is organized this way, with
separate dirs for windows, linux, etc.

I assume native would host apr ? Or both apr and jk ? And maybe the
win installer ?

Costin



On 3/1/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Given the comments, I propose using a single repository with the
> following structure (based on our root "tomcat" repository):
> - tc6.0.x/trunk:
>- src/share: all the relevant sources go there
>- webapps: all our current webapps, including the examples webapps
> (note: portions of the source of certain webapps could be included in
> the main source tree)
>- src/native: the current tcnative code
> - tc6.0.x/branches
> - tc6.0.x/tags
>
> I suppose mod_jk will stay where it is right now. I was also thinking
> about merging commons-modeler in the tomcat.util packages, retaining the
> functionality that we use (AFAIK, there are commons-modeler users out
> there, I saw at least a couple articles over the years).
>
> Any other ideas ?
>
> 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]

Re: Tomcat 6 source organisation part 2

[Remy Maucherat]

Costin Manolache wrote:

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res


There's a native folder too, and most likely there should be a test 
folder too.



and the docs webapp at top level, as Yoav suggested.

"share" has a long history - I think JDK is organized this way, with
separate dirs for windows, linux, etc.

I assume native would host apr ? Or both apr and jk ? And maybe the
win installer ?


Yes, native will host APR. For mod_jk, I don't know, it's really a 
separate project.


Rémy

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

Re: Tomcat 6 source organisation part 2

[Yoav Shapira]

Hola,

> "share" has a long history - I think JDK is organized this way, with
> separate dirs for windows, linux, etc.

Maybe the JDK was organized that way in the past, but doesn't seem to
be that way any more.  Anyways, I don't think it has a purpose
currently.  If something we're not aware of comes screaming at us, we
can add it back in later, but I'm in favor of removing unneeded layers
and directories where possible.

> I assume native would host apr ? Or both apr and jk ? And maybe the
> win installer ?

Yes, yes, and yes IMHO.

Yoav

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

Re: Tomcat 6 source organisation part 2

[Mario Ivankovits]

Hi!
>> tc6(.0.x ?)/trunk/java
>> tc6/trunk/native
>> tc6/trunk/webapps
>> tc6/trunk/res
Isn't it widely used to have:

src/java
src/tests
src/native

Ciao,
Mario


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

Re: Tomcat 6 source organisation part 2

[Costin Manolache]

On 3/1/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
> >> tc6(.0.x ?)/trunk/java
> >> tc6/trunk/native
> >> tc6/trunk/webapps
> >> tc6/trunk/res
> Isn't it widely used to have:
>
> src/java
> src/tests
> src/native

Widely used doesn't mean it's good in all cases :-)

For most simple native projects, the source was under src/ - with
Makefile at top level, and also an include/, doc/ folder.
This got cut&pasted probably to src/java, src/test, etc

The extra src/ is useless in our code organization.

Costin

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

Re: Tomcat 6 source organisation part 2

[Mario Ivankovits]

Hi!Costin Manolache schrieb:
> The extra src/ is useless in our code organization.
>   
Sure, but it didn't cost anything and it makes clear where to look if
one searches the sources.
Its simply one nice little place for all the great code.

But ok, its my personal preference :-)

---
Mario


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

svn commit: r382141 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp: AsyncSocketSender.java DataSenders.properties

[fhanik]

Author: fhanik
Date: Wed Mar  1 12:02:14 2006
New Revision: 382141

URL: http://svn.apache.org/viewcvs?rev=382141&view=rev
Log:
Removed the async socket sender, this is obsolete. We are keeping the FastAsync 
for java.io support on platforms where NIO is troublesome

Removed:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/AsyncSocketSender.java
Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSenders.properties

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSenders.properties
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSenders.properties?rev=382141&r1=382140&r2=382141&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSenders.properties
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSenders.properties
 Wed Mar  1 12:02:14 2006
@@ -1,4 +1,3 @@
 fastasyncqueue=org.apache.catalina.tribes.tcp.FastAsyncSocketSender
-asynchronous=org.apache.catalina.tribes.tcp.AsyncSocketSender
 synchronous=org.apache.catalina.tribes.tcp.SocketSender
 pooled=org.apache.catalina.tribes.tcp.PooledSocketSender



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

svn commit: r382188 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: io/ tcp/

[fhanik]

Author: fhanik
Date: Wed Mar  1 15:04:11 2006
New Revision: 382188

URL: http://svn.apache.org/viewcvs?rev=382188&view=rev
Log:
Rebuilt the ACK message, it is not a complete package according to our 
replication TCP protocol.
This way, we can use ACK messages with our NIO senders as well.
Added in the skeleton of the NioSender and the parallel NioSender
The NioSender will be able to be used in async mode as well as in sync mode 
using the ParallelNioSender



Added:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/NioSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/ParallelNioSender.java
Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/Constants.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/IDataSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSocketSender.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/TcpReplicationThread.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java?rev=382188&r1=382187&r2=382188&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
 Wed Mar  1 15:04:11 2006
@@ -321,7 +321,10 @@
  * 
  */
 public static byte[] createDataPackage(ClusterData cdata) throws 
java.io.IOException {
-byte[] data = cdata.getDataPackage();
+return createDataPackage(cdata.getDataPackage());
+}
+
+public static byte[] createDataPackage(byte[] data) {
 int length = 
 START_DATA.length + //header length
 4 + //data length indicator

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/Constants.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/Constants.java?rev=382188&r1=382187&r2=382188&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/Constants.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/Constants.java
 Wed Mar  1 15:04:11 2006
@@ -17,6 +17,8 @@
 
 package org.apache.catalina.tribes.tcp;
 
+import org.apache.catalina.tribes.io.XByteBuffer;
+
 /**
  * Manifest constants for the org.apache.catalina.tribes.tcp
  * package.
@@ -28,5 +30,8 @@
 public class Constants {
 
 public static final String Package = "org.apache.catalina.tribes.tcp";
+
+public static final byte[] ACK_DATA = new byte[] {6, 2, 3};
+public static final byte[] ACK_COMMAND = 
XByteBuffer.createDataPackage(ACK_DATA);
 
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java?rev=382188&r1=382187&r2=382188&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
 Wed Mar  1 15:04:11 2006
@@ -221,6 +221,8 @@
  * We are only sending acks
  */
 protected int txBufSize = 25188;
+
+protected XByteBuffer ackbuf = new 
XByteBuffer(Constants.ACK_COMMAND.length,true);
 
 
 // - 
Constructor
@@ -530,7 +532,7 @@
 /**
  * @return Returns the waitForAck.
  */
-public boolean isWaitForAck() {
+public boolean getWaitForAck() {
 return waitForAck;
 }
 
@@ -709,7 +711,7 @@
return ;
try {
 createSocket();
-if (isWaitForAck()) socket.setSoTimeout((int) ackTimeout);
+if (getWaitForAck()) socket.setSoTimeout((int) ackTimeout);
 isSocketConnected = true;
 socketOpenCounter++;
 this.keepAliveCount = 0;
@@ -888,7 +890,7 @@
 try {
 socketout.write(XByteBuffer.createDataPackage((ClusterData)data))

[Proposal] Small manager improvement

[Rainer Jung]

I have a small patch that I think improves the session listing in the 
manager webapp:


The doc says


Session Statistics

Display the default session timeout for a web application, and the 
number of currently active sessions that fall within ten-minute ranges 
of their actual timeout times. For example, after restarting Tomcat and 
then executing one of the JSP samples in the /examples web app, you 
might get something like this:



Actually that's not true and I have the impression the code does 
something not very useful which we can very easily tranform to something 
really useful:


At the moment the code calculates a histogramm of the different 
maxInactiveInterval values for all sessions of a context. Now most 
contexts I know, work with a fixed maxInactiveInterval for all sessions 
  in the context. As a result, all of the sessions are in the same 
histogram class and instead of the possible up to 60 lines of result 
histogram, the code always simply produces a single line showing again 
the total number of sessions - which is already included on the same 
page further down. So no real sense in that.


With a few lines of change we could easily list a histogram of how far 
sessions are away from their idle timeout. That seems to be a much more 
interesting information for monitoring, e.g. it enables to make a well 
informed decision on shrinking or sizing up session timeouts. This would 
also be in better alignment with the documntation of manger. This is 
sugestion 1a.


What I would even like better is instead printing a hitogramm of the 
actual idle time of the sessions. I think for most admins this is a more 
easily understandable metric.


So suggestion 1b: change sessions-function in manager webapp to show a 
histogram of session idle distribution instead of maxActiveTimeout 
distribution.


Suggestion 2: another small fix would allow a manager user to 
prematurely expire all sessions which are idle for a longer time than 
the amount of minutes she types into a text field (before she presses 
the new expire button.


I have a use case for this: some applications work with long running 
sessions (employee applications) that might have relatively big 
sessions. These applications typically have a timeout of several hours 
to allow resumption of work after lunch breaks, meeting etc. Often such 
apps depend on other external applications. When those have a bad day, 
the users of the web app might experience very long response times. So 
they decide to try a new login to the web app. From that point in time 
their old sessions are no longer used, but still stay in memory for 
several more hours. As soon as the external app has another hickup, 
another round of sessions gets lost by the same user behaviour. A well 
informed admin could now react to such a non-standard situation by 
deciding to expire all sessions which are idle longer than the amount of 
minutes she decides, e.g. one hour.


I did all that for TC5 and for 5.5 it's mostly the same. If their is 
interest in it, I would provide patches, including doc patches. I still 
would need spanish and japanese translations for "expire". :)


Feedback is highly welcome.


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

DO NOT REPLY [Bug 38826] New: - spec violation?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38826

   Summary: spec violation?
   Product: Tomcat 5
   Version: 5.5.12
  Platform: All
OS/Version: Windows 2000
Status: NEW
  Severity: critical
  Priority: P1
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi all!

In Servlet spec, Filters section (SRV.6) I didnt found any
mentions that error-handling process should bypass filters.

My problem is:
I have lot of heavy-working jsps in my app (yes I know bad design etc but at the
moment there is no way to rewrite it). Sometimes, when one of jsps generated
200K of output the app-level error is encountered and is thrown to web
container. It should return the error-page + status-code of 500 but such a big
output in front of it leaded to "early" flush (status code 200 + part of html
response was already sent to client).

Such big amount of output data should be buffered to prevent "early" commit. I
created a bufferer-filter for this purposes. 
But when I finally got an exception and execution is passed to error page I see
that error-page don't use HttpServletResponseWrapper I defined in my filter.
Instead of it error-page works with unwrapped object
"org.apache.catalina.connector.ResponseFacade" and obviously bypass my filtering
logic.

-- 
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 38826] - spec violation?

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38826


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-03-02 02:51 ---

The original unwrapped request and response objects created by the container
are passed to the servlet or 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]

Re: Tomcat 6 source organisation part 2

[Keith Wannamaker]

We should keep the java sources separate from the native sources by one 
more level under src/, aka the share directory (or something- I always 
thought it referenced "share"d across platforms as simply opposed to 
specific "native" code).


Keith

Remy Maucherat wrote:

Yoav Shapira wrote:

I've been meaning to ask this for years now: what's the purpose of the
"share" directory under src?  We share all our source by definition,
so it just seems like an extra layer...


I have no idea what "share" means either ;)

So let's make it:
- tc6.0.x/trunk:
  - src: all the relevant sources go there
  - webapps: all our current webapps, including the examples webapps
  - resources: misc resources, such as configuration files (server.xml), 
readmes, etc


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]

Re: Tomcat 6 source organisation part 2

[Keith Wannamaker]

Yes, this will do nicely.

Keith

Costin Manolache wrote:

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res




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

Re: Tomcat 6 source organisation part 2

[Filip Hanik - Dev Lists]

are all the conf files, startup scripts etc in one place? res?
I was thinking that we still have a src directory, and subdirectories 
under that.


trunk/src/java
trunk/src/native
trunk/webapps

etc

Keith Wannamaker wrote:

Yes, this will do nicely.

Keith

Costin Manolache wrote:

We still need separate dirs for native code and java I think.

What about:

tc6(.0.x ?)/trunk/java
tc6/trunk/native
tc6/trunk/webapps
tc6/trunk/res




-
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]