Custom tags are cached in most containers (tag pooling). If the parameters to a tag are the same the same instance of a tag object is used. It is up to the container when to discard / garbage collect the tag instances.
I don't know if this is the problem / issue here but hope it helps. Edgar > -----Original Message----- > From: Richard Mixon (qwest) [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 20, 2003 11:35 PM > To: Struts Users Mailing List > Subject: [OT] STL startup times - is caching going on? > > > This is a little off-topic, but I am using the Struts EL > taglibs in the applications this is happening. Any > suggestions, ideas are appreciated. (I also posted on the > Jakarta taglibs list). > > I am having an issue with large startup times the first time > one of my pages runs that uses JSTL mostly the core library. > Subsequent requests (even for different users on different > data) take much, much less time. > > Here is a little more detail. Any ideas are much appreciated. > My ISP is pretty irate because we suck up huge amounts of CPU > each time it happens. > > We are using Tomcat 4.1.24, Java 1.4.1 and Struts 1.1. > > OK, the page uses a couple of nested foreach loops to > generate a grid/chart of SVG markup language. It also uses a > couple of small foreach loops to generate tick marks on an > axis. It looks something like: > > Chart page > <embed> tag > include JSP/JSTL page to generate footer. > include JSP/JSTL page to generate x and y axis > JSTL markup to generate main body of chart > include JSP/JSTL page to generate footer. > > The request takes a half second to build the Java objects > that the JSTL code uses to render on the page. But the > rendering takes 45 second on a 650MHZ Sun SPARC III machine > and almost that long on a fast Windows machine (2500 MHZ). > > The second and subsequent times the chart rendering drops > down to less than 200 milliseconds. Then about five minutes > later, if the chart is requested again, it takes the 45 > seconds to generate, then 200 milliseconds for subsequent requests. > > Thanks in advance - Richard > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
