Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release()not invoked]

[Hans Bergsten]

Hans Bergsten wrote:

Costin Manolache wrote:

[...]
Wow. I would be _very_ curious to see those benchmarks and the "modern"
JVM that was used.
All my tests ( including JDK1.4, IBM vms, GCJ ) show that reusing is well
worth the trouble - at least if you have 100s of requests per second
( it is not worht the trouble for very low loads ). But I'm happy to
hear that I'm wrong.


I'll try to find the figures we looked at and post them, or run a new
benchmark against TC 4.1 with and without tag handler pooling enabled.
But it may take some time, because right now I'm busy with other stuff.
If you disagree with the decision, you may want to send your feedback
to the EG: [EMAIL PROTECTED] JSP 2.0 is still just PFD.


Okay, I ran a few test cases with Tomcat 4.1.18. Benchmarks are of
course never perfect, but it should be good enough to evaluate the
difference with and without tag handler reuse.

My test server is a 1 GHz Pentium with 256 MB, with Sun's Linux
JDK 1.4.1. I ran all tests with Apache JMeter, once with 5 threads (so
the MAX_POOL_SIZE is not exceeded) and one time with 20 threads, with
and without pooling enabled.

I also hacked the servlet class generated with pooling enabled so that
there's no overhead from the reuse itself. I simple create one instance
of each tag handler at the beginning of the _jspService() method and
use this instance for all invokations. This is as efficient as it can
be, with no extra cost for synchronization or Map lookups. I ran this
test once with 20 threads.

I used this test page:

  <%@ page contentType="text/plain" %>
  <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

  

  

  

While it's simple, it should show the impact of tag handler reuse.
With pooling disabled, one tag handler instance is created for the
outer , a new one is created for the inner 
for each pass through the loop (i.e. 100 instances), and a new
instance for  is created for each invokation (i.e. 1000
instances). With pooling enabled, the total number of instances
depends on the number of concurrent requests. For the 5 threads tests,
it should stay close to 5 instances (although non-pooled instances
may occasionally be created and released immediately). For the 20
threads test, a lot more instances are created (since the pool is
currently limited to 5 instances), but it should still be less than
when pooling is disabled.

Okay, here are the results

Without pooling  With pooling  Reuse w/o overhead
-
5 threads
  Avg.:  330 ms349 ms N/A
  Rate:15.2/sec  13.6/sec N/A

20 threads
  Avg.:1,752 ms  1,446 ms1,265 ms
  Rate:12.1/sec  13.6/sec14.7/sec

To me, this indicates that if you can avoid _all_ reuse overhead,
there's some performace to be gained from reuse but not much. With the
current implementation, however, the overhead seems to kill all gains
from creating fewer instances. I doubt increasing MAX_POOL_SIZE makes
much of a difference.

Feel free to run the test on your platform. It could be interesting
to see some more results. Also, if you think my test page is flawed,
I'd appreciate ideas for how to improve it.

Hans
--
Hans Bergsten<[EMAIL PROTECTED]>
Gefion Software   
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Torsten Fohrer]

please, correct my if i be wrong.


On Saturday 18 January 2003 22:56, you wrote:
> I agree that the currnet Jasper tag pooling could be improved.
>
>
> Per JSP Page (current)
> --
>
> The current tag pool manages one or more pools of tags on a per JSP
> page basis. With a synchronized method call for each get/reuse pair
> for a TagHandler used in the page. That page could have as many current
> requests as Processor threads.  The TagHandlerPool's for the JSP page
> could grow to the point where they have as many TagHandler elements
> as needed to handle the maximum number of concurrent requests (Threads).
>

how it be to reduce the synchronize methods to a big synchronize block at 
beginning and end of the page, storing all tag instances in another object, 
like local map, pageContext and so?

by the way..is the pageContext.setAttribute(...,SCOPE_PAGE ) synchronize, 
and if yes, why?

> Per JSP Page Thread Local
> -
>
> Switching this to ThreadLocal would remove all need for synchronized
> access for the TagHandlerPool get/reuse but significantly increase the
> memory usage. You end up with a TagHandlerPool for each thread, for each
> JSP page.
>

each tomcat connect has it own thread pool, right so if i have http with 100, 
and https with 100, i have a lot of thread locale objects. Does you mean a 
pool per jsp/tag  or tag/thread?

> Both of these could require enoubh memory to hold the number of TagHandler
> classes = Number of Threads * Number of JSP pages * Number of unique
> TagHandlers needed per JSP
>
>
> There are two other options based on managing a global tag pool rather than
> a per JSP page tag pool.  If you have many JSP pages with custom tags there
> will be common tags/attributes used across all of them.  Why not be able
> to reuse these TagHandler's across all the JSP pages instead of on a per
> JSP page basis. This could significantly reduce the number of instances of
> TagHandler's which have to be pooled, and the memory the consume.  Consider
> the JSTL c:if tag and how many times it could get used across 20 different
> JSP pages.
>
> Global
> --
>
> TagHandlerPool's which are global and pool all unique TagHandler classes
> for all JSP pages. In this case you would require one synchronized call at
> the start of the JSP page to populate its local pool with reusable
> TagHandler's from the global pool. Then on JSP page exit return the
> TagHandler's from its local pool to the global. Requires two synchronized
> method calls per JSP page execution, but mimimizes the memory footprint of
> pooled tags.
>

see first comment to reduce synchroniz. is a good idea, identify the taglibs 
with a attributes/attribute values/name combination...right?

> Global Thread Local
> ---
>
> TagHandlerPool's which are global within a thread and pool all unique
> TagHandler classes for all JSP pages which execute within the thread. No
> synchronized methods would be required for this design.  This would have a
> smaller memory footprint than the Per JSP Page (current) and Per Jsp Page
> Thread Local tag pools, but use more memory than the Global tag pool.

ok, see comment above.

>
>
> Of the four designs above I think the Global Thread Local design may be the
> best. It removes the need for synchronized get/reuse and has a smaller
> memory footprint than the Per JSP Page tag pool design.
>
> Regards,
>
> Glenn
>
> Costin Manolache wrote:
> > Bill Barker wrote:
> >>If tag-pooling works for you, I'm happy for you.  The current
> >>implementation
> >>doesn't work for me big time.  However, I'm very interested in Costin's
> >>claim that it can be done thread-local.
> >
> > One quick question ( looking at generated code ) - why is the TP limited
> > to 5 instances ? If you expect 20+ concurent requests ( where the TP
> > would actually matter ) - you'll have the overhead of TP sync, and almost
> > no benefit. Can you try again with a larger capacity ?
> >
> > Regarding the "claim" that it can be done thread-local: I attached a
> > first draft, I'll enhance it later ( it could use ThreadWithAttributes -
> > to save one extra hashtable lookup ). Let me know if it helps.
> >
> >
> > Costin
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 

Regards,

Torsten


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Costin Manolache]

Remy Maucherat wrote:


>>>If tag-pooling works for you, I'm happy for you.  The current
>>>implementation
>>>doesn't work for me big time.  However, I'm very interested in Costin's
>>>claim that it can be done thread-local.
>> 
>> 
>> One quick question ( looking at generated code ) - why is the TP limited
>> to 5 instances ? If you expect 20+ concurent requests ( where the TP
>> would actually matter ) - you'll have the overhead of TP sync, and almost
>> no benefit. Can you try again with a larger capacity ?
>> 
>> Regarding the "claim" that it can be done thread-local: I attached a
>> first draft, I'll enhance it later ( it could use ThreadWithAttributes -
>> to save one extra hashtable lookup ). Let me know if it helps.
> 
> If we could add a check so that JDKs < 1.4 would use the old synced
> code, and JDK >= 1.4 would use TL, I think it would be the best.

ThreadLocal is JDK1.2+ AFAIK.
It's just that the implementation in 1.4 has been optimized ( or so I 
heard). But even 1.2 TL should be faster than the sync.

IMO the 5 limit has a bigger impact than the sync - I would bet Bill 
tested with >20 concurent requests. I would make the max much bigger
( 100 ? ) - if fewer tags are used in a page, then the max will never be
reached.


> BTW, wouldn't using ThreadWithAttributes tie Jasper to Tomcat ?

Well - with some conditionals and Class.forName() it can be done. 
It would be a pretty good idea to have jasper use tomcat-util buffers
directly - as you know, I  believe that would be a huge speedup.

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Glenn Nielsen]

Glenn Nielsen wrote:

Bill Barker wrote:


I, personally, think that it's time for a branch in j-t-c.  At this 
point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch 
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 
3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[X] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching





Ok, after some more explanation (Thanks Remy & Costin) I will change my vote to +0.

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Glenn Nielsen]

I agree that the currnet Jasper tag pooling could be improved.


Per JSP Page (current)
--

The current tag pool manages one or more pools of tags on a per JSP
page basis. With a synchronized method call for each get/reuse pair
for a TagHandler used in the page. That page could have as many current
requests as Processor threads.  The TagHandlerPool's for the JSP page
could grow to the point where they have as many TagHandler elements
as needed to handle the maximum number of concurrent requests (Threads).

Per JSP Page Thread Local
-

Switching this to ThreadLocal would remove all need for synchronized
access for the TagHandlerPool get/reuse but significantly increase the
memory usage. You end up with a TagHandlerPool for each thread, for each
JSP page.

Both of these could require enoubh memory to hold the number of TagHandler classes =
Number of Threads * Number of JSP pages * Number of unique TagHandlers needed per JSP


There are two other options based on managing a global tag pool rather than
a per JSP page tag pool.  If you have many JSP pages with custom tags there
will be common tags/attributes used across all of them.  Why not be able
to reuse these TagHandler's across all the JSP pages instead of on a per JSP page
basis. This could significantly reduce the number of instances of TagHandler's
which have to be pooled, and the memory the consume.  Consider the JSTL c:if tag
and how many times it could get used across 20 different JSP pages.

Global
--

TagHandlerPool's which are global and pool all unique TagHandler classes for all JSP pages.
In this case you would require one synchronized call at the start of the JSP page
to populate its local pool with reusable TagHandler's from the global pool. Then
on JSP page exit return the TagHandler's from its local pool to the global.
Requires two synchronized method calls per JSP page execution, but mimimizes the
memory footprint of pooled tags.

Global Thread Local
---

TagHandlerPool's which are global within a thread and pool all unique TagHandler
classes for all JSP pages which execute within the thread. No synchronized methods
would be required for this design.  This would have a smaller memory footprint
than the Per JSP Page (current) and Per Jsp Page Thread Local tag pools, but use
more memory than the Global tag pool.


Of the four designs above I think the Global Thread Local design may be the best.
It removes the need for synchronized get/reuse and has a smaller memory footprint
than the Per JSP Page tag pool design.

Regards,

Glenn

Costin Manolache wrote:

Bill Barker wrote:



If tag-pooling works for you, I'm happy for you.  The current
implementation
doesn't work for me big time.  However, I'm very interested in Costin's
claim that it can be done thread-local.



One quick question ( looking at generated code ) - why is the TP limited
to 5 instances ? If you expect 20+ concurent requests ( where the TP 
would actually matter ) - you'll have the overhead of TP sync, and almost 
no benefit. Can you try again with a larger capacity ?

Regarding the "claim" that it can be done thread-local: I attached a first
draft, I'll enhance it later ( it could use ThreadWithAttributes - to save
one extra hashtable lookup ). Let me know if it helps.


Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Torsten Fohrer]

one questions? can jasper not use a simply synchronized block on the jsp 
instance, getting 1 tag instance/class/declaration and stores it somewhere, 
as a example in the pageContext/local variable, and synchronize later in the 
finally block and puts back the tag instances.

Torsten

On Saturday 18 January 2003 21:19, you wrote:
> Costin Manolache wrote:
> > Bill Barker wrote:
> >>If tag-pooling works for you, I'm happy for you.  The current
> >>implementation
> >>doesn't work for me big time.  However, I'm very interested in Costin's
> >>claim that it can be done thread-local.
> >
> > One quick question ( looking at generated code ) - why is the TP limited
> > to 5 instances ? If you expect 20+ concurent requests ( where the TP
> > would actually matter ) - you'll have the overhead of TP sync, and almost
> > no benefit. Can you try again with a larger capacity ?
> >
> > Regarding the "claim" that it can be done thread-local: I attached a
> > first draft, I'll enhance it later ( it could use ThreadWithAttributes -
> > to save one extra hashtable lookup ). Let me know if it helps.
>
> If we could add a check so that JDKs < 1.4 would use the old synced
> code, and JDK >= 1.4 would use TL, I think it would be the best.
>
> BTW, wouldn't using ThreadWithAttributes tie Jasper to Tomcat ?
>
> Remy
>
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Remy Maucherat]

Costin Manolache wrote:

Bill Barker wrote:



If tag-pooling works for you, I'm happy for you.  The current
implementation
doesn't work for me big time.  However, I'm very interested in Costin's
claim that it can be done thread-local.



One quick question ( looking at generated code ) - why is the TP limited
to 5 instances ? If you expect 20+ concurent requests ( where the TP 
would actually matter ) - you'll have the overhead of TP sync, and almost 
no benefit. Can you try again with a larger capacity ?

Regarding the "claim" that it can be done thread-local: I attached a first
draft, I'll enhance it later ( it could use ThreadWithAttributes - to save
one extra hashtable lookup ). Let me know if it helps.

If we could add a check so that JDKs < 1.4 would use the old synced 
code, and JDK >= 1.4 would use TL, I think it would be the best.

BTW, wouldn't using ThreadWithAttributes tie Jasper to Tomcat ?

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Costin Manolache]

Bill Barker wrote:

> If tag-pooling works for you, I'm happy for you.  The current
> implementation
> doesn't work for me big time.  However, I'm very interested in Costin's
> claim that it can be done thread-local.

One quick question ( looking at generated code ) - why is the TP limited
to 5 instances ? If you expect 20+ concurent requests ( where the TP 
would actually matter ) - you'll have the overhead of TP sync, and almost 
no benefit. Can you try again with a larger capacity ?

Regarding the "claim" that it can be done thread-local: I attached a first
draft, I'll enhance it later ( it could use ThreadWithAttributes - to save
one extra hashtable lookup ). Let me know if it helps.


Costin

package org.apache.jasper.runtime;

import javax.servlet.jsp.JspException;
import javax.servlet.jsp.tagext.Tag;
import org.apache.jasper.Constants;
import java.util.Hashtable;
import java.util.Enumeration;

/**
 * Pool of tag handlers that can be reused.
 * Experimental: use thread local.
 *
 * @author Jan Luehe
 */
public class TagHandlerPool {

private int maxSize=100;
private int initialSize=5;
private ThreadLocal perThread=new ThreadLocal();
// for cleanup
private Hashtable threadData=new Hashtable();

private static class PerThreadData {
Tag handlers[];
int current;
}

/**
 * Constructs a tag handler pool with the default capacity.
 */
public TagHandlerPool() {
this(Constants.MAX_POOL_SIZE);
}

/**
 * Constructs a tag handler pool with the given capacity.
 *
 * @param capacity Tag handler pool capacity
 */
public TagHandlerPool(int capacity) {
this.maxSize = capacity;
//this.handlers = new Tag[capacity];
//this.current = -1;
}

/**
 * Gets the next available tag handler from this tag handler pool,
 * instantiating one if this tag handler pool is empty.
 *
 * @param handlerClass Tag handler class
 *
 * @return Reused or newly instantiated tag handler
 *
 * @throws JspException if a tag handler cannot be instantiated
 */
public Tag get(Class handlerClass) throws JspException {
PerThreadData ptd=(PerThreadData)perThread.get();
if( ptd!=null && ptd.current >=0 ) {
return ptd.handlers[ptd.current--];
} else {
try {
return (Tag) handlerClass.newInstance();
} catch (Exception e) {
throw new JspException(e.getMessage(), e);
}
}
}

/**
 * Adds the given tag handler to this tag handler pool, unless this tag
 * handler pool has already reached its capacity, in which case the tag
 * handler's release() method is called.
 *
 * @param handler Tag handler to add to this tag handler pool
 */
public void reuse(Tag handler) {
PerThreadData ptd=(PerThreadData)perThread.get();

if( ptd==null ) {
ptd=new PerThreadData();
ptd.handlers=new Tag[ initialSize ];
ptd.current=0;
threadData.put( ptd, ptd );
}

if (ptd.current < (ptd.handlers.length - 1)) {
ptd.handlers[++ptd.current] = handler;
return;
}

// no more space
if( ptd.handlers.length < maxSize ) {
// reallocate
Tag newH[]=new Tag[ptd.handlers.length + initialSize];
System.arraycopy(ptd.handlers, 0, newH, 0, ptd.handlers.length);
ptd.handlers=newH;
ptd.handlers[++ptd.current]=handler;
return;
}

//else
handler.release();
}

/**
 * Calls the release() method of all available tag handlers in this tag
 * handler pool.
 */
public synchronized void release() {
Enumeration ptdE=threadData.keys();
while( ptdE.hasMoreElements() ) {
PerThreadData ptd=(PerThreadData)ptdE.nextElement();
for (int i=ptd.current; i>=0; i--) {
ptd.handlers[i].release();
}
}
}
}



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Remy Maucherat]

Glenn Nielsen wrote:

Why is it not possible to add (optional) JMX support to j-t-c components so
that we don't have to branch?

I did not say anything about 4.1, just that I feel it is preferable to not
have to maintain two j-t-c code bases.


You can't have everything JMX being optional, it would be just a big 
mess. Plus, for some changes, it's impossible.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.




I think this is a majority vote. Besides, it was agreed on before that 
a branch would be created in j-t-c.


Please point me at the previous vote. If we voted and approved branching 
j-t-c
previously why wasn't it branched then and why are we voting again?

There was no vote, but it was mentioned in Costin's posts (or the 
replies), when talking about changing Coyote API to something JMX.

The added development overhead is small, and I feel it is needed to keep 
the 4.1.x tree stable.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Costin Manolache]

Glenn Nielsen wrote:

>>> Before branching and having to maintain patches in two branches,
>>> why not try to fix the builds and/or change the implemenation of the
>>> additional JMX support so that it can be built optionally.
>> 
>> 
>> Sorry, but this is not possible, and I will *not* include these changes
>> in 4.1.x, at least not for now.
> 
> Why is it not possible to add (optional) JMX support to j-t-c components
> so that we don't have to branch?

Because optional JMX is going to be too painfull and limit a lot of what 
we can do ( or make it much more complex than it needs to be ).

I'll remove JMX from util - that can be easily avoided. 3.3 and 4.0 
have their own http and ajp connectors.


> I did not say anything about 4.1, just that I feel it is preferable to not
> have to maintain two j-t-c code bases.

I agree - but if the cost is making the code too convoluted and use only a 
small subset of JMX - I think it's better to branch.

Registration can be wrapped ( easily ). Notifications and use of 
MBeanRegistration are hard to wrap. 

>From a different perspective - even if j-t-c is branched, it should be
possible to use either branch in any tomcat - if you have JMX, you can
use HEAD with 3.3 or 4.1. 

Costin







--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Glenn Nielsen]

Remy Maucherat wrote:

Glenn Nielsen wrote:


Bill Barker wrote:



[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.



Sorry, but this is not possible, and I will *not* include these changes 
in 4.1.x, at least not for now.

Why is it not possible to add (optional) JMX support to j-t-c components so
that we don't have to branch?

I did not say anything about 4.1, just that I feel it is preferable to not
have to maintain two j-t-c code bases.




I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.



I think this is a majority vote. Besides, it was agreed on before that a 
branch would be created in j-t-c.


Please point me at the previous vote. If we voted and approved branching j-t-c
previously why wasn't it branched then and why are we voting again?


Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Torsten Fohrer]

I patched jasper2 and tagpool to synchronize only at begin/end of the jsp site 
=> 2 syncs per request

Torsten Fohrer

On Saturday 18 January 2003 10:24, you wrote:
> Bill Barker wrote:
> > Yeah, well, almost all of my JSP pages are defined by:
> > 
> >   somename
> >   /somepath/somepage.jsp
> > 
> > And I can assure you that the params for JspServlet don't work at all
> > (unless I take the totally brain-dead path of including the Jasper params
> > in my own servlets).
>
> Either I misunderstood something, or the instructions are bad, but the
> tagPooling parameter is set in conf/web.xml (in the Jasper servlet
> declaration), and is server-wide.
>
> > If tag-pooling works for you, I'm happy for you.  The current
> > implementation doesn't work for me big time.  However, I'm very
> > interested in Costin's claim that it can be done thread-local.
>
> I suppose the effect of syncing can vary greatly depending on the server.
> Using thread local to store the tag instances may be a good idea indeed.
> Definitely something to consider if we decide to target Tomcat 5 at JDK
> 1.4.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 16234] New: - Click on the context node in administration webapps generates an error

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=16234

Click on the context node in administration webapps generates an error

   Summary: Click on the context node in administration webapps
generates an error
   Product: Tomcat 4
   Version: 4.1.19
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


HTTP Status 500 - Error retrieving attribute swallowOutput

type Status report

message Error retrieving attribute swallowOutput

description The server encountered an internal error (Error retrieving attribute
swallowOutput) that prevented it from fulfilling this request.
Apache Tomcat/4.1

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Object Pooling(especially database conn)

[Paul Yunusov]

On Saturday 18 January 2003 06:41 am, White Knight wrote:
> Hi,
> I feel providing Object Pooling ability to tomcat would be very useful.
> Database connection pooling would be very useful for a lot of users.
> I have been doing it as a separate component.I wrote for my purpose and
> bundled with the tomcat my folks are using.I have used the Object pooling
> facility in commons library.
>
> Wouldn't it be nice to make such a thing standard?
>
> Hope to hear your opinions.

Try
ls $CATALINA_HOME/common/lib/*pool*
ls $CATALINA_HOME/common/lib/*dbcp*
and look at
http://marc.theaimsgroup.com/?l=tomcat-user&m=102225547106556&w=2
or similar messages,

or I don't exactly understand you.

Paul

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Remy Maucherat]

Glenn Nielsen wrote:

Bill Barker wrote:



[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.


Sorry, but this is not possible, and I will *not* include these changes 
in 4.1.x, at least not for now.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.


I think this is a majority vote. Besides, it was agreed on before that a 
branch would be created in j-t-c.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: MissingResourceException on ResourceBundle.getBundle()

[Sriram N]

--- Manveen Kaur <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I have a web-app that looks up a properties file.
> 
> I'm getting a java.util.MissingResourceException on
> ResourceBundle.getBundle(..);
> The jar containg the properties file is in WEB-INF/lib.
> 

Could you post the code snippet that tries to load this properties file ?
I don't have access to my code right now, but I think I've written something
like 
-- quote --
ResourceBundle.getBundle("dbconnection");

-- end quote --
> Is this a classpath issue? Is there a workaround?
> 
I don't think this is a classpath issue.
I do this for two web-apps and it works just fine on Tomcat 4.1.12.


> Any help would be greatly appreciated.
> 
> thanks
> Manveen
> 
-- Sriram



__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Glenn Nielsen]

Bill Barker wrote:

I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch (e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3 and
Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the HEAD.


[ ] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[X] -1 I'm against the idea of branching




Before branching and having to maintain patches in two branches,
why not try to fix the builds and/or change the implemenation of the
additional JMX support so that it can be built optionally.

I am a huge +1 on using JMX to capture runtime monitoring data,
but -1 on having two branches to maintain in j-t-c.

Glenn



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10026] - manager/stop and manager/remove

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=10026

manager/stop and manager/remove

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-18 12:19 ---
Sorry, apparently I got to reopen this, please read Craig's comments on #10027:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10027

Seems this problem is related to Tomcat locking (at least some) JARs on WIN

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Object Pooling(especially database conn)

[White Knight]

Hi,
I feel providing Object Pooling ability to tomcat would be very useful.
Database connection pooling would be very useful for a lot of users.
I have been doing it as a separate component.I wrote for my purpose and bundled with 
the tomcat my folks are using.I have used the Object pooling facility in commons 
library.

Wouldn't it be nice to make such a thing standard?

Hope to hear your opinions.



-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Remy Maucherat]

Bill Barker wrote:

Yeah, well, almost all of my JSP pages are defined by:

  somename
  /somepath/somepage.jsp

And I can assure you that the params for JspServlet don't work at all
(unless I take the totally brain-dead path of including the Jasper params in
my own servlets).


Either I misunderstood something, or the instructions are bad, but the 
tagPooling parameter is set in conf/web.xml (in the Jasper servlet 
declaration), and is server-wide.

If tag-pooling works for you, I'm happy for you.  The current implementation
doesn't work for me big time.  However, I'm very interested in Costin's
claim that it can be done thread-local.


I suppose the effect of syncing can vary greatly depending on the server.
Using thread local to store the tag instances may be a good idea indeed. 
Definitely something to consider if we decide to target Tomcat 5 at JDK 1.4.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, January 18, 2003 12:36 AM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked


> Bill Barker wrote:
> > I saw just the opposite.  Jasper2 with tag-pooling was a real dog (the
time
> > spent in synchronized methods to maintain the pool completely swamped
any
> > benefit from GC).  After patching my copy to make don't-tag-pool the
default
> > (since there isn't any way to do this in the config :( ), then Tomcat
> > 4.1/Jasper2 was about 60% faster that Tomcat 3.3/Jasper1 when I 'ab'
> > benchmarked it against one of my more complex pages.
>
> There's a switch in the conifguration to enable/disable tag pooling,
> actually. I'm quite sure it works fine.
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html
>
> Personally, some quick test I had done showed tag pooling to be fatster
> on my configuration.
>

Yeah, well, almost all of my JSP pages are defined by:

  somename
  /somepath/somepage.jsp

And I can assure you that the params for JspServlet don't work at all
(unless I take the totally brain-dead path of including the Jasper params in
my own servlets).

If tag-pooling works for you, I'm happy for you.  The current implementation
doesn't work for me big time.  However, I'm very interested in Costin's
claim that it can be done thread-local.

> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[Remy Maucherat]

Bill Barker wrote:

I saw just the opposite.  Jasper2 with tag-pooling was a real dog (the time
spent in synchronized methods to maintain the pool completely swamped any
benefit from GC).  After patching my copy to make don't-tag-pool the default
(since there isn't any way to do this in the config :( ), then Tomcat
4.1/Jasper2 was about 60% faster that Tomcat 3.3/Jasper1 when I 'ab'
benchmarked it against one of my more complex pages.


There's a switch in the conifguration to enable/disable tag pooling, 
actually. I'm quite sure it works fine.
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html

Personally, some quick test I had done showed tag pooling to be fatster 
on my configuration.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Branch j-t-c for Tomcat 5

[Remy Maucherat]

Costin Manolache wrote:

Bill Barker wrote:



I, personally, think that it's time for a branch in j-t-c.  At this point,
even Tomcat 3.3 won't build against the HEAD.

My proposal is:  Revert the JMX dependencies in j-t-c, Create a branch
(e.g.
coyote_10), and re-apply the JMX patches to the HEAD branch.  Tomcat 3.3
and Tomcat 4.1 will use the coyote_10 branch, and Tomcat 5 will use the
HEAD.

[X] +1 I Support the idea of a branch, and will help maintain it.
[ ] +0 I like the idea
[ ] -0 I don't like the idea
[ ] -1 I'm against the idea of branching




We can branch at tomcat_4_19 tag - that's the simplest solution.

Sorry for the mess - but I think the benefits of knowing what happens
inside tomcat are worth the extra dependencies and some temporary build
problems ( and an extra branch ).


+1 for branching based on the TOMCAT_4_1_19 tag. That's what I was going 
to propose anyway.

Indeed, one of the biggest problems in Tomcat 4.1.x is there are no 
monitoring capabilities at all (except doing a thread dump, I guess ;-) ).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: