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

[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=16001


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 00:39 ---
*** Bug 32957 has been marked as a duplicate of this bug. ***

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

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

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

[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=16001


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-05-23 12:34 ---
*** Bug 34986 has been marked as a duplicate of this bug. ***

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

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-08-19 02:16 ---
According to the JSP 1.1 Errata published on 5/31/00
(http://java.sun.com/products/jsp/errata_1_1_a_042800.html see under "Issue 14")
the behavior exhibited by Jasper (regarding tag pooling) is not in accordance
with the specification for JSP 1.1. The errata recognizes the shortcoming of the
original spec, which did not provide any mechanism for clearing the tag
handler’s state between uses, and it states that tag instances cannot be reused
if they don't correspond to actions with the same attributes, unless release()
is called between uses. 

So, the same instance of the handler can be used for


but for 


you either have to use different instances, or you have to call release() before
second use.

I would assume the same applies for JSP 1.2, unless the specification explicitly
states otherwise.

The errata is there for everyone to see right along side of the original final
specification 
http://java.sun.com/products/jsp/download.html#specs

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-19 04:42 ---
It's true that the 1.1 errata was included in the 1.2 Spec.  However, it's not 
relevent to this report.  Jasper will use seperate instances of the "foo" tag 
handler, which you've already agreed is valid.

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-08-19 17:25 ---
Yep, you are right. I guess we're left with turning tag pooling off. 
Many thanks!

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Jasper  |Jasper 2
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-12 07:37 ---
The JSP spec requires that the release method is called before the tag is 
allowed to pass to GC.  With the default settings to enable tag-pooling, the 
tag is returned to the pool, so the release method can't be called. 

To get the behavior that you want, disable tag-pooling in 
$CATALINA_HOME/conf/web.xml.

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 18:40 ---
*** Bug 16031 has been marked as a duplicate of this bug. ***

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 18:52 ---
The following is regarding bug 16031:

I assume you are referring to the tag handler's release() method when you talk
about resetting its state?

Note that according to the spec, the release() method is guaranteed to
be called on any tag handler, "but there may be multiple invocations
on doStartTag() and doEndTag() in between."

Therefore, your tag handler should not rely on its release() method to
reset any private invocation-specific state. This state is best
initialized in doStartTag(). This means that in your specific example, you
should clear your "key" and "value" objects in your tag handler's doStartTag()
method.

See important tips for tag-handler lifecycle management at

 http://jakarta.apache.org/taglibs/guidelines.html

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-13 19:42 ---
According to the spec, the release() method is guaranteed to be called on any 
tag handler, this is to say, even when the tag handler instance is pooled, it 
still should invoke release() to release any state the tag handler may posess.

In my case, I have a tag handler super class that needs to get a state value 
from session and set it for the child class to construct business view object. 
I agree that it is feasible to clean it up in doStartTag() since my tag is not 
an iteration tag. But still it would be ideal to use release() to clean up 
private invocation-specific state.

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-14 18:08 ---
*** Bug 16071 has been marked as a duplicate of this bug. ***

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 16:13 ---
Created an attachment (id=4464)
A war containing an example of the scenario in which the bug is exposed

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 16:25 ---
I think that Tag.release is not invoked between two uses of the same tag, now
that it is extracted from the pool.

If the tag store a value in an internal variable, depending on a required
attribute, you'll find the previuos value in the next use even if you set it to
null in release.

I don't know if the life-cycle model of custom tags is changed in last
specifications, but I expect to have a clean instance of the object every time I
use it, especially if I've implemented release.

I've posted an attachment containing a small war with a simple tag and a page of
example. Try it.

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 16:42 ---
You cannot put it to null. You have to make a call to removeValue(). Really you
SHOULD NOT do this, because we think that has to be done automatically :P

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 16:55 ---

Lets see if I can get through to you guys, Jan Luehe's fine post was 
apparently not enough.

>From the Tag.release() javadoc:
"...there may be multiple invocations on doStartTag and doEndTag in between."

This is plain english and means that on the same page the tag can be taken out 
of the pool, and then used several times _WITHOUT_ .release() being called in 
between AND THIS IS NOT A BUG. Ergo, Tag.release can NOT be used for resetting 
states between uses of tags.

If you need to reset your internal values that SHOULD be done in doEndTag for 
instance.

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 17:23 ---
I think that from a progammers view :

The programmers should not care about how internal things are done. That is, if
tomcat uses pools of objects for performance improvements or any other approach,
programmer should not care about it, it should only use a tag and if later it is
reused, asume a initial state.



Should not be this the right approach as done on other servers ?

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 17:41 ---

As with any API, the programmer is supposed to understand how it works. I 
didn't write the spec, but it is pretty obvious to me that it is working as 
intended.

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-01-16 18:21 ---
*** Bug 16171 has been marked as a duplicate of this bug. ***

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 08:13 ---
As I understand the api, it does not talk about custom tag pools, it only speaks
about tags, if you use a pool, it should be transparent.

And in other servers it works as we think it should work.

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:19 ---
Your tag does not comply with the JSP specification, and, as a result it may or
may not work. This issue WILL NOT be fixed in Tomcat.
Thanks, and DO NOT REOPEN THIS BUG.

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:37 ---
Ismael,

Please take a look at section 10.5 in the 1.2 spec and section 12.4 in the 2.0
spec :

"Below is a somewhat complete example of the way one JSP container could
choose to do some tag handler management. There are many other strategies that
could be followed, with different pay offs.
The example is as below. In this example, we are assuming that x:iterate is an
iterative tag, while x:doit and x:foobar are simple tag. We will also assume that
x:iterate and x:foobar implement the TryCatchFinally interface, while x:doit does
not.

” />

” />

” />
The particular code shown below assumes there is some pool of tag handlers
that are managed (details not described, although pool managing is simpler when
there are no optional attributes), and attemps to reuse tag handlers if
possible. The
code also “hoists” setting of properties to reduce the cost when appropriate, e.g.
inside an iteration."

As you can see pooling IS Mentioned. If you take a look at the example code that
follows this section you will see that release() is NOT called between tag
invocations. 

The only thing that the spec says has to happen is that release() is called
before the tag is gc'd. This could potentialy only occur when an webcontainer is
shutdown. 

I would suggest you take a look at a custom tag library like struts that
demontrates how custom tags should cleanup when used in a pooled environment.

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 15:29 ---

Consider reading the rest of the spec as well...
Yes tags are meant to be pooled. However .release() is NOT intended to be 
called between reuses of a tag... as the javadoc clearly states.

Even the name "release" tells us that this is not a "reinit".

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 16:39 ---
Ok guys. You're right.

I found the book (about JSP 1.1) in which a flow-chart of the life-cycle of a
tag has driven me in error.

More, there are some JSP engine (such as Weblogic that has implemented the pool
before Tomcat) where release is invoke just after the return of doEndTag, even
if specification says different.

But specs rule!

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 19:43 ---
A note from Hans Bergsten, for reference.

I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-01-20 08:35 ---
Ok, thank you for your responses, I misinterpretted the specification. But I was
confused because on previous version of tomcat (4.1.12 I think) it seemed to
work as I thought it should work. I also tested on another servers and I got the
same behaviour. 

Sorry, next time I will reread the specification before posting :)

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-02-17 15:55 ---
*** Bug 17130 has been marked as a duplicate of this bug. ***

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-02-17 20:23 ---
OK guys, release() method is NOT guaranteed to be called on any tag handler, so
..there may be multiple invocations on doStartTag and doEndTag in between.

But programmers needs a method to initialize the tag between uses. Initializing
it at doStartTag method is not OK because setters are called before doStartTag
so programmer could clear the setted variables.

We need a method to initialize the tag before it's called, Maybe changing the
get method get() at TagHandlerPool.java

If not, please great gurus, how can we use tag pooling without this
initialization issues. JSP spec is not clear about this!

public synchronized Tag get(Class handlerClass) throws JspException {
Tag handler = null;

if (current >= 0) {
handler = handlers[current--];
 
// If handler is already in the cache release it
// It cannot be done at startTag not at EndTag because closed tags can
// return a java object
handler.release();
} else {
try {
return (Tag) handlerClass.newInstance();
} catch (Exception e) {
throw new JspException(e.getMessage(), e);
}
}

return handler;
}

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-03-25 23:33 ---
*** Bug 18349 has been marked as a duplicate of this bug. ***

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:03 ---
I agree that initializing variables in doStartTag() doesn't make sense, since 
the property sets are already called BEFORE doStartTag() according to the 
spec.  So, where does this leave the programmers a place to re-initialize the 
veriables (most importantly the optional custom tag variables).  I figure that 
doAfterBody() is no good because it is called multiple times for BodyTag 
handlers.  So, the only place left is to override setPageContext() and have it 
call super.setPageContext() AND release().  

This is obviously a hack and doesn't seem like a good answer, but I don't see 
any other choice.  Is there one?

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

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

[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=16001

Tag.release() not invoked





--- Additional Comments From [EMAIL PROTECTED]  2003-03-26 18:33 ---
If you look through the comments for this "bug", the solution is defined by the
JSP spec: a tag handler instance can _not_ be reused for occurances of the
corresponding custom action that specify different optional attributes. Hence,
there's no risk that a tag handler that has been used with an optional attribute
is   later used without that optional attribute. See this article for details:

 
  Page 2, the "Tag handler life cycle and instance reuse" section

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

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

[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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2004-01-29 16:53 ---
*** Bug 26527 has been marked as a duplicate of this bug. ***

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

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

[Remy Maucherat]

Martin Algesten wrote:

Remy,

once again we agree :)


Lol, I guess. After the 100th time this bug is being reopened, I'm 
getting pissed ;-)

Remy


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

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

[Tim Moore]

This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 10:58 AM
> To: Tomcat Developers List
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Martin Algesten wrote:
> > Remy,
> > 
> > once again we agree :)
> 
> Lol, I guess. After the 100th time this bug is being reopened, I'm 
> getting pissed ;-)
> 
> Remy

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

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

[Hans Bergsten]

Tim Moore wrote:

This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.


I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section

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

[Tim Moore]

> -Original Message-
> From: Hans Bergsten [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 1:37 PM
> To: Tomcat Developers List
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Tim Moore wrote:
> > This bug seems to be submitted several times a week.  Maybe an FAQ 
> > would be in order? (or FOB -- frequently opened bugs haha)
> > 
> > Then again, if people don't search the bug database before 
> submitting 
> > a new one, then I guess they can't be expected to read the FAQ.
> > 
> > And on the other hand, if the spec confuses this many people, maybe 
> > that should be fed back to the spec authors.  Just adding a "reset" 
> > method to Tag that is called before each invocation might 
> help people 
> > understand the difference between that and release.
> 
> I'm in the EG and we had a long discussion about this again 
> for JSP 2.0. The end result is that the current behavior (do 
> _not_ call release() between invocations) will stay. A 
> confusing arrow from the "released" state to the 
> "initialized" state in the state diagram will be removed, 
> however. This state transition came with lots and lots of 
> restrictions, but it seems like some vendor (and developers) 
> saw it as a requirement to call release() between 
> invocations, even though the text clearly state that that's 
> not the case.
> 

I agree that the current behavior of release should not change.  There
are important uses for long-term state that we shouldn't throw away just
because of some confusion.

But what do you think about the idea of adding a new method?  My
thinking is that if there were a reset method where people could reset
invocation-local state, then it would be easier for people to understand
the correct purpose of release in contrast.  I know there are perfectly
good ways to reset now, so this change would be more for psychological
reasons than technical ones.  You have to admit, though, the fact that
this misunderstanding is so common does say something about the clarity
of the API.  I made this mistake initially, and I believe many of the
Jakarta tags did as well.

I also know that adding methods to an interface can be problematic for
backwards compatibility reasons, but if a noop implementation is added
to TagSupport, that would handle 90% of the problem.

What do you think?
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


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

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

[Hans Bergsten]

Tim Moore wrote:

[...]
I agree that the current behavior of release should not change.  There
are important uses for long-term state that we shouldn't throw away just
because of some confusion.


Right.


But what do you think about the idea of adding a new method?  My
thinking is that if there were a reset method where people could reset
invocation-local state, then it would be easier for people to understand
the correct purpose of release in contrast.  I know there are perfectly
good ways to reset now, so this change would be more for psychological
reasons than technical ones.  You have to admit, though, the fact that
this misunderstanding is so common does say something about the clarity
of the API.  I made this mistake initially, and I believe many of the
Jakarta tags did as well.


Yes, the whole reuse things was pretty much unspecified in JSP 1.1.
When we tried to clarify it in JSP 1.2, we discussed adding a reset()
method at length (the reuse discussions are by far the most intense
discussions in the JSP EG ;-) but in the end decided to keep the API
backwards compatible and bolt reuse on top of it (with the various
rules for when release() can be called, only reuse for the same
attribute set, etc.). In hindsight, I think it was a mistake, but that
boat has sailed. See below.


I also know that adding methods to an interface can be problematic for
backwards compatibility reasons, but if a noop implementation is added
to TagSupport, that would handle 90% of the problem.

What do you think?


That's the main reason that we decided to not add a method in JSP 1.2,
and the same applies to JSP 2.0. Even though you can minimize the
problem by adding a noop in TagSupport, you're still not covering 100%
of the cases.

Another reason for not doing this in JSP 2.0 is that JSP 2.0 introduces
a new tag handler API: SimpleTag. This API has a much simpler lifecycle,
basically just attribute setters and one doTag() method that, coupled
with the new JspFragment API, handles iterations and accessing the body
evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.

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

[Martin Algesten]

Remy,

once again we agree :)

M

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 17 January 2003 14:19
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT 
> <http://nagoya.apache.org/bugzilla/show_bug.cg> i?id=16001>.
> 
> 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=16001

Tag.release() not invoked

[EMAIL PROTECTED] changed:

   What|Removed |Added


 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-17 14:19
--- Your tag does not comply with the JSP specification, and, as a
result it may or may not work. This issue WILL NOT be fixed in Tomcat.
Thanks, and DO NOT REOPEN THIS BUG.

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


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

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

[Costin Manolache]

Hans Bergsten wrote:

> evaluation all in one place. To make things even easier, these tag
> handlers can _not_ be reused at all. Benchmarks with modern JVMs show
> that the gain from reuse is not worth all the trouble. So, for new
> tags we recommend using the SimpleTag API which takes care of the
> problem by forbidding reuse.

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.

Costin




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

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

[Tim Moore]

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 17, 2003 5:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked
> 
> 
> Hans Bergsten wrote:
> 
> > evaluation all in one place. To make things even easier, these tag 
> > handlers can _not_ be reused at all. Benchmarks with modern 
> JVMs show 
> > that the gain from reuse is not worth all the trouble. So, for new 
> > tags we recommend using the SimpleTag API which takes care of the 
> > problem by forbidding reuse.
> 
> 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.
> 
> Costin

I thought the benefit of Tag.release and pooling was that I could create
a tag that does something expensive at init time (acquire a DB
connection, read a file, whatever) and reuse those resources until
released.  Maybe that's a bad practice?  But then what's the advantage
of having release called only once before GC?

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863


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

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

[Hans Bergsten]

Costin Manolache wrote:

Hans Bergsten wrote:



evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.



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.

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

[Hans Bergsten]

Tim Moore wrote:

[...]
I thought the benefit of Tag.release and pooling was that I could create
a tag that does something expensive at init time (acquire a DB
connection, read a file, whatever) and reuse those resources until
released.  Maybe that's a bad practice?  But then what's the advantage
of having release called only once before GC?


Yes, that was the idea, and since the "classic" API is still part of
JSP 2.0, you can use it for this type of tag handler if you need it.
Most tag handler's don't need it though (you can often cache the
expensive objects elsewhere, such as in the application or session
scope). So for the majority of case, the SimpleTag API will be the
best fit.

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

[Glenn Nielsen]

Costin Manolache wrote:

Hans Bergsten wrote:



evaluation all in one place. To make things even easier, these tag
handlers can _not_ be reused at all. Benchmarks with modern JVMs show
that the gain from reuse is not worth all the trouble. So, for new
tags we recommend using the SimpleTag API which takes care of the
problem by forbidding reuse.



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.

Costin

Hear, Hear!!

I saw a significant, measureable improvement in performance when I upgraded
our production systems to Jasper 2 with tag pooling from Jasper 1 without.
CPU load on the production server dropped around 30%, request latency was
reduced significantly, etc.  The app server handles 30k-100K requests per day.
This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an app server.
OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time tuning
the JVM stack and GC java startup args.

Tag pooling elminates significant amounts of GC.  That is where the real
benefit of tag pooling comes from.  With tag pooing the frequency and
length of GC's are reduced a great deal.

Glenn


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

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

[Bill Barker]

- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 17, 2003 7:04 PM
Subject: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked


> Costin Manolache wrote:
> > Hans Bergsten wrote:
> >
> >
> >>evaluation all in one place. To make things even easier, these tag
> >>handlers can _not_ be reused at all. Benchmarks with modern JVMs show
> >>that the gain from reuse is not worth all the trouble. So, for new
> >>tags we recommend using the SimpleTag API which takes care of the
> >>problem by forbidding reuse.
> >
> >
> > 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.
> >
> > Costin
>
> Hear, Hear!!
>
> I saw a significant, measureable improvement in performance when I
upgraded
> our production systems to Jasper 2 with tag pooling from Jasper 1 without.
> CPU load on the production server dropped around 30%, request latency was
> reduced significantly, etc.  The app server handles 30k-100K requests per
day.
> This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an app
server.
> OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time
tuning
> the JVM stack and GC java startup args.
>
> Tag pooling elminates significant amounts of GC.  That is where the real
> benefit of tag pooling comes from.  With tag pooing the frequency and
> length of GC's are reduced a great deal.
>

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.

> Glenn
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


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

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

[Costin Manolache]

Bill Barker wrote:

>> I saw a significant, measureable improvement in performance when I
> upgraded
>> our production systems to Jasper 2 with tag pooling from Jasper 1
>> without. CPU load on the production server dropped around 30%, request
>> latency was
>> reduced significantly, etc.  The app server handles 30k-100K requests per
> day.
>> This is on a Sun dual CPU E250, 768MB of Ram, that is run solely as an
>> app
> server.
>> OS is Solaris 8, JVM is 1.3.1 using HotSpot server, and I have spent time
> tuning
>> the JVM stack and GC java startup args.
>>
>> Tag pooling elminates significant amounts of GC.  That is where the real
>> benefit of tag pooling comes from.  With tag pooing the frequency and
>> length of GC's are reduced a great deal.
>>
> 
> 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.


Yes, I've seen similar results - tag libs are very tricky from a performance
point of view.

The problem is that jasper does a lot of synchronization - it is a problem
with the tagpool implementation, not an indication that creating tons of 
garbage is good. You can make the whole tag reuse be sync-free,
and have the entire page served without any allocation - just create the
tags once, at init time - and keep them in a per/thread data. 


Costin





 






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


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

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

[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: 

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

[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

[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

[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: 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

[Johan Åbrandt]

Hans Bergsten wrote:


Tim Moore wrote:


This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.



I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section




If I understand the section Hans directs to correctly, re-use of a 
pooled tag is only allowed if the tags have the same set of attributes:

"A tag handler instance can only be reused for an occurrence with the 
same set of attributes."

Where in the specification (JSP 1.2) is this specified? Is it derived 
from section 10.3?, or is it mentioned explicitly somewhere else?

Is this the way the Jasper tag pooling is implemented?


Hans




Br - Johan



__

This message and its attachments have been found clean from known viruses 
with three different antivirus programs.
__

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

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

[Hans Bergsten]

Johan Åbrandt wrote:

Hans Bergsten wrote:


Tim Moore wrote:


This bug seems to be submitted several times a week.  Maybe an FAQ would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe that
should be fed back to the spec authors.  Just adding a "reset" method to
Tag that is called before each invocation might help people understand
the difference between that and release.




I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section


If I understand the section Hans directs to correctly, re-use of a 
pooled tag is only allowed if the tags have the same set of attributes:

"A tag handler instance can only be reused for an occurrence with the 
same set of attributes."

Where in the specification (JSP 1.2) is this specified? Is it derived 
from section 10.3?, or is it mentioned explicitly somewhere else?

See JSP.10.1.1 in the JSP 1.2 spec:

  Methods
  There are two main actions: doStartTag and doEndTag. Once all
  appropriate properties have been initialized, the doStartTag and
  doEndTag methods can be invoked on the tag handler. Between these
  invocations, the tag handler is assumed to hold a state that must
  be preserved. After the doEndTag invocation, the tag handler is
  available for further invocations (and it is expected to have
  retained its properties).

  Lifecycle
  [...]
  * [3] Note that since there are no guarantees on the state of the
properties, a tag handler that had some optional properties set
can only be reused if those properties are set to a new (known)
value. This means that tag handlers can only be reused within the
same "AttSet" (set of attributes that have been set).

I could have sworn it was explicitly stated somewhere else as well,
since bullet [3] is confusing; it's a description of a transition from
"released" to "initialized", which by the way comes with a few more
rules (e.g. the tag handler must recreate long-lived resources it
may have created in its constructor when reused after release()).

For JSP 2.0, however, the "same set of attributes" requirement is
explicitly stated (from an upcoming PFD2):

  The JSP container may reuse classic tag handler instances for
  multiple occurrences of the corresponding custom action, in the
  same page or in different pages, but only if the same set of
  attributes are used for all occurrences. If a tag handler is used
  for more than one occurence, the container must reset all attributes
  where the values differ between the custom action occurrences.
  Attributes with the same value in all occurrences must not be reset.
  If an attribute value is set as a request-time attribute value (using
  a scripting or an EL expression), the container must reset the
  attribute between all reuses of the tag handler instance.


Is this the way the Jasper tag pooling is implemented?


As far as I have seen, yes.

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

[Johan Åbrandt]

Hans Bergsten wrote:


Johan Åbrandt wrote:


Hans Bergsten wrote:


Tim Moore wrote:


This bug seems to be submitted several times a week.  Maybe an FAQ 
would
be in order? (or FOB -- frequently opened bugs haha)

Then again, if people don't search the bug database before submitting a
new one, then I guess they can't be expected to read the FAQ.

And on the other hand, if the spec confuses this many people, maybe 
that
should be fed back to the spec authors.  Just adding a "reset" 
method to
Tag that is called before each invocation might help people understand
the difference between that and release.




I'm in the EG and we had a long discussion about this again for JSP 2.0.
The end result is that the current behavior (do _not_ call release()
between invocations) will stay. A confusing arrow from the "released"
state to the "initialized" state in the state diagram will be removed,
however. This state transition came with lots and lots of restrictions,
but it seems like some vendor (and developers) saw it as a requirement
to call release() between invocations, even though the text clearly
state that that's not the case.

This is being discussed pretty much everywhere these days and I hope
people eventually will get it. I wrote about it in an article just
after JSP 1.2 was released. Feel free to point people to it if you
get tired of rehashing the same arguments over and over ;-)

  
  Page 2, the "Tag handler life cycle and instance reuse" section



If I understand the section Hans directs to correctly, re-use of a 
pooled tag is only allowed if the tags have the same set of attributes:

"A tag handler instance can only be reused for an occurrence with the 
same set of attributes."

Where in the specification (JSP 1.2) is this specified? Is it derived 
from section 10.3?, or is it mentioned explicitly somewhere else?


See JSP.10.1.1 in the JSP 1.2 spec:

  Methods
  There are two main actions: doStartTag and doEndTag. Once all
  appropriate properties have been initialized, the doStartTag and
  doEndTag methods can be invoked on the tag handler. Between these
  invocations, the tag handler is assumed to hold a state that must
  be preserved. After the doEndTag invocation, the tag handler is
  available for further invocations (and it is expected to have
  retained its properties).

  Lifecycle
  [...]
  * [3] Note that since there are no guarantees on the state of the
properties, a tag handler that had some optional properties set
can only be reused if those properties are set to a new (known)
value. This means that tag handlers can only be reused within the
same "AttSet" (set of attributes that have been set).



Ok, thanks for clarifying this.



I could have sworn it was explicitly stated somewhere else as well,
since bullet [3] is confusing; it's a description of a transition from
"released" to "initialized", which by the way comes with a few more
rules (e.g. the tag handler must recreate long-lived resources it
may have created in its constructor when reused after release()).

For JSP 2.0, however, the "same set of attributes" requirement is
explicitly stated (from an upcoming PFD2):

  The JSP container may reuse classic tag handler instances for
  multiple occurrences of the corresponding custom action, in the
  same page or in different pages, but only if the same set of
  attributes are used for all occurrences. If a tag handler is used
  for more than one occurence, the container must reset all attributes
  where the values differ between the custom action occurrences.
  Attributes with the same value in all occurrences must not be reset.
  If an attribute value is set as a request-time attribute value (using
  a scripting or an EL expression), the container must reset the
  attribute between all reuses of the tag handler instance.



Like the last paragraph... =)




Is this the way the Jasper tag pooling is implemented?





As far as I have seen, yes.



Sorry for asking, I should have (did actually) checked myself...



Hans



__

This message and its attachments have been found clean from known viruses 
with three different antivirus programs.
__

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

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

[Costin Manolache]

Taking Glenn's post out of thread:


Glenn Nielsen wrote:

> 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).

If we're going to keep the current around - we should at least increase
the limit. 



> 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

A mechanism to clean up unused pools could help reduce this ( similar with 
ThreadPool ). ( maybe combined with some JMX to give insight into how many 
pools and tags are in used - quite usefull ).

This is the classical "memory versus time" - a choice that users should make
for themself, depending on the application they run. A production site with 
a lot of memory and very high traffic on few pages may choose the speed.


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

If this is still thread local - I'm +0 ( i.e. I won't implement it, but
I think it's a great idea ).

That would make it ( threads * maxTag ), where maxTag is the maximum number
of one tag in any page. 

It shouldn't be hard - you'll need to pass the context and keep the
ThreadLocal in the context.

Of course - keep in mind that you need one pool for each tag+attribute_set
( another wise requirement..)


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

If by global you mean cross-context - I don't think it would work ( 
versioning, security, etc ).


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

Again - if by global you mean per context, +1. Per server is too dangerous
( a thread can hold on the reference for a tag and access it when it is 
in used in a different context ).


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

+1 for Context Thread Local ( eventually combined with some expiration
strategy ).


Costin


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

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: 

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

[Torsten Fohrer]

on option, can it be minimize the synchronized calls, as a example.

1. Removing synchronized methods in TagPool
2. Adding a synchronize block on top of the jspService method, that get all
needed tag instances
3. normal using the instances
4. Adding a synchronize block in finally block to put back the tag instances

this can simply extended to support tagpool per unique tag/attribute
combination in the same context.


Torsten Fohrer

> -Ursprüngliche Nachricht-
> Von: Costin Manolache [mailto:[EMAIL PROTECTED]]
> Gesendet: Dienstag, 21. Januar 2003 01:08
> An: [EMAIL PROTECTED]
> Betreff: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - 
> Tag.release()
> not invoked
> 
> 
> Taking Glenn's post out of thread:
> 
> 
> Glenn Nielsen wrote:
> 
> > 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).
> 
> If we're going to keep the current around - we should at 
> least increase
> the limit. 
> 
> 
> 
> > 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
> 
> A mechanism to clean up unused pools could help reduce this ( 
> similar with 
> ThreadPool ). ( maybe combined with some JMX to give insight 
> into how many 
> pools and tags are in used - quite usefull ).
> 
> This is the classical "memory versus time" - a choice that 
> users should make
> for themself, depending on the application they run. A 
> production site with 
> a lot of memory and very high traffic on few pages may choose 
> the speed.
> 
> 
> > 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.
> 
> If this is still thread local - I'm +0 ( i.e. I won't 
> implement it, but
> I think it's a great idea ).
> 
> That would make it ( threads * maxTag ), where maxTag is the 
> maximum number
> of one tag in any page. 
> 
> It shouldn't be hard - you'll need to pass the context and keep the
> ThreadLocal in the context.
> 
> Of course - keep in mind that you need one pool for each 
> tag+attribute_set
> ( another wise requirement..)
> 
> 
> > 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.
> 
> If by global you mean cross-context - I don't think it would work ( 
> versioning, security, etc ).
> 
> 
> > 
> > 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 Pe

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

[Glenn Nielsen]

Costin Manolache wrote:

Taking Glenn's post out of thread:


Glenn Nielsen wrote:



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).



If we're going to keep the current around - we should at least increase
the limit. 




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



A mechanism to clean up unused pools could help reduce this ( similar with 
ThreadPool ). ( maybe combined with some JMX to give insight into how many 
pools and tags are in used - quite usefull ).

This is the classical "memory versus time" - a choice that users should make
for themself, depending on the application they run. A production site with 
a lot of memory and very high traffic on few pages may choose the speed.



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.



If this is still thread local - I'm +0 ( i.e. I won't implement it, but
I think it's a great idea ).

That would make it ( threads * maxTag ), where maxTag is the maximum number
of one tag in any page. 

It shouldn't be hard - you'll need to pass the context and keep the
ThreadLocal in the context.

Of course - keep in mind that you need one pool for each tag+attribute_set
( another wise requirement..)



Global


Let me rename this:

Context 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.



If by global you mean cross-context - I don't think it would work ( 
versioning, security, etc ).


No, Global means global within a single webapp but pools tags for all
JSP pages within a context.  There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.





Global Thread Local


Let me rename this:

Context 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.



Again - if by global you mean per context, +1. Per server is too dangerous
( a thread can hold on the reference for a tag and access it when it is 
in used in a different context ).



Yes, Global means global within a single webapp but pools tags for all
JSP pages within the context.  There are too many problems trying to pool
cross-context due to each context having its own WebappClassLoader.




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.



+1 for Context Thread Local ( eventually combined with some expiration
strategy ).



Was that a +1 to the renamed Context Global Thread Local?

Glenn



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

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

[Costin Manolache]

Hans Bergsten wrote:

>  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

>From 1.2s to 1.7s there is about 35% difference. I would call this 
quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
increase the thread count to 100 - and you'll see this going up.

The difference ( 0.5s ) is probably 2-3 times the response time of
apache for a static page. And most users will feel it.

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

Increasing it from the current 5 - it would make a difference. 
I agree - the "ideal" no overhead is harder to achieve, but I think the 
thread-local,no-sync case is close enough. 

I'll try to reproduce the test. BTW, how many requests did you make, and
what was the max response time ( max is very affected by GC ) ? I usually do 
5000 to warm up and 10.000 to run the test.

This is a very good start, thanks for bringing this up. 

Costin


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

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

[Glenn Nielsen]

Interesting.  Your test JSP page looks like a valid test.

There is no data about GC in your tests, of course GC can happen at any time.

I would be interested in seeing the tests run with -Xincgc and -Xverbose:gc.
Then run a high enough volume of tests that a Full GC gets triggered a dozen
times or so.  I would think the GC data would be very different between the
5 thread and 20 thread tests with tag pooling enabled.  The metrics to use
might be the time spent doing GC, the number of incremental GC's, and the
number of Full GC's.

There is also no data about system CPU load. The tests show performance
from a request latency and requests per second viewpoint, but do not
necessarily show the difference in scaling.  Showing CPU load might
indicate whether one solution scales better than another.

Regards,

Glenn

Hans Bergsten wrote:

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





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

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

[Hans Bergsten]

Glenn Nielsen wrote:

Interesting.  Your test JSP page looks like a valid test.


Good.


There is no data about GC in your tests, of course GC can happen at any 
time.

I would be interested in seeing the tests run with -Xincgc and 
-Xverbose:gc.
Then run a high enough volume of tests that a Full GC gets triggered a 
dozen
times or so.  I would think the GC data would be very different between the
5 thread and 20 thread tests with tag pooling enabled.  The metrics to use
might be the time spent doing GC, the number of incremental GC's, and the
number of Full GC's.

I can rerun the tests with these options and include a sample of the
verbose:gc output. Does that help? I'm afraid I don't have the time to
summarize the GC data as you suggest, but you're welcome to do so ;-)


There is also no data about system CPU load. The tests show performance
from a request latency and requests per second viewpoint, but do not
necessarily show the difference in scaling.  Showing CPU load might
indicate whether one solution scales better than another.


Any tips about the best way to measure CPU in a meaningful way on Linux?
I know about top/gtop, vmstat, uptime etc. but they show system values
(or snapshots of the current CPU for a thread). I vaguely recall using
a command on Solaris many years ago that takes the command you want to
measure as an argument and gives you min, max and average CPU when it
completes, but I've forgot what it's called. Does it ring any bells?
If not, what do you recommend to measure CPU?

Hans


Hans Bergsten wrote:


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






--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




--
Ha

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

[Hans Bergsten]

Costin Manolache wrote:

Hans Bergsten wrote:



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




From 1.2s to 1.7s there is about 35% difference. I would call this 
quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
increase the thread count to 100 - and you'll see this going up.

The difference ( 0.5s ) is probably 2-3 times the response time of
apache for a static page. And most users will feel it.


I agree that in percentage, the difference is somewhat significant,
but don't make too much out of the real value. My test server is not
representative of the type of hardware you would use for a site with
this type of load. On hardware suitable for the task, the difference in
the real values will likely be a lot smaller, and IMHO, insignificant.
But please, let's not start a long debate about what's significant or
not (that depends on too many factors). All I'm trying to show with
these simple tests is that for pooling to really make a difference at
all, you need to avoid all overhead, which may be very hard, and that
the overhead with current pooling seems to eat all potential gain.


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.



Increasing it from the current 5 - it would make a difference. 
I agree - the "ideal" no overhead is harder to achieve, but I think the 
thread-local,no-sync case is close enough. 

I'll try to reproduce the test. BTW, how many requests did you make, and
what was the max response time ( max is very affected by GC ) ? I usually do 
5000 to warm up and 10.000 to run the test.

I ran 10,000 requests for each test case after a manual warm up (just a
few requests to give the JIT a chance to kick in). If I rerun the tests
to capture GC data (as Glen was asking for), I can run a longer warm-up
as well. I didn't record the max values, but IIRC they were around 100
sec in all cases.


This is a very good start, thanks for bringing this up. 

I hope it at least gives us a better idea about what types of gains
we can realistically expect from tag handler reuse.

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: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

[Remy Maucherat]

Hans Bergsten wrote:

Costin Manolache wrote:


quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
increase the thread count to 100 - and you'll see this going up.

The difference ( 0.5s ) is probably 2-3 times the response time of
apache for a static page. And most users will feel it.



I agree that in percentage, the difference is somewhat significant,
but don't make too much out of the real value. My test server is not
representative of the type of hardware you would use for a site with
this type of load. On hardware suitable for the task, the difference in
the real values will likely be a lot smaller, and IMHO, insignificant.
But please, let's not start a long debate about what's significant or
not (that depends on too many factors). All I'm trying to show with
these simple tests is that for pooling to really make a difference at
all, you need to avoid all overhead, which may be very hard, and that
the overhead with current pooling seems to eat all potential gain.


Personally, I like to think in terms of percentages, as it gives 
something to measure improvement, and anything which will give 10% of 
free performance is good. (Of course, if you don't need the extra 
performance, then good for you)

There have been a lot of changes which individually gave only a small 
performance gain when going from 4.0 to 4.1, but put everything together 
and it ends up being much faster. I also think it's great there's no 
longer any huge hotspot left in Tomcat, which would represent that much 
in (wasted) processing time. 5.0 will be no different, and will feature 
a lot of incremental performance improvements, which hopefully will be 
significant once all put together.

Remy


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

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

[Costin Manolache]

Hans Bergsten wrote:

>>> 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
>> 
>> 
>>>From 1.2s to 1.7s there is about 35% difference. I would call this
>> quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
>> increase the thread count to 100 - and you'll see this going up.
>> 
>> The difference ( 0.5s ) is probably 2-3 times the response time of
>> apache for a static page. And most users will feel it.
> 
> I agree that in percentage, the difference is somewhat significant,
> but don't make too much out of the real value. My test server is not
> representative of the type of hardware you would use for a site with
> this type of load. On hardware suitable for the task, the difference in

And the test page is not representative of the type of pages that will
run on a real site.  I know that.

All we can measure with relative accuracy is the overhead of the 
container/jsp implementation - at least in relative terms. 
Take as the reference the time ( or RPS ) for Apache to serve the same
output as a static page. Or the time a servlet will take to generate
the same output. Run your tests with 5, 20, 100 RPS ( and "ab" may be
a better driver ). Compare the results - and most likely a production
server will see similar ratios.

I'll try to find some time ( next week - I hope ) and run the same 
tests with the "no sync" pool.


> the real values will likely be a lot smaller, and IMHO, insignificant.
> But please, let's not start a long debate about what's significant or
> not (that depends on too many factors). All I'm trying to show with
> these simple tests is that for pooling to really make a difference at
> all, you need to avoid all overhead, which may be very hard, and that
> the overhead with current pooling seems to eat all potential gain.

Well - it shows pretty clearly that the _current_ implementation
of thread pool is broken. Even if we don't take sync into account, the pool
has a 5 object limit - what else could you expect ??


> I ran 10,000 requests for each test case after a manual warm up (just a
> few requests to give the JIT a chance to kick in). If I rerun the tests
> to capture GC data (as Glen was asking for), I can run a longer warm-up
> as well. I didn't record the max values, but IIRC they were around 100
> sec in all cases.

The 1.4 JIT takes some time to kick in, if you run batches of 1000 requests
you'll see the time keeps improving. I would do at leat 5000 request to
warm up the jit.

>> This is a very good start, thanks for bringing this up.
> 
> I hope it at least gives us a better idea about what types of gains
> we can realistically expect from tag handler reuse.

Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to 
object reuse. It is possible that tag handlers are different and 
the other overheads will obscure any benefit ( at least under low load ),
but I can bet that under heavy load recycling will be very significant, if 
done correctly. 

Costin




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

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

[Peter Lin]

 
I haven't read all the posts on this discussion, but here's some facts from personal 
observations.
for pages with only a few tags, ie less than 30, tag pooling doesn't help.  On the 
otherhand, if your page has 100+ tags, it improves performance. Some of the pages I 
benchmarked with had about 135 tags. In those situations, I saw a 20-50% improvement. 
I would argue that sites that don't have a lot of load should simply turn off tag 
pooling.  Site that use tags extensively and get 1millions page views a day, will gain 
significantly from tag pooling.
 
peter lin
 
 Costin Manolache <[EMAIL PROTECTED]> wrote:Hans Bergsten wrote:

>>> Without pooling With pooling Reuse w/o overhead
>>>-
>>>5 threads
>>> Avg.: 330 ms 349 ms N/A
>>> Rate: 15.2/sec 13.6/sec N/A
>>>
>>>20 threads
>>> Avg.: 1,752 ms 1,446 ms 1,265 ms
>>> Rate: 12.1/sec 13.6/sec 14.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
>> 
>> 
>>>From 1.2s to 1.7s there is about 35% difference. I would call this
>> quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
>> increase the thread count to 100 - and you'll see this going up.
>> 
>> The difference ( 0.5s ) is probably 2-3 times the response time of
>> apache for a static page. And most users will feel it.
> 
> I agree that in percentage, the difference is somewhat significant,
> but don't make too much out of the real value. My test server is not
> representative of the type of hardware you would use for a site with
> this type of load. On hardware suitable for the task, the difference in

And the test page is not representative of the type of pages that will
run on a real site. I know that.

All we can measure with relative accuracy is the overhead of the 
container/jsp implementation - at least in relative terms. 
Take as the reference the time ( or RPS ) for Apache to serve the same
output as a static page. Or the time a servlet will take to generate
the same output. Run your tests with 5, 20, 100 RPS ( and "ab" may be
a better driver ). Compare the results - and most likely a production
server will see similar ratios.

I'll try to find some time ( next week - I hope ) and run the same 
tests with the "no sync" pool.


> the real values will likely be a lot smaller, and IMHO, insignificant.
> But please, let's not start a long debate about what's significant or
> not (that depends on too many factors). All I'm trying to show with
> these simple tests is that for pooling to really make a difference at
> all, you need to avoid all overhead, which may be very hard, and that
> the overhead with current pooling seems to eat all potential gain.

Well - it shows pretty clearly that the _current_ implementation
of thread pool is broken. Even if we don't take sync into account, the pool
has a 5 object limit - what else could you expect ??


> I ran 10,000 requests for each test case after a manual warm up (just a
> few requests to give the JIT a chance to kick in). If I rerun the tests
> to capture GC data (as Glen was asking for), I can run a longer warm-up
> as well. I didn't record the max values, but IIRC they were around 100
> sec in all cases.

The 1.4 JIT takes some time to kick in, if you run batches of 1000 requests
you'll see the time keeps improving. I would do at leat 5000 request to
warm up the jit.

>> This is a very good start, thanks for bringing this up.
> 
> I hope it at least gives us a better idea about what types of gains
> we can realistically expect from tag handler reuse.

Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to 
object reuse. It is possible that tag handlers are different and 
the other overheads will obscure any benefit ( at least under low load ),
but I can bet that under heavy load recycling will be very significant, if 
done correctly. 

Costin




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



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

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

[Costin Manolache]

Peter Lin wrote:

> 
>  
> I haven't read all the posts on this discussion, but here's some facts
> from personal observations.
> for pages with only a few tags, ie less than 30, tag pooling doesn't help.
>  On the otherhand, if your page has 100+ tags, it improves performance.
> Some of the pages I benchmarked with had about 135 tags. In those
> situations, I saw a 20-50% improvement. I would argue that sites that
> don't have a lot of load should simply turn off tag pooling.  Site that
> use tags extensively and get 1millions page views a day, will gain
> significantly from tag pooling.


Is this based on the current tag pool implementation in jasper2 ?
Because it is pretty clear that the tag pool has few problems. 

I would say the nature of the tags will also have a big impact. If your
tag is very simple - you'll probably get some "small" benefits under load
( 20..30% ?). If the tag uses internal data structures, buffers, etc - 
it's very likely you'll see more ( since creating each tag instance will
also create the additional hashtable, StringBuffers, etc ).

I would bet that with complex tags that are specifically written to take 
advantage of the recycling you would see at least 2x better performance ( 
with a good sync-free and large enough tag pool ). If your tag is using 
any buffers or complex/expensive data structures that can be recycled - 
you'll save a lot. 

I don't think the number of tags in a page is too important - even if you
have 1 complex tag - with 100 concurent users - you should see a difference.

In an ideal world, all "core" tags would be recyclable and garbage-free - 
that may allow them to run at comparable speed with a hard-coded page.


Costin


>  
> peter lin
>  
>  Costin Manolache <[EMAIL PROTECTED]> wrote:Hans Bergsten wrote:
> 
 Without pooling With pooling Reuse w/o overhead
-
5 threads
 Avg.: 330 ms 349 ms N/A
 Rate: 15.2/sec 13.6/sec N/A

20 threads
 Avg.: 1,752 ms 1,446 ms 1,265 ms
 Rate: 12.1/sec 13.6/sec 14.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
>>> 
>>> 
From 1.2s to 1.7s there is about 35% difference. I would call this
>>> quite significant. Even between 1.4 and 1.7 - you have 20%. Try to
>>> increase the thread count to 100 - and you'll see this going up.
>>> 
>>> The difference ( 0.5s ) is probably 2-3 times the response time of
>>> apache for a static page. And most users will feel it.
>> 
>> I agree that in percentage, the difference is somewhat significant,
>> but don't make too much out of the real value. My test server is not
>> representative of the type of hardware you would use for a site with
>> this type of load. On hardware suitable for the task, the difference in
> 
> And the test page is not representative of the type of pages that will
> run on a real site. I know that.
> 
> All we can measure with relative accuracy is the overhead of the
> container/jsp implementation - at least in relative terms.
> Take as the reference the time ( or RPS ) for Apache to serve the same
> output as a static page. Or the time a servlet will take to generate
> the same output. Run your tests with 5, 20, 100 RPS ( and "ab" may be
> a better driver ). Compare the results - and most likely a production
> server will see similar ratios.
> 
> I'll try to find some time ( next week - I hope ) and run the same
> tests with the "no sync" pool.
> 
> 
>> the real values will likely be a lot smaller, and IMHO, insignificant.
>> But please, let's not start a long debate about what's significant or
>> not (that depends on too many factors). All I'm trying to show with
>> these simple tests is that for pooling to really make a difference at
>> all, you need to avoid all overhead, which may be very hard, and that
>> the overhead with current pooling seems to eat all potential gain.
> 
> Well - it shows pretty clearly that the _current_ implementation
> of thread pool is broken. Even if we don't take sync into account, the
> pool has a 5 object limit - what else could you expect ??
> 
> 
>> I ran 10,000 requests for each test case after a manual warm up (just a
>> few requests to give the JIT a chance to kick in). If I rerun the tests
>> to capture GC data (as Glen was asking for), I can run a longer warm-up
>> as well. I didn't record the max values, but IIRC they were around 100
>> sec in all cases.
> 
> The 1.4 JIT takes some time to kick in, if you run batches of 1000
> requests you'll see the time keeps improving. I would do at leat 5000
> request to warm up the jit.
> 
>>> This is a very good start, thanks for bringing this up.
>> 
>> I hope it at least gives us a better idea about what types of gains
>> we can realistically expect from tag handler reuse.
> 
> Most of the improvements in coyote ( or in 3.3 over 3.2 ) are due to
> object reuse. It is possible th

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

[Peter Lin]

 
these were all JSTL tags.  Back when I ran the tests, I posted some of the results.  I 
did tests that were synthetic, ie out 100 JSTL out tags in one page.  Others were 
based on an actual page layout with lots of markup logic that use jstl  in 
conjunction with jslt xml tags.
 
the tests were with tomcat 4.1's jasper2 and with 4.0x jasper1. obviously the tag 
pooling was only with jasper2. I didn't have time to test tomcat 3.x tag pooling.
 
peter lin
 
 Costin Manolache <[EMAIL PROTECTED]> wrote:Peter Lin wrote:

> 
> 
> I haven't read all the posts on this discussion, but here's some facts
> from personal observations.
> for pages with only a few tags, ie less than 30, tag pooling doesn't help.
> On the otherhand, if your page has 100+ tags, it improves performance.
> Some of the pages I benchmarked with had about 135 tags. In those
> situations, I saw a 20-50% improvement. I would argue that sites that
> don't have a lot of load should simply turn off tag pooling. Site that
> use tags extensively and get 1millions page views a day, will gain
> significantly from tag pooling.


Is this based on the current tag pool implementation in jasper2 ?
Because it is pretty clear that the tag pool has few problems. 

I would say the nature of the tags will also have a big impact. If your
tag is very simple - you'll probably get some "small" benefits under load
( 20..30% ?). If the tag uses internal data structures, buffers, etc - 
it's very likely you'll see more ( since creating each tag instance will
also create the additional hashtable, StringBuffers, etc ).

I would bet that with complex tags that are specifically written to take 
advantage of the recycling you would see at least 2x better performance ( 
with a good sync-free and large enough tag pool ). If your tag is using 
any buffers or complex/expensive data structures that can be recycled - 
you'll save a lot. 

I don't think the number of tags in a page is too important - even if you
have 1 complex tag - with 100 concurent users - you should see a difference.

In an ideal world, all "core" tags would be recyclable and garbage-free - 
that may allow them to run at comparable speed with a hard-coded page.


Costin




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

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

[Hans Bergsten]

Costin Manolache wrote:

[...]
In an ideal world, all "core" tags would be recyclable and garbage-free - 
that may allow them to run at comparable speed with a hard-coded page.

I think it's more important to implement "open coding" of JSTL, i.e.
generate if and for statement instead of using  and 
tag handlers. That would really make a difference for all apps that
use JSTL, while the potential gains from tag handler reuse depend on
a lot of factors that varies between applications and the runtime
environment.

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: Tag reuse performance [Was: Re: DO NOT REPLY [Bug 16001] - Tag.release() not invoked]

[Costin Manolache]

Hans Bergsten wrote:

> Costin Manolache wrote:
>> [...]
>> In an ideal world, all "core" tags would be recyclable and garbage-free -
>> that may allow them to run at comparable speed with a hard-coded page.
> 
> I think it's more important to implement "open coding" of JSTL, i.e.
> generate if and for statement instead of using  and 
> tag handlers. That would really make a difference for all apps that
> use JSTL, while the potential gains from tag handler reuse depend on
> a lot of factors that varies between applications and the runtime
> environment.

+1 - "open coding" is far better ( for performance ). Is the API/model
for portable open coding defined and stable ? That would be by far the 
biggest improvement in JSP performance.

But for people who use regular tag handlers - I think we need to fix
the tag pool, and a fixed tag pool will improve the performance 
significantly. And if regular tags are used, for whatever reason, 
recycling should be taken into account - if people care a bit
about performance.

Costin


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

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

[Remy Maucherat]

Costin Manolache wrote:

Hans Bergsten wrote:



Costin Manolache wrote:


[...]
In an ideal world, all "core" tags would be recyclable and garbage-free -
that may allow them to run at comparable speed with a hard-coded page.


I think it's more important to implement "open coding" of JSTL, i.e.
generate if and for statement instead of using  and 
tag handlers. That would really make a difference for all apps that
use JSTL, while the potential gains from tag handler reuse depend on
a lot of factors that varies between applications and the runtime
environment.



+1 - "open coding" is far better ( for performance ). Is the API/model
for portable open coding defined and stable ? That would be by far the 
biggest improvement in JSP performance.

Kin-Man told me it wasn't done yet (he mentioned the curent methods 
should stay, though), unfortunately. From what he said, he needed to 
write more tag plugins to see if he was able to implement JSTL tags with 
the current API.
I agree it's definitely a good way to get around the problems with tags 
without adding too much complexity. In the end, I decided to talk about 
it a bit in a chapter of my book.
What's really funny is that you can get rid of the tag handler, and 
write only the tag plugin. That's of course, if you don't care about 
portability, and you have the tag plugin able to handle all forms of you 
tag.

But for people who use regular tag handlers - I think we need to fix
the tag pool, and a fixed tag pool will improve the performance 
significantly. And if regular tags are used, for whatever reason, 
recycling should be taken into account - if people care a bit
about performance.

+1.

Remy


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