You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Yaroslav Sokolov <ya...@gmail.com> on 2006/03/03 13:36:35 UTC
What's about unloading policy of jsp-servlets ?
Hi,
I have found, that once loaded jsp-servlets are never unloaded.
To test I just configured tomcat to process *.html files by JspServlet
and then traversed jdk documentation. The result was not very exciting -
after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
and started not to work...
So maybe it would be not a bad idea to try to keep in memeory just some fixed
number of jsp-servlets ?
I have written a sample implementation of such a policy, but it is not very elegant
as internal structure containing jsp-servlets, it seems, was not designed for such actions...
Regards,
Yarick.
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
I think that is so as minimum because of after applying the patch it can be retrieved
nearely all the jdk documentation (except of some huge files ( > 2M ) ).
One more thing - average size of *.class file in the specified sample is 30-50K.
Regards,
Yarick.
Yoav Shapira wrote:
> What makes you think your OOME has to do with the number of JspServlet
> instances? Run a profiler, you might be surprised.
>
> Yoav
>
> On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>
>>Hi,
>>
>>I have found, that once loaded jsp-servlets are never unloaded.
>>
>>To test I just configured tomcat to process *.html files by JspServlet
>>and then traversed jdk documentation. The result was not very exciting -
>>after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
>>and started not to work...
>>
>>So maybe it would be not a bad idea to try to keep in memeory just some fixed
>>number of jsp-servlets ?
>>
>>I have written a sample implementation of such a policy, but it is not very elegant
>>as internal structure containing jsp-servlets, it seems, was not designed for such actions...
>>
>>Regards,
>>Yarick.
[skipped]
> --
> Yoav Shapira
> Senior Architect
> Nimalex LLC
> 1 Mifflin Place, Suite 310
> Cambridge, MA, USA
> yoavs@computer.org / www.yoavshapira.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yoav Shapira <yo...@apache.org>.
What makes you think your OOME has to do with the number of JspServlet
instances? Run a profiler, you might be surprised.
Yoav
On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> Hi,
>
> I have found, that once loaded jsp-servlets are never unloaded.
>
> To test I just configured tomcat to process *.html files by JspServlet
> and then traversed jdk documentation. The result was not very exciting -
> after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
> and started not to work...
>
> So maybe it would be not a bad idea to try to keep in memeory just some fixed
> number of jsp-servlets ?
>
> I have written a sample implementation of such a policy, but it is not very elegant
> as internal structure containing jsp-servlets, it seems, was not designed for such actions...
>
> Regards,
> Yarick.
>
>
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-02-21 13:26:44.984221000 +0100
> @@ -174,6 +174,17 @@
> */
> private boolean xpoweredBy;
>
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + private int maxLoadedJsps = 20;
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + private int jspUnloadTestInterval = 4;
> +
> public String getProperty(String name ) {
> return settings.getProperty( name );
> }
> @@ -355,6 +366,14 @@
> return null;
> }
>
> + public int getMaxLoadedJsps() {
> + return maxLoadedJsps;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return jspUnloadTestInterval;
> + }
> +
> /**
> * Create an EmbeddedServletOptions object using data available from
> * ServletConfig and ServletContext.
> @@ -636,6 +655,40 @@
> }
> }
>
> + String maxLoadedJsps = config.getInitParameter("maxLoadedJsps");
> + if (maxLoadedJsps != null) {
> + try {
> + this.maxLoadedJsps = Integer.parseInt(maxLoadedJsps);
> + if (this.maxLoadedJsps <= 0) {
> + this.maxLoadedJsps = 20;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + }
> +
> + String jspUnloadTestInterval = config.getInitParameter("jspUnloadTestInterval");
> + if (jspUnloadTestInterval != null) {
> + try {
> + this.jspUnloadTestInterval = Integer.parseInt(jspUnloadTestInterval);
> + if (this.jspUnloadTestInterval <= 0) {
> + this.jspUnloadTestInterval = 4;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + }
> +
> // Setup the global Tag Libraries location cache for this
> // web-application.
> tldLocationsCache = new TldLocationsCache(context);
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-02-21 13:27:07.568387400 +0100
> @@ -448,6 +448,14 @@
> return cache;
> }
>
> + public int getMaxLoadedJsps() {
> + return 0;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return 0;
> + }
> +
> /**
> * Background compilation check intervals in seconds
> */
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-02-21 13:27:24.210173000 +0100
> @@ -184,5 +184,16 @@
> * @return the Map(String uri, TreeNode tld) instance.
> */
> public Map getCache();
> +
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + public int getMaxLoadedJsps();
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + public int getJspUnloadTestInterval();
>
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-02-21 13:16:29.004201800 +0100
> @@ -25,10 +25,7 @@
> import java.security.PermissionCollection;
> import java.security.Policy;
> import java.security.cert.Certificate;
> -import java.util.Collections;
> -import java.util.HashMap;
> -import java.util.Iterator;
> -import java.util.Map;
> +import java.util.*; // yarick: java.util.HashMap -> java.util.*
>
> import javax.servlet.ServletContext;
> import javax.servlet.jsp.JspFactory;
> @@ -148,8 +145,8 @@
> /**
> * Maps JSP pages to their JspServletWrapper's
> */
> - private Map jsps = Collections.synchronizedMap( new HashMap());
> -
> + private Map jsps = Collections.synchronizedMap( new LinkedHashMap( 16, 0.75f, true ) ); // yarick: HashMap -> LinkedHashMap
> +
>
> /**
> * The background thread.
> @@ -192,6 +189,21 @@
> }
>
> /**
> + * Get an already existing JspServletWrapper and increases services count.
> + *
> + * @param jspUri JSP URI
> + * @return JspServletWrapper for JSP
> + */
> + public JspServletWrapper getWrapperAndIncService(String jspUri) {
> + JspServletWrapper jswr;
> + synchronized( jsps ) {
> + jswr = (JspServletWrapper) jsps.get(jspUri);
> + if( null != jswr ) jswr.incService();
> + }
> + return jswr;
> + }
> +
> + /**
> * Remove a JspServletWrapper.
> *
> * @param jspUri JSP URI of JspServletWrapper to remove
> @@ -521,4 +533,28 @@
>
> }
>
> +// { inserted by Yarick
> +
> + /** must be called from synchronized by {@link org.apache.jasper.servlet.JspServlet} context */
> + public JspServletWrapper getJspForUnload()
> + {
> + int MAX_UNLOADABLE_JSPS = 10;
> + if( jsps.size() > MAX_UNLOADABLE_JSPS ) {
> + JspServletWrapper jsw = null;
> + synchronized( jsps ) {
> + Iterator it = jsps.entrySet().iterator();
> + for( int rest_jsps=jsps.size(); rest_jsps > MAX_UNLOADABLE_JSPS && it.hasNext(); --rest_jsps ) {
> + jsw = (JspServletWrapper) ( (Map.Entry) it.next() ).getValue();
> + if( jsw.getExecutingServicesCount() == 0 && !jsw.isTagFile() ) {
> + it.remove();
> + return jsw;
> + }
> + }
> + }
> + }
> + return null;
> + }
> +
> +// } inserted by Yarick
> +
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-02-21 13:37:08.060784200 +0100
> @@ -17,8 +17,9 @@
> package org.apache.jasper.servlet;
>
> import java.io.IOException;
> +import java.io.File;
> import java.lang.reflect.Constructor;
> -import java.util.Enumeration;
> +import java.util.*;
>
> import javax.servlet.ServletConfig;
> import javax.servlet.ServletContext;
> @@ -97,8 +98,10 @@
> options = new EmbeddedServletOptions(config, context);
> }
> rctxt = new JspRuntimeContext(context, options);
> -
> - if (log.isDebugEnabled()) {
> +
> + startUnloadJspsThread(); // inserted by yarick
> +
> + if (log.isDebugEnabled()) {
> log.debug(Localizer.getMessage("jsp.message.scratch.dir.is",
> options.getScratchDir().toString()));
> log.debug(Localizer.getMessage("jsp.message.dont.modify.servlets"));
> @@ -278,7 +281,7 @@
> if (log.isDebugEnabled()) {
> log.debug("JspServlet.destroy()");
> }
> -
> + stopUnloadJspsThread(); // inserted by yarick
> rctxt.destroy();
> }
>
> @@ -290,29 +293,99 @@
> Throwable exception, boolean precompile)
> throws ServletException, IOException {
>
> - JspServletWrapper wrapper =
> - (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - synchronized(this) {
> - wrapper = (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - // Check if the requested JSP page exists, to avoid
> - // creating unnecessary directories and files.
> - if (null == context.getResource(jspUri)) {
> - response.sendError(HttpServletResponse.SC_NOT_FOUND,
> - jspUri);
> - return;
> + JspServletWrapper wrapper = null;
> + try {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if( null == wrapper )
> + synchronized(this) {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if (wrapper == null) {
> + // Check if the requested JSP page exists, to avoid
> + // creating unnecessary directories and files.
> + if (null == context.getResource(jspUri)) {
> + response.sendError(HttpServletResponse.SC_NOT_FOUND,
> + jspUri);
> + return;
> + }
> + boolean isErrorPage = exception != null;
> + wrapper = new JspServletWrapper(config, options, jspUri,
> + isErrorPage, rctxt);
> + rctxt.addWrapper(jspUri,wrapper);
> }
> - boolean isErrorPage = exception != null;
> - wrapper = new JspServletWrapper(config, options, jspUri,
> - isErrorPage, rctxt);
> - rctxt.addWrapper(jspUri,wrapper);
> + wrapper.incService();
> + }
> +
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + String _destroyingUri = destroyingUri;
> + if( wrapper.getJspUri().equals( _destroyingUri ) )
> + synchronized( _destroyingUri ) {
> + if( _destroyingUri == destroyingUri )
> + _destroyingUri.wait();
> }
> +
> + wrapper.service(request, response, precompile);
> +
> + } catch( InterruptedException ignore ) {}
> + finally { // inserted by yarick
> + synchronized(this) {
> + if( null != wrapper ) wrapper.decService();
> }
> - }
> + }
> + }
>
> - wrapper.service(request, response, precompile);
> +// { inserted by yarick
> + private Thread unloadThread;
> + private String destroyingUri;
>
> + protected void startUnloadJspsThread() {
> + String pathToWebApp = context.getRealPath("/");
> + if( pathToWebApp.endsWith( File.separator ) )
> + pathToWebApp = pathToWebApp.substring( 0, pathToWebApp.length()-1 );
> +
> + unloadThread = new Thread( "jspUnloader ["+pathToWebApp.substring( pathToWebApp.lastIndexOf( File.separatorChar ) )+( "/" )+"]" ) {
> + public void run() { runUnloadJspsThread(); }
> + };
> + unloadThread.setDaemon( true );
> + unloadThread.start();
> + }
> +
> + protected void stopUnloadJspsThread() {
> + if( null != unloadThread ) {
> + unloadThread.interrupt();
> + try { unloadThread.join( 10 * 1000 ); } // wait maximum 10 seconds
> + catch( InterruptedException ignore ) {}
> + unloadThread = null;
> + }
> }
>
> + protected void runUnloadJspsThread() {
> + try {
> + while( !Thread.currentThread().isInterrupted() ) {
> + JspServletWrapper jsw;
> + synchronized( this ) {
> + jsw = rctxt.getJspForUnload();
> + if( null != jsw ) destroyingUri = new String( jsw.getJspUri() );
> + }
> +
> + if( null == jsw )
> + Thread.sleep( options.getJspUnloadTestInterval() * 1000 );
> + else
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + synchronized( destroyingUri ) {
> + try {
> + jsw.destroy();
> + } finally {
> + String prev_destroyingUri = destroyingUri;
> + destroyingUri = null;
> + prev_destroyingUri.notifyAll();
> + }
> + }
> + }
> + } catch( InterruptedException exit ) {}
> + }
> +// } inserted by yarick
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-02-21 13:24:43.999843400 +0100
> @@ -86,6 +86,7 @@
> private JasperException compileException;
> private long servletClassLastModifiedTime;
> private long lastModificationTest = 0L;
> + private int executingServicesCount; // yarick
>
> /*
> * JspServletWrapper for JSP pages.
> @@ -397,6 +398,10 @@
> }
> }
>
> + synchronized public void incService() { ++executingServicesCount; } // yarick: inserted accounting of 'service'
> + synchronized public void decService() { --executingServicesCount; } // yarick: inserted accounting of 'service'
> + String getJspUri() { return jspUri; } // yarick: inserted
> +
> public void destroy() {
> if (theServlet != null) {
> theServlet.destroy();
> @@ -416,6 +421,9 @@
> this.lastModificationTest = lastModificationTest;
> }
>
> + /** @return Returns count of currently executing of method {@link #service} */
> + public int getExecutingServicesCount() { return executingServicesCount; } // yarick
> +
> /**
> * <p>Attempts to construct a JasperException that contains helpful information
> * about what went wrong. Uses the JSP compiler system to translate the line
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> This byte based solution doesn't seem useful to me: for example in
>> JBoss there is support for finer grain replication, and it doesn't use
>> byte arrays.
> I don't think data transfers get more fine grained than a single byte :)
Of course, but using byte[] as a type anywhere is bad, I think (not
recyclable, needs byte copying, etc). Using an indirection like
ByteBuffer or ByteChunk is the minimum.
> (don't think you can write a bit to a stream)
> If you think of AOP and just transfer data diffs, they still get
> transferred as bytes. using byte[] arrays lets the container control the
> serialization. this way, you can have as fine or coarse grained as you
> want. The API shouldn't impose what serialization mechanism is being
> used, that is why it is byte[]
Yes, I was thinking AOP or similar mechanism. Of course, at some point,
it will get to bytes to be transferred to another node, but it's a
feature and format of the transport since the StandardSession will have
no idea how to apply it. If (as I understand it) it's just a callback
which is meant to be implemented by classes which extend
StandardSession, then IMO it is too strict to impose dirty/diff logic. I
still prefer using classes which extend StandardSession and StandardManager.
>> I'd like to have more explanation why this new APIs are a great idea,
>> and how they will be used.
> of course, very large size clusters, with linear increase in network
> chatter, not exponential like today.
> more to come...
I have trouble seeing the relation between the proposed API additions to
org.apache.catalina.Session and the capability of having a large cluster ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 1. Requirements to be implemented by the Session.java API
>> bool isDirty - (has the session changed in this request)
>> bool isDiffable - is the session able provide a diff
>> byte[] getSessionData() - returns the whole session
>> byte[] getSessionDiff() - optional, see isDiffable, resets the diff
>> data
>> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
>> changes from another node
>>
>> 2. Requirements to be implemented by the SessionManager.java API
>> void setSessionMap(HashMap map) - makes the map implementation
>> pluggable
>
> This byte based solution doesn't seem useful to me: for example in
> JBoss there is support for finer grain replication, and it doesn't use
> byte arrays.
I don't think data transfers get more fine grained than a single byte :)
(don't think you can write a bit to a stream)
If you think of AOP and just transfer data diffs, they still get
transferred as bytes. using byte[] arrays lets the container control the
serialization. this way, you can have as fine or coarse grained as you
want. The API shouldn't impose what serialization mechanism is being
used, that is why it is byte[]
>
> I'd like to have more explanation why this new APIs are a great idea,
> and how they will be used.
of course, very large size clusters, with linear increase in network
chatter, not exponential like today.
more to come...
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
> changes from another node
>
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation pluggable
This byte based solution doesn't seem useful to me: for example in JBoss
there is support for finer grain replication, and it doesn't use byte
arrays.
I'd like to have more explanation why this new APIs are a great idea,
and how they will be used.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
thanks for the comments, replies inlined.
> You may be able to simply judge isDiffable for yourself without that
> method by checking that getSessionDiff() != null.
>
yes, that is true. I put in isDiffable, the semantics would be a little
easier to understand, than using a return value of null for logic.
>> 2. Requirements to be implemented by the SessionManager.java API
>> void setSessionMap(HashMap map) - makes the map implementation pluggable
>>
>
> The argument there should be of type Map, not HashMap, to allow other
> Map implementations.
>
Yes, good catch!!
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
A couple of small comments:
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
> changes from another node
You may be able to simply judge isDiffable for yourself without that
method by checking that getSessionDiff() != null.
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation pluggable
The argument there should be of type Map, not HashMap, to allow other
Map implementations.
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Andy Piper wrote:
> Hi Filip
>
> At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
>> 3. And the key to this, is that we will have an implementation of a
>> LazyReplicatedHashMap
>> The key object in this map is the session Id.
>> The map entry object is an object that looks like this
>> ReplicatedEntry {
>> string id;//sessionid
>> bool isPrimary; //does this node hold the data
>> bool isBackup; //does this node hold backup data
>> Session session; //not null values for primary and backup nodes
>> Member primary; //information about the primary node
>> Member backup; //information about the backup node
>> }
>
> Burning a primary-secondary scheme into the API seems a little less
> general. I think you should assume there can be N backups, where N is
> usually 1. How do you handle locking with this API?
we already have an all-to-all implementation, this is just another
implementation. but it is true, maybe there should be more than one
backup, I'll start with one, and move to more than one if needed. In
terms of locking, none planned, to much overhead.
correctness can be achieved within the session itself, ie if it is
getting serialized, it would need to lock itself and then reset its
state for the next diff. sessions today have access counters, which
means that we can also periodically solicit sessions that are not being
accessed at the time, and not worry about the locks at all.
>
>> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>>
>> So all the nodes will have the a sessionId,ReplicatedEntry
>> combinations in their session map. But only two nodes will have the
>> actual data.
>> This solution is for sticky LB only, but when failover happens, the
>> LB can pick any node as each node knows where to get the data.
>> The newly selected node, will keep the backup node or select a new
>> one, and do a publish to the entire cluster of the locations.
>
> Doesn't this mean you have to publish to the whole cluster at session
> creation? This will eventually limit scalability IMO.
as mentioned earlier, for very large clusters, we can use a Cookie to
store the backup location, this is the solution to your concern about
broadcasting the map each time. although, other challenges arise with
this. but I plan on having both solutions.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Andy Piper <an...@bea.com>.
Hi Filip
At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
>3. And the key to this, is that we will have an implementation of a
>LazyReplicatedHashMap
> The key object in this map is the session Id.
> The map entry object is an object that looks like this
> ReplicatedEntry {
> string id;//sessionid
> bool isPrimary; //does this node hold the data
> bool isBackup; //does this node hold backup data
> Session session; //not null values for primary and backup nodes
> Member primary; //information about the primary node
> Member backup; //information about the backup node
> }
Burning a primary-secondary scheme into the API seems a little less
general. I think you should assume there can be N backups, where N is
usually 1. How do you handle locking with this API?
> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>
>So all the nodes will have the a sessionId,ReplicatedEntry
>combinations in their session map. But only two nodes will have the
>actual data.
>This solution is for sticky LB only, but when failover happens, the
>LB can pick any node as each node knows where to get the data.
>The newly selected node, will keep the backup node or select a new
>one, and do a publish to the entire cluster of the locations.
Doesn't this mean you have to publish to the whole cluster at session
creation? This will eventually limit scalability IMO.
andy
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
you can use a stupid one here too. just make sure it is sticky.
Tino Schwarze wrote:
> Hi Filip,
>
> On Fri, Mar 03, 2006 at 10:44:21AM -0600, Filip Hanik - Dev Lists wrote:
>
>> I wrote together a little idea (also emailed to geronimo-dev for
>> feedback) on how the next generation of session replication should be done.
>> Today's replication is an all-to-all replication, and within that realm,
>> its pretty poor. It creates way to much network traffic as each request
>> results in X number of network transmits (where X is the number of nodes
>> in the cluster/domain).
>>
> [...]
>
> The drawback of your approach is that you still need an intelligent
> loadbalancer in front of the cluster. When using all-to-all replication
> you can use a stupid one, which simply schedules requests round-robin.
>
> Bye,
>
> Tino.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Tino Schwarze <ti...@tisc.de>.
Hi Filip,
On Fri, Mar 03, 2006 at 10:44:21AM -0600, Filip Hanik - Dev Lists wrote:
> I wrote together a little idea (also emailed to geronimo-dev for
> feedback) on how the next generation of session replication should be done.
> Today's replication is an all-to-all replication, and within that realm,
> its pretty poor. It creates way to much network traffic as each request
> results in X number of network transmits (where X is the number of nodes
> in the cluster/domain).
[...]
The drawback of your approach is that you still need an intelligent
loadbalancer in front of the cluster. When using all-to-all replication
you can use a stupid one, which simply schedules requests round-robin.
Bye,
Tino.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
for very large clusters, you use the same mechanism, except, instead of
distributing the entire session map, the backup node info is stored in a
cookie.
Filip
> If we would store the result-set (list of already created beans) in
> the session, we'd have to store them twice, once in the "cache" and
> once in request for presentation. However, a pluggable diff object
> would be great!
>
how you store it, once or twice is up to you, and how you code your app.
if you are storing it twice then that is a flaw in your programming, not
in tomcat nor in the session replication.
> Btw, another point: The object/handler/whatever which decides whether
> a session create event should be distributed at all should be
> configurable/replaceable too.
> Background: most or at least many hardware loadbalancer use urls for
> service health monitoring. They do not send any cookies back, so in
> fact each heartbit creates a new session. Our lb + failover lb are
> sending heartbits each 8 seconds each. With session timeout of 30
> minutes we always have 450 active lb sessions on each server.
> Distributing those sessions should be considered spam and waste of
> network resources :-)
>
as mentioned, you can choose cookie or distributed map. when you use the
cookie logic, you still need to cancel out the primary cookie in case
the lb did a false positive.
> In case primary node knows, that it will go down in near future and
> should send all his users away, it could stop accepting new requests
> and redirect old users directly to the backup node(s). That way the
> performance risk of getting sessions cross over the network could be
> reduced.
>
> What do you think about it?
>
this would be implementing code that is not needed. solving a problem
that is already solved doesn't help anyone.
>
>> http://people.apache.org/~fhanik/kiss.html ;)
>>
>
> I fully agree with the KISS principle, and follow it in my job and all
> projects, that's why we never use anything we don't need, like
> app-servers, or-mappers and such, until one proves, that using the
> thing make the live really easier and not complicated.
>
> Therefore I understand that implementing support for everything
> everyone need and keeping the code simple are contrarian goals, but
> making the code fine-graned and elements exchangeable wouldn't violate
> KISS, would it?
>
it would only violate it if you the features are never used, and
everyone sticks with the default. then you have code that is not in place.
I usually don't write the code until there is an expressed need for it,
and I can't get that expressed need until people say they dont like the
default impl.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Leon Rosenberg <ro...@googlemail.com>.
ups:
> If we would store the result-set (list of already created beans) in
> the session,
read:
If we would _NOT_ store the result-set (list of already created beans) in
the session,
Sorry.
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Leon Rosenberg <ro...@googlemail.com>.
comments inside
On 3/4/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> Leon Rosenberg wrote:
> > Hello Filip,
> >
> > very interesting proporsal indeed. May I point you to some importand
> > use-cases and ask whether your proporsal has solutions for it.
> >
> > 1. Poviding an easy way to customize diffs.
> >
> > As far as I understand customizable diffs are possible by a) patching
> > the StandardSession or b) configuring alternative SessionManager which
> > would create a wrapper to the StandardSession. Still I'd prefer an
> > easier way, for example a DiffCreator object inside the session which
> > can be replaced upon session creating.
> > The background of the question is following:
> > we have a large webfarm with huge traffic on it. Our sessions are
> > partly heavyweght, since we using them for caching (we have much to
> > much memory in the tomcat and want to use it). For example we are
> > caching search results (very heavyweight) which are provided by a
> > third-party search engine. In case a use just switches the view or
> > navigate in cached parts of the search result, they are replied from
> > cache reducing load on the third-party system. In case of a server
> > crash and the failover to another server we would accept loosing the
> > cached version in favour of reducing the traffic. Therefore a
> > customization would be very useful.
> >
> This scenario sounds like you shouldn't use the session as cache,
> implement a cache object that does the same thing.
> but point taken, you want a way to customize the diffs, my guess is that
> you could have a pluggable diff object that attaches to the session.
> This object can be configured through server.xml (global) or context.xml
> (per webapp)
>
If we would store the result-set (list of already created beans) in
the session, we'd have to store them twice, once in the "cache" and
once in request for presentation. However, a pluggable diff object
would be great!
Btw, another point: The object/handler/whatever which decides whether
a session create event should be distributed at all should be
configurable/replaceable too.
Background: most or at least many hardware loadbalancer use urls for
service health monitoring. They do not send any cookies back, so in
fact each heartbit creates a new session. Our lb + failover lb are
sending heartbits each 8 seconds each. With session timeout of 30
minutes we always have 450 active lb sessions on each server.
Distributing those sessions should be considered spam and waste of
network resources :-)
>
>
> > 2. Session sharing between different webapps.
> > Following use-case: As soon as the user submits personal information
> > it's sent over https instead of http to secure it from the
> > man-in-the-middle. Our https is handled by the loadbalancer
> > (hardware), so we aren't able to provide https for every user
> > operation. The application which is handling personal data contains
> > all the same classes as the primary application, but another
> > configuration, so it can be considered a different webapps. For
> > tracking purposes we need data from users primary session, which we
> > can't access in the https application. It would be very cool (and
> > actually a task in my bugzilla account at work) to provide a service
> > which could maintain a part of the session centralized and allow other
> > servers/webapps to get this sessions data.
> >
> easier way to do this would be to create a centralized cache, and put it
> in <tomcat>/shared/lib/
> This might be out of scope for Tomcat, and out of scope for replication
> for sure.
Forgot to mention that the webapps are running on different instances
in different service pools :-) What I had in mind was a kind of second
session cookie, which is set per domain (configurable), read out by
any webapp in the same domain and synchronized with a "central session
holder". But you're right, this is probably out of tomcat scope and
could be solved with a central service instance available over the
network and filters in webapps (or whatever). Point taken :-)
>
> > 3. Controlled failover:
> > In order to make soft-releases and maintainance (without logging out
> > the user) it would be very cool to transfer a session from one server
> > to another and back.
> > Use case:
> > The webfarm consists of two servers, A and B. Admin issues a command
> > to server A notto accept new sessions anymore. Server A (customizable
> > code of course) rewrites the loadbalancer cookie to point to server B.
> > User makes next request and comes to server B which then gets the
> > session from A. After all A sessions expire (or a timeout) server A
> > goes down for maintainance. After Server A is back up again and the
> > game continues with B.
> >
> This is automatic. It will happen exactly the way you describe. The way
> the LazyReplicatedMap works is as follows:
> 1. Backup node fails -> primary node chooses a new backup node
> 2. Primary node fails -> since Tomcat doesn't know which node the user
> will come to their
> next http request, nothing is done.
> When the user makes a request, and the session manager says
> LazyMap.getSession(id) and that session is not yet on the server,
> the lazymap will request the session from the backup server, load it
> up, set this node as primary.
> that is why it is called lazy, cause it wont load the session until
> it is actually needed, and because it doesn't know what node will become
> primary, this is decided by the load balancer.
Understood... that means that all tomcats communicate with each other
sending at least discover requests on create/destroy session, which
you mentioned in the previous post.
I'm still not quite sure if this can work efficently without a central
place for session management, but you sound very confident.
One problem that I still see with your approach: in large clusters
(say more then 20 servers) chances for user to come out on the backup
node are null (well 5.26% which is pretty near null in production
environment). This means that immediately after primary node fails a
lot of traffic between the backup node and the other nodes will take
place. In our use case, where we want to put down 10 of 20 servers for
release purposes it can mean VERY much unnecessary traffic.
In case primary node knows, that it will go down in near future and
should send all his users away, it could stop accepting new requests
and redirect old users directly to the backup node(s). That way the
performance risk of getting sessions cross over the network could be
reduced.
What do you think about it?
> http://people.apache.org/~fhanik/kiss.html ;)
I fully agree with the KISS principle, and follow it in my job and all
projects, that's why we never use anything we don't need, like
app-servers, or-mappers and such, until one proves, that using the
thing make the live really easier and not complicated.
Therefore I understand that implementing support for everything
everyone need and keeping the code simple are contrarian goals, but
making the code fine-graned and elements exchangeable wouldn't violate
KISS, would it?
>
> Filip
>
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Leon Rosenberg wrote:
> Hello Filip,
>
> very interesting proporsal indeed. May I point you to some importand
> use-cases and ask whether your proporsal has solutions for it.
>
> 1. Poviding an easy way to customize diffs.
>
> As far as I understand customizable diffs are possible by a) patching
> the StandardSession or b) configuring alternative SessionManager which
> would create a wrapper to the StandardSession. Still I'd prefer an
> easier way, for example a DiffCreator object inside the session which
> can be replaced upon session creating.
> The background of the question is following:
> we have a large webfarm with huge traffic on it. Our sessions are
> partly heavyweght, since we using them for caching (we have much to
> much memory in the tomcat and want to use it). For example we are
> caching search results (very heavyweight) which are provided by a
> third-party search engine. In case a use just switches the view or
> navigate in cached parts of the search result, they are replied from
> cache reducing load on the third-party system. In case of a server
> crash and the failover to another server we would accept loosing the
> cached version in favour of reducing the traffic. Therefore a
> customization would be very useful.
>
This scenario sounds like you shouldn't use the session as cache,
implement a cache object that does the same thing.
but point taken, you want a way to customize the diffs, my guess is that
you could have a pluggable diff object that attaches to the session.
This object can be configured through server.xml (global) or context.xml
(per webapp)
> 2. Session sharing between different webapps.
> Following use-case: As soon as the user submits personal information
> it's sent over https instead of http to secure it from the
> man-in-the-middle. Our https is handled by the loadbalancer
> (hardware), so we aren't able to provide https for every user
> operation. The application which is handling personal data contains
> all the same classes as the primary application, but another
> configuration, so it can be considered a different webapps. For
> tracking purposes we need data from users primary session, which we
> can't access in the https application. It would be very cool (and
> actually a task in my bugzilla account at work) to provide a service
> which could maintain a part of the session centralized and allow other
> servers/webapps to get this sessions data.
>
easier way to do this would be to create a centralized cache, and put it
in <tomcat>/shared/lib/
This might be out of scope for Tomcat, and out of scope for replication
for sure.
> 3. Controlled failover:
> In order to make soft-releases and maintainance (without logging out
> the user) it would be very cool to transfer a session from one server
> to another and back.
> Use case:
> The webfarm consists of two servers, A and B. Admin issues a command
> to server A notto accept new sessions anymore. Server A (customizable
> code of course) rewrites the loadbalancer cookie to point to server B.
> User makes next request and comes to server B which then gets the
> session from A. After all A sessions expire (or a timeout) server A
> goes down for maintainance. After Server A is back up again and the
> game continues with B.
>
This is automatic. It will happen exactly the way you describe. The way
the LazyReplicatedMap works is as follows:
1. Backup node fails -> primary node chooses a new backup node
2. Primary node fails -> since Tomcat doesn't know which node the user
will come to their
next http request, nothing is done.
When the user makes a request, and the session manager says
LazyMap.getSession(id) and that session is not yet on the server,
the lazymap will request the session from the backup server, load it
up, set this node as primary.
that is why it is called lazy, cause it wont load the session until
it is actually needed, and because it doesn't know what node will become
primary, this is decided by the load balancer.
> best regards
> Leon
>
> P.S. One more question... If I understood your correctly you plan to
> share the session with exact one other server. I haven't found
> anything about central replication service in your mail, so how is the
> server deciding which is he's replication partner? Kind of random
> algorythm or broadcast request? Please enlight me :-)
>
>
the algorithm is pluggable, a tomcat A server can decide back up all
sessions to the same node, tomcat B, or tomcatA can distribute its
sessions round robin to B,C,D,...
or a more sophisticated and complicated mechanism can be developed, but
probably not needed and it doesn't adhere to
http://people.apache.org/~fhanik/kiss.html ;)
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [feedback request] session replication
Posted by Leon Rosenberg <ro...@googlemail.com>.
Hello Filip,
very interesting proporsal indeed. May I point you to some importand
use-cases and ask whether your proporsal has solutions for it.
1. Poviding an easy way to customize diffs.
As far as I understand customizable diffs are possible by a) patching
the StandardSession or b) configuring alternative SessionManager which
would create a wrapper to the StandardSession. Still I'd prefer an
easier way, for example a DiffCreator object inside the session which
can be replaced upon session creating.
The background of the question is following:
we have a large webfarm with huge traffic on it. Our sessions are
partly heavyweght, since we using them for caching (we have much to
much memory in the tomcat and want to use it). For example we are
caching search results (very heavyweight) which are provided by a
third-party search engine. In case a use just switches the view or
navigate in cached parts of the search result, they are replied from
cache reducing load on the third-party system. In case of a server
crash and the failover to another server we would accept loosing the
cached version in favour of reducing the traffic. Therefore a
customization would be very useful.
2. Session sharing between different webapps.
Following use-case: As soon as the user submits personal information
it's sent over https instead of http to secure it from the
man-in-the-middle. Our https is handled by the loadbalancer
(hardware), so we aren't able to provide https for every user
operation. The application which is handling personal data contains
all the same classes as the primary application, but another
configuration, so it can be considered a different webapps. For
tracking purposes we need data from users primary session, which we
can't access in the https application. It would be very cool (and
actually a task in my bugzilla account at work) to provide a service
which could maintain a part of the session centralized and allow other
servers/webapps to get this sessions data.
3. Controlled failover:
In order to make soft-releases and maintainance (without logging out
the user) it would be very cool to transfer a session from one server
to another and back.
Use case:
The webfarm consists of two servers, A and B. Admin issues a command
to server A notto accept new sessions anymore. Server A (customizable
code of course) rewrites the loadbalancer cookie to point to server B.
User makes next request and comes to server B which then gets the
session from A. After all A sessions expire (or a timeout) server A
goes down for maintainance. After Server A is back up again and the
game continues with B.
Those are the three main use-cases we would be very interested in. I
understand that neither of them is solveable without internal webapp
knowledge, but it could be solved the way, that the webapp only need
to provide/configure one-two custom handlers with few lines of code
and doesn't have to reimplement everything each time.
Since we have to develop the three use-cases either way and in case
tomcat team is interested in supporting them too, we would gladly
participate in the development and develop it "the tomcat conform"
way, so it can be contributed.
best regards
Leon
P.S. One more question... If I understood your correctly you plan to
share the session with exact one other server. I haven't found
anything about central replication service in your mail, so how is the
server deciding which is he's replication partner? Kind of random
algorythm or broadcast request? Please enlight me :-)
On 3/3/06, Filip Hanik - Dev Lists <de...@hanik.com> wrote:
> I wrote together a little idea (also emailed to geronimo-dev for
> feedback) on how the next generation of session replication should be done.
> Today's replication is an all-to-all replication, and within that realm,
> its pretty poor. It creates way to much network traffic as each request
> results in X number of network transmits (where X is the number of nodes
> in the cluster/domain).
>
> The suggested solution offers two advantages:
> 1. Each request with a dirty session should only result in 1 network
> send (unless session create, session delete, or failover)
> 2. The session Manager (StandardManager,DeltaManager,etc) should not
> have to know about replication, the DeltaManager today is too
> complicated and too involved in the replication logic.
>
> I propose a very simple, yet very efficient replication mechanism, that
> is so straight forward that with a simple extension of the
> StandardSession (if not even built in) you can have session replication.
> It will even support future efforts for replication when we can have AOP
> monitor the sessions itself for data that has changed without
> setAttribute/removeAttribute, and the implementation wouldn't change much.
>
> in my opinion, the Session API should not have to know about clustering
> or session replication, nor should it need to worry about location.
> the clustering API should take care of all of that.
>
> the solution that we plan to implement for Tomcat is fairly straight
> forward. Let me see if I can give an idea of how the API shouldn't need
> to worry, its a little lengthy, but it shows that the Session and the
> SessionManager need to know zero about clustering or session locations.
> (this is only one solution, and other solutions should demonstrate the
> same point, SessionAPI need to know nothing about clustering or session
> locations)
>
> 1. Requirements to be implemented by the Session.java API
> bool isDirty - (has the session changed in this request)
> bool isDiffable - is the session able provide a diff
> byte[] getSessionData() - returns the whole session
> byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
> void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
> changes from another node
>
> 2. Requirements to be implemented by the SessionManager.java API
> void setSessionMap(HashMap map) - makes the map implementation pluggable
>
> 3. And the key to this, is that we will have an implementation of a
> LazyReplicatedHashMap
> The key object in this map is the session Id.
> The map entry object is an object that looks like this
> ReplicatedEntry {
> string id;//sessionid
> bool isPrimary; //does this node hold the data
> bool isBackup; //does this node hold backup data
> Session session; //not null values for primary and backup nodes
> Member primary; //information about the primary node
> Member backup; //information about the backup node
> }
>
> The LazyReplicatedHashMap overrides get(key) and put(id,session)
>
> So all the nodes will have the a sessionId,ReplicatedEntry combinations
> in their session map. But only two nodes will have the actual data.
> This solution is for sticky LB only, but when failover happens, the LB
> can pick any node as each node knows where to get the data.
> The newly selected node, will keep the backup node or select a new one,
> and do a publish to the entire cluster of the locations.
>
> As you can see, all-to-all communications only happens when a Session is
> (created|destroyed|failover). Other than that it is primary-to-backup
> communication only, and this can be in terms of diffs or entire sessions
> using the isDirty or getDiff. This is triggered either by an interceptor
> at the end of each request or by a batch process for less network jitter
> but less accuracy (but adequate) for fail over.
>
> What makes this possible will be that Tribes will have true state
> replication and other true RPC calls into the cluster.
>
> positive thoughts, criticism and bashing are all welcome :)
> (remember that I work with the KISS principle)
> http://people.apache.org/~fhanik/kiss.html
>
> Filip
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[feedback request] session replication
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
I wrote together a little idea (also emailed to geronimo-dev for
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that realm,
its pretty poor. It creates way to much network traffic as each request
results in X number of network transmits (where X is the number of nodes
in the cluster/domain).
The suggested solution offers two advantages:
1. Each request with a dirty session should only result in 1 network
send (unless session create, session delete, or failover)
2. The session Manager (StandardManager,DeltaManager,etc) should not
have to know about replication, the DeltaManager today is too
complicated and too involved in the replication logic.
I propose a very simple, yet very efficient replication mechanism, that
is so straight forward that with a simple extension of the
StandardSession (if not even built in) you can have session replication.
It will even support future efforts for replication when we can have AOP
monitor the sessions itself for data that has changed without
setAttribute/removeAttribute, and the implementation wouldn't change much.
in my opinion, the Session API should not have to know about clustering
or session replication, nor should it need to worry about location.
the clustering API should take care of all of that.
the solution that we plan to implement for Tomcat is fairly straight
forward. Let me see if I can give an idea of how the API shouldn't need
to worry, its a little lengthy, but it shows that the Session and the
SessionManager need to know zero about clustering or session locations.
(this is only one solution, and other solutions should demonstrate the
same point, SessionAPI need to know nothing about clustering or session
locations)
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() - optional, see isDiffable, resets the diff data
void setSessionDiff(byte[] diff) - optional, see isDiffable, apply
changes from another node
2. Requirements to be implemented by the SessionManager.java API
void setSessionMap(HashMap map) - makes the map implementation pluggable
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string id;//sessionid
bool isPrimary; //does this node hold the data
bool isBackup; //does this node hold backup data
Session session; //not null values for primary and backup nodes
Member primary; //information about the primary node
Member backup; //information about the backup node
}
The LazyReplicatedHashMap overrides get(key) and put(id,session)
So all the nodes will have the a sessionId,ReplicatedEntry combinations
in their session map. But only two nodes will have the actual data.
This solution is for sticky LB only, but when failover happens, the LB
can pick any node as each node knows where to get the data.
The newly selected node, will keep the backup node or select a new one,
and do a publish to the entire cluster of the locations.
As you can see, all-to-all communications only happens when a Session is
(created|destroyed|failover). Other than that it is primary-to-backup
communication only, and this can be in terms of diffs or entire sessions
using the isDirty or getDiff. This is triggered either by an interceptor
at the end of each request or by a batch process for less network jitter
but less accuracy (but adequate) for fail over.
What makes this possible will be that Tribes will have true state
replication and other true RPC calls into the cluster.
positive thoughts, criticism and bashing are all welcome :)
(remember that I work with the KISS principle)
http://people.apache.org/~fhanik/kiss.html
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Very interesting, I think the patch would be even better if the caching
policy was configurable.
ie, LRU, MRU, FIFO etc. To take it beyond that, the cache should be
configurable per context (see last note).
your test case is a little out there, (who would map .html to cached
JSPs:) but it proves your point.
I'm a +0 on this patch as I am currently not involved in the jasper
code, but would be willing (+1) to help out creating a more complete
patch, as I think Yarick brings out a great point.
In a shared hosted environments, means that one user could take up
almost all memory space for JSP pages that are never accessed.
I'd like some thoughts from the Jasper developers.
thanks
Filip
Yaroslav Sokolov wrote:
> Hi,
>
> I have found, that once loaded jsp-servlets are never unloaded.
>
> To test I just configured tomcat to process *.html files by JspServlet
> and then traversed jdk documentation. The result was not very exciting -
> after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError:
> Java heap space"
> and started not to work...
>
> So maybe it would be not a bad idea to try to keep in memeory just
> some fixed
> number of jsp-servlets ?
>
> I have written a sample implementation of such a policy, but it is not
> very elegant
> as internal structure containing jsp-servlets, it seems, was not
> designed for such actions...
>
> Regards,
> Yarick.
> ------------------------------------------------------------------------
>
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-02-21 13:26:44.984221000 +0100
> @@ -174,6 +174,17 @@
> */
> private boolean xpoweredBy;
>
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + private int maxLoadedJsps = 20;
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + private int jspUnloadTestInterval = 4;
> +
> public String getProperty(String name ) {
> return settings.getProperty( name );
> }
> @@ -355,6 +366,14 @@
> return null;
> }
>
> + public int getMaxLoadedJsps() {
> + return maxLoadedJsps;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return jspUnloadTestInterval;
> + }
> +
> /**
> * Create an EmbeddedServletOptions object using data available from
> * ServletConfig and ServletContext.
> @@ -636,6 +655,40 @@
> }
> }
>
> + String maxLoadedJsps = config.getInitParameter("maxLoadedJsps");
> + if (maxLoadedJsps != null) {
> + try {
> + this.maxLoadedJsps = Integer.parseInt(maxLoadedJsps);
> + if (this.maxLoadedJsps <= 0) {
> + this.maxLoadedJsps = 20;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + }
> +
> + String jspUnloadTestInterval = config.getInitParameter("jspUnloadTestInterval");
> + if (jspUnloadTestInterval != null) {
> + try {
> + this.jspUnloadTestInterval = Integer.parseInt(jspUnloadTestInterval);
> + if (this.jspUnloadTestInterval <= 0) {
> + this.jspUnloadTestInterval = 4;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + }
> +
> // Setup the global Tag Libraries location cache for this
> // web-application.
> tldLocationsCache = new TldLocationsCache(context);
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-02-21 13:27:07.568387400 +0100
> @@ -448,6 +448,14 @@
> return cache;
> }
>
> + public int getMaxLoadedJsps() {
> + return 0;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return 0;
> + }
> +
> /**
> * Background compilation check intervals in seconds
> */
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-02-21 13:27:24.210173000 +0100
> @@ -184,5 +184,16 @@
> * @return the Map(String uri, TreeNode tld) instance.
> */
> public Map getCache();
> +
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + public int getMaxLoadedJsps();
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + public int getJspUnloadTestInterval();
>
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-02-21 13:16:29.004201800 +0100
> @@ -25,10 +25,7 @@
> import java.security.PermissionCollection;
> import java.security.Policy;
> import java.security.cert.Certificate;
> -import java.util.Collections;
> -import java.util.HashMap;
> -import java.util.Iterator;
> -import java.util.Map;
> +import java.util.*; // yarick: java.util.HashMap -> java.util.*
>
> import javax.servlet.ServletContext;
> import javax.servlet.jsp.JspFactory;
> @@ -148,8 +145,8 @@
> /**
> * Maps JSP pages to their JspServletWrapper's
> */
> - private Map jsps = Collections.synchronizedMap( new HashMap());
> -
> + private Map jsps = Collections.synchronizedMap( new LinkedHashMap( 16, 0.75f, true ) ); // yarick: HashMap -> LinkedHashMap
> +
>
> /**
> * The background thread.
> @@ -192,6 +189,21 @@
> }
>
> /**
> + * Get an already existing JspServletWrapper and increases services count.
> + *
> + * @param jspUri JSP URI
> + * @return JspServletWrapper for JSP
> + */
> + public JspServletWrapper getWrapperAndIncService(String jspUri) {
> + JspServletWrapper jswr;
> + synchronized( jsps ) {
> + jswr = (JspServletWrapper) jsps.get(jspUri);
> + if( null != jswr ) jswr.incService();
> + }
> + return jswr;
> + }
> +
> + /**
> * Remove a JspServletWrapper.
> *
> * @param jspUri JSP URI of JspServletWrapper to remove
> @@ -521,4 +533,28 @@
>
> }
>
> +// { inserted by Yarick
> +
> + /** must be called from synchronized by {@link org.apache.jasper.servlet.JspServlet} context */
> + public JspServletWrapper getJspForUnload()
> + {
> + int MAX_UNLOADABLE_JSPS = 10;
> + if( jsps.size() > MAX_UNLOADABLE_JSPS ) {
> + JspServletWrapper jsw = null;
> + synchronized( jsps ) {
> + Iterator it = jsps.entrySet().iterator();
> + for( int rest_jsps=jsps.size(); rest_jsps > MAX_UNLOADABLE_JSPS && it.hasNext(); --rest_jsps ) {
> + jsw = (JspServletWrapper) ( (Map.Entry) it.next() ).getValue();
> + if( jsw.getExecutingServicesCount() == 0 && !jsw.isTagFile() ) {
> + it.remove();
> + return jsw;
> + }
> + }
> + }
> + }
> + return null;
> + }
> +
> +// } inserted by Yarick
> +
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-02-21 13:37:08.060784200 +0100
> @@ -17,8 +17,9 @@
> package org.apache.jasper.servlet;
>
> import java.io.IOException;
> +import java.io.File;
> import java.lang.reflect.Constructor;
> -import java.util.Enumeration;
> +import java.util.*;
>
> import javax.servlet.ServletConfig;
> import javax.servlet.ServletContext;
> @@ -97,8 +98,10 @@
> options = new EmbeddedServletOptions(config, context);
> }
> rctxt = new JspRuntimeContext(context, options);
> -
> - if (log.isDebugEnabled()) {
> +
> + startUnloadJspsThread(); // inserted by yarick
> +
> + if (log.isDebugEnabled()) {
> log.debug(Localizer.getMessage("jsp.message.scratch.dir.is",
> options.getScratchDir().toString()));
> log.debug(Localizer.getMessage("jsp.message.dont.modify.servlets"));
> @@ -278,7 +281,7 @@
> if (log.isDebugEnabled()) {
> log.debug("JspServlet.destroy()");
> }
> -
> + stopUnloadJspsThread(); // inserted by yarick
> rctxt.destroy();
> }
>
> @@ -290,29 +293,99 @@
> Throwable exception, boolean precompile)
> throws ServletException, IOException {
>
> - JspServletWrapper wrapper =
> - (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - synchronized(this) {
> - wrapper = (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - // Check if the requested JSP page exists, to avoid
> - // creating unnecessary directories and files.
> - if (null == context.getResource(jspUri)) {
> - response.sendError(HttpServletResponse.SC_NOT_FOUND,
> - jspUri);
> - return;
> + JspServletWrapper wrapper = null;
> + try {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if( null == wrapper )
> + synchronized(this) {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if (wrapper == null) {
> + // Check if the requested JSP page exists, to avoid
> + // creating unnecessary directories and files.
> + if (null == context.getResource(jspUri)) {
> + response.sendError(HttpServletResponse.SC_NOT_FOUND,
> + jspUri);
> + return;
> + }
> + boolean isErrorPage = exception != null;
> + wrapper = new JspServletWrapper(config, options, jspUri,
> + isErrorPage, rctxt);
> + rctxt.addWrapper(jspUri,wrapper);
> }
> - boolean isErrorPage = exception != null;
> - wrapper = new JspServletWrapper(config, options, jspUri,
> - isErrorPage, rctxt);
> - rctxt.addWrapper(jspUri,wrapper);
> + wrapper.incService();
> + }
> +
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + String _destroyingUri = destroyingUri;
> + if( wrapper.getJspUri().equals( _destroyingUri ) )
> + synchronized( _destroyingUri ) {
> + if( _destroyingUri == destroyingUri )
> + _destroyingUri.wait();
> }
> +
> + wrapper.service(request, response, precompile);
> +
> + } catch( InterruptedException ignore ) {}
> + finally { // inserted by yarick
> + synchronized(this) {
> + if( null != wrapper ) wrapper.decService();
> }
> - }
> + }
> + }
>
> - wrapper.service(request, response, precompile);
> +// { inserted by yarick
> + private Thread unloadThread;
> + private String destroyingUri;
>
> + protected void startUnloadJspsThread() {
> + String pathToWebApp = context.getRealPath("/");
> + if( pathToWebApp.endsWith( File.separator ) )
> + pathToWebApp = pathToWebApp.substring( 0, pathToWebApp.length()-1 );
> +
> + unloadThread = new Thread( "jspUnloader ["+pathToWebApp.substring( pathToWebApp.lastIndexOf( File.separatorChar ) )+( "/" )+"]" ) {
> + public void run() { runUnloadJspsThread(); }
> + };
> + unloadThread.setDaemon( true );
> + unloadThread.start();
> + }
> +
> + protected void stopUnloadJspsThread() {
> + if( null != unloadThread ) {
> + unloadThread.interrupt();
> + try { unloadThread.join( 10 * 1000 ); } // wait maximum 10 seconds
> + catch( InterruptedException ignore ) {}
> + unloadThread = null;
> + }
> }
>
> + protected void runUnloadJspsThread() {
> + try {
> + while( !Thread.currentThread().isInterrupted() ) {
> + JspServletWrapper jsw;
> + synchronized( this ) {
> + jsw = rctxt.getJspForUnload();
> + if( null != jsw ) destroyingUri = new String( jsw.getJspUri() );
> + }
> +
> + if( null == jsw )
> + Thread.sleep( options.getJspUnloadTestInterval() * 1000 );
> + else
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + synchronized( destroyingUri ) {
> + try {
> + jsw.destroy();
> + } finally {
> + String prev_destroyingUri = destroyingUri;
> + destroyingUri = null;
> + prev_destroyingUri.notifyAll();
> + }
> + }
> + }
> + } catch( InterruptedException exit ) {}
> + }
> +// } inserted by yarick
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-02-21 13:24:43.999843400 +0100
> @@ -86,6 +86,7 @@
> private JasperException compileException;
> private long servletClassLastModifiedTime;
> private long lastModificationTest = 0L;
> + private int executingServicesCount; // yarick
>
> /*
> * JspServletWrapper for JSP pages.
> @@ -397,6 +398,10 @@
> }
> }
>
> + synchronized public void incService() { ++executingServicesCount; } // yarick: inserted accounting of 'service'
> + synchronized public void decService() { --executingServicesCount; } // yarick: inserted accounting of 'service'
> + String getJspUri() { return jspUri; } // yarick: inserted
> +
> public void destroy() {
> if (theServlet != null) {
> theServlet.destroy();
> @@ -416,6 +421,9 @@
> this.lastModificationTest = lastModificationTest;
> }
>
> + /** @return Returns count of currently executing of method {@link #service} */
> + public int getExecutingServicesCount() { return executingServicesCount; } // yarick
> +
> /**
> * <p>Attempts to construct a JasperException that contains helpful information
> * about what went wrong. Uses the JSP compiler system to translate the line
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Thanks for the patch...
>
> This is a well known problem, JSPs are not unloaded unless the entire
> webapp is unloaded. And to make things worse - by default all JSP
> static content is compiled to strings, that take all the memory. I
> think we have ( or had ) an option to generate some non .class file -
> which could be more easily managed.
>
> Unfortunately I'm not familiar enough with jasper code - but it looks
> good to me. The model of keeping the entire jsp static content in
> memory forever is IMO very broken... It may help cheat on some
> benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
> world.
Huh ? This is nonsense. JSPs, until further notice, are servlets. As a
result, why should they have unloding strategies and similar nonsense ?
Strong -1: I will veto any attempt to fix this "issue".
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> -1.
> "A veto without a justification is invalid and has no weight."
> http://www.apache.org/foundation/voting.html#Veto
Maybe I am not productive, but you are completely stupid too. I don't
have to justify anything here anyway, I already did.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> David Rees wrote:
>> On 3/7/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>>> Ok, I can make the next conclusions:
>>>
>>> 1. Tomcat eats resources on first opening of any jsp page and never
>>> returns
>>> them back - servlets just are never unloaded.
>>> 2. As it happens in all the versions of Tomcat, there are many jsps,
>>> not
>>> meeting requirements
>>> of the specification (no destroy() method when there is some useful
>>> data in
>>> fields) but well working under Tomcat.
>>> 3. We do not want to change this situation ( -> I shall not even try
>>> to send
>>> any better patch here :-\ (but I will ;-) ) )
>>
>> What about my previous suggestion of externalizing JSP strings, but
>> only externalizing strings greater than a certain (user configurable)
>> size? That would give you huge memory savings in your test case
>> (running static .html files as JSPs) while allowing users to retain
>> the existing functionality without a performance hit.
>
> -1.
"A veto without a justification is invalid and has no weight."
http://www.apache.org/foundation/voting.html#Veto
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
David Rees wrote:
> On 3/7/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>> Ok, I can make the next conclusions:
>>
>> 1. Tomcat eats resources on first opening of any jsp page and never returns
>> them back - servlets just are never unloaded.
>> 2. As it happens in all the versions of Tomcat, there are many jsps, not
>> meeting requirements
>> of the specification (no destroy() method when there is some useful data in
>> fields) but well working under Tomcat.
>> 3. We do not want to change this situation ( -> I shall not even try to send
>> any better patch here :-\ (but I will ;-) ) )
>
> What about my previous suggestion of externalizing JSP strings, but
> only externalizing strings greater than a certain (user configurable)
> size? That would give you huge memory savings in your test case
> (running static .html files as JSPs) while allowing users to retain
> the existing functionality without a performance hit.
-1.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
David Rees wrote:
> On 3/7/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>> Ok, I can make the next conclusions:
>>
>> 1. Tomcat eats resources on first opening of any jsp page and never returns
>> them back - servlets just are never unloaded.
>> 2. As it happens in all the versions of Tomcat, there are many jsps, not
>> meeting requirements
>> of the specification (no destroy() method when there is some useful data in
>> fields) but well working under Tomcat.
>> 3. We do not want to change this situation ( -> I shall not even try to send
>> any better patch here :-\ (but I will ;-) ) )
>
> What about my previous suggestion of externalizing JSP strings, but
> only externalizing strings greater than a certain (user configurable)
> size? That would give you huge memory savings in your test case
> (running static .html files as JSPs) while allowing users to retain
> the existing functionality without a performance hit.
>
I already have this extension. I initiated this topic to see the community
opinion about situation when JSPs were forever in memory after first loading.
I have seen the opinion.
> -Dave
>
Regards,
Yarick.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by David Rees <dr...@gmail.com>.
On 3/7/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> Ok, I can make the next conclusions:
>
> 1. Tomcat eats resources on first opening of any jsp page and never returns
> them back - servlets just are never unloaded.
> 2. As it happens in all the versions of Tomcat, there are many jsps, not
> meeting requirements
> of the specification (no destroy() method when there is some useful data in
> fields) but well working under Tomcat.
> 3. We do not want to change this situation ( -> I shall not even try to send
> any better patch here :-\ (but I will ;-) ) )
What about my previous suggestion of externalizing JSP strings, but
only externalizing strings greater than a certain (user configurable)
size? That would give you huge memory savings in your test case
(running static .html files as JSPs) while allowing users to retain
the existing functionality without a performance hit.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Leon Rosenberg <ro...@googlemail.com>.
http://www.coremedia.de
http://www.reddot.com
http://www.magnolia.info/en/magnolia.html
and further 100-200 cms vendors...
Of course you now your applications need better, but it seems like
finding an excuse for a bad design. If the jsps are static, like in
your case, they aren't jsps anymore, are they? But well, this is going
very far OT :-)
regards
leon
On 3/7/06, S. Dierkes <sd...@mediaclockwork.de> wrote:
> It's not possible, the requirement is an identical layout for printout and
> html (as far as possible), so from a layouter application (kind of
> WYSIWIG-DTP-Editor) a screen (jsp) and a print representation (pdf) is
> created for each physical page(including multiple columns layout, formated
> text with fixed line breaks, copy pages, ...). So each jsp has it's own
> layout and believe me the layouts are not simple, I just checked: the
> largest JSP representing one physical page has ~360kB (w/o debug
> information) containing ~150 page objects (50 rendering to fields(input,
> textarea)) from Layout-program.
>
> -----Ursprüngliche Nachricht-----
> Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Gesendet: Dienstag, 7. März 2006 23:15
> An: Tomcat Developers List
> Betreff: Re: What's about unloading policy of jsp-servlets ?
>
>
> Why do you create jsps from the database instead of filling a small set of
> jsps with the content from the database?
>
> Leon
>
> On 3/7/06, S. Dierkes <sd...@mediaclockwork.de> wrote:
> > If you're still searching for a real world application: we have an
> > application where JSP's are generated dynamically from database (no
> > on-the-fly because to time consuming, so they are created offline),
> > currently there had been ~1500 JSP's (~100MB) created (plus the
> > application itself). The application creates JSP and PDF of real-world
> > forms (fill in as html, print out as pdf) for different customers
> > (mainly banks), so the jsp-base is constantly increasing. Ok, memory
> > is not really an issue in production, since we can increase it on
> > demand, but a configurable memory behaviour could be a nice feature
> > and might save memory for other server purposes. Don't get me wrong, I
> > think the best solution for production is still more RAM, but at least
> > for testing it would be nice to have less needs for RAM.
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> > Gesendet: Dienstag, 7. März 2006 16:20
> > An: Tomcat Developers List
> > Betreff: Re: What's about unloading policy of jsp-servlets ?
> >
> >
> > On 3/7/06, Renato <re...@yahoo.com> wrote:
> > > a webhosting company that has a shared JVM instance of tomcat for
> > > its websites and runs unmanaged code bumps into this kind of problem
> > > all the time ;)).
> >
> > hmm... sorry, I host java webapps for customers, and this is my last
> > problem. I mean a typical webapp contains approx. 100 classes and 50
> > jsps? Most of the classes are always in use and therefore in memory as
> > well as the jsps. I don't really see the problem here. I mean before I
> > run out of memory for JSPs, I will run out of memory for classes....
> > Leon
> >
> > >
> > > --- Leon Rosenberg <ro...@googlemail.com>
> > > wrote:
> > >
> > > > Yaroslav,
> > > >
> > > > you've made great work with the patch, but honestly, which
> > > > real-world application uses hunderds of megabytes of jsps?
> > > >
> > > > that just doesn't make sense...
> > > >
> > > > regards
> > > > Leon
> > > >
> > > > P.S. don't want to be offending, but i just can't
> > > > find a single use-case...
> > > >
> > > > On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> > > > wrote:
> > > > > Ok, I can make the next conclusions:
> > > > >
> > > > > 1. Tomcat eats resources on first opening of any
> > > > jsp page and never returns
> > > > > them back - servlets just are never unloaded.
> > > > > 2. As it happens in all the versions of Tomcat,
> > > > there are many jsps, not
> > > > > meeting requirements
> > > > > of the specification (no destroy() method when
> > > > there is some useful data in
> > > > > fields) but well working under Tomcat.
> > > > > 3. We do not want to change this situation ( -> I
> > > > shall not even try to send
> > > > > any better patch here :-\ (but I will ;-) ) )
> > > > >
> > > > > One more conclusion - if all the jsp content of
> > > > our web site does not fit in
> > > > > memory, we
> > > > > should buy more memory. Else we must not use jsp
> > > > technology in all the
> > > > > pages. We should choose
> > > > > something other than jsp, for example velocity,
> > > > SSI,...
> > > > >
> > > > > P.S. by the way, when web application is unloaded
> > > > such bad jsps lose data
> > > > > anyway.
> > > > >
> > > > > On 06/03/06, Costin Manolache <co...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Starting is different from stopping.
> > > > > >
> > > > > > Yes, the spec allows unloading - but in reality
> > > > most JSPs and servlets
> > > > > > can't deal well with that. And the argument that
> > > > it is optional
> > > > > > doesn't work - in many cases the person who
> > > > writes the servlet/jsp is
> > > > > > not the same as the person who is running the
> > > > production server or
> > > > > > does the configuration tunning.
> > > > > >
> > > > > > There are subtle bugs that may show up when this
> > > > feature would be
> > > > > > enabled - people doing the config might be
> > > > tempted to reduce memory
> > > > > > use, and this would result in extremely hard to
> > > > reproduce and debug
> > > > > > problems.
> > > > > >
> > > > > > By 'spec compliance' I mean more 'compatibility
> > > > with the existing spec
> > > > > > _and_ the current usage of the spec'. The later
> > > > is IMO more important
> > > > > > in many cases than the letter or any
> > > > interpretation of the spec.
> > > > > >
> > > > > > Costin
> > > > > >
> > > > > > On 3/6/06, Yaroslav Sokolov
> > > > <ya...@gmail.com> wrote:
> > > > > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> > > > wrote:
> > > > > > > >
> > > > > > > > Costin Manolache wrote:
> > > > > > > > > But it's a separate issue - I agree that
> > > > unloading unused jsps is
> > > > > > the
> > > > > > > > > most important.
> > > > > > > >
> > > > > > > > The recommended production usage (= optimal)
> > > > of JSPs is when they are
> > > > > > > > precommpiled, which means that the Jasper
> > > > servlet is not used, and the
> > > > > > > > JSPs are plain servlets. Their lifecycle is
> > > > then identical to the
> > > > > > > > lifecycle of servlets.
> > > > > > >
> > > > > > >
> > > > > > > I do not see any reason, why different
> > > > servlets could not have different
> > > > > > > life cycles.
> > > > > > > Even more, the last sentence is in contrary to
> > > > current implementation -
> > > > > > > some servlets can be loaded not on demand, but
> > > > on starting of a web
> > > > > > > application.
> > > > > > > So, their life cycle has already been _not_
> > > > identical to the life cycle
> > > > > > of
> > > > > > > other servlets.
> > > > > > >
> > > > > > >
> > > > > > > I understand the Jasper servlet is junk, and
> > > > is a testing ground for bad
> > > > > > > > ideas, though (ex: the background
> > > > compilation thread, and now this).
> > > > > > > >
> > > > > > > > Rémy
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Regards,
> > > > > > > Yaroslav Sokolov.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Yaroslav Sokolov.
> > > > >
> > > > >
> > > >
> > > >
> > > --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
AW: What's about unloading policy of jsp-servlets ?
Posted by "S. Dierkes" <sd...@mediaclockwork.de>.
It's not possible, the requirement is an identical layout for printout and
html (as far as possible), so from a layouter application (kind of
WYSIWIG-DTP-Editor) a screen (jsp) and a print representation (pdf) is
created for each physical page(including multiple columns layout, formated
text with fixed line breaks, copy pages, ...). So each jsp has it's own
layout and believe me the layouts are not simple, I just checked: the
largest JSP representing one physical page has ~360kB (w/o debug
information) containing ~150 page objects (50 rendering to fields(input,
textarea)) from Layout-program.
-----Ursprüngliche Nachricht-----
Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
Gesendet: Dienstag, 7. März 2006 23:15
An: Tomcat Developers List
Betreff: Re: What's about unloading policy of jsp-servlets ?
Why do you create jsps from the database instead of filling a small set of
jsps with the content from the database?
Leon
On 3/7/06, S. Dierkes <sd...@mediaclockwork.de> wrote:
> If you're still searching for a real world application: we have an
> application where JSP's are generated dynamically from database (no
> on-the-fly because to time consuming, so they are created offline),
> currently there had been ~1500 JSP's (~100MB) created (plus the
> application itself). The application creates JSP and PDF of real-world
> forms (fill in as html, print out as pdf) for different customers
> (mainly banks), so the jsp-base is constantly increasing. Ok, memory
> is not really an issue in production, since we can increase it on
> demand, but a configurable memory behaviour could be a nice feature
> and might save memory for other server purposes. Don't get me wrong, I
> think the best solution for production is still more RAM, but at least
> for testing it would be nice to have less needs for RAM.
>
> -----Ursprüngliche Nachricht-----
> Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Gesendet: Dienstag, 7. März 2006 16:20
> An: Tomcat Developers List
> Betreff: Re: What's about unloading policy of jsp-servlets ?
>
>
> On 3/7/06, Renato <re...@yahoo.com> wrote:
> > a webhosting company that has a shared JVM instance of tomcat for
> > its websites and runs unmanaged code bumps into this kind of problem
> > all the time ;)).
>
> hmm... sorry, I host java webapps for customers, and this is my last
> problem. I mean a typical webapp contains approx. 100 classes and 50
> jsps? Most of the classes are always in use and therefore in memory as
> well as the jsps. I don't really see the problem here. I mean before I
> run out of memory for JSPs, I will run out of memory for classes....
> Leon
>
> >
> > --- Leon Rosenberg <ro...@googlemail.com>
> > wrote:
> >
> > > Yaroslav,
> > >
> > > you've made great work with the patch, but honestly, which
> > > real-world application uses hunderds of megabytes of jsps?
> > >
> > > that just doesn't make sense...
> > >
> > > regards
> > > Leon
> > >
> > > P.S. don't want to be offending, but i just can't
> > > find a single use-case...
> > >
> > > On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> > > wrote:
> > > > Ok, I can make the next conclusions:
> > > >
> > > > 1. Tomcat eats resources on first opening of any
> > > jsp page and never returns
> > > > them back - servlets just are never unloaded.
> > > > 2. As it happens in all the versions of Tomcat,
> > > there are many jsps, not
> > > > meeting requirements
> > > > of the specification (no destroy() method when
> > > there is some useful data in
> > > > fields) but well working under Tomcat.
> > > > 3. We do not want to change this situation ( -> I
> > > shall not even try to send
> > > > any better patch here :-\ (but I will ;-) ) )
> > > >
> > > > One more conclusion - if all the jsp content of
> > > our web site does not fit in
> > > > memory, we
> > > > should buy more memory. Else we must not use jsp
> > > technology in all the
> > > > pages. We should choose
> > > > something other than jsp, for example velocity,
> > > SSI,...
> > > >
> > > > P.S. by the way, when web application is unloaded
> > > such bad jsps lose data
> > > > anyway.
> > > >
> > > > On 06/03/06, Costin Manolache <co...@gmail.com>
> > > wrote:
> > > > >
> > > > > Starting is different from stopping.
> > > > >
> > > > > Yes, the spec allows unloading - but in reality
> > > most JSPs and servlets
> > > > > can't deal well with that. And the argument that
> > > it is optional
> > > > > doesn't work - in many cases the person who
> > > writes the servlet/jsp is
> > > > > not the same as the person who is running the
> > > production server or
> > > > > does the configuration tunning.
> > > > >
> > > > > There are subtle bugs that may show up when this
> > > feature would be
> > > > > enabled - people doing the config might be
> > > tempted to reduce memory
> > > > > use, and this would result in extremely hard to
> > > reproduce and debug
> > > > > problems.
> > > > >
> > > > > By 'spec compliance' I mean more 'compatibility
> > > with the existing spec
> > > > > _and_ the current usage of the spec'. The later
> > > is IMO more important
> > > > > in many cases than the letter or any
> > > interpretation of the spec.
> > > > >
> > > > > Costin
> > > > >
> > > > > On 3/6/06, Yaroslav Sokolov
> > > <ya...@gmail.com> wrote:
> > > > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > Costin Manolache wrote:
> > > > > > > > But it's a separate issue - I agree that
> > > unloading unused jsps is
> > > > > the
> > > > > > > > most important.
> > > > > > >
> > > > > > > The recommended production usage (= optimal)
> > > of JSPs is when they are
> > > > > > > precommpiled, which means that the Jasper
> > > servlet is not used, and the
> > > > > > > JSPs are plain servlets. Their lifecycle is
> > > then identical to the
> > > > > > > lifecycle of servlets.
> > > > > >
> > > > > >
> > > > > > I do not see any reason, why different
> > > servlets could not have different
> > > > > > life cycles.
> > > > > > Even more, the last sentence is in contrary to
> > > current implementation -
> > > > > > some servlets can be loaded not on demand, but
> > > on starting of a web
> > > > > > application.
> > > > > > So, their life cycle has already been _not_
> > > identical to the life cycle
> > > > > of
> > > > > > other servlets.
> > > > > >
> > > > > >
> > > > > > I understand the Jasper servlet is junk, and
> > > is a testing ground for bad
> > > > > > > ideas, though (ex: the background
> > > compilation thread, and now this).
> > > > > > >
> > > > > > > Rémy
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Yaroslav Sokolov.
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Yaroslav Sokolov.
> > > >
> > > >
> > >
> > >
> > --------------------------------------------------------------------
> > -
> > > To unsubscribe, e-mail:
> > > dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Leon Rosenberg <ro...@googlemail.com>.
Why do you create jsps from the database instead of filling a small
set of jsps with the content from the database?
Leon
On 3/7/06, S. Dierkes <sd...@mediaclockwork.de> wrote:
> If you're still searching for a real world application: we have an
> application where JSP's are generated dynamically from database (no
> on-the-fly because to time consuming, so they are created offline),
> currently there had been ~1500 JSP's (~100MB) created (plus the application
> itself). The application creates JSP and PDF of real-world forms (fill in as
> html, print out as pdf) for different customers (mainly banks), so the
> jsp-base is constantly increasing.
> Ok, memory is not really an issue in production, since we can increase it on
> demand, but a configurable memory behaviour could be a nice feature and
> might save memory for other server purposes. Don't get me wrong, I think the
> best solution for production is still more RAM, but at least for testing it
> would be nice to have less needs for RAM.
>
> -----Ursprüngliche Nachricht-----
> Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
> Gesendet: Dienstag, 7. März 2006 16:20
> An: Tomcat Developers List
> Betreff: Re: What's about unloading policy of jsp-servlets ?
>
>
> On 3/7/06, Renato <re...@yahoo.com> wrote:
> > a webhosting company that has a shared JVM instance of
> > tomcat for its websites and runs unmanaged code bumps
> > into this kind of problem all the time ;)).
>
> hmm... sorry, I host java webapps for customers, and this is my last
> problem. I mean a typical webapp contains approx. 100 classes and 50 jsps?
> Most of the classes are always in use and therefore in memory as well as the
> jsps. I don't really see the problem here. I mean before I run out of memory
> for JSPs, I will run out of memory for classes.... Leon
>
> >
> > --- Leon Rosenberg <ro...@googlemail.com>
> > wrote:
> >
> > > Yaroslav,
> > >
> > > you've made great work with the patch, but honestly,
> > > which real-world
> > > application uses hunderds of megabytes of jsps?
> > >
> > > that just doesn't make sense...
> > >
> > > regards
> > > Leon
> > >
> > > P.S. don't want to be offending, but i just can't
> > > find a single use-case...
> > >
> > > On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> > > wrote:
> > > > Ok, I can make the next conclusions:
> > > >
> > > > 1. Tomcat eats resources on first opening of any
> > > jsp page and never returns
> > > > them back - servlets just are never unloaded.
> > > > 2. As it happens in all the versions of Tomcat,
> > > there are many jsps, not
> > > > meeting requirements
> > > > of the specification (no destroy() method when
> > > there is some useful data in
> > > > fields) but well working under Tomcat.
> > > > 3. We do not want to change this situation ( -> I
> > > shall not even try to send
> > > > any better patch here :-\ (but I will ;-) ) )
> > > >
> > > > One more conclusion - if all the jsp content of
> > > our web site does not fit in
> > > > memory, we
> > > > should buy more memory. Else we must not use jsp
> > > technology in all the
> > > > pages. We should choose
> > > > something other than jsp, for example velocity,
> > > SSI,...
> > > >
> > > > P.S. by the way, when web application is unloaded
> > > such bad jsps lose data
> > > > anyway.
> > > >
> > > > On 06/03/06, Costin Manolache <co...@gmail.com>
> > > wrote:
> > > > >
> > > > > Starting is different from stopping.
> > > > >
> > > > > Yes, the spec allows unloading - but in reality
> > > most JSPs and servlets
> > > > > can't deal well with that. And the argument that
> > > it is optional
> > > > > doesn't work - in many cases the person who
> > > writes the servlet/jsp is
> > > > > not the same as the person who is running the
> > > production server or
> > > > > does the configuration tunning.
> > > > >
> > > > > There are subtle bugs that may show up when this
> > > feature would be
> > > > > enabled - people doing the config might be
> > > tempted to reduce memory
> > > > > use, and this would result in extremely hard to
> > > reproduce and debug
> > > > > problems.
> > > > >
> > > > > By 'spec compliance' I mean more 'compatibility
> > > with the existing spec
> > > > > _and_ the current usage of the spec'. The later
> > > is IMO more important
> > > > > in many cases than the letter or any
> > > interpretation of the spec.
> > > > >
> > > > > Costin
> > > > >
> > > > > On 3/6/06, Yaroslav Sokolov
> > > <ya...@gmail.com> wrote:
> > > > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > Costin Manolache wrote:
> > > > > > > > But it's a separate issue - I agree that
> > > unloading unused jsps is
> > > > > the
> > > > > > > > most important.
> > > > > > >
> > > > > > > The recommended production usage (= optimal)
> > > of JSPs is when they are
> > > > > > > precommpiled, which means that the Jasper
> > > servlet is not used, and the
> > > > > > > JSPs are plain servlets. Their lifecycle is
> > > then identical to the
> > > > > > > lifecycle of servlets.
> > > > > >
> > > > > >
> > > > > > I do not see any reason, why different
> > > servlets could not have different
> > > > > > life cycles.
> > > > > > Even more, the last sentence is in contrary to
> > > current implementation -
> > > > > > some servlets can be loaded not on demand, but
> > > on starting of a web
> > > > > > application.
> > > > > > So, their life cycle has already been _not_
> > > identical to the life cycle
> > > > > of
> > > > > > other servlets.
> > > > > >
> > > > > >
> > > > > > I understand the Jasper servlet is junk, and
> > > is a testing ground for bad
> > > > > > > ideas, though (ex: the background
> > > compilation thread, and now this).
> > > > > > >
> > > > > > > Rémy
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Yaroslav Sokolov.
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Yaroslav Sokolov.
> > > >
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail:
> > > dev-help@tomcat.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Mar 7, 2006, at 5:59 PM, Remy Maucherat wrote:
> Yoav Shapira wrote:
>> Hola,
>> Let's all try to stay professional.
>
> Then why do you selectively ignore this guy's blatant whining ?
>
>> Yaroslav or whomever else is interested: if you can produce a
>> patch that
>> (a) Can be turned on or off
>> (b) Is set to off by default, so current behavior is unmodified
>> unless
>> the user turns it on
>> (c) Doesn't harm anything else
>> (d) Comes with a test case that shows it doesn't harm anything else
>> Then I'm sure you can get 3 +1 votes and have the patch incorporated.
>
> I simply do not see any overall technical focus anymore in this
> project, it's just chaos, and users, as long as they whine loud
> enough seem to get anything they want included. This doesn't sound
> appealing to me.
>
Well, 3 binding +1 votes and no (valid) vetos means that yes,
if someone wants the code enough and at least 3 of those who have
authority over the code agree, and no one has a valid veto, then
it gets in.
Otherwise you have many things, but not an ASF project.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> It's not as much a +1 to the feature itself, it's a +1 to an open
> communication channel and a professional debate.
Very well. I think I'll leave you to your wonderful professional
discussion then.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> Yoav Shapira wrote:
> > Hola,
> > Let's all try to stay professional.
>
> Then why do you selectively ignore this guy's blatant whining ?
Because I don't want to waste time commenting on it -- it's not a
topic of interest for me, not a use-case I need.
> I simply do not see any overall technical focus anymore in this project,
> it's just chaos, and users, as long as they whine loud enough seem to
> get anything they want included. This doesn't sound appealing to me.
There's always pushing and pulling between people wanting a feature
and people wanting the product to stay as clean, lean, and focused as
possible. Like you (Remy), I'm usually on the clean, lean, and
focused side.
But when more than one or two users who seem to have a clue of what
they're doing express desire for the same feature, and it's a small
enough feature so that it can be easily enabled or disabled in a
configuration file, and at least one committer other than myself
appears interested as well, I don't mind giving it to them at the
expense of a little "technical focus."
It's not as much a +1 to the feature itself, it's a +1 to an open
communication channel and a professional debate.
Yoav
--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hola,
> Let's all try to stay professional.
Then why do you selectively ignore this guy's blatant whining ?
> Yaroslav or whomever else is interested: if you can produce a patch that
>
> (a) Can be turned on or off
> (b) Is set to off by default, so current behavior is unmodified unless
> the user turns it on
> (c) Doesn't harm anything else
> (d) Comes with a test case that shows it doesn't harm anything else
>
> Then I'm sure you can get 3 +1 votes and have the patch incorporated.
I simply do not see any overall technical focus anymore in this project,
it's just chaos, and users, as long as they whine loud enough seem to
get anything they want included. This doesn't sound appealing to me.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Why would anyone serve 'uncached small files' or parse properties on
> each request ???
> Well, maybe that was the (incomplete) implementation long ago - and I
> agree, it would be really bad for performance.
If you have more than 100MB of JSPs, I think the request distribution is
going to be well spread out.
> The static file can be loaded in init(), in a cache ( LRU or more
> complex, or just a weak reference ) - if the jsp is not used for a
> long time and the strings get GC, it'll have a small hit on the next
> usage - similar with the initial load. And it might have a small
> impact because of the cache and the weak reference versus final
> Strings.
> But I think it may compensate in other area - the memory is a very
> unpredictable thing, I've seen many cases where reducing the pressure
> and having more free space is faster than keeping everything in memory
> when the load is high ( because hight load usually means a small
> portion of the code is hit hard, and makes use of the extra memory,
> etc )
Yes. Nowehere else could I see the need to refactor, complexify and add
bugs to cater to edge cases and improbable scenarios. The power of OSS
(or at least, ASF's take on OSS).
> Anyway - there is no point trying to predict how performance will be
> affected, if there is a patch it's easy to check.
Sure.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/8/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > I believe I did some tests at that time and didn't seem so bad.
> > It's not like it's going to read the strings/files on each request -
> > it's loading them
> > once, and will stay in memory for all the 'hot' jsps. The difference between a
> > static final String access and a loaded String is not that big, and
> > for GC - it'll
> > get to the old generation quite soon.
> >
> > Do you have any test - or technical reason - why it would be 'really bad' ?
> > I'm very interested - it's allways good to learn new things about GC...
> > In any case - my thinking at that time was that this should be the
> > default mode for 3.3 if it matures. Not sure what was the exact
> > benchmark I used - but I was quite obsessed with performance.
>
> I believe serving multiple uncached small files as part of a single
> request will have bad performance. If using properties files, pre
> request parsing will be involved, which seems costly. I don't see how to
> avoid this issue.
Why would anyone serve 'uncached small files' or parse properties on
each request ???
Well, maybe that was the (incomplete) implementation long ago - and I
agree, it would be really bad for performance.
The static file can be loaded in init(), in a cache ( LRU or more
complex, or just a weak reference ) - if the jsp is not used for a
long time and the strings get GC, it'll have a small hit on the next
usage - similar with the initial load. And it might have a small
impact because of the cache and the weak reference versus final
Strings.
But I think it may compensate in other area - the memory is a very
unpredictable thing, I've seen many cases where reducing the pressure
and having more free space is faster than keeping everything in memory
when the load is high ( because hight load usually means a small
portion of the code is hit hard, and makes use of the extra memory,
etc )
Anyway - there is no point trying to predict how performance will be
affected, if there is a patch it's easy to check.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> I believe I did some tests at that time and didn't seem so bad.
> It's not like it's going to read the strings/files on each request -
> it's loading them
> once, and will stay in memory for all the 'hot' jsps. The difference between a
> static final String access and a loaded String is not that big, and
> for GC - it'll
> get to the old generation quite soon.
>
> Do you have any test - or technical reason - why it would be 'really bad' ?
> I'm very interested - it's allways good to learn new things about GC...
> In any case - my thinking at that time was that this should be the
> default mode for 3.3 if it matures. Not sure what was the exact
> benchmark I used - but I was quite obsessed with performance.
I believe serving multiple uncached small files as part of a single
request will have bad performance. If using properties files, pre
request parsing will be involved, which seems costly. I don't see how to
avoid this issue.
> Well, that would probably be bad for tomcat - and longer term bad for
> your own tree :-)
> There are a lot of valid reasons to contribute - or not contribute -
> to a project.
Actually, for the rest of the code, it goes really well so far.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > Tomcat 3.0 didn't have bad performance because design decisons, but
> > because poor implementation.
> > IMO 3.3 was reasonably good as performance - even for JSP. Not sure if
> > 4.0 was so much faster at that time.
> > It's possible our memory is affected by our opinions - but I'm pretty
> > sure that lower footprint in 3.3 had a good impact on general
> > performance, not a bad one.
>
> If you ever use external strings/files or similar, performance is going
> to be really bad. Most likely this was not enabled in your testing.
I believe I did some tests at that time and didn't seem so bad.
It's not like it's going to read the strings/files on each request -
it's loading them
once, and will stay in memory for all the 'hot' jsps. The difference between a
static final String access and a loaded String is not that big, and
for GC - it'll
get to the old generation quite soon.
Do you have any test - or technical reason - why it would be 'really bad' ?
I'm very interested - it's allways good to learn new things about GC...
In any case - my thinking at that time was that this should be the
default mode for 3.3 if it matures. Not sure what was the exact
benchmark I used - but I was quite obsessed with performance.
>
> >> Sorry, but I have a perfectly valid reason to give a -1. It's very
> >> simple from my perspective anyway: I will make sure I will not be using
> >> patches such as this one, and so I will maintain my own Jasper branch
> >> (as I am doing for the rest of the container).
> >
> > It is indeed a valid -1 on your own tree :-)
>
> Yes, but then I think I will do what the Sun folks are doing: I'll
> forget contributing back the useful stuff, and only come back with
> annoyances.
Well, that would probably be bad for tomcat - and longer term bad for
your own tree :-)
There are a lot of valid reasons to contribute - or not contribute -
to a project.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Tomcat 3.0 didn't have bad performance because design decisons, but
> because poor implementation.
> IMO 3.3 was reasonably good as performance - even for JSP. Not sure if
> 4.0 was so much faster at that time.
> It's possible our memory is affected by our opinions - but I'm pretty
> sure that lower footprint in 3.3 had a good impact on general
> performance, not a bad one.
If you ever use external strings/files or similar, performance is going
to be really bad. Most likely this was not enabled in your testing.
>> Sorry, but I have a perfectly valid reason to give a -1. It's very
>> simple from my perspective anyway: I will make sure I will not be using
>> patches such as this one, and so I will maintain my own Jasper branch
>> (as I am doing for the rest of the container).
>
> It is indeed a valid -1 on your own tree :-)
Yes, but then I think I will do what the Sun folks are doing: I'll
forget contributing back the useful stuff, and only come back with
annoyances.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > "slow" usually requires a context - i.e. server type, memory, CPU,
> > expected load.
> > And beeing 'fastest' is not allways the most important thing for
> > everyone - fastest jsp won't help if it OOM or if other components get
> > less memory.
> >
> > Footprint is as important as well.
>
> The is the sort of design decisions and resultant performance that was
> in Tomcat 3.0's JSP and which gave Tomcat a bad name for *years*. Since
> it's all in the name of helping this one user and his nice 300MB of
> JSPs, it is not a good move, even if optional.
Tomcat 3.0 didn't have bad performance because design decisons, but
because poor implementation.
IMO 3.3 was reasonably good as performance - even for JSP. Not sure if
4.0 was so much faster at that time.
It's possible our memory is affected by our opinions - but I'm pretty
sure that lower footprint in 3.3 had a good impact on general
performance, not a bad one.
>
> >> - it adds complexity
> >> - it will create additional code generation paths that will not be
> >> tested (as usual)
> >
> > Almost every feature will add some complexity, and will be tested by
> > the subset of people who need it ( example: the apr library :-)
>
> Actually, this is false. Countless features stopped working one day
> after their initial submission because there was casual interest in
> them, and only a handful of users (which never upgraded) were using
> them. This is definitely the case here, and overall, this makes Tomcat
> lower quality.
True - many of the features are only used by very few people ( as a
percentage ).
And also true that adding all the features - without more modularity -
is bad for tomcat
quality.
> Sorry, but I have a perfectly valid reason to give a -1. It's very
> simple from my perspective anyway: I will make sure I will not be using
> patches such as this one, and so I will maintain my own Jasper branch
> (as I am doing for the rest of the container).
It is indeed a valid -1 on your own tree :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> "slow" usually requires a context - i.e. server type, memory, CPU,
> expected load.
> And beeing 'fastest' is not allways the most important thing for
> everyone - fastest jsp won't help if it OOM or if other components get
> less memory.
>
> Footprint is as important as well.
The is the sort of design decisions and resultant performance that was
in Tomcat 3.0's JSP and which gave Tomcat a bad name for *years*. Since
it's all in the name of helping this one user and his nice 300MB of
JSPs, it is not a good move, even if optional.
>> - it adds complexity
>> - it will create additional code generation paths that will not be
>> tested (as usual)
>
> Almost every feature will add some complexity, and will be tested by
> the subset of people who need it ( example: the apr library :-)
Actually, this is false. Countless features stopped working one day
after their initial submission because there was casual interest in
them, and only a handful of users (which never upgraded) were using
them. This is definitely the case here, and overall, this makes Tomcat
lower quality.
>> - I contend that in 2006 it is useless
>
> It is useless for people who run huge servers and can fit everything in memory.
>
> It is not useless for people who have lots of JSPs or run on shared memory.
I know you are not going to give up.
>>> I feel strongly about this issue because I am concerned with using
>>> tomcat in lower memory environments ( not only my extreme case, but
>>> also on 'regular' computers where tomcat is not the center of the
>>> universe and can't take all the memory ). Remy is obviously concerned
>>> about big server case where performance is a very important issue.
>>> Having a flag can do both cases - except that the code is already
>>> complex, so it's better to be worth it. Of course, if the patch is
>>> also cleaning up jspservlet and makes it easy - that won't be an issue
>>> :-)
>> The problem is that the issues you care about have caused some trouble
>> lately, so I don't feel very compelled to follow your opinions on this one.
>
> We all cause some troubles from time to time, and tend to value our own opinions
> a bit high. Luckily - this is not about following my opinion or my
> troubles - it's about
> a tomcat feature. The fact that it's useless for yourself, or that 3.3
> was slow, or that adding any code increases complexity and testing are
> not IMO valid reasons to veto.
Sorry, but I have a perfectly valid reason to give a -1. It's very
simple from my perspective anyway: I will make sure I will not be using
patches such as this one, and so I will maintain my own Jasper branch
(as I am doing for the rest of the container).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > Well, it the patch is based on unloading the JSP - it won't be easy,
> > the -1 that Remy expressed initially seems valid ( and all it takes to
> > make it valid is a second comitter, which I just did ). So according
> > to the rules it won't work - and even if it would work, it may still
> > cause unexpected breakage of applications which is bad.
> >
> > If it externalizes the strings - I don't see what valid veto can be
> > raised, we did this in the past ( 3.3 - not complete ). It would also
> > help to have some simple 'ab' tests to show how much is lost in raw
> > performance - it's allways a tradeoff between memory and disk, and a
> > lot of applications work just fine without keeping all in memory - but
> > it's good to know numbers instead of talking about our assumptions.
>
> Let's see:
> - it will be slow (I can find really embarrassing Tomcat 3.x JSP
> performance graphs, if you want)
"slow" usually requires a context - i.e. server type, memory, CPU,
expected load.
And beeing 'fastest' is not allways the most important thing for
everyone - fastest jsp won't help if it OOM or if other components get
less memory.
Footprint is as important as well.
> - it adds complexity
> - it will create additional code generation paths that will not be
> tested (as usual)
Almost every feature will add some complexity, and will be tested by
the subset of people who need it ( example: the apr library :-)
> - I contend that in 2006 it is useless
It is useless for people who run huge servers and can fit everything in memory.
It is not useless for people who have lots of JSPs or run on shared memory.
>
> > I feel strongly about this issue because I am concerned with using
> > tomcat in lower memory environments ( not only my extreme case, but
> > also on 'regular' computers where tomcat is not the center of the
> > universe and can't take all the memory ). Remy is obviously concerned
> > about big server case where performance is a very important issue.
> > Having a flag can do both cases - except that the code is already
> > complex, so it's better to be worth it. Of course, if the patch is
> > also cleaning up jspservlet and makes it easy - that won't be an issue
> > :-)
>
> The problem is that the issues you care about have caused some trouble
> lately, so I don't feel very compelled to follow your opinions on this one.
We all cause some troubles from time to time, and tend to value our own opinions
a bit high. Luckily - this is not about following my opinion or my
troubles - it's about
a tomcat feature. The fact that it's useless for yourself, or that 3.3
was slow, or that adding any code increases complexity and testing are
not IMO valid reasons to veto.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Well, it the patch is based on unloading the JSP - it won't be easy,
> the -1 that Remy expressed initially seems valid ( and all it takes to
> make it valid is a second comitter, which I just did ). So according
> to the rules it won't work - and even if it would work, it may still
> cause unexpected breakage of applications which is bad.
>
> If it externalizes the strings - I don't see what valid veto can be
> raised, we did this in the past ( 3.3 - not complete ). It would also
> help to have some simple 'ab' tests to show how much is lost in raw
> performance - it's allways a tradeoff between memory and disk, and a
> lot of applications work just fine without keeping all in memory - but
> it's good to know numbers instead of talking about our assumptions.
Let's see:
- it will be slow (I can find really embarrassing Tomcat 3.x JSP
performance graphs, if you want)
- it adds complexity
- it will create additional code generation paths that will not be
tested (as usual)
- I contend that in 2006 it is useless
> I feel strongly about this issue because I am concerned with using
> tomcat in lower memory environments ( not only my extreme case, but
> also on 'regular' computers where tomcat is not the center of the
> universe and can't take all the memory ). Remy is obviously concerned
> about big server case where performance is a very important issue.
> Having a flag can do both cases - except that the code is already
> complex, so it's better to be worth it. Of course, if the patch is
> also cleaning up jspservlet and makes it easy - that won't be an issue
> :-)
The problem is that the issues you care about have caused some trouble
lately, so I don't feel very compelled to follow your opinions on this one.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
Well, it the patch is based on unloading the JSP - it won't be easy,
the -1 that Remy expressed initially seems valid ( and all it takes to
make it valid is a second comitter, which I just did ). So according
to the rules it won't work - and even if it would work, it may still
cause unexpected breakage of applications which is bad.
If it externalizes the strings - I don't see what valid veto can be
raised, we did this in the past ( 3.3 - not complete ). It would also
help to have some simple 'ab' tests to show how much is lost in raw
performance - it's allways a tradeoff between memory and disk, and a
lot of applications work just fine without keeping all in memory - but
it's good to know numbers instead of talking about our assumptions.
I feel strongly about this issue because I am concerned with using
tomcat in lower memory environments ( not only my extreme case, but
also on 'regular' computers where tomcat is not the center of the
universe and can't take all the memory ). Remy is obviously concerned
about big server case where performance is a very important issue.
Having a flag can do both cases - except that the code is already
complex, so it's better to be worth it. Of course, if the patch is
also cleaning up jspservlet and makes it easy - that won't be an issue
:-)
Costin
On 3/7/06, Yoav Shapira <yo...@apache.org> wrote:
> Hola,
> Let's all try to stay professional.
>
> Yaroslav or whomever else is interested: if you can produce a patch that
>
> (a) Can be turned on or off
> (b) Is set to off by default, so current behavior is unmodified unless
> the user turns it on
> (c) Doesn't harm anything else
> (d) Comes with a test case that shows it doesn't harm anything else
>
> Then I'm sure you can get 3 +1 votes and have the patch incorporated.
>
> Yoav
>
> On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> > S. Dierkes wrote:
> > > If you're still searching for a real world application: we have an
> > > application where JSP's are generated dynamically from database (no
> > > on-the-fly because to time consuming, so they are created offline),
> > > currently there had been ~1500 JSP's (~100MB) created (plus the application
> > > itself). The application creates JSP and PDF of real-world forms (fill in as
> > > html, print out as pdf) for different customers (mainly banks), so the
> > > jsp-base is constantly increasing.
> >
> > Lol, that's really pathetic ...
> >
> > Rémy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> --
> Yoav Shapira
> Senior Architect
> Nimalex LLC
> 1 Mifflin Place, Suite 310
> Cambridge, MA, USA
> yoavs@computer.org / www.yoavshapira.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
Let's all try to stay professional.
Yaroslav or whomever else is interested: if you can produce a patch that
(a) Can be turned on or off
(b) Is set to off by default, so current behavior is unmodified unless
the user turns it on
(c) Doesn't harm anything else
(d) Comes with a test case that shows it doesn't harm anything else
Then I'm sure you can get 3 +1 votes and have the patch incorporated.
Yoav
On 3/7/06, Remy Maucherat <re...@apache.org> wrote:
> S. Dierkes wrote:
> > If you're still searching for a real world application: we have an
> > application where JSP's are generated dynamically from database (no
> > on-the-fly because to time consuming, so they are created offline),
> > currently there had been ~1500 JSP's (~100MB) created (plus the application
> > itself). The application creates JSP and PDF of real-world forms (fill in as
> > html, print out as pdf) for different customers (mainly banks), so the
> > jsp-base is constantly increasing.
>
> Lol, that's really pathetic ...
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
S. Dierkes wrote:
> If you're still searching for a real world application: we have an
> application where JSP's are generated dynamically from database (no
> on-the-fly because to time consuming, so they are created offline),
> currently there had been ~1500 JSP's (~100MB) created (plus the application
> itself). The application creates JSP and PDF of real-world forms (fill in as
> html, print out as pdf) for different customers (mainly banks), so the
> jsp-base is constantly increasing.
Lol, that's really pathetic ...
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by "S. Dierkes" <sd...@mediaclockwork.de>.
If you're still searching for a real world application: we have an
application where JSP's are generated dynamically from database (no
on-the-fly because to time consuming, so they are created offline),
currently there had been ~1500 JSP's (~100MB) created (plus the application
itself). The application creates JSP and PDF of real-world forms (fill in as
html, print out as pdf) for different customers (mainly banks), so the
jsp-base is constantly increasing.
Ok, memory is not really an issue in production, since we can increase it on
demand, but a configurable memory behaviour could be a nice feature and
might save memory for other server purposes. Don't get me wrong, I think the
best solution for production is still more RAM, but at least for testing it
would be nice to have less needs for RAM.
-----Ursprüngliche Nachricht-----
Von: Leon Rosenberg [mailto:rosenberg.leon@googlemail.com]
Gesendet: Dienstag, 7. März 2006 16:20
An: Tomcat Developers List
Betreff: Re: What's about unloading policy of jsp-servlets ?
On 3/7/06, Renato <re...@yahoo.com> wrote:
> a webhosting company that has a shared JVM instance of
> tomcat for its websites and runs unmanaged code bumps
> into this kind of problem all the time ;)).
hmm... sorry, I host java webapps for customers, and this is my last
problem. I mean a typical webapp contains approx. 100 classes and 50 jsps?
Most of the classes are always in use and therefore in memory as well as the
jsps. I don't really see the problem here. I mean before I run out of memory
for JSPs, I will run out of memory for classes.... Leon
>
> --- Leon Rosenberg <ro...@googlemail.com>
> wrote:
>
> > Yaroslav,
> >
> > you've made great work with the patch, but honestly,
> > which real-world
> > application uses hunderds of megabytes of jsps?
> >
> > that just doesn't make sense...
> >
> > regards
> > Leon
> >
> > P.S. don't want to be offending, but i just can't
> > find a single use-case...
> >
> > On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> > wrote:
> > > Ok, I can make the next conclusions:
> > >
> > > 1. Tomcat eats resources on first opening of any
> > jsp page and never returns
> > > them back - servlets just are never unloaded.
> > > 2. As it happens in all the versions of Tomcat,
> > there are many jsps, not
> > > meeting requirements
> > > of the specification (no destroy() method when
> > there is some useful data in
> > > fields) but well working under Tomcat.
> > > 3. We do not want to change this situation ( -> I
> > shall not even try to send
> > > any better patch here :-\ (but I will ;-) ) )
> > >
> > > One more conclusion - if all the jsp content of
> > our web site does not fit in
> > > memory, we
> > > should buy more memory. Else we must not use jsp
> > technology in all the
> > > pages. We should choose
> > > something other than jsp, for example velocity,
> > SSI,...
> > >
> > > P.S. by the way, when web application is unloaded
> > such bad jsps lose data
> > > anyway.
> > >
> > > On 06/03/06, Costin Manolache <co...@gmail.com>
> > wrote:
> > > >
> > > > Starting is different from stopping.
> > > >
> > > > Yes, the spec allows unloading - but in reality
> > most JSPs and servlets
> > > > can't deal well with that. And the argument that
> > it is optional
> > > > doesn't work - in many cases the person who
> > writes the servlet/jsp is
> > > > not the same as the person who is running the
> > production server or
> > > > does the configuration tunning.
> > > >
> > > > There are subtle bugs that may show up when this
> > feature would be
> > > > enabled - people doing the config might be
> > tempted to reduce memory
> > > > use, and this would result in extremely hard to
> > reproduce and debug
> > > > problems.
> > > >
> > > > By 'spec compliance' I mean more 'compatibility
> > with the existing spec
> > > > _and_ the current usage of the spec'. The later
> > is IMO more important
> > > > in many cases than the letter or any
> > interpretation of the spec.
> > > >
> > > > Costin
> > > >
> > > > On 3/6/06, Yaroslav Sokolov
> > <ya...@gmail.com> wrote:
> > > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> > wrote:
> > > > > >
> > > > > > Costin Manolache wrote:
> > > > > > > But it's a separate issue - I agree that
> > unloading unused jsps is
> > > > the
> > > > > > > most important.
> > > > > >
> > > > > > The recommended production usage (= optimal)
> > of JSPs is when they are
> > > > > > precommpiled, which means that the Jasper
> > servlet is not used, and the
> > > > > > JSPs are plain servlets. Their lifecycle is
> > then identical to the
> > > > > > lifecycle of servlets.
> > > > >
> > > > >
> > > > > I do not see any reason, why different
> > servlets could not have different
> > > > > life cycles.
> > > > > Even more, the last sentence is in contrary to
> > current implementation -
> > > > > some servlets can be loaded not on demand, but
> > on starting of a web
> > > > > application.
> > > > > So, their life cycle has already been _not_
> > identical to the life cycle
> > > > of
> > > > > other servlets.
> > > > >
> > > > >
> > > > > I understand the Jasper servlet is junk, and
> > is a testing ground for bad
> > > > > > ideas, though (ex: the background
> > compilation thread, and now this).
> > > > > >
> > > > > > Rémy
> > > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Yaroslav Sokolov.
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Yaroslav Sokolov.
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:
> > dev-help@tomcat.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 3/7/06, Renato <re...@yahoo.com> wrote:
> a webhosting company that has a shared JVM instance of
> tomcat for its websites and runs unmanaged code bumps
> into this kind of problem all the time ;)).
hmm... sorry, I host java webapps for customers, and this is my last
problem. I mean a typical webapp contains approx. 100 classes and 50
jsps? Most of the classes are always in use and therefore in memory as
well as the jsps. I don't really see the problem here. I mean before I
run out of memory for JSPs, I will run out of memory for classes....
Leon
>
> --- Leon Rosenberg <ro...@googlemail.com>
> wrote:
>
> > Yaroslav,
> >
> > you've made great work with the patch, but honestly,
> > which real-world
> > application uses hunderds of megabytes of jsps?
> >
> > that just doesn't make sense...
> >
> > regards
> > Leon
> >
> > P.S. don't want to be offending, but i just can't
> > find a single use-case...
> >
> > On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> > wrote:
> > > Ok, I can make the next conclusions:
> > >
> > > 1. Tomcat eats resources on first opening of any
> > jsp page and never returns
> > > them back - servlets just are never unloaded.
> > > 2. As it happens in all the versions of Tomcat,
> > there are many jsps, not
> > > meeting requirements
> > > of the specification (no destroy() method when
> > there is some useful data in
> > > fields) but well working under Tomcat.
> > > 3. We do not want to change this situation ( -> I
> > shall not even try to send
> > > any better patch here :-\ (but I will ;-) ) )
> > >
> > > One more conclusion - if all the jsp content of
> > our web site does not fit in
> > > memory, we
> > > should buy more memory. Else we must not use jsp
> > technology in all the
> > > pages. We should choose
> > > something other than jsp, for example velocity,
> > SSI,...
> > >
> > > P.S. by the way, when web application is unloaded
> > such bad jsps lose data
> > > anyway.
> > >
> > > On 06/03/06, Costin Manolache <co...@gmail.com>
> > wrote:
> > > >
> > > > Starting is different from stopping.
> > > >
> > > > Yes, the spec allows unloading - but in reality
> > most JSPs and servlets
> > > > can't deal well with that. And the argument that
> > it is optional
> > > > doesn't work - in many cases the person who
> > writes the servlet/jsp is
> > > > not the same as the person who is running the
> > production server or
> > > > does the configuration tunning.
> > > >
> > > > There are subtle bugs that may show up when this
> > feature would be
> > > > enabled - people doing the config might be
> > tempted to reduce memory
> > > > use, and this would result in extremely hard to
> > reproduce and debug
> > > > problems.
> > > >
> > > > By 'spec compliance' I mean more 'compatibility
> > with the existing spec
> > > > _and_ the current usage of the spec'. The later
> > is IMO more important
> > > > in many cases than the letter or any
> > interpretation of the spec.
> > > >
> > > > Costin
> > > >
> > > > On 3/6/06, Yaroslav Sokolov
> > <ya...@gmail.com> wrote:
> > > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> > wrote:
> > > > > >
> > > > > > Costin Manolache wrote:
> > > > > > > But it's a separate issue - I agree that
> > unloading unused jsps is
> > > > the
> > > > > > > most important.
> > > > > >
> > > > > > The recommended production usage (= optimal)
> > of JSPs is when they are
> > > > > > precommpiled, which means that the Jasper
> > servlet is not used, and the
> > > > > > JSPs are plain servlets. Their lifecycle is
> > then identical to the
> > > > > > lifecycle of servlets.
> > > > >
> > > > >
> > > > > I do not see any reason, why different
> > servlets could not have different
> > > > > life cycles.
> > > > > Even more, the last sentence is in contrary to
> > current implementation -
> > > > > some servlets can be loaded not on demand, but
> > on starting of a web
> > > > > application.
> > > > > So, their life cycle has already been _not_
> > identical to the life cycle
> > > > of
> > > > > other servlets.
> > > > >
> > > > >
> > > > > I understand the Jasper servlet is junk, and
> > is a testing ground for bad
> > > > > > ideas, though (ex: the background
> > compilation thread, and now this).
> > > > > >
> > > > > > Rémy
> > > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Yaroslav Sokolov.
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Yaroslav Sokolov.
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail:
> > dev-help@tomcat.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Renato <re...@yahoo.com>.
a webhosting company that has a shared JVM instance of
tomcat for its websites and runs unmanaged code bumps
into this kind of problem all the time ;)).
--- Leon Rosenberg <ro...@googlemail.com>
wrote:
> Yaroslav,
>
> you've made great work with the patch, but honestly,
> which real-world
> application uses hunderds of megabytes of jsps?
>
> that just doesn't make sense...
>
> regards
> Leon
>
> P.S. don't want to be offending, but i just can't
> find a single use-case...
>
> On 3/7/06, Yaroslav Sokolov <ya...@gmail.com>
> wrote:
> > Ok, I can make the next conclusions:
> >
> > 1. Tomcat eats resources on first opening of any
> jsp page and never returns
> > them back - servlets just are never unloaded.
> > 2. As it happens in all the versions of Tomcat,
> there are many jsps, not
> > meeting requirements
> > of the specification (no destroy() method when
> there is some useful data in
> > fields) but well working under Tomcat.
> > 3. We do not want to change this situation ( -> I
> shall not even try to send
> > any better patch here :-\ (but I will ;-) ) )
> >
> > One more conclusion - if all the jsp content of
> our web site does not fit in
> > memory, we
> > should buy more memory. Else we must not use jsp
> technology in all the
> > pages. We should choose
> > something other than jsp, for example velocity,
> SSI,...
> >
> > P.S. by the way, when web application is unloaded
> such bad jsps lose data
> > anyway.
> >
> > On 06/03/06, Costin Manolache <co...@gmail.com>
> wrote:
> > >
> > > Starting is different from stopping.
> > >
> > > Yes, the spec allows unloading - but in reality
> most JSPs and servlets
> > > can't deal well with that. And the argument that
> it is optional
> > > doesn't work - in many cases the person who
> writes the servlet/jsp is
> > > not the same as the person who is running the
> production server or
> > > does the configuration tunning.
> > >
> > > There are subtle bugs that may show up when this
> feature would be
> > > enabled - people doing the config might be
> tempted to reduce memory
> > > use, and this would result in extremely hard to
> reproduce and debug
> > > problems.
> > >
> > > By 'spec compliance' I mean more 'compatibility
> with the existing spec
> > > _and_ the current usage of the spec'. The later
> is IMO more important
> > > in many cases than the letter or any
> interpretation of the spec.
> > >
> > > Costin
> > >
> > > On 3/6/06, Yaroslav Sokolov
> <ya...@gmail.com> wrote:
> > > > On 04/03/06, Remy Maucherat <re...@apache.org>
> wrote:
> > > > >
> > > > > Costin Manolache wrote:
> > > > > > But it's a separate issue - I agree that
> unloading unused jsps is
> > > the
> > > > > > most important.
> > > > >
> > > > > The recommended production usage (= optimal)
> of JSPs is when they are
> > > > > precommpiled, which means that the Jasper
> servlet is not used, and the
> > > > > JSPs are plain servlets. Their lifecycle is
> then identical to the
> > > > > lifecycle of servlets.
> > > >
> > > >
> > > > I do not see any reason, why different
> servlets could not have different
> > > > life cycles.
> > > > Even more, the last sentence is in contrary to
> current implementation -
> > > > some servlets can be loaded not on demand, but
> on starting of a web
> > > > application.
> > > > So, their life cycle has already been _not_
> identical to the life cycle
> > > of
> > > > other servlets.
> > > >
> > > >
> > > > I understand the Jasper servlet is junk, and
> is a testing ground for bad
> > > > > ideas, though (ex: the background
> compilation thread, and now this).
> > > > >
> > > > > Rémy
> > > > >
> > > >
> > > > --
> > > > Regards,
> > > > Yaroslav Sokolov.
> > > >
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Yaroslav Sokolov.
> >
> >
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail:
> dev-help@tomcat.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Leon Rosenberg <ro...@googlemail.com>.
Yaroslav,
you've made great work with the patch, but honestly, which real-world
application uses hunderds of megabytes of jsps?
that just doesn't make sense...
regards
Leon
P.S. don't want to be offending, but i just can't find a single use-case...
On 3/7/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> Ok, I can make the next conclusions:
>
> 1. Tomcat eats resources on first opening of any jsp page and never returns
> them back - servlets just are never unloaded.
> 2. As it happens in all the versions of Tomcat, there are many jsps, not
> meeting requirements
> of the specification (no destroy() method when there is some useful data in
> fields) but well working under Tomcat.
> 3. We do not want to change this situation ( -> I shall not even try to send
> any better patch here :-\ (but I will ;-) ) )
>
> One more conclusion - if all the jsp content of our web site does not fit in
> memory, we
> should buy more memory. Else we must not use jsp technology in all the
> pages. We should choose
> something other than jsp, for example velocity, SSI,...
>
> P.S. by the way, when web application is unloaded such bad jsps lose data
> anyway.
>
> On 06/03/06, Costin Manolache <co...@gmail.com> wrote:
> >
> > Starting is different from stopping.
> >
> > Yes, the spec allows unloading - but in reality most JSPs and servlets
> > can't deal well with that. And the argument that it is optional
> > doesn't work - in many cases the person who writes the servlet/jsp is
> > not the same as the person who is running the production server or
> > does the configuration tunning.
> >
> > There are subtle bugs that may show up when this feature would be
> > enabled - people doing the config might be tempted to reduce memory
> > use, and this would result in extremely hard to reproduce and debug
> > problems.
> >
> > By 'spec compliance' I mean more 'compatibility with the existing spec
> > _and_ the current usage of the spec'. The later is IMO more important
> > in many cases than the letter or any interpretation of the spec.
> >
> > Costin
> >
> > On 3/6/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> > > On 04/03/06, Remy Maucherat <re...@apache.org> wrote:
> > > >
> > > > Costin Manolache wrote:
> > > > > But it's a separate issue - I agree that unloading unused jsps is
> > the
> > > > > most important.
> > > >
> > > > The recommended production usage (= optimal) of JSPs is when they are
> > > > precommpiled, which means that the Jasper servlet is not used, and the
> > > > JSPs are plain servlets. Their lifecycle is then identical to the
> > > > lifecycle of servlets.
> > >
> > >
> > > I do not see any reason, why different servlets could not have different
> > > life cycles.
> > > Even more, the last sentence is in contrary to current implementation -
> > > some servlets can be loaded not on demand, but on starting of a web
> > > application.
> > > So, their life cycle has already been _not_ identical to the life cycle
> > of
> > > other servlets.
> > >
> > >
> > > I understand the Jasper servlet is junk, and is a testing ground for bad
> > > > ideas, though (ex: the background compilation thread, and now this).
> > > >
> > > > Rémy
> > > >
> > >
> > > --
> > > Regards,
> > > Yaroslav Sokolov.
> > >
> > >
> >
>
>
> --
> Regards,
> Yaroslav Sokolov.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
Ok, I can make the next conclusions:
1. Tomcat eats resources on first opening of any jsp page and never returns
them back - servlets just are never unloaded.
2. As it happens in all the versions of Tomcat, there are many jsps, not
meeting requirements
of the specification (no destroy() method when there is some useful data in
fields) but well working under Tomcat.
3. We do not want to change this situation ( -> I shall not even try to send
any better patch here :-\ (but I will ;-) ) )
One more conclusion - if all the jsp content of our web site does not fit in
memory, we
should buy more memory. Else we must not use jsp technology in all the
pages. We should choose
something other than jsp, for example velocity, SSI,...
P.S. by the way, when web application is unloaded such bad jsps lose data
anyway.
On 06/03/06, Costin Manolache <co...@gmail.com> wrote:
>
> Starting is different from stopping.
>
> Yes, the spec allows unloading - but in reality most JSPs and servlets
> can't deal well with that. And the argument that it is optional
> doesn't work - in many cases the person who writes the servlet/jsp is
> not the same as the person who is running the production server or
> does the configuration tunning.
>
> There are subtle bugs that may show up when this feature would be
> enabled - people doing the config might be tempted to reduce memory
> use, and this would result in extremely hard to reproduce and debug
> problems.
>
> By 'spec compliance' I mean more 'compatibility with the existing spec
> _and_ the current usage of the spec'. The later is IMO more important
> in many cases than the letter or any interpretation of the spec.
>
> Costin
>
> On 3/6/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> > On 04/03/06, Remy Maucherat <re...@apache.org> wrote:
> > >
> > > Costin Manolache wrote:
> > > > But it's a separate issue - I agree that unloading unused jsps is
> the
> > > > most important.
> > >
> > > The recommended production usage (= optimal) of JSPs is when they are
> > > precommpiled, which means that the Jasper servlet is not used, and the
> > > JSPs are plain servlets. Their lifecycle is then identical to the
> > > lifecycle of servlets.
> >
> >
> > I do not see any reason, why different servlets could not have different
> > life cycles.
> > Even more, the last sentence is in contrary to current implementation -
> > some servlets can be loaded not on demand, but on starting of a web
> > application.
> > So, their life cycle has already been _not_ identical to the life cycle
> of
> > other servlets.
> >
> >
> > I understand the Jasper servlet is junk, and is a testing ground for bad
> > > ideas, though (ex: the background compilation thread, and now this).
> > >
> > > Rémy
> > >
> >
> > --
> > Regards,
> > Yaroslav Sokolov.
> >
> >
>
--
Regards,
Yaroslav Sokolov.
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
Starting is different from stopping.
Yes, the spec allows unloading - but in reality most JSPs and servlets
can't deal well with that. And the argument that it is optional
doesn't work - in many cases the person who writes the servlet/jsp is
not the same as the person who is running the production server or
does the configuration tunning.
There are subtle bugs that may show up when this feature would be
enabled - people doing the config might be tempted to reduce memory
use, and this would result in extremely hard to reproduce and debug
problems.
By 'spec compliance' I mean more 'compatibility with the existing spec
_and_ the current usage of the spec'. The later is IMO more important
in many cases than the letter or any interpretation of the spec.
Costin
On 3/6/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> On 04/03/06, Remy Maucherat <re...@apache.org> wrote:
> >
> > Costin Manolache wrote:
> > > But it's a separate issue - I agree that unloading unused jsps is the
> > > most important.
> >
> > The recommended production usage (= optimal) of JSPs is when they are
> > precommpiled, which means that the Jasper servlet is not used, and the
> > JSPs are plain servlets. Their lifecycle is then identical to the
> > lifecycle of servlets.
>
>
> I do not see any reason, why different servlets could not have different
> life cycles.
> Even more, the last sentence is in contrary to current implementation -
> some servlets can be loaded not on demand, but on starting of a web
> application.
> So, their life cycle has already been _not_ identical to the life cycle of
> other servlets.
>
>
> I understand the Jasper servlet is junk, and is a testing ground for bad
> > ideas, though (ex: the background compilation thread, and now this).
> >
> > Rémy
> >
>
> --
> Regards,
> Yaroslav Sokolov.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
On 04/03/06, Remy Maucherat <re...@apache.org> wrote:
>
> Costin Manolache wrote:
> > But it's a separate issue - I agree that unloading unused jsps is the
> > most important.
>
> The recommended production usage (= optimal) of JSPs is when they are
> precommpiled, which means that the Jasper servlet is not used, and the
> JSPs are plain servlets. Their lifecycle is then identical to the
> lifecycle of servlets.
I do not see any reason, why different servlets could not have different
life cycles.
Even more, the last sentence is in contrary to current implementation -
some servlets can be loaded not on demand, but on starting of a web
application.
So, their life cycle has already been _not_ identical to the life cycle of
other servlets.
I understand the Jasper servlet is junk, and is a testing ground for bad
> ideas, though (ex: the background compilation thread, and now this).
>
> Rémy
>
--
Regards,
Yaroslav Sokolov.
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>> Costin Manolache wrote:
>>> Using less memory and supporting users who don't run tomcat on huge
>> servers
>>> is not
>>> ridiculous. And 'this is not my use case' is not a valid reason to veto
>> IMO.
>>
>> We're talking about a very small amount of memory. Webapps which have
>> lots of large JSPs are not small webapps, obviously: they are going to
>> require lots of resources anyway. Using straight classes is quite
>> efficient besides the small initial memory cost.
>
>
> I have a feeling you only look at one use case ( high perf, heavy loaded
> server )
> and can't accept there are other reasonable use cases. Well - probably I do
> the
> same :-), as I care more about my use case ( tomcat using low resources )
> than
> the big server.
How are you going to run the sort of applications we are talking about
with low amounts of memory. I am waiting for your arguments.
> Maybe you have a lot of large files and just a bit of 'dynamic' behavior -
> and most
> pages won't get 100 requests per second, maybe just few requests per minute.
As you are aware, every technology and associated implementation has a
way to make them misbehave. I think I can also come up with perfectly
legitimate examples which defeat a low memory implementation, and make
it run like crap for no reason.
> There are many web servers like this.
Web servers which use JSPs ?
> Not all JSP uses are complex 'build a
> pet store with
> as many taglibs as possible'. Having a lot of content doesn't mean you need
> a lot of
> memory or CPU resources ( just a big hard drive ). The only thing that
> requires lots of
> resources - even if the load is very low - is the implementation of jasper,
> and even this
> patch can solve some of the worse effects.
These sort of uses will not require a huge amount of JSPs. Having 1MB
worth of JSP files is pretty big already (ex: the admin webapp is made
of 600KB of JSPs).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>
> Costin Manolache wrote:
> > Using less memory and supporting users who don't run tomcat on huge
> servers
> > is not
> > ridiculous. And 'this is not my use case' is not a valid reason to veto
> IMO.
>
> We're talking about a very small amount of memory. Webapps which have
> lots of large JSPs are not small webapps, obviously: they are going to
> require lots of resources anyway. Using straight classes is quite
> efficient besides the small initial memory cost.
I have a feeling you only look at one use case ( high perf, heavy loaded
server )
and can't accept there are other reasonable use cases. Well - probably I do
the
same :-), as I care more about my use case ( tomcat using low resources )
than
the big server.
Maybe you have a lot of large files and just a bit of 'dynamic' behavior -
and most
pages won't get 100 requests per second, maybe just few requests per minute.
There are many web servers like this. Not all JSP uses are complex 'build a
pet store with
as many taglibs as possible'. Having a lot of content doesn't mean you need
a lot of
memory or CPU resources ( just a big hard drive ). The only thing that
requires lots of
resources - even if the load is very low - is the implementation of jasper,
and even this
patch can solve some of the worse effects.
Anyway - there is not point to argue, at least until someone has a better
patch.
I agree that unloading JSPs is not the best solution.
Costin
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Using less memory and supporting users who don't run tomcat on huge servers
> is not
> ridiculous. And 'this is not my use case' is not a valid reason to veto IMO.
We're talking about a very small amount of memory. Webapps which have
lots of large JSPs are not small webapps, obviously: they are going to
require lots of resources anyway. Using straight classes is quite
efficient besides the small initial memory cost.
> How are JSPs GC friendly ??? By keeping all strings referenced by the class,
> so they
> can't be GC until the webapp is unloaded ?
Trying to argue with you is a complete waste of time. I meant,
obviously, that this makes it very easy to not generate a ton of garbage
objects per invocation.
> I think it is perfectly possible to compile JSPs in a different way - the
> current compilation
> is not the only solution or only way to generate java from the jsps.
Whatever you say.
> I also agree with you that JSPs are complex enough that messing with the
> code generation
> is too dangerous - I wouldn't touch it, but if some people have patches, we
> should consider
> them.
They should bring a demonstrably useful benefit. This proposed redesign
is only useful thanks to Sun's VM memory management.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Jacob Hookom wrote:
> Couldn't it be as straight forward as doing a composite cache in the Jsp
> Servlet-- an LRU of a specific size that demotes to a weakhashmap?
> Leave the compiler as is (the whole thing should be re-written though).
As I said earlier, there's already plenty of "cool" features in the JSP
servlet (through the runtime context), so one more cannot be the end of
the world (if it's that simple).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Jacob Hookom <ja...@hookom.net>.
Couldn't it be as straight forward as doing a composite cache in the Jsp
Servlet-- an LRU of a specific size that demotes to a weakhashmap?
Leave the compiler as is (the whole thing should be re-written though).
Costin Manolache wrote:
>On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>
>
>>Costin Manolache wrote:
>>
>>
>>>On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>>>
>>>
>>>
>>>>I also don't see any need to have zillions of JSPs filled with template
>>>>text, especially if you're willing to take a small performance hit
>>>>(there's that thing called dynamic includes which could be used to
>>>>handle large portions of static text).
>>>>
>>>>
>>>Well, unfortunately tomcat-dev's role is to implement a servlet
>>>
>>>
>>container,
>>
>>
>>>not to
>>>decide how people should use it and how many JSPs or other technologies
>>>should
>>>the use, or how they should set up their hardware :-)
>>>I don't think it's good to target a single use case or set of users -
>>>
>>>
>>i.e.
>>
>>
>>>huge servers, and
>>>sites with small enough number of JSPs to fit in memory.
>>>
>>>
>>This is blatantly false. tomcat-dev's role is to come up with an
>>implementation. There's nowhere anything specified about complying with
>>anyone's needs. Here, I consider the needs of this user ridiculous, so I
>>will not even consider them.
>>
>>
>
>
>Using less memory and supporting users who don't run tomcat on huge servers
>is not
>ridiculous. And 'this is not my use case' is not a valid reason to veto IMO.
>
>
>
>
>
>
>>>>Many cases would benefit from more control over memory - hosting or
>>>>
>>>>
>>>>>embedded or sites with lots of jsps or lots of data. Forcing all
>>>>>static content in memory is not the best use of the memory.
>>>>>
>>>>>
>>>>There's no other solution really. Any other implementation will perform
>>>>bad, due to the very fragmented nature of static text.
>>>>
>>>>
>>>Apache seems to do ok with serving static text without loading it all in
>>>memory :-)
>>>And except JSP, I don't know many other templating solution that
>>>
>>>
>>requires
>>
>>
>>>all data
>>> to be in memory - of course, not everything is as fast as JSP, but raw
>>>speed is not
>>>the only concern :-)
>>>
>>>
>>You are trolling here. I would be more than happy to serve JSPs as
>>static text, but somehow I cannot. Again, JSPs are not a regular
>>templating solution since they have to be compiled. This is not all bad,
>>since this allows easy optimizations too (for example, the JSPs are GC
>>friendly).
>>
>>
>
>
>How are JSPs GC friendly ??? By keeping all strings referenced by the class,
>so they
>can't be GC until the webapp is unloaded ?
>
>I think it is perfectly possible to compile JSPs in a different way - the
>current compilation
>is not the only solution or only way to generate java from the jsps.
>
>I also agree with you that JSPs are complex enough that messing with the
>code generation
>is too dangerous - I wouldn't touch it, but if some people have patches, we
>should consider
>them.
>
>Costin
>
>
>
--
Jacob Hookom - Minneapolis
----------------------------
JSF-EG, JSF-RI, EL, Facelets
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>
> Costin Manolache wrote:
> > On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
> >
> >> I also don't see any need to have zillions of JSPs filled with template
> >> text, especially if you're willing to take a small performance hit
> >> (there's that thing called dynamic includes which could be used to
> >> handle large portions of static text).
> >
> >
> > Well, unfortunately tomcat-dev's role is to implement a servlet
> container,
> > not to
> > decide how people should use it and how many JSPs or other technologies
> > should
> > the use, or how they should set up their hardware :-)
> > I don't think it's good to target a single use case or set of users -
> i.e.
> > huge servers, and
> > sites with small enough number of JSPs to fit in memory.
>
> This is blatantly false. tomcat-dev's role is to come up with an
> implementation. There's nowhere anything specified about complying with
> anyone's needs. Here, I consider the needs of this user ridiculous, so I
> will not even consider them.
Using less memory and supporting users who don't run tomcat on huge servers
is not
ridiculous. And 'this is not my use case' is not a valid reason to veto IMO.
>>> Many cases would benefit from more control over memory - hosting or
> >>> embedded or sites with lots of jsps or lots of data. Forcing all
> >>> static content in memory is not the best use of the memory.
> >> There's no other solution really. Any other implementation will perform
> >> bad, due to the very fragmented nature of static text.
> >
> > Apache seems to do ok with serving static text without loading it all in
> > memory :-)
> > And except JSP, I don't know many other templating solution that
> requires
> > all data
> > to be in memory - of course, not everything is as fast as JSP, but raw
> > speed is not
> > the only concern :-)
>
> You are trolling here. I would be more than happy to serve JSPs as
> static text, but somehow I cannot. Again, JSPs are not a regular
> templating solution since they have to be compiled. This is not all bad,
> since this allows easy optimizations too (for example, the JSPs are GC
> friendly).
How are JSPs GC friendly ??? By keeping all strings referenced by the class,
so they
can't be GC until the webapp is unloaded ?
I think it is perfectly possible to compile JSPs in a different way - the
current compilation
is not the only solution or only way to generate java from the jsps.
I also agree with you that JSPs are complex enough that messing with the
code generation
is too dangerous - I wouldn't touch it, but if some people have patches, we
should consider
them.
Costin
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>
>> I also don't see any need to have zillions of JSPs filled with template
>> text, especially if you're willing to take a small performance hit
>> (there's that thing called dynamic includes which could be used to
>> handle large portions of static text).
>
>
> Well, unfortunately tomcat-dev's role is to implement a servlet container,
> not to
> decide how people should use it and how many JSPs or other technologies
> should
> the use, or how they should set up their hardware :-)
> I don't think it's good to target a single use case or set of users - i.e.
> huge servers, and
> sites with small enough number of JSPs to fit in memory.
This is blatantly false. tomcat-dev's role is to come up with an
implementation. There's nowhere anything specified about complying with
anyone's needs. Here, I consider the needs of this user ridiculous, so I
will not even consider them.
>>> Many cases would benefit from more control over memory - hosting or
>>> embedded or sites with lots of jsps or lots of data. Forcing all
>>> static content in memory is not the best use of the memory.
>> There's no other solution really. Any other implementation will perform
>> bad, due to the very fragmented nature of static text.
>
> Apache seems to do ok with serving static text without loading it all in
> memory :-)
> And except JSP, I don't know many other templating solution that requires
> all data
> to be in memory - of course, not everything is as fast as JSP, but raw
> speed is not
> the only concern :-)
You are trolling here. I would be more than happy to serve JSPs as
static text, but somehow I cannot. Again, JSPs are not a regular
templating solution since they have to be compiled. This is not all bad,
since this allows easy optimizations too (for example, the JSPs are GC
friendly).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
>
> I also don't see any need to have zillions of JSPs filled with template
> text, especially if you're willing to take a small performance hit
> (there's that thing called dynamic includes which could be used to
> handle large portions of static text).
Well, unfortunately tomcat-dev's role is to implement a servlet container,
not to
decide how people should use it and how many JSPs or other technologies
should
the use, or how they should set up their hardware :-)
I don't think it's good to target a single use case or set of users - i.e.
huge servers, and
sites with small enough number of JSPs to fit in memory.
> > Many cases would benefit from more control over memory - hosting or
> > embedded or sites with lots of jsps or lots of data. Forcing all
> > static content in memory is not the best use of the memory.
>
> There's no other solution really. Any other implementation will perform
> bad, due to the very fragmented nature of static text.
Apache seems to do ok with serving static text without loading it all in
memory :-)
And except JSP, I don't know many other templating solution that requires
all data
to be in memory - of course, not everything is as fast as JSP, but raw
speed is not
the only concern :-)
>> BTW, I am ok with shipping additional presentation technologies with
> >> Tomcat, we do not need to give JSP any special treatment anymore.
> >
> > True, may be better to implement such a thing without all the
> > complexity of taglibs, etc.
> >
> > Well - my home web server has 32M RAM on a 200 Mhz arm ... :-). Of
> > course, I don't plan to run jsp on it - but coyote works well enough.
>
> Did you look at the other presentation layer technologies available, and
> how appropriate they would be for your environment ?
Suggestions ? I was thinking of something as simple as SSI ( since the
code is already there ),
I just need to adapt it for coyote.
Costin
Re: What's about unloading policy of jsp-servlets ?
Posted by David Rees <dr...@gmail.com>.
On 3/5/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > Many cases would benefit from more control over memory - hosting or
> > embedded or sites with lots of jsps or lots of data. Forcing all
> > static content in memory is not the best use of the memory.
>
> There's no other solution really. Any other implementation will perform
> bad, due to the very fragmented nature of static text.
One way to offset the poor performance of having highly fragmented
static text would be to only externalize strings which exceed a
specific size. This would have the benefit of reducing the number of
external references while also reducing the amount of memory used by
JSPs.
Having this variable tunable would allow end-users to test and tune
for their workload. Set it small to reduce memory utilization, set it
high to improve performance, or disable it alltogether to keep the
existing behavior.
-Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> The point is not how much memory you have - but to have control over
> how it is used. There are plenty of other things that might benefit
> from staying in memory - a large cache for the data, etc. Many servers
> might have 4+ G RAM, but they tend to run multiple processes and a JVM
> might not get all the memory ( also keep in mind the interaction
> between java and swap might not be pleasant - and jsp/class data can't
> be paged out, it's very MM unfriendly )
I don't think it represents a large amount of data, and I also don't
think you could allocate this relatively small amount og memory to a
more efficient cache (db caches need an order of magnitude more memory,
for example). The main problem is the static way that the Sun VMs use to
manage this portion of memory.
I also don't see any need to have zillions of JSPs filled with template
text, especially if you're willing to take a small performance hit
(there's that thing called dynamic includes which could be used to
handle large portions of static text).
>> It still doesn't cost much to give some more perm gen to Sun's VM (still
>> a fairly manageable amount IMO, but of course, if you want to do hosting
>> or it's an embedded situation, it's a problem).
>
> Many cases would benefit from more control over memory - hosting or
> embedded or sites with lots of jsps or lots of data. Forcing all
> static content in memory is not the best use of the memory.
There's no other solution really. Any other implementation will perform
bad, due to the very fragmented nature of static text.
>> BTW, I am ok with shipping additional presentation technologies with
>> Tomcat, we do not need to give JSP any special treatment anymore.
>
> True, may be better to implement such a thing without all the
> complexity of taglibs, etc.
>
> Well - my home web server has 32M RAM on a 200 Mhz arm ... :-). Of
> course, I don't plan to run jsp on it - but coyote works well enough.
Did you look at the other presentation layer technologies available, and
how appropriate they would be for your environment ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/5/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>
>
>
> On 3/5/06, Costin Manolache <co...@gmail.com> wrote:
> >
> > It seems this patch won't pass - but maybe other patches could make at
> > least
> > small improvements in reducing the required memory use, and let users do
> > the
> > trade they want.
>
>
> I do not position this patch as solution of the problem. This patch is
> just illustration
> that there is such a problem and it is possible to be solved solved.
>
We actually know that jsp is keeping all content as class data for a very
long time :-).
And also suspect it can be solved - there are few other things tried in the
past.
And finally, it is interesting the oppinion if we want to unload
> jsp-servlets at all or not.
> (My opinion is that we should not waste memory by rare or just-once used
> things, as
> finally it makes the web server out of service.)
>
It seems the answer is no - tomcat require consensus and at least Remy is
-1.
I kind if agree it's not the right solution ( most people don't expect jsps
to get unloaded, and don't code for
that ) - but I tought it might be a nice option to have.
If you really need this - try a different patch, and check with Remy on what
are his concerns and how
to address them.
If yes, I offer to have fixed maximal number of loaded jsp-servlets per
> web-application
> and true handling of this policy. I mean, that is must not be possible to
> have at the
> same time more loaded jsp-servlets than it is set by the policy. Of
> course, such a
> policy should be optional.
>
> Implementation of such a policy, as I already have written, is more
> complex patch than
> the illustration: "as internal structure containing jsp-servlets, it
> seems, was not designed for
> such actions..."
>
Yes, it may be better to fix jasper and do the harder solutions.
My understanding of Remy's veto is that JSPs should behave like all servlets
- i.e. shouldn't get unloaded
or loaded unexpectedly. It was also my concern ( users not expecting jsps to
get unloaded, and using statics, etc)
So you will need a more complex patch - I suggested unloading the string
tables ( which in your case are the bulk of the memory used ), but there
are probably other solutions as well. Good luck, IMO it would be great to
have this
improved !
Costin
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
On 3/5/06, Costin Manolache <co...@gmail.com> wrote:
>
> It seems this patch won't pass - but maybe other patches could make at
> least
> small improvements in reducing the required memory use, and let users do
> the
> trade they want.
I do not position this patch as solution of the problem. This patch is just
illustration
that there is such a problem and it is possible to be solved solved.
And finally, it is interesting the oppinion if we want to unload
jsp-servlets at all or not.
(My opinion is that we should not waste memory by rare or just-once used
things, as
finally it makes the web server out of service.)
If yes, I offer to have fixed maximal number of loaded jsp-servlets per
web-application
and true handling of this policy. I mean, that is must not be possible to
have at the
same time more loaded jsp-servlets than it is set by the policy. Of course,
such a
policy should be optional.
Implementation of such a policy, as I already have written, is more complex
patch than
the illustration: "as internal structure containing jsp-servlets, it seems,
was not designed for
such actions..."
--
Regards,
Yaroslav Sokolov.
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/4/06, Bill Barker <wb...@wilshire.com> wrote:
>
> "Costin Manolache" <co...@gmail.com> wrote in message
> news:96e4b5230603041605l41f5ee3bud032aaa14d8f9427@mail.gmail.com...
> On 3/4/06, Remy Maucherat <re...@apache.org> wrote:
> >> The only solution is to forbid
> >> scriptlets (or as an option use a processing when a page does not
> >> contain scriptlets - and of course, rewrite a significant amount of
> >> Jasper - way cool :D), in which case compilation is not needed, and we
> >> can simply execute the nodes (memory is saved by optionally discarding
> >> the nodes between requests).
> >
> >Why ? It could as well save all static content in a separate file ( I
> >remember this was implemented at least in part ), and instead of
> >generating the strings in the class, use
> >a cache that manages the string table.
> >
>
> The Jasper with 3.3 has this as an option. Since it's main use was to
> shrink the size of the _jspservice method, and Jasper2 has a better
approach
> to this, it was dropped in Jasper2. Also, in 3.3 Jasper, the static text
> object is a static object in the class, so you don't get any memory
benifits
> from using it.
>
> I'm also with Remy on this that almost all users would rather trade memory
> for speed on this issue. However, if you want to make it an optional
> behavior for Jasper to store the static text as either a serialized char
> [][] as in TC 3.3, or ResourceBundle, by all means, knock yourself out
;-).
3.3 implementation was far from perfect, but I think it was in a good
direction.
It seems this patch won't pass - but maybe other patches could make at least
small improvements in reducing the required memory use, and let users do the
trade they want.
I agree with you and Remy that memory is cheap and it's good to trade memory
for
speed - if you can fit all your database, plus all the pages and servlets in
memory - you have a perfect situation. But there are a lot of cases where
you can't put everything in memory, and you have to choose what to keep in
memory - maybe a large buffer for database, and some common pages - but keep
infrequently used stuff out, or unload
things that are not in use. It's not always as simple as 'just keep
everything in ram'.
>
> >That would be more flexible than this patch - and allow more control
> >over how much memory is used. Well - with all the APR and sendfile you
> >could even try to send large chunks of static content from disk - not
> >sure what's the performance benefits in the static servlet for
> >example.
> >
>
> In most non-example JSPs, there really aren't many big blocks of static
text
> to sendfile. They tend to look more like:
> <c:forEach items="${itemList.items}" var="foo">
> <tr><td>${foo.name}</td><td>${foo.price}</td><td>${foo.available
}</td></tr>
> </c:forEach>
>
Unfortunately jasper ( and JSPs ) are a bit too complex - maybe a simpler
template system
could be used to play with such memory management experiments.
Well - since JSP has no chance of fitting in my memory requirements ( 32M
RAM on my NSLU2 ) -
I'll probably have to try something...
Costin
Re: What's about unloading policy of jsp-servlets ?
Posted by Bill Barker <wb...@wilshire.com>.
"Costin Manolache" <co...@gmail.com> wrote in message
news:96e4b5230603041605l41f5ee3bud032aaa14d8f9427@mail.gmail.com...
On 3/4/06, Remy Maucherat <re...@apache.org> wrote:
>> The only solution is to forbid
>> scriptlets (or as an option use a processing when a page does not
>> contain scriptlets - and of course, rewrite a significant amount of
>> Jasper - way cool :D), in which case compilation is not needed, and we
>> can simply execute the nodes (memory is saved by optionally discarding
>> the nodes between requests).
>
>Why ? It could as well save all static content in a separate file ( I
>remember this was implemented at least in part ), and instead of
>generating the strings in the class, use
>a cache that manages the string table.
>
The Jasper with 3.3 has this as an option. Since it's main use was to
shrink the size of the _jspservice method, and Jasper2 has a better approach
to this, it was dropped in Jasper2. Also, in 3.3 Jasper, the static text
object is a static object in the class, so you don't get any memory benifits
from using it.
I'm also with Remy on this that almost all users would rather trade memory
for speed on this issue. However, if you want to make it an optional
behavior for Jasper to store the static text as either a serialized char
[][] as in TC 3.3, or ResourceBundle, by all means, knock yourself out ;-).
>That would be more flexible than this patch - and allow more control
>over how much memory is used. Well - with all the APR and sendfile you
>could even try to send large chunks of static content from disk - not
>sure what's the performance benefits in the static servlet for
>example.
>
In most non-example JSPs, there really aren't many big blocks of static text
to sendfile. They tend to look more like:
<c:forEach items="${itemList.items}" var="foo">
<tr><td>${foo.name}</td><td>${foo.price}</td><td>${foo.available}</td></tr>
</c:forEach>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/4/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > Good point, fixing jasper servlet is a not going to help in production
> > env ( and precompiled jsps), so it's probably not worth it.
> >
> > However - I disagree that JSPs are 'just' servlets - or at least they
> > should not be plain and stupid translation of text to 'println'
> > servlets. The current behavior of jsps wrt memory is horrible if you
> > have lot of content - all the plain text ends up in memory, as part of
> > the class. It's good for cheating on benchmarks - bad for production.
> > There are far better ways to use the memory.
>
> The alternative is wasting CPU and disk reading stuff from disk all over
> again for nothing, which for most servers are even more useful
> resources. We're talking about using less than 128MB of memory here, so
> it's not too much (who has more than 128MB of static text in his JSPs ?).
The point is not how much memory you have - but to have control over
how it is used. There are plenty of other things that might benefit
from staying in memory - a large cache for the data, etc. Many servers
might have 4+ G RAM, but they tend to run multiple processes and a JVM
might not get all the memory ( also keep in mind the interaction
between java and swap might not be pleasant - and jsp/class data can't
be paged out, it's very MM unfriendly )
>
> If you're interested in the lowest footprint, JSP is not the right
> technology: you need a templating (or anything not compiled) technology
> and disable its caching features (it will be quite slow, but will use
> minimal amounts of resident memory).
I'm interested in having control over memory use.
Jasper currently requires that all JSP content is kept in RAM - but it
can as well use some fixed cache ( like 64M or 128M ) and work better
for sites with lots of jsps or less ram.
I think JSP is not that bad ( well, there are a lot of bad things in
it ) - it is good to have the logic compiled to a java class. My
problem is with the static data implementation in jasper.
> The only solution is to forbid
> scriptlets (or as an option use a processing when a page does not
> contain scriptlets - and of course, rewrite a significant amount of
> Jasper - way cool :D), in which case compilation is not needed, and we
> can simply execute the nodes (memory is saved by optionally discarding
> the nodes between requests).
Why ? It could as well save all static content in a separate file ( I
remember this was implemented at least in part ), and instead of
generating the strings in the class, use
a cache that manages the string table.
That would be more flexible than this patch - and allow more control
over how much memory is used. Well - with all the APR and sendfile you
could even try to send large chunks of static content from disk - not
sure what's the performance benefits in the static servlet for
example.
>
> > IMO separating the strings and loading/unloading them using a cache
> > would help a lot in such situations ( i.e. large number of jsps ==
> > huge memory use ). Unloading not frequently/recently used jsps ( and
> > servlets, and webapps ) might also be very nice, assuming they can
> > handle being unloaded. But I agree that the current patch is not the
> > right solution.
>
> Unloading the servlet's instance is possible, not the class definition.
That's because of the class loader per webapps - I think a flat
classloader ( jboss-style ) could handle unloading serlvet definition.
But this is not the problem with jsps - if the static content is
stored as data ( in separate file from .class ), you don't even need
to unload the jsp instance. Unlike a servlet, jsp has the flexibility
to generate any code it wants.
> Unloading webapps is not possible at the moment (even if it was, modern
> webapps take ages and tons of resources to start, so it wouldn't be
> practical IMO).
Case by case. Unloading and loading webapps dynamically used to work :-)
> It still doesn't cost much to give some more perm gen to Sun's VM (still
> a fairly manageable amount IMO, but of course, if you want to do hosting
> or it's an embedded situation, it's a problem).
Many cases would benefit from more control over memory - hosting or
embedded or sites with lots of jsps or lots of data. Forcing all
static content in memory is not the best use of the memory.
> BTW, I am ok with shipping additional presentation technologies with
> Tomcat, we do not need to give JSP any special treatment anymore.
True, may be better to implement such a thing without all the
complexity of taglibs, etc.
Well - my home web server has 32M RAM on a 200 Mhz arm ... :-). Of
course, I don't plan to run jsp on it - but coyote works well enough.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Good point, fixing jasper servlet is a not going to help in production
> env ( and precompiled jsps), so it's probably not worth it.
>
> However - I disagree that JSPs are 'just' servlets - or at least they
> should not be plain and stupid translation of text to 'println'
> servlets. The current behavior of jsps wrt memory is horrible if you
> have lot of content - all the plain text ends up in memory, as part of
> the class. It's good for cheating on benchmarks - bad for production.
> There are far better ways to use the memory.
The alternative is wasting CPU and disk reading stuff from disk all over
again for nothing, which for most servers are even more useful
resources. We're talking about using less than 128MB of memory here, so
it's not too much (who has more than 128MB of static text in his JSPs ?).
If you're interested in the lowest footprint, JSP is not the right
technology: you need a templating (or anything not compiled) technology
and disable its caching features (it will be quite slow, but will use
minimal amounts of resident memory). The only solution is to forbid
scriptlets (or as an option use a processing when a page does not
contain scriptlets - and of course, rewrite a significant amount of
Jasper - way cool :D), in which case compilation is not needed, and we
can simply execute the nodes (memory is saved by optionally discarding
the nodes between requests).
> IMO separating the strings and loading/unloading them using a cache
> would help a lot in such situations ( i.e. large number of jsps ==
> huge memory use ). Unloading not frequently/recently used jsps ( and
> servlets, and webapps ) might also be very nice, assuming they can
> handle being unloaded. But I agree that the current patch is not the
> right solution.
Unloading the servlet's instance is possible, not the class definition.
Unloading webapps is not possible at the moment (even if it was, modern
webapps take ages and tons of resources to start, so it wouldn't be
practical IMO).
It still doesn't cost much to give some more perm gen to Sun's VM (still
a fairly manageable amount IMO, but of course, if you want to do hosting
or it's an embedded situation, it's a problem).
BTW, I am ok with shipping additional presentation technologies with
Tomcat, we do not need to give JSP any special treatment anymore.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
Good point, fixing jasper servlet is a not going to help in production
env ( and precompiled jsps), so it's probably not worth it.
However - I disagree that JSPs are 'just' servlets - or at least they
should not be plain and stupid translation of text to 'println'
servlets. The current behavior of jsps wrt memory is horrible if you
have lot of content - all the plain text ends up in memory, as part of
the class. It's good for cheating on benchmarks - bad for production.
There are far better ways to use the memory.
IMO separating the strings and loading/unloading them using a cache
would help a lot in such situations ( i.e. large number of jsps ==
huge memory use ). Unloading not frequently/recently used jsps ( and
servlets, and webapps ) might also be very nice, assuming they can
handle being unloaded. But I agree that the current patch is not the
right solution.
Costin
On 3/4/06, Remy Maucherat <re...@apache.org> wrote:
> Costin Manolache wrote:
> > But it's a separate issue - I agree that unloading unused jsps is the
> > most important.
>
> The recommended production usage (= optimal) of JSPs is when they are
> precommpiled, which means that the Jasper servlet is not used, and the
> JSPs are plain servlets. Their lifecycle is then identical to the
> lifecycle of servlets.
>
> I understand the Jasper servlet is junk, and is a testing ground for bad
> ideas, though (ex: the background compilation thread, and now this).
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> But it's a separate issue - I agree that unloading unused jsps is the
> most important.
The recommended production usage (= optimal) of JSPs is when they are
precommpiled, which means that the Jasper servlet is not used, and the
JSPs are plain servlets. Their lifecycle is then identical to the
lifecycle of servlets.
I understand the Jasper servlet is junk, and is a testing ground for bad
ideas, though (ex: the background compilation thread, and now this).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
On 03/03/06, Costin Manolache <co...@gmail.com> wrote:
>
>
> [skipped]
>
> The difficult question is - how does it affect the spec compliance ?
it is friendly to the spec ;-) :
[start quoting of Java™ Servlet Specification Version 2.4]
SRV.2.3.4 End of Service
The servlet container is not required to keep a servlet loaded for any
particular
period of time. A servlet instance may be kept active in a servlet container
for a
period of milliseconds, for the lifetime of the servlet container (which
could be a
number of days, months, or years), or any amount of time in between.
[end quoting]
My understanding was that container is allowed to unload servlets and
> jsps and webapps whenever he wants. The only problem I see is
> servlets/jsps using fields - static or not, I assume people don't
> expect them to go away and don't have code in destroy() to save state.
I hope there are not so many jsps described above. In any case, if such a
policy was optional - it can be not turned on for web applications like
these.
Also, there are such jsps just because of provocation that once loaded
servlet
has never been unloaded until shutting down of the web application.
So it might break a lot of code.
>
>
>
> Costin
>
[skipped]
--
Regards,
Yaroslav Sokolov.
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> Actually I found this strings-problem as well. I even created a patch to
> test how it affects on memory filling.
>
> The result was the next. When strings were stored outside of *.class files,
> number of loaded jsp-servlets increased about 3 times. Time of generation of
> *.jsp -> *.java -> *.class files was moderate decreased. But finally, all the
> memory were occupied by jsp-servlets and tomcat threw OOME exception...
The compile time is lower because the .java source is smaller.
Are you sure the soft strings were unloaded ? I would expect the
remaining .java/.class to be quite small for a static .html -
eventually it'll throw OOM, but after a lot of .html files.
But it's a separate issue - I agree that unloading unused jsps is the
most important.
The difficult question is - how does it affect the spec compliance ?
My understanding was that container is allowed to unload servlets and
jsps and webapps whenever he wants. The only problem I see is
servlets/jsps using fields - static or not, I assume people don't
expect them to go away and don't have code in destroy() to save state.
So it might break a lot of code.
Costin
>
> (I put strings to separated file, loaded them only of necessity and kept only
> soft references to these strings.)
>
> Regards,
> Yarick.
>
> Costin Manolache wrote:
> > Thanks for the patch...
> >
> > This is a well known problem, JSPs are not unloaded unless the entire
> > webapp is unloaded. And to make things worse - by default all JSP
> > static content is compiled to strings, that take all the memory. I
> > think we have ( or had ) an option to generate some non .class file -
> > which could be more easily managed.
> >
> > Unfortunately I'm not familiar enough with jasper code - but it looks
> > good to me. The model of keeping the entire jsp static content in
> > memory forever is IMO very broken... It may help cheat on some
> > benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
> > world.
> >
> >
> > Costin
> >
> > On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> >
> >>Hi,
> >>
> >>I have found, that once loaded jsp-servlets are never unloaded.
> >>
> >>To test I just configured tomcat to process *.html files by JspServlet
> >>and then traversed jdk documentation. The result was not very exciting -
> >>after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
> >>and started not to work...
> >>
> >>So maybe it would be not a bad idea to try to keep in memeory just some fixed
> >>number of jsp-servlets ?
> >>
> >>I have written a sample implementation of such a policy, but it is not very elegant
> >>as internal structure containing jsp-servlets, it seems, was not designed for such actions...
> >>
> >>Regards,
> >>Yarick.
>
> [skipped]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Yarick, can you open a defect in bugzilla and attach the patch, once we
have a few more developers look at it,
we can apply it,
also let us know if you'd be interested in working with the group to
come up with a per context configurable cache mechanism
Filip
Yaroslav Sokolov wrote:
> Actually I found this strings-problem as well. I even created a
> patch to
> test how it affects on memory filling.
>
> The result was the next. When strings were stored outside of *.class
> files,
> number of loaded jsp-servlets increased about 3 times. Time of
> generation of
> *.jsp -> *.java -> *.class files was moderate decreased. But finally,
> all the
> memory were occupied by jsp-servlets and tomcat threw OOME exception...
>
> (I put strings to separated file, loaded them only of necessity and
> kept only
> soft references to these strings.)
>
> Regards,
> Yarick.
>
> Costin Manolache wrote:
>> Thanks for the patch...
>>
>> This is a well known problem, JSPs are not unloaded unless the entire
>> webapp is unloaded. And to make things worse - by default all JSP
>> static content is compiled to strings, that take all the memory. I
>> think we have ( or had ) an option to generate some non .class file -
>> which could be more easily managed.
>>
>> Unfortunately I'm not familiar enough with jasper code - but it looks
>> good to me. The model of keeping the entire jsp static content in
>> memory forever is IMO very broken... It may help cheat on some
>> benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
>> world.
>>
>>
>> Costin
>>
>> On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have found, that once loaded jsp-servlets are never unloaded.
>>>
>>> To test I just configured tomcat to process *.html files by JspServlet
>>> and then traversed jdk documentation. The result was not very
>>> exciting -
>>> after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError:
>>> Java heap space"
>>> and started not to work...
>>>
>>> So maybe it would be not a bad idea to try to keep in memeory just
>>> some fixed
>>> number of jsp-servlets ?
>>>
>>> I have written a sample implementation of such a policy, but it is
>>> not very elegant
>>> as internal structure containing jsp-servlets, it seems, was not
>>> designed for such actions...
>>>
>>> Regards,
>>> Yarick.
>
> [skipped]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Yaroslav Sokolov <ya...@gmail.com>.
Actually I found this strings-problem as well. I even created a patch to
test how it affects on memory filling.
The result was the next. When strings were stored outside of *.class files,
number of loaded jsp-servlets increased about 3 times. Time of generation of
*.jsp -> *.java -> *.class files was moderate decreased. But finally, all the
memory were occupied by jsp-servlets and tomcat threw OOME exception...
(I put strings to separated file, loaded them only of necessity and kept only
soft references to these strings.)
Regards,
Yarick.
Costin Manolache wrote:
> Thanks for the patch...
>
> This is a well known problem, JSPs are not unloaded unless the entire
> webapp is unloaded. And to make things worse - by default all JSP
> static content is compiled to strings, that take all the memory. I
> think we have ( or had ) an option to generate some non .class file -
> which could be more easily managed.
>
> Unfortunately I'm not familiar enough with jasper code - but it looks
> good to me. The model of keeping the entire jsp static content in
> memory forever is IMO very broken... It may help cheat on some
> benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
> world.
>
>
> Costin
>
> On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
>
>>Hi,
>>
>>I have found, that once loaded jsp-servlets are never unloaded.
>>
>>To test I just configured tomcat to process *.html files by JspServlet
>>and then traversed jdk documentation. The result was not very exciting -
>>after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
>>and started not to work...
>>
>>So maybe it would be not a bad idea to try to keep in memeory just some fixed
>>number of jsp-servlets ?
>>
>>I have written a sample implementation of such a policy, but it is not very elegant
>>as internal structure containing jsp-servlets, it seems, was not designed for such actions...
>>
>>Regards,
>>Yarick.
[skipped]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: What's about unloading policy of jsp-servlets ?
Posted by Costin Manolache <co...@gmail.com>.
Thanks for the patch...
This is a well known problem, JSPs are not unloaded unless the entire
webapp is unloaded. And to make things worse - by default all JSP
static content is compiled to strings, that take all the memory. I
think we have ( or had ) an option to generate some non .class file -
which could be more easily managed.
Unfortunately I'm not familiar enough with jasper code - but it looks
good to me. The model of keeping the entire jsp static content in
memory forever is IMO very broken... It may help cheat on some
benchmarks ( i.e. jsp versus html, etc ), but it's wrong for real
world.
Costin
On 3/3/06, Yaroslav Sokolov <ya...@gmail.com> wrote:
> Hi,
>
> I have found, that once loaded jsp-servlets are never unloaded.
>
> To test I just configured tomcat to process *.html files by JspServlet
> and then traversed jdk documentation. The result was not very exciting -
> after browsing ~ 150 pages tomcat cried "java.lang.OutOfMemoryError: Java heap space"
> and started not to work...
>
> So maybe it would be not a bad idea to try to keep in memeory just some fixed
> number of jsp-servlets ?
>
> I have written a sample implementation of such a policy, but it is not very elegant
> as internal structure containing jsp-servlets, it seems, was not designed for such actions...
>
> Regards,
> Yarick.
>
>
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOptions.java 2006-02-21 13:26:44.984221000 +0100
> @@ -174,6 +174,17 @@
> */
> private boolean xpoweredBy;
>
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + private int maxLoadedJsps = 20;
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + private int jspUnloadTestInterval = 4;
> +
> public String getProperty(String name ) {
> return settings.getProperty( name );
> }
> @@ -355,6 +366,14 @@
> return null;
> }
>
> + public int getMaxLoadedJsps() {
> + return maxLoadedJsps;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return jspUnloadTestInterval;
> + }
> +
> /**
> * Create an EmbeddedServletOptions object using data available from
> * ServletConfig and ServletContext.
> @@ -636,6 +655,40 @@
> }
> }
>
> + String maxLoadedJsps = config.getInitParameter("maxLoadedJsps");
> + if (maxLoadedJsps != null) {
> + try {
> + this.maxLoadedJsps = Integer.parseInt(maxLoadedJsps);
> + if (this.maxLoadedJsps <= 0) {
> + this.maxLoadedJsps = 20;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.maxLoadedJsps", ""+this.maxLoadedJsps));
> + }
> + }
> + }
> +
> + String jspUnloadTestInterval = config.getInitParameter("jspUnloadTestInterval");
> + if (jspUnloadTestInterval != null) {
> + try {
> + this.jspUnloadTestInterval = Integer.parseInt(jspUnloadTestInterval);
> + if (this.jspUnloadTestInterval <= 0) {
> + this.jspUnloadTestInterval = 4;
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + } catch(NumberFormatException ex) {
> + if (log.isWarnEnabled()) {
> + log.warn(Localizer.getMessage("jsp.warning.jspUnloadTestInterval",""+this.jspUnloadTestInterval));
> + }
> + }
> + }
> +
> // Setup the global Tag Libraries location cache for this
> // web-application.
> tldLocationsCache = new TldLocationsCache(context);
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/JspC.java 2006-02-21 13:27:07.568387400 +0100
> @@ -448,6 +448,14 @@
> return cache;
> }
>
> + public int getMaxLoadedJsps() {
> + return 0;
> + }
> +
> + public int getJspUnloadTestInterval() {
> + return 0;
> + }
> +
> /**
> * Background compilation check intervals in seconds
> */
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/Options.java 2006-02-21 13:27:24.210173000 +0100
> @@ -184,5 +184,16 @@
> * @return the Map(String uri, TreeNode tld) instance.
> */
> public Map getCache();
> +
> + /**
> + * The maxim number of loaded jsps per web-application. If there are more
> + * jsps loaded, they will be unloaded.
> + */
> + public int getMaxLoadedJsps();
> +
> + /**
> + * How often it is tryed to unload jsps (in seconds)
> + */
> + public int getJspUnloadTestInterval();
>
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java 2006-02-21 13:16:29.004201800 +0100
> @@ -25,10 +25,7 @@
> import java.security.PermissionCollection;
> import java.security.Policy;
> import java.security.cert.Certificate;
> -import java.util.Collections;
> -import java.util.HashMap;
> -import java.util.Iterator;
> -import java.util.Map;
> +import java.util.*; // yarick: java.util.HashMap -> java.util.*
>
> import javax.servlet.ServletContext;
> import javax.servlet.jsp.JspFactory;
> @@ -148,8 +145,8 @@
> /**
> * Maps JSP pages to their JspServletWrapper's
> */
> - private Map jsps = Collections.synchronizedMap( new HashMap());
> -
> + private Map jsps = Collections.synchronizedMap( new LinkedHashMap( 16, 0.75f, true ) ); // yarick: HashMap -> LinkedHashMap
> +
>
> /**
> * The background thread.
> @@ -192,6 +189,21 @@
> }
>
> /**
> + * Get an already existing JspServletWrapper and increases services count.
> + *
> + * @param jspUri JSP URI
> + * @return JspServletWrapper for JSP
> + */
> + public JspServletWrapper getWrapperAndIncService(String jspUri) {
> + JspServletWrapper jswr;
> + synchronized( jsps ) {
> + jswr = (JspServletWrapper) jsps.get(jspUri);
> + if( null != jswr ) jswr.incService();
> + }
> + return jswr;
> + }
> +
> + /**
> * Remove a JspServletWrapper.
> *
> * @param jspUri JSP URI of JspServletWrapper to remove
> @@ -521,4 +533,28 @@
>
> }
>
> +// { inserted by Yarick
> +
> + /** must be called from synchronized by {@link org.apache.jasper.servlet.JspServlet} context */
> + public JspServletWrapper getJspForUnload()
> + {
> + int MAX_UNLOADABLE_JSPS = 10;
> + if( jsps.size() > MAX_UNLOADABLE_JSPS ) {
> + JspServletWrapper jsw = null;
> + synchronized( jsps ) {
> + Iterator it = jsps.entrySet().iterator();
> + for( int rest_jsps=jsps.size(); rest_jsps > MAX_UNLOADABLE_JSPS && it.hasNext(); --rest_jsps ) {
> + jsw = (JspServletWrapper) ( (Map.Entry) it.next() ).getValue();
> + if( jsw.getExecutingServicesCount() == 0 && !jsw.isTagFile() ) {
> + it.remove();
> + return jsw;
> + }
> + }
> + }
> + }
> + return null;
> + }
> +
> +// } inserted by Yarick
> +
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-01-03 10:14:02.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServlet.java 2006-02-21 13:37:08.060784200 +0100
> @@ -17,8 +17,9 @@
> package org.apache.jasper.servlet;
>
> import java.io.IOException;
> +import java.io.File;
> import java.lang.reflect.Constructor;
> -import java.util.Enumeration;
> +import java.util.*;
>
> import javax.servlet.ServletConfig;
> import javax.servlet.ServletContext;
> @@ -97,8 +98,10 @@
> options = new EmbeddedServletOptions(config, context);
> }
> rctxt = new JspRuntimeContext(context, options);
> -
> - if (log.isDebugEnabled()) {
> +
> + startUnloadJspsThread(); // inserted by yarick
> +
> + if (log.isDebugEnabled()) {
> log.debug(Localizer.getMessage("jsp.message.scratch.dir.is",
> options.getScratchDir().toString()));
> log.debug(Localizer.getMessage("jsp.message.dont.modify.servlets"));
> @@ -278,7 +281,7 @@
> if (log.isDebugEnabled()) {
> log.debug("JspServlet.destroy()");
> }
> -
> + stopUnloadJspsThread(); // inserted by yarick
> rctxt.destroy();
> }
>
> @@ -290,29 +293,99 @@
> Throwable exception, boolean precompile)
> throws ServletException, IOException {
>
> - JspServletWrapper wrapper =
> - (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - synchronized(this) {
> - wrapper = (JspServletWrapper) rctxt.getWrapper(jspUri);
> - if (wrapper == null) {
> - // Check if the requested JSP page exists, to avoid
> - // creating unnecessary directories and files.
> - if (null == context.getResource(jspUri)) {
> - response.sendError(HttpServletResponse.SC_NOT_FOUND,
> - jspUri);
> - return;
> + JspServletWrapper wrapper = null;
> + try {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if( null == wrapper )
> + synchronized(this) {
> + wrapper = (JspServletWrapper) rctxt.getWrapperAndIncService(jspUri);
> + if (wrapper == null) {
> + // Check if the requested JSP page exists, to avoid
> + // creating unnecessary directories and files.
> + if (null == context.getResource(jspUri)) {
> + response.sendError(HttpServletResponse.SC_NOT_FOUND,
> + jspUri);
> + return;
> + }
> + boolean isErrorPage = exception != null;
> + wrapper = new JspServletWrapper(config, options, jspUri,
> + isErrorPage, rctxt);
> + rctxt.addWrapper(jspUri,wrapper);
> }
> - boolean isErrorPage = exception != null;
> - wrapper = new JspServletWrapper(config, options, jspUri,
> - isErrorPage, rctxt);
> - rctxt.addWrapper(jspUri,wrapper);
> + wrapper.incService();
> + }
> +
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + String _destroyingUri = destroyingUri;
> + if( wrapper.getJspUri().equals( _destroyingUri ) )
> + synchronized( _destroyingUri ) {
> + if( _destroyingUri == destroyingUri )
> + _destroyingUri.wait();
> }
> +
> + wrapper.service(request, response, precompile);
> +
> + } catch( InterruptedException ignore ) {}
> + finally { // inserted by yarick
> + synchronized(this) {
> + if( null != wrapper ) wrapper.decService();
> }
> - }
> + }
> + }
>
> - wrapper.service(request, response, precompile);
> +// { inserted by yarick
> + private Thread unloadThread;
> + private String destroyingUri;
>
> + protected void startUnloadJspsThread() {
> + String pathToWebApp = context.getRealPath("/");
> + if( pathToWebApp.endsWith( File.separator ) )
> + pathToWebApp = pathToWebApp.substring( 0, pathToWebApp.length()-1 );
> +
> + unloadThread = new Thread( "jspUnloader ["+pathToWebApp.substring( pathToWebApp.lastIndexOf( File.separatorChar ) )+( "/" )+"]" ) {
> + public void run() { runUnloadJspsThread(); }
> + };
> + unloadThread.setDaemon( true );
> + unloadThread.start();
> + }
> +
> + protected void stopUnloadJspsThread() {
> + if( null != unloadThread ) {
> + unloadThread.interrupt();
> + try { unloadThread.join( 10 * 1000 ); } // wait maximum 10 seconds
> + catch( InterruptedException ignore ) {}
> + unloadThread = null;
> + }
> }
>
> + protected void runUnloadJspsThread() {
> + try {
> + while( !Thread.currentThread().isInterrupted() ) {
> + JspServletWrapper jsw;
> + synchronized( this ) {
> + jsw = rctxt.getJspForUnload();
> + if( null != jsw ) destroyingUri = new String( jsw.getJspUri() );
> + }
> +
> + if( null == jsw )
> + Thread.sleep( options.getJspUnloadTestInterval() * 1000 );
> + else
> + /* dances around making it not possible to call servlet.init() before
> + * previous copy of servlet is unloaded ( called method servlet.destroy() )
> + */
> + synchronized( destroyingUri ) {
> + try {
> + jsw.destroy();
> + } finally {
> + String prev_destroyingUri = destroyingUri;
> + destroyingUri = null;
> + prev_destroyingUri.notifyAll();
> + }
> + }
> + }
> + } catch( InterruptedException exit ) {}
> + }
> +// } inserted by yarick
> }
> diff -rdu apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java
> --- apache-tomcat-5.5.15-src-orig/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-01-03 10:14:04.000000000 +0100
> +++ apache-tomcat-5.5.15-src-patched/jasper/jasper2/src/share/org/apache/jasper/servlet/JspServletWrapper.java 2006-02-21 13:24:43.999843400 +0100
> @@ -86,6 +86,7 @@
> private JasperException compileException;
> private long servletClassLastModifiedTime;
> private long lastModificationTest = 0L;
> + private int executingServicesCount; // yarick
>
> /*
> * JspServletWrapper for JSP pages.
> @@ -397,6 +398,10 @@
> }
> }
>
> + synchronized public void incService() { ++executingServicesCount; } // yarick: inserted accounting of 'service'
> + synchronized public void decService() { --executingServicesCount; } // yarick: inserted accounting of 'service'
> + String getJspUri() { return jspUri; } // yarick: inserted
> +
> public void destroy() {
> if (theServlet != null) {
> theServlet.destroy();
> @@ -416,6 +421,9 @@
> this.lastModificationTest = lastModificationTest;
> }
>
> + /** @return Returns count of currently executing of method {@link #service} */
> + public int getExecutingServicesCount() { return executingServicesCount; } // yarick
> +
> /**
> * <p>Attempts to construct a JasperException that contains helpful information
> * about what went wrong. Uses the JSP compiler system to translate the line
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org