You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2003/01/21 01:08:20 UTC
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 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Making PureTLS work
Posted by Eric Rescorla <ek...@rtfm.com>.
Remy Maucherat <re...@apache.org> writes:
> Eric Rescorla wrote:
> >>If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
> >>its usefulness.
> > It shouldn't be incompatible. What's going on here is a provider
> > conflict.
>
> > You need to ensure that Cryptix is ahead of whatever IBM provider you
> > ahve installed.
>
> That is possible, I didn't think of setting Cryptix as endorsed. I did
> try it with PureTLS, though.
PureTLS needs Cryptix.
> I had similar problem with JSSE and the IBM VM.
Java crypto support could be a lot better.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Making PureTLS work
Posted by Remy Maucherat <re...@apache.org>.
Eric Rescorla wrote:
> Remy Maucherat <re...@apache.org> writes:
>
>
>>Hi,
>>
>>I was wondering if people among the happy few who got PureTLS (0.9b3)
>>running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.
>>
>>
>>I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).
>>
>>I read on the PureTLS website (err, sorry webpage) that it supported
>>OpenSSL certs. So I should be able to reuse the certs I generated for
>>mod_ssl ?
>
> Yes.
>
>
>>If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
>>its usefulness.
>
> It shouldn't be incompatible. What's going on here is a provider conflict.
> You need to ensure that Cryptix is ahead of whatever IBM provider you
> ahve installed.
That is possible, I didn't think of setting Cryptix as endorsed. I did
try it with PureTLS, though.
I had similar problem with JSSE and the IBM VM.
>>As for the error with Sun VM, I don't know what to do
>>(there doesn't seem to be any docs at all anywhere) ...
>
> Hmmm.... The Sun error looks to me like a standard password
> conflict. Are you sure you have the right password?
Mm, I'll check. Since I couldn't find what type of certificate it
needed, I decided to try first with the ones included with the PureTLS
distribution.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Making PureTLS work
Posted by Eric Rescorla <ek...@rtfm.com>.
Remy Maucherat <re...@apache.org> writes:
> Hi,
>
> I was wondering if people among the happy few who got PureTLS (0.9b3)
> running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.
>
>
> I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).
>
> I read on the PureTLS website (err, sorry webpage) that it supported
> OpenSSL certs. So I should be able to reuse the certs I generated for
> mod_ssl ?
Yes.
> If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
> its usefulness.
It shouldn't be incompatible. What's going on here is a provider conflict.
You need to ensure that Cryptix is ahead of whatever IBM provider you
ahve installed.
> As for the error with Sun VM, I don't know what to do
> (there doesn't seem to be any docs at all anywhere) ...
Hmmm.... The Sun error looks to me like a standard password
conflict. Are you sure you have the right password?
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Making PureTLS work
Posted by Remy Maucherat <re...@apache.org>.
Hi,
I was wondering if people among the happy few who got PureTLS (0.9b3)
running with Tomcat 4.1 or 5.0 post some kind of small HOWTO.
I'm running Linux (RH 7.3, with IBM 1.4.0 or Sun 1.4.1).
I read on the PureTLS website (err, sorry webpage) that it supported
OpenSSL certs. So I should be able to reuse the certs I generated for
mod_ssl ?
Anyway, that's for later. In order to avoid making mistakes, I reused
the .pem files I found in the distribution.
After tweaking my server.xml to point at the right files (of course, I
had to read the sources to know how to do it), I got the following
exceptions:
- with IBM JDK:
Caused by: java.lang.InternalError:
java.security.NoSuchAlgorithmException: class configured for Cipher:
com.ibm.crypto.
provider.DESedeCipher is not a subclass of xjava.security.Cipher
at COM.claymoresystems.crypto.PEMData.readPEMObject(Unknown Source)
at
COM.claymoresystems.crypto.EAYEncryptedPrivateKey.createPrivateKey(Unknown
Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown
Source)
at COM.claymoresystems.ptls.SSLContext.loadEAYKeyFile(Unknown
Source)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:165)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)
- with Sun JDK:
java.io.IOException: PKCS#5: Invalid number of padding bytes
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.init(PureTLSSocketFactory.java:175)
at
org.apache.tomcat.util.net.puretls.PureTLSSocketFactory.createSocket(PureTLSSocketFactory.java:104)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.initEndpoint(PoolTcpEndpoint.java:275)
at
org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:150)
If PureTLS isn't compatible with IBM JVM, then fine, but I can't see its
usefulness. As for the error with Sun VM, I don't know what to do (there
doesn't seem to be any docs at all anywhere) ...
Any ideas ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tag Pooling ( was: Re: DO NOT REPLY [Bug 16001] - Tag.release()
not invoked
Posted by Glenn Nielsen <gl...@mail.more.net>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>