Re: What's about unloading policy of jsp-servlets ?

[Yaroslav Sokolov]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]> 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.

DO NOT REPLY [Bug 38875] New: - Misleading error message when there are problems loading APR libraries

[bugzilla]

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

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

   Summary: Misleading error message when there are problems loading
APR libraries
   Product: Tomcat 5
   Version: 5.5.15
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


We recently rebuilt APR during an OS reinstall. After this, Tomcat failed to
load the tcnative libraries:

INFO: The Apache Tomcat Native library which allows optimal performance in
production environments was not found on the java.library.path:
/x1/opt/tomcat-5.5/tomcat/bin/tomcat-native-1.1.2/jni/native/.libs

However the libraries were definitely present there.

Eventually I poked around in AprLifecycleListener.java, and found that the code
initializing the APR library:

try {
  String methodName = "initialize";
  Class paramTypes[] = new Class[1];
  paramTypes[0] = String.class;
  Object paramValues[] = new Object[1];
  paramValues[0] = null;
  Class clazz = Class.forName("org.apache.tomcat.jni.Library");
  Method method = clazz.getMethod(methodName, paramTypes);
  method.invoke(null, paramValues);
  major = clazz.getField("TCN_MAJOR_VERSION").getInt(null);
  minor = clazz.getField("TCN_MINOR_VERSION").getInt(null);
  patch = clazz.getField("TCN_PATCH_VERSION").getInt(null);
  } catch (Throwable t) {
  if (!log.isDebugEnabled()) {
  log.info(sm.getString("aprListener.aprInit",
  System.getProperty("java.library.path")));
   ...

You see it catches a Throwable, and *assumes* it means the library isn't
present. In my case this was not so. When I added a log.error() to print the
Throwable, I got:


SEVERE: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:80)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:766)
at org.apache.catalina.startup.Catalina.load(Catalina.java:503)
at org.apache.catalina.startup.Catalina.load(Catalina.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:247)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Caused by: java.lang.UnsatisfiedLinkError:
/x1/opt/tomcat-5.5/apache-tomcat-5.5.15/bin/tomcat-native-1.1.2/jni/native/.libs/libtcnative-1.so.0.2.2:
/usr/local/apr-install/1.2.2/lib/libapr-1.so.0: undefined symbol: sock_is_ipv6,
no libtcnative-1 in
java.library.path(/x1/opt/tomcat-5.5/tomcat/bin/tomcat-native-1.1.2/jni/native/.libs)
at org.apache.tomcat.jni.Library.(Library.java:55)
at org.apache.tomcat.jni.Library.initialize(Library.java:156)
... 15 more


For the record, this is apparently a bug in APR 1.2.2 triggered when it is
compiled with --disable-ipv6.

It would be good if Tomcat could catch the specific exception thrown when the
file is not found, and print all others, like this.

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

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

Re: Good day (Acesta este un mesaj trimis automat/This is an autoreply message)

[Ion Gh Rosca]

Datorita volumului mare de mesaje nesolicitate primite pe aceasta adresa
am activat filtrarea mesajelor la un nivel ridicat.
Daca nu ati primit raspuns in decurs de 7 zile si pentru a preveni
calificarea mesajului dumneavoastra drept Junk Email, Spam etc., va
rugam sa retransmiteti mesajul adaugand in campul subiect
"RECTORAT-ASE".

Va multumim pentru intelegere, 
Cabinetul Rectorului
Academia de Studii Economice din Bucuresti

--

Due to the large number of unsolicited messages received we have enabled
e-mail filtering at high level. 
If you have not received an answer to your message within 7
working days and to prevent your message to be treated as Junk email,
Spam etc., please re-send your message with the following in the subject
line: "RECTORAT-ASE"

Thank you for understanding, 
Rector's Office
Academy of Economic Studies of Bucharest




>>> tomcat-dev 03/07/06 12:32 >>>

Mail transaction failed. Partial message is available.


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

DO NOT REPLY [Bug 38877] New: - Loader tag in server.xml induces a wrong class loading scheme

[bugzilla]

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

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

   Summary: Loader tag in server.xml induces a wrong class loading
scheme
   Product: Tomcat 5
   Version: 5.5.16
  Platform: Other
OS/Version: other
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When you have a "Loader" tag for your "context" in the "server.xml" file, the
class loading scheme of tomcat is broken.

In this case, your custom Loader receieves, as a parent ClassLoader, an instance
of the System ClassLoader, instead of an instance of the Shared ClassLoader (see
http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html).

This is because, when the "Loader" tag is present, the custom loader (typically
a subclass of "WebappLoader") is created while reading the XML file, BEFORE
knowing the parent container (and therefore, defore knowing the parent
ClassLoader = Shared ClassLoader) [class ContextRuleSet, method begin(),line 
253].

In this case, the default class loader is set to the SystemClassLoader [class
ContainerBase, method getParentClassLoader(), line 580].

On the other hand, if you DON'T have the tag, the loader is created later [class
StandardContext, method start, line 4022].

I consider this bug a a major one, as the class loading scheme is broken (I
consider class loading as a fundamental element of J2EE). This bug prevents an
easy professionnal development of web applications, as it imposes the manual
copy of classes and jars into the apposite WEB-INF locations, instead of using a
suited class loader allowing an easy share of classes between projets.

Related bugs: ASF Bugzilla Bug 37054, ASF Bugzilla Bug 37302.

Mathieu

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

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

DO NOT REPLY [Bug 38875] - Misleading error message when there are problems loading APR libraries

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 11:01 ---
Both openssl and APR must be in the LD_LIBRARY_PATH.
The easiest way is to use the:
ldd libtcnative-1.so.0.2.2

Make sure LD_LIBRARY_PATH includes all tcnative dependencies.

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

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

DO NOT REPLY [Bug 38223] - ConfigurableClasspathWebappLoader

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 11:02 ---
(In reply to comment #8)
> (In reply to comment #7)
> > Hi. I've tried to get your latest code to work with my Tomcat 5.0.30. I of
> > course recompiled the source, as I'm using JDK 1.4.2. 
> 
> Ack. I'll chance the JDK compatibility level in my Eclipse IDE. And I'm 
> testing
> against Tomcat 5.5.15 Beta.
> 
> > I also had to change the digester from tomcat.util.digester to 
> > commons-digester
> > as the former package is not available on my installation (tomcat 5.5 only 
> > ?).
> > 
> 
> Ack. This is interesting. Tomcat 5.5.15 has tomcat.util.digester instead of
> commons-digester. I don't know why this is the reason - a search in the 
> archives
> should yield some answer, and I'll try to find out this answer.
> 
> > Now when I load my web application, everytime I try to access something 
> > which is
> > handled by the default servlet (such as images or static html), I get a 404
> > error - "servlet default is not available".
> > 
> 
> Ack. I just tested this on both Tomcat 5.5.15 as well as 5.0.30. I'm able to 
> run
> the "testing" and the documentation web apps. I'm also able to view the images
> and HTML from within these apps on both the Tomcat versions.
> 
> > Apparently, with the configurable web app class loader loaded, tomcat can't 
> > find
> > DefaultServlet from servlets-default.jar. I'm not sure why is that, but 
> > with my
> > implementation it does the same.
> > 
> > I enabled full debug logging for tomcat, and Here are the class loader 
> > hierarchy
> > for a normal web application:
> > 
> 
> > 
> > As you can see, for some reason one level of StandardClassLoader, which 
> > contains
> > the servlets-default.jar is missing for some reason. 
> > 
> > Can you guess what's going on ?
> 
> I've to leave for the day, and will look into this tomorrow.
> 
> -- Sriram



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

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

Re: TCK Use

[Yoav Shapira]

Hola,
Send Geir an email to tell him you're interested.  You'll need to sign
an NDA, and then he will place the TCK binaries in your minotaur home
directory.  The TCKs come with instructions on how to use them.

I'd like to run the TCKs for every release, but my bandwidth is fairly
low at the moment, so I'd love if you did the above yourself and then
I can try to help if you run into trouble.

Yoav

On 3/6/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> I'm wondering about what I'd need to do/contact for using the TCK as a
> committer working on JSP 2.1?
>
> As for an update to the group, I'm still working on .tag files, but the
> new EL implementation is now part of the compiler.
>
> I'm torn on one thing though:
>
> 1) Bind the use of the org.apache.el explicitly in the Jasper code base
>
> 2) Minimize the use of org.apache.el implementation references to
> possibly allow other EL implementations (even for alternate syntaxes) to
> be used at runtime, such as using a JEXL or OGNL ExpressionFactory w/ JSP.
>
> --
> Jacob Hookom  -  Minneapolis
> 
> JSF-EG, JSF-RI, EL, Facelets
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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

Re: What's about unloading policy of jsp-servlets ?

[Leon Rosenberg]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's about unloading policy of jsp-servlets ?

[Renato]

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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> 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
> <[EMAIL PROTECTED]> wrote:
> > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]>
> 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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Re: What's about unloading policy of jsp-servlets ?

[Leon Rosenberg]

On 3/7/06, Renato <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > 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
> > <[EMAIL PROTECTED]> wrote:
> > > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]>
> > 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:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

svn commit: r383911 - in /tomcat/container/tc5.5.x/modules: groupcom/src/share/org/apache/catalina/tribes/ groupcom/src/share/org/apache/catalina/tribes/group/ groupcom/src/share/org/apache/catalina/t

[fhanik]

Author: fhanik
Date: Tue Mar  7 07:40:30 2006
New Revision: 383911

URL: http://svn.apache.org/viewcvs?rev=383911&view=rev
Log:
refactored to allow more than one listener.
Membership is retrievable throughout the interceptor stack, so that it is 
available to all interceptors.

Modified:

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

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

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

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

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

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

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

tomcat/container/tc5.5.x/modules/ha/src/share/org/apache/catalina/ha/tcp/SimpleTcpCluster.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/Channel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/Channel.java?rev=383911&r1=383910&r2=383911&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/Channel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/Channel.java
 Tue Mar  7 07:40:30 2006
@@ -82,8 +82,11 @@
  */
 public void heartbeat();
 
-public void setMembershipListener(MembershipListener listener);
-public void setChannelListener(ChannelListener listener);
+public void addMembershipListener(MembershipListener listener);
+public void addChannelListener(ChannelListener listener);
+
+public void removeMembershipListener(MembershipListener listener);
+public void removeChannelListener(ChannelListener listener);
 
 /**
  * has members

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java?rev=383911&r1=383910&r2=383911&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
 Tue Mar  7 07:40:30 2006
@@ -43,4 +43,30 @@
 public void messageReceived(ChannelMessage data);
 
 public void heartbeat();
+
+/**
+ * has members
+ */
+public boolean hasMembers() ;
+
+/**
+ * Get all current cluster members
+ * @return all members or empty array 
+ */
+public Member[] getMembers() ;
+
+/**
+ * Return the member that represents this node.
+ * 
+ * @return Member
+ */
+public Member getLocalMember() ;
+
+/**
+ * 
+ * @param mbr Member
+ * @return Member
+ */
+public Member getMember(Member mbr);
+
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelCoordinator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelCoordinator.java?rev=383911&r1=383910&r2=383911&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelCoordinator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/ChannelCoordinator.java
 Tue Mar  7 07:40:30 2006
@@ -164,5 +164,40 @@
 if ( clusterSender!=null ) clusterSender.heartbeat();
 super.heartbeat();
 }
+
+/**
+ * has members
+ */
+public boolean hasMembers() {
+return this.getMembershipService().hasMembers();
+}
+
+/**
+ * Get all current cluster members
+ * @return all members or empty array
+ */
+public Member[] getMembers() {
+return this.getMembershipService().getMembers();
+}
+
+/**
+ * 
+ * @param mbr Member
+ * @return Member
+ */
+public Member getMember(Member mbr){
+return this.getMembershipService().getMember(mbr);
+}
+
+
+/**
+ * Return the member that represents this node.
+ *
+ * @return Member
+ */
+public Member getLocalMember() {
+return this.getMembershipService().getLocalMember();
+}
+

 }

Modified: 
tomcat

Re: Tomcat 6 source organisation part 2

[Remy Maucherat]

Remy Maucherat wrote:

Hi,

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

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

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

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


Any other ideas ?


Ok, so I'll (try to) create the structure (not the one in this mail), 
but how is it done in SVN ? Is it all simply folders without anything 
special ?


Rémy

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

Re: Tomcat 6 source organisation part 2

[Florian Fray]

Hi Remy!

Ok, so I'll (try to) create the structure (not the one in this mail), 
but how is it done in SVN ? Is it all simply folders without anything 
special ?


A simple bunch of "svn mkdir" commands will do its job.
There's nothing special about it.

Regards

Florian



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

Re: TCK Use

[Mark Thomas]

Jacob Hookom wrote:
> I'm wondering about what I'd need to do/contact for using the TCK as a
> committer working on JSP 2.1?

Any PMC member can request a TCK by sending the request to
[EMAIL PROTECTED]

Mark


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

svn commit: r383977 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: ByteMessage.java group/tipis/ group/tipis/Response.java group/tipis/RpcCallback.java group/tip

[fhanik]

Author: fhanik
Date: Tue Mar  7 11:41:44 2006
New Revision: 383977

URL: http://svn.apache.org/viewcvs?rev=383977&view=rev
Log:
Added in a skeleton for the rcp messaging base

Added:

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

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

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

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/RpcChannel.java
Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ByteMessage.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ByteMessage.java?rev=383977&r1=383976&r2=383977&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ByteMessage.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ByteMessage.java
 Tue Mar  7 11:41:44 2006
@@ -16,6 +16,10 @@
 package org.apache.catalina.tribes;
 
 import java.io.Serializable;
+import java.io.Externalizable;
+import java.io.ObjectInput;
+import java.io.IOException;
+import java.io.ObjectOutput;
 
 /**
  * A byte message is not serialized and deserialized by the channel
@@ -23,7 +27,7 @@
  * @version $Revision: 304032 $, $Date: 2005-07-27 10:11:55 -0500 (Wed, 27 Jul 
2005) $
  */
 
-public class ByteMessage implements Serializable {
+public class ByteMessage implements Serializable, Externalizable {
 private byte[] message;
 
 public ByteMessage() {
@@ -39,6 +43,17 @@
 
 public void setMessage(byte[] message) {
 this.message = message;
+}
+
+public void readExternal(ObjectInput in ) throws IOException {
+int length = in.readInt();
+message = new byte[length];
+in.read(message,0,length);
+}
+
+public void writeExternal(ObjectOutput out) throws IOException {
+out.writeInt(message.length);
+out.write(message,0,message.length);
 }
 
 }

Added: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/Response.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/Response.java?rev=383977&view=auto
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/Response.java
 (added)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/Response.java
 Tue Mar  7 11:41:44 2006
@@ -0,0 +1,53 @@
+/*
+ * Copyright 1999,2004-2006 The Apache Software Foundation.
+ * 
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.tribes.group.tipis;
+
+import java.io.Serializable;
+
+import org.apache.catalina.tribes.Member;
+
+/**
+ * A response object holds a message from a responding partner.
+ * @author Filip Hanik
+ * @version 1.0
+ */
+public class Response {
+private Member source;
+private Serializable message;
+public Response() {
+}
+
+public Response(Member source, Serializable message) {
+this.source = source;
+this.message = message;
+}
+
+public void setSource(Member source) {
+this.source = source;
+}
+
+public void setMessage(Serializable message) {
+this.message = message;
+}
+
+public Member getSource() {
+return source;
+}
+
+public Serializable getMessage() {
+return message;
+}
+}
\ No newline at end of file

Added: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/RpcCallback.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/RpcCallback.java?rev=383977&view=auto
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/RpcCallback.java
 (added)
+++ 
tomcat/contai

svn commit: r383979 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: group/tipis/ tipis/ tipis/Response.java tipis/RpcCallback.java tipis/RpcChannel.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 11:43:20 2006
New Revision: 383979

URL: http://svn.apache.org/viewcvs?rev=383979&view=rev
Log:
Moved the package, to a better location as it is channel independent

Added:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/
  - copied from r383977, 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/
Removed:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/tipis/
Modified:

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

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

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/Response.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/Response.java?rev=383979&r1=383977&r2=383979&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/Response.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/Response.java
 Tue Mar  7 11:43:20 2006
@@ -13,7 +13,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-package org.apache.catalina.tribes.group.tipis;
+package org.apache.catalina.tribes.tipis;
 
 import java.io.Serializable;
 

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcCallback.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcCallback.java?rev=383979&r1=383977&r2=383979&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcCallback.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcCallback.java
 Tue Mar  7 11:43:20 2006
@@ -13,7 +13,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-package org.apache.catalina.tribes.group.tipis;
+package org.apache.catalina.tribes.tipis;
 
 import java.io.Serializable;
 import org.apache.catalina.tribes.Member;

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java?rev=383979&r1=383977&r2=383979&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 Tue Mar  7 11:43:20 2006
@@ -13,7 +13,7 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-package org.apache.catalina.tribes.group.tipis;
+package org.apache.catalina.tribes.tipis;
 
 import java.io.Serializable;
 



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

Re: [feedback request] session replication

[Filip Hanik - Dev Lists]

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

DO NOT REPLY [Bug 38888] New: - Release method for custom tags not called.

[bugzilla]

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

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

   Summary: Release method for custom tags not called.
   Product: Tomcat 4
   Version: 4.1.31
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


(from http://java.sun.com/products/jsp/tutorial/TagLibraries18.html#62842)
The tag method invocation sequence is as follows:
 ATag t = new ATag();
 t.setPageContext(...);
 t.setParent(...);
 t.setAttribute1(value1);
 t.setAttribute2(value2);
 t.doStartTag();
 t.doEndTag();
 t.release();

Create a tag with one attribute (A) that depends on the initialization of
another attribute (B).  If B is still null when doStartTag is called, initialize
it to a copy of A.  Reset B (to null) in the release method.  For debugging
purposes, the tag should just print out the values of A and B, labeled.

Create a test page that calls the tag twice, neither time setting B, but both
times setting A to different values ("first time" and "second time", for
example).  It should print something like the following:
 first time, first time
 second time, second time
But it will print the following:
 first time, first time
 second time, first time

Workaround: surround the doStartTag with a try/catch/finally, and call the
release method in the finally block.

Notes: this is probably platform independant - I've tested on Linux and WinXP.

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

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

svn commit: r383997 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 12:24:06 2006
New Revision: 383997

URL: http://svn.apache.org/viewcvs?rev=383997&view=rev
Log:
Most of the impl is complete

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java?rev=383997&r1=383996&r2=383997&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 Tue Mar  7 12:24:06 2006
@@ -15,17 +15,26 @@
  */
 package org.apache.catalina.tribes.tipis;
 
+import java.io.Externalizable;
+import java.io.IOException;
+import java.io.ObjectInput;
+import java.io.ObjectOutput;
 import java.io.Serializable;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.HashMap;
 
 import org.apache.catalina.tribes.Channel;
 import org.apache.catalina.tribes.ChannelException;
+import org.apache.catalina.tribes.ChannelListener;
 import org.apache.catalina.tribes.Member;
+import org.apache.catalina.tribes.util.UUIDGenerator;
 
 /**
  * A channel to handle RPC messaging
  * @author Filip Hanik
  */
-public class RpcChannel {
+public class RpcChannel implements ChannelListener{
 
 public static final int FIRST_REPLY = 1;
 public static final int MAJORITY_REPLY = 2;
@@ -33,7 +42,9 @@
 
 private Channel channel;
 private RpcCallback callback;
-private String rpcId;
+private byte[] rpcId;
+
+private HashMap responseMap = new HashMap();
 
 /**
  * Create an RPC channel. You can have several RPC channels attached to a 
group
@@ -42,10 +53,11 @@
  * @param channel Channel
  * @param callback RpcCallback
  */
-public RpcChannel(String rpcId, Channel channel, RpcCallback callback) {
+public RpcChannel(byte[] rpcId, Channel channel, RpcCallback callback) {
 this.channel = channel;
 this.callback = callback;
 this.rpcId = rpcId;
+//channel.addChannelListener(this);
 }
 
 
@@ -54,15 +66,47 @@
  * @param destination Member[] - the destination for the message, and the 
members you request a reply from
  * @param message Serializable - the message you are sending out
  * @param options int - FIRST_REPLY, MAJORITY_REPLY or ALL_REPLY
- * @param timeout long - timeout in milliseconds, if no reply is received 
within this time an exception is thrown
+ * @param timeout long - timeout in milliseconds, if no reply is received 
within this time null is returned
  * @return Response[] - an array of response objects.
  * @throws ChannelException
  */
 public Response[] send(Member[] destination, 
Serializable message,
int options, 
-   long timeout) throws ChannelException {
-throw new UnsupportedOperationException();
+   long timeout) throws ChannelException, 
InterruptedException {
+
+RpcCollectorKey key = new 
RpcCollectorKey(UUIDGenerator.randomUUID(false));
+RpcCollector collector = new 
RpcCollector(key,options,destination.length,timeout);
+synchronized (collector) {
+responseMap.put(key,collector);
+RpcMessage rmsg = new RpcMessage(rpcId,key.id,message);
+channel.send(destination,rmsg);
+collector.wait(timeout);
+}
+return collector.getResponses();
+}
+
+
+public void messageReceived(Serializable msg, Member sender) {
+RpcMessage rmsg = (RpcMessage)msg;
+RpcCollectorKey key = new RpcCollectorKey(rmsg.uuid);
+RpcCollector collector = (RpcCollector)responseMap.get(key);
+if ( collector == null ) {
+callback.leftOver(rmsg.message,sender);
+} else {
+synchronized (collector) {
+collector.addResponse(rmsg.message,sender);
+if ( collector.isComplete() ) collector.notifyAll();
+}
+}
+
+}
+
+public boolean accept(Serializable msg, Member sender) {
+if ( msg instanceof RpcMessage ) {
+RpcMessage rmsg = (RpcMessage)msg;
+return Arrays.equals(rmsg.rpcId,rpcId);
+}else return false;
 }
 
 public Channel getChannel() {
@@ -73,7 +117,7 @@
 return callback;
 }
 
-public String getRpcId() {
+public byte[] getRpcId() {
 return rpcId;
 }
 
@@ -85,8 +129,116 @@
 this.callback = callback;
 }
 
-public void setRpcId(String rpcId) {
+public void setR

DO NOT REPLY [Bug 38888] - Release method for custom tags not called.

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 20:26 ---
The JSP page implementation class also guarantees that release will be invoked
on the tag handler ** before the end of the page **.

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

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

svn commit: r384000 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 12:30:26 2006
New Revision: 384000

URL: http://svn.apache.org/viewcvs?rev=384000&view=rev
Log:
implemented timing on the pooled queue

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java?rev=384000&r1=383999&r2=384000&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 Tue Mar  7 12:30:26 2006
@@ -157,16 +157,27 @@
 }
 
 public synchronized DataSender getSender(long timeout) {
-if ( !isOpen ) throw new IllegalStateException("Queue is closed");
-DataSender sender = null;
-if ( notinuse.size() == 0 && inuse.size() 0) {
+long start = System.currentTimeMillis();
+while ( true ) {
+if (!isOpen)throw new IllegalStateException("Queue is closed");
+DataSender sender = null;
+if (notinuse.size() == 0 && inuse.size() < limit) {
+sender = parent.getNewDataSender();
+} else if (notinuse.size() > 0) {
 sender = (DataSender) notinuse.remove(0);
-}
-if ( sender != null ) inuse.add(sender);
-//System.out.println("get: in use:"+inuse.size()+" 
not:"+notinuse.size()+" thread:"+Thread.currentThread().getName());
-return sender;
+}
+if (sender != null) {
+inuse.add(sender);
+return sender;
+}//end if
+long delta = System.currentTimeMillis() - start;
+if ( delta > timeout && timeout>0) return null;
+else {
+try {
+wait(timeout - delta);
+}catch (InterruptedException x){}
+}//end if
+}
 }
 
 public synchronized void returnSender(DataSender sender) {
@@ -177,7 +188,7 @@
 //to do
 inuse.remove(sender);
 notinuse.add(sender);
-//System.out.println("return: in use:"+inuse.size()+" 
not:"+notinuse.size()+" thread:"+Thread.currentThread().getName());
+notify();
 }
 
 public synchronized void close() {
@@ -194,6 +205,7 @@
 }//for
 notinuse.clear();
 inuse.clear();
+notify();
 
 
 
@@ -201,6 +213,7 @@
 
 public synchronized void open() {
 isOpen = true;
+notify();
 }
 }
 



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

svn commit: r384003 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 12:43:47 2006
New Revision: 384003

URL: http://svn.apache.org/viewcvs?rev=384003&view=rev
Log:
Implemented queueing 

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java?rev=384003&r1=384002&r2=384003&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/PooledSender.java
 Tue Mar  7 12:43:47 2006
@@ -174,7 +174,7 @@
 if ( delta > timeout && timeout>0) return null;
 else {
 try {
-wait(timeout - delta);
+wait(Math.max(timeout - delta,1));
 }catch (InterruptedException x){}
 }//end if
 }



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

svn commit: r384009 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 13:01:25 2006
New Revision: 384009

URL: http://svn.apache.org/viewcvs?rev=384009&view=rev
Log:
removed not needed constructor

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java?rev=384009&r1=384008&r2=384009&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/XByteBuffer.java
 Tue Mar  7 13:01:25 2006
@@ -106,14 +106,6 @@
 this.discard = discard;
 }
 
-
-/**
- * Constructs a new XByteBuffer with an initial size of 1024 bytes
- */
-public XByteBuffer(boolean discard)  {
-this(DEF_SIZE,discard);
-}
-
 public int getLength() {
 return bufSize;
 }



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

Re: What's about unloading policy of jsp-servlets ?

[S. Dierkes]

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:[EMAIL PROTECTED] 
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > 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
> > <[EMAIL PROTECTED]> wrote:
> > > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]>
> > 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 t

svn commit: r384023 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/tipis/RpcChannel.java test/org/apache/catalina/tribes/demos/EchoRpcTest.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 13:46:32 2006
New Revision: 384023

URL: http://svn.apache.org/viewcvs?rev=384023&view=rev
Log:
Finished the Rpc channel and a sample demo

Added:

tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java?rev=384023&r1=384022&r2=384023&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 Tue Mar  7 13:46:32 2006
@@ -35,6 +35,7 @@
  * @author Filip Hanik
  */
 public class RpcChannel implements ChannelListener{
+protected static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory.getLog(RpcChannel.class);
 
 public static final int FIRST_REPLY = 1;
 public static final int MAJORITY_REPLY = 2;
@@ -57,7 +58,7 @@
 this.channel = channel;
 this.callback = callback;
 this.rpcId = rpcId;
-//channel.addChannelListener(this);
+channel.addChannelListener(this);
 }
 
 
@@ -75,6 +76,7 @@
int options, 
long timeout) throws ChannelException, 
InterruptedException {
 
+if ( destination==null || destination.length == 0 ) return new 
Response[0];
 RpcCollectorKey key = new 
RpcCollectorKey(UUIDGenerator.randomUUID(false));
 RpcCollector collector = new 
RpcCollector(key,options,destination.length,timeout);
 synchronized (collector) {
@@ -90,16 +92,26 @@
 public void messageReceived(Serializable msg, Member sender) {
 RpcMessage rmsg = (RpcMessage)msg;
 RpcCollectorKey key = new RpcCollectorKey(rmsg.uuid);
-RpcCollector collector = (RpcCollector)responseMap.get(key);
-if ( collector == null ) {
-callback.leftOver(rmsg.message,sender);
-} else {
-synchronized (collector) {
-collector.addResponse(rmsg.message,sender);
-if ( collector.isComplete() ) collector.notifyAll();
+if ( rmsg.reply ) {
+RpcCollector collector = (RpcCollector)responseMap.get(key);
+if (collector == null) {
+callback.leftOver(rmsg.message, sender);
+} else {
+synchronized (collector) {
+collector.addResponse(rmsg.message, sender);
+if (collector.isComplete()) collector.notifyAll();
+}//synchronized
+}//end if
+} else{
+Serializable reply = callback.replyRequest(rmsg.message,sender);
+rmsg.reply = true;
+rmsg.message = reply;
+try {
+channel.send(new Member[] {sender}, rmsg);
+}catch ( Exception x )  {
+log.error("Unable to send back reply in RpcChannel.",x);
 }
-}
-
+}//end if
 }
 
 public boolean accept(Serializable msg, Member sender) {
@@ -138,6 +150,11 @@
 private Serializable message;
 private byte[] uuid;
 private byte[] rpcId;
+private boolean reply = false;
+
+public RpcMessage() {
+//for serialization
+}
 
 public RpcMessage(byte[] rpcId, byte[] uuid, Serializable message) {
 this.rpcId = rpcId;
@@ -146,6 +163,7 @@
 }
 
 public void readExternal(ObjectInput in) throws 
IOException,ClassNotFoundException {
+reply = in.readBoolean();
 int length = in.readInt();
 uuid = new byte[length];
 in.read(uuid, 0, length);
@@ -156,6 +174,7 @@
 }
 
 public void writeExternal(ObjectOutput out) throws IOException {
+out.writeBoolean(reply);
 out.writeInt(uuid.length);
 out.write(uuid, 0, uuid.length);
 out.writeInt(rpcId.length);

Added: 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java?rev=384023&view=auto
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
 (added)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
 Tue Mar

DO NOT REPLY [Bug 38889] New: - mod_jk disregards configuration file order of JkMount

[bugzilla]

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

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

   Summary: mod_jk disregards configuration file order of JkMount
   Product: Tomcat 5
   Version: 5.5.15
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I've been trying out the new version of mod_jk (1.2.15) 

I've been working on upgrading our mod_jk from 1.2.9 to 1.2.15.  (We
use mod_jk primarily on Linux, in conjunction with apache 2.0.53 and
tomcat 5.5.15).

During testing, I noticed several cases of JkMount mappings going to
the wrong set of workers.  By `wrong', I mean `not the same workers as
1.2.9 would have chosen'; this behavior is reproducible with both the
apache 1.3 and 2.0 versions of mod_jk

Here is an example:

  Given JkMount directives:

  JkMount /k/* worker_k
  JkMount /s/* worker_s
  JkMount /m/* worker_m
  JkMount /h/* worker_h
  JkMount /*.jsp   worker_default

These mount points effectively represent 5 different applications
under a single VirtualHost; and they're handled by 5 different groups
of tomcats.


I'll make a request for the uri "/this-uri-wont-match". Here is the
portion of JkLogFile that attempts matching:


  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (449): 
Attempting to map URI '/this-uri-wont-match' from 5 maps
  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (461): 
Attempting to map context URI '/*.jsp'
  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (461): 
Attempting to map context URI '/k/*'
  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (461): 
Attempting to map context URI '/s/*'
  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (461): 
Attempting to map context URI '/m/*'
  [Tue Mar 07 16:20:40 2006] [16809:] [debug] 
map_uri_to_worker::jk_uri_worker_map.c (461): 
Attempting to map context URI '/h/*'


I see that the code is attempting a `longest-pattern-first' match.
However, the side effect of this is uri's like

  /m/some.jsp
  /h/some-other.jsp
  /s/yet-another.jsp
  

become unreachable.  Because mod_jk 1.2.15 uses pattern length, and
not *configuration file* order, there are circumstances where it will
never match the desired servlet container.


Commenting out the call to worker_qsort() (line 297 of
jk_uri_worker_map.c -- diff attached) makes the issue go away.


Would it be possible to go back to matching based on configuration
file order?

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

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

DO NOT REPLY [Bug 38889] - mod_jk disregards configuration file order of JkMount

[bugzilla]

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

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 21:50 ---
Created an attachment (id=17844)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17844&action=view)
Patch to jk_uri_worker_map.c


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

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

svn commit: r384024 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/tipis/RpcChannel.java test/org/apache/catalina/tribes/demos/EchoRpcTest.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 13:54:33 2006
New Revision: 384024

URL: http://svn.apache.org/viewcvs?rev=384024&view=rev
Log:
avoid memory leak in the rpc channel

Modified:

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

tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java?rev=384024&r1=384023&r2=384024&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 Tue Mar  7 13:54:33 2006
@@ -79,11 +79,15 @@
 if ( destination==null || destination.length == 0 ) return new 
Response[0];
 RpcCollectorKey key = new 
RpcCollectorKey(UUIDGenerator.randomUUID(false));
 RpcCollector collector = new 
RpcCollector(key,options,destination.length,timeout);
-synchronized (collector) {
-responseMap.put(key,collector);
-RpcMessage rmsg = new RpcMessage(rpcId,key.id,message);
-channel.send(destination,rmsg);
-collector.wait(timeout);
+try {
+synchronized (collector) {
+responseMap.put(key, collector);
+RpcMessage rmsg = new RpcMessage(rpcId, key.id, message);
+channel.send(destination, rmsg);
+collector.wait(timeout);
+}
+}finally {
+responseMap.remove(key);
 }
 return collector.getResponses();
 }
@@ -98,8 +102,10 @@
 callback.leftOver(rmsg.message, sender);
 } else {
 synchronized (collector) {
-collector.addResponse(rmsg.message, sender);
-if (collector.isComplete()) collector.notifyAll();
+if ( responseMap.containsKey(key) ) {
+collector.addResponse(rmsg.message, sender);
+if (collector.isComplete()) collector.notifyAll();
+}
 }//synchronized
 }//end if
 } else{

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java?rev=384024&r1=384023&r2=384024&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/test/org/apache/catalina/tribes/demos/EchoRpcTest.java
 Tue Mar  7 13:54:33 2006
@@ -31,6 +31,7 @@
 RpcChannel rpc;
 int options;
 long timeout;
+String name;
 
 public EchoRpcTest(Channel channel, String name, int count, String 
message, long pause, int options, long timeout) {
 this.channel = channel;
@@ -40,6 +41,7 @@
 this.options = options;
 this.rpc = new RpcChannel(name.getBytes(),channel,this);
 this.timeout = timeout;
+this.name = name;
 }
 
 /**
@@ -65,7 +67,7 @@
  */
 public Serializable replyRequest(Serializable msg, Member sender) {
 System.out.println("Received a reply request message from 
["+sender.getName()+"] with data ["+msg+"]");
-return "Reply:"+msg;
+return "Reply("+name+"):"+msg;
 }
 
 public void run() {



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

DO NOT REPLY [Bug 38875] - Misleading error message when there are problems loading APR libraries

[bugzilla]

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

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2006-03-07 21:59 ---
The bug I'm reporting is that Tomcat does not report the correct error. Tomcat
said that the library was not *found*, whereas in reality it could not be
*loaded*. I had to recompile Tomcat to get a decent stacktrace and diagnose the
actual problem, which shouldn't be necessary.

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

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

Re: What's about unloading policy of jsp-servlets ?

[David Rees]

On 3/7/06, Yaroslav Sokolov <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

David Rees wrote:

On 3/7/06, Yaroslav Sokolov <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r384031 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java

[fhanik]

Author: fhanik
Date: Tue Mar  7 14:07:13 2006
New Revision: 384031

URL: http://svn.apache.org/viewcvs?rev=384031&view=rev
Log:
fixed majority receiving, when you want a response from the majority of the 
members

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java?rev=384031&r1=384030&r2=384031&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tipis/RpcChannel.java
 Tue Mar  7 14:07:13 2006
@@ -102,9 +102,12 @@
 callback.leftOver(rmsg.message, sender);
 } else {
 synchronized (collector) {
+//make sure it hasn't been removed
 if ( responseMap.containsKey(key) ) {
 collector.addResponse(rmsg.message, sender);
 if (collector.isComplete()) collector.notifyAll();
+} else {
+callback.leftOver(rmsg.message, sender);
 }
 }//synchronized
 }//end if
@@ -222,7 +225,7 @@
 case MAJORITY_REPLY:
 {
 float perc = ((float)responses.size()) / ((float)destcnt);
-return perc >= 50f;
+return perc >= 0.50f;
 }
 case FIRST_REPLY:
 return responses.size()>0;



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

Strange memory problem

[Tino Schwarze]

Hi there,

I'm currently tracking an OutOfMemory problem. We've got a web app which
gets OutOfMemory after some heavy use. I installed Mustang 1.6b62 on the
machines and had them dump heap on OOM. Then I looked into the heap dump
using jhat.

I noticed that there are several objects hanging around with a strange
reference:

Java Local Reference (from [EMAIL PROTECTED]) :
--> some.of.our.classes

According to jhat, no other objects are referencing these objects (only
Finalizer).

Has anybody a clue what might cause this? After all, they don't seem to
get garbage collected.

Bye+Thanks!

Tino.


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

Re: What's about unloading policy of jsp-servlets ?

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

David Rees wrote:

On 3/7/06, Yaroslav Sokolov <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




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

Re: What's about unloading policy of jsp-servlets ?

[Leon Rosenberg]

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > > 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 <[EMAIL PROTECTED]>
> > > 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
> > > <[EMAIL PROTECTED]> wrote:
> > > > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]>
> > > 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
> > 

AW: What's about unloading policy of jsp-servlets ?

[S. Dierkes]

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:[EMAIL PROTECTED] 
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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > 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 <[EMAIL PROTECTED]>
> > > 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 <[EMAIL PROTECTED]>
> > > 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 existin

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: Strange memory problem

[Remy Maucherat]

Tino Schwarze wrote:

Hi there,

I'm currently tracking an OutOfMemory problem. We've got a web app which
gets OutOfMemory after some heavy use. I installed Mustang 1.6b62 on the
machines and had them dump heap on OOM. Then I looked into the heap dump
using jhat.

I noticed that there are several objects hanging around with a strange
reference:

Java Local Reference (from [EMAIL PROTECTED]) :
--> some.of.our.classes

According to jhat, no other objects are referencing these objects (only
Finalizer).

Has anybody a clue what might cause this? After all, they don't seem to
get garbage collected.


Personally, I don't know these new tools, so I don't know how to 
interpret what they say. For example, maybe there's a whole reference 
chain between the two.


Rémy

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

Re: What's about unloading policy of jsp-servlets ?

[Yoav Shapira]

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


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

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

Re: What's about unloading policy of jsp-servlets ?

[Leon Rosenberg]

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > > 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 <[EMAIL PROTECTED]>
> > > > 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 <[EMAIL PROTECTED]>
> > > > 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 th

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Yoav Shapira
> Senior Architect
> Nimalex LLC
> 1 Mifflin Place, Suite 310
> Cambridge, MA, USA
> [EMAIL PROTECTED] / www.yoavshapira.com
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Strange memory problem

[Costin Manolache]

ThreadWithAttributes extends Thread and caches some info ( Request
object for example ).
Since they are threads - they don't need to be referenced, and won't
get GC until the thread is done.

It's strange that it'll directly reference your classes.

Costin


On 3/7/06, Tino Schwarze <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'm currently tracking an OutOfMemory problem. We've got a web app which
> gets OutOfMemory after some heavy use. I installed Mustang 1.6b62 on the
> machines and had them dump heap on OOM. Then I looked into the heap dump
> using jhat.
>
> I noticed that there are several objects hanging around with a strange
> reference:
>
> Java Local Reference (from [EMAIL PROTECTED]) :
> --> some.of.our.classes
>
> According to jhat, no other objects are referencing these objects (only
> Finalizer).
>
> Has anybody a clue what might cause this? After all, they don't seem to
> get garbage collected.
>
> Bye+Thanks!
>
> Tino.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: What's about unloading policy of jsp-servlets ?

[Yoav Shapira]

Hola,


On 3/7/06, Remy Maucherat <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] / www.yoavshapira.com

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

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/7/06, Remy Maucherat <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/7/06, Remy Maucherat <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What's about unloading policy of jsp-servlets ?

[Remy Maucherat]

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

Re: What's about unloading policy of jsp-servlets ?

[Costin Manolache]

On 3/7/06, Remy Maucherat <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]