Re: Tomcat Concurrency and Hit Rate Issue
from a pracitcal perspective, chances are at any given time there will only be 1 person submitting the completed form. 400 seems like a very low number to me. Now if you're talking about a survey that is sent out to 10K people with a window of 5 hours to submit it, it probably won't be a problem. Most people ignore surveys to begin with. Unless you know the users absolutely will fill it out, I wouldn't really worry about it. sql server 2K is ok as long as you don't have more than 50+ concurrent queries. The reason for that is the sql server worker thread to CPU ratio is: 2 worker thread: 1 cpu also, the kind of query has a tremendous impact on performance. if you really have to support a large number of concurrent insert/updates, you're going to have to dig around the various sql server community sites and use COM+/DAL. Your bottleneck won't be the webserver. whether you use IIS, resin or tomcat, the database will the bottleneck. peter lin Thomas McDonald [EMAIL PROTECTED] wrote: I'm not sure if this is the right list to post this quesiton too, but here goes: I am doing a web survey on Tomcat 5.0.19 hooked to a SQL Server 2000 backend I am trying to figure out what sort of hit rate it can take. I'll send an email to 400 people inviting them to take the survey. They all won't show up at once (and I don't necessarily have to invite them all at the same time--I can spread it out over 3/4 hours), but I don't know if Tomcat can take the load of say, 50 people using the site at once. Any suggestions on how I can figure this out? __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
Re: Tomcat Concurrency and Hit Rate Issue
I would try sql server forums first to see what kind of load your server can handle. You can load test some sample queries using JMeter. this will tell you the upper limit for your particular server. [EMAIL PROTECTED] - if you have questions. If you're using a single CPU server, you should be able to handle 10 active sessions without any problems. assuming you've taken care to write stored procedures and you're not doing funky joins. Reads won't be any problem for you, it's really the writes. peter lin Thomas McDonald [EMAIL PROTECTED] wrote: Thanks. Actually all the people will take it. It is an internal survey and they are being told by their managers that they must take it. That said, I would expect about 12-25 people hiting the site at any one time (If I send out all 400 invitations at one time). Also, it isn't a one shot survey submission. It is a 3-4 question at a time kind of survey and about 200-300 questions total. So there will be lots of reads/writes. Some of the initial queries are complex (lots of joins, etc.) so I am a little worried about SQL performance. Anyway, I'll take this to the the list mentioned by J.Petersen: [EMAIL PROTECTED], but if anyone has anymore useful comments I would welcome them. --- Peter Lin wrote: from a pracitcal perspective, chances are at any given time there will only be 1 person submitting the completed form. 400 seems like a very low number to me. Now if you're talking about a survey that is sent out to 10K people with a window of 5 hours to submit it, it probably won't be a problem. Most people ignore surveys to begin with. Unless you know the users absolutely will fill it out, I wouldn't really worry about it. sql server 2K is ok as long as you don't have more than 50+ concurrent queries. The reason for that is the sql server worker thread to CPU ratio is: 2 worker thread: 1 cpu also, the kind of query has a tremendous impact on performance. if you really have to support a large number of concurrent insert/updates, you're going to have to dig around the various sql server community sites and use COM+/DAL. Your bottleneck won't be the webserver. whether you use IIS, resin or tomcat, the database will the bottleneck. peter lin Thomas McDonald wrote: I'm not sure if this is the right list to post this quesiton too, but here goes: I am doing a web survey on Tomcat 5.0.19 hooked to a SQL Server 2000 backend I am trying to figure out what sort of hit rate it can take. I'll send an email to 400 people inviting them to take the survey. They all won't show up at once (and I don't necessarily have to invite them all at the same time--I can spread it out over 3/4 hours), but I don't know if Tomcat can take the load of say, 50 people using the site at once. Any suggestions on how I can figure this out? __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Search - Find what youre looking for faster.
Re: Seeing poor JSTL performance
if you do a search on taglibs-user for 2002, you'll lots of benchmarks I ran using
JSTL. The long and short of it is this.
1. JSP tags use quite a bit more memory than scriptlet (i.e. pure java embedded in
jsp). Many people consider scriptlet evil.
2. if you're using more than 150 tags per page, you should consider turning on tag
pooling if you're using tomcat. If you're not using tomcat, see if your webserver
supports tag pooling.
3. are your beans efficient. things like doing search may be cpu/time intensive.
4. what is the expected concurrent load?
tomcat5 just went stable and it supports page level tag pooling. If you can, run
OptimizeIt on your pages to see exactly why it's not performing well. JSTL may not be
the cause, but you won't know until you get real data.
peter
Jim Kennedy [EMAIL PROTECTED] wrote:
I've been reading some developers comments that the JSTL does not perform very well.
I'm am experiencing poor performance that I attribute to the use of the JSTL. Here is
something typical I do:
--
[input] name=
Description: [input] ${search[?des_key?]}? size=20 class=textbox
Model Number: [input] ${search[?mn_key?]}? size=20 class=textbox
Serial Number: [input] ${search[?sn_key?]}? size=20 class=textbox
PO Number: [input] ${search[?po_key?]}? size=30 class=textbox
Location: Select a location test=${location.id==search['asset_locationcode']}
SELECTED
[input]
[input]
---
Is there something I'm doing in the code that I could avoid to enhance the
performance. This is only a code fragment. Assume that variables are defined in
advance.
-
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
Re: Non Java Developers, programmers using JSTL and taglibs
From past experience there are alot of people who like the cold fusion style of page authoring. If you've ever looked at cold fusion tags and page syntax, JSTL is very similar. Even though tag like syntax has been around for a while, many people are still unconfortable with them. There's several reasons for this from personal experience. Page authors who use WYSIWYG editors and don't understand the difference between p and div abhore looking at tags. You don't want these people working on pages anyway. On the otherhand, experience HTML coders who write html by hand find it a nice environment that allows them to do some simple markup logic w/o learning java. I had to train junior developer in the past that primarily used WYSIWYG editors. Once they got used to hand coding html, using tag was preferable to writing java. Power comes a cost of learning, so if people find their page authors are unwilling to put forth the effort, then there's not much you can do. I won't mention companies, but there are other BIG players that are moving towards tag syntax in their product line for webservices. peter --- Glenn Nielsen [EMAIL PROTECTED] wrote: Pierre Delisle wrote: Also, I'd be very interested in hearing about the type of environment you work in for the development of dynamic web applications. That should help us understand as a community the usage profiles and their bias :-) Thanks, -- Pierre All of the discussion so far on this topic has made the assumption that those using this technology are part of a development team. A team that may include graphic designers, web designers, programmers, dba's, and architects where design concepts like MVC can be implemented. This assumption holds up for the most part for businesses which use this technology for web enabling the enterprise. For our own inhouse development we follow this model also, although our team is very small (3-4 people), and most of the team can fulfill multiple roles. My organization provides email and web site hosting for non profit organizations and schools. The types of organizations which can't afford to hire a development team or hire expensive consultants to design complex applications. But these customers often have a need to add some sort of simple dynamic content to their web sites. Generally those who maintain these web sites are not programmers. A better term to describe them would be page authors. Technologies such as JSP pages with custom tags, especially the Standard Taglib, can lower the technology barrier to a point where some adventurous page authors can invest the time to learn enough about these technologies to create simple applications which adds dynamic content to their web site. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non Java Developers, programmers using JSTL and taglibs
Here is an example off the top of my head. It will be grossly over generalized, but it is still useful. Asssuming you have three individuals with specialized duties: 1. page designer - ie the graphics guy who makes things look great 2. html coder - knows every nook and cranny of browsers, what renders, what breaks and how to get around it. doesn't care to know Java or other OOP languages 3. developer In past jobs, good designers will know some HTML. The best page designers know HTML pretty well. Pure graphic designer tend to do a terrible job and their designs don't translate well. The likelihood of finding an awesome designer that doesn't know a lick of html, but can create great webpages is unlikely. The html coders I've worked with like tag syntax and are fine with javascript, so jstl is fine for them. Some of the best HTML coders are decent graphic designers. Unfortunately not all companies can afford to have these specialized individuals, so if you're in that situation, buy the person a book and spend a couple hours a week during lunch to cross train. JSTL and tags in general are designed to solve a human problem, but it's half the picture. You still have to work hard to make development work smoothly. Shawn Bayern's book JSTL in action is a good book, so new designers should consider getting the book. When ever I have to work with people who don't know HTML or javascripting, I create a blank template with just the title and a marker for where logic goes. Like !-- list results here, don't touch-- and walk through it with the designer. That allows the page designer to work around that, which allows you to keep working and plugin your piece later on. Some markup logic can be encapsulated in a very specific tag, which a page designer can use without worrying about correct usage. if all else fails, dreamweaver does provide support for jsp tags http://www.macromedia.com/software/dreamweaver/productinfo/features/mx/07jsp_development.html peter --- Vinay [EMAIL PROTECTED] wrote: This is a very interesting discussion , at this point I would like to join this discussion and express my concerns and opinions. I am basically a Java programmer, using struts for our software development. Even though I am right now doing both design work using JSTL-EL and development I can't really make the web pages beautiful. I don't use any IDE or any tools though for any of the stuff. So we may have a designer soon and the concern is that most designers I think will not have knowledge of JSTL .I don't know how difficult it is to make the designer knowledgeable about JSTL tags ,Java Objects or Java beans and even if we may allow the designer to do the web page design using some tool like dreamweaver , still there be lot of burden upon the programmer to embed the JSTL-EL tags into the JSP pages. It also requires the developer to use a tool such as Dreamweaver to edit the web designer's code,which may cause some discrepancies in the design(this might not be true,just my guess). But I still think that JSTL-EL is the way to go as it really helps define a view logic (user interface)without any scriplets. Vinay __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Whitespace generated by JSTL tags
there were discussions a while back on this topic. I submitted a suggestion to the expert group for JSP requarding this issue for JSP compile filters. Using compression is one fix, but it doesn't really address the heart of the problem. If you look at the generated source file, you will see tons of out.write for all those blank lines. It's a bit wasteful to have all blank lines, so there should be a clear specification on how JSP page compiler should remove extra spaces if application desires. I had several discussions with the developers of Jasper2. The current spec states the whitespace and blank lines have to be preserved. I'm hoping the JSP spec after 2.0 will address this issue and make it a configurable. peter Wolfgang Röckelein wrote: Hi, Hans Bergsten wrote: Anyway, the best way to handle it is probably to use a filter that compresses the response (most browsers supports compressed responses today) since that would reduce the space needed for both whitespace and repeated tags. See this article for an example of the implementation of such a filter: http://www.javaworld.com/javaworld/jw-06-2001/jw-0622-filters.html Has anybody used this filer with a recent tomcat Version? I mostly get 0 length files from this filter (Tomcat 4.1.12) ... Thank you for any hints, Wolfgang -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
I will dig deeper and post my findings.
thanks
peter
Shawn Bayern wrote:
On Thu, 17 Oct 2002, peter lin wrote:
we did verify acookie exists. I should have been more clear in my
original email.
That's not really the issue; the question is what's causing the error
logs that you're suggesting are indicative of a bug. Since the Standard
Taglib simply results 'acookie.value' into a call to getValue() of your
Cookie, it seems unlikely that the problem lies with the Standard Taglib,
unless I'm misunderstanding your report.
shouldn't JSTL throw an exception, since acookie is wrapped, so
using c:out value=${acookie.value.name}/ is the correct syntax.
Using c:out value=${acookie.name}/ should throw an exception,
rather than go into an infinite loop and generate megs of error logs?
No, the tag should simply result in a call to
acookie.getName().toString(). That's why I'm suggesting you throw
correspondent code in a scriptlet and see if it fails in the same way.
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
I wrote a basic test page and this is the result I get.
output
print out the classname
java.util.HashMap$Entry
java.util.HashMap$Entry
java.util.HashMap$Entry
print out the cookie
id1=value_for_id1
JSESSIONID=1B6A8CE1F51A31E335719420A239BEB2
id2=value_for_id2
The source is below:
-
% taglib prefix=c uri=http://java.sun.com/jstl/core; %
print out the classnamep
c:forEach var=acookie items=${cookie}
%
Object ck = pageContext.getAttribute(acookie);
out.println(ck.getClass().getName());
%br
/c:forEach
p
print out the cookiep
c:forEach var=acookie items=${cookie}
c:out value=${acookie.value.name}/=c:out
value=${acookie.value.value}/br
/c:forEach
-
It looks like using c:out value=${acookie.name}/ won't retrieve the
value, since acookie is a hashentry, it can't do
acookie.getName().toString(). I'm guessing that is correct
functionality right?
peter
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
It causes tomcat 4.1.12 to generate logs continuously. If I don't hit
stop in the browser, it will continue to generate logs. After a couple
of minutes, the log is tens of megs.
I don't know if it's the responsibility of the EL to throw an exception
or if jasper should be responsible. with is why the subject says maybe
:)
if you think it's a jasper bug, I will consult tomcat-dev and
investigate further. thanks.
peter
Shawn Bayern wrote:
On Thu, 17 Oct 2002, peter lin wrote:
It looks like using c:out value=${acookie.name}/ won't retrieve
the value, since acookie is a hashentry, it can't do
acookie.getName().toString(). I'm guessing that is correct
functionality right?
Right, for ${cookie} is a Map of all cookie names to Cookie instances.
So, in the context of the test page, where does the bug come up?
--
Shawn Bayern
JSTL in Action http://www.jstlbook.com
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
without EL it works fine. I've tried with scriplet code and it works fine. I've tried it with the correct syntax and it works fine. it's only when the syntax is incorrect that it doesn't throw an exception like symbol cannot be resolved, clascastexception or some other exception. Right or wrong, I expect the EL to realize duh, that's the wrong syntax silly pete. I'm throwing an exception. when I have time, I'll try to verify jstl 1.0.2 with 4.0.6 and see if has the same effect. If it doesn't cause continuous logging, it's probably a bug in tomcat. The funny thing is the page compiles just fine. peter Shawn Bayern wrote: On Fri, 18 Oct 2002, peter lin wrote: It causes tomcat 4.1.12 to generate logs continuously. If I don't hit stop in the browser, it will continue to generate logs. After a couple of minutes, the log is tens of megs. I don't know if it's the responsibility of the EL to throw an exception or if jasper should be responsible. with is why the subject says maybe :) if you think it's a jasper bug, I will consult tomcat-dev and investigate further. thanks. Again, I'm not sure of the specific action that you're saying causes this looping. Is there something in the EL that you're saying causes a loop? Is it the iteration over 'cookie'? Can you replicate it without using the EL? Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: might have found a bug in jslt 1.0.2
I'm glad your just as confused as I am, since I honestly don't know either :) I was hoping you'd have the magic answer, but looks like I'll have to dig around this weekend to figure what the exact cause is. thanks for responding to my obtuse questions, since I'm confused as to why this behavior happens at all. I'll post what ever I find, hopefully detailed information about how to reproduce or track it down. peter Shawn Bayern wrote: On Fri, 18 Oct 2002, peter lin wrote: it's only when the syntax is incorrect that it doesn't throw an exception like symbol cannot be resolved, clascastexception or some other exception. Right or wrong, I expect the EL to realize duh, that's the wrong syntax silly pete. I'm throwing an exception. Which EL expression causes this? If the syntax of an expression isn't parseable, the EL should throw an exception. If the property is simply unknown, the behavior can depend on whether we're dealing with a Map or JavaBean; it's all defined by the spec. Since our JSTL implementation doesn't directly produce logs, I'm just trying to figure out *exactly* what you're doing that does produce logs, and then trace it back to the code that ultimately causes them to be created. Ideally, you'd have a minimal pair of two *identical* fragments, one of which uses the EL and produces the erroneous logs, and one of which doesn't. Sorry if I'm being obtuse; I'm just not understanding the problem reports, or I'm missing some information. Shawn -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:taglibs-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:taglibs-user-help;jakarta.apache.org
Re: What sucks about c:import!
I'm assuming you want to get at things like cookies, user-agent and other http header data. you may want to make a request to the expert group, so that it is included in the next version of JSTL. I believe the current importsupport class just uses standard url httpurlconnection classes. shawn will know more about the current implementation and where it might go in the future. peter Mark R. Diggory wrote: Now that I have your attention. We are continually working with managing headers in our URL object requests to get resources from different locations. Is there really any way I can set the request Header info on the URL object being created by c:import? Right now I have my own custom implementations to aquire such resources. I'd rather be able to use the Standard Taglib. -Mark Diggory Harvard-MIT Data Center -- 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: What sucks about c:import!
in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. peter lin Henri Yandell wrote: Isn't this the kind of thing that Jakarta Commons HttpClient specialises in? In which case a taglib for that would be a pretty nice affair... [I assume there's not one already..] Hen On Wed, 21 Aug 2002, Shawn Bayern wrote: Indeed - JSTL 1.0 does not support advanced HTTP operations from within JSP pages using c:import (e.g., basic authentication, free modification of headers), but a future version of JSTL could if there were enough perceived need. As Peter says, it's a good idea to inform the expert group if you'd like to see this feature; the address is [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: What sucks about c:import!
I'm not sure where it should reside to be honest. I can see argument for both sides. If I wanted to access data that resides on an IIS machine that has challenge/response turned on, it would be good to have cookie/auth support in jstl c:import but one could easily argue it should be in a bean to provide more advanced capabilities like caching or other RPC protocols. For an enterprise solution with high loads, it might make more sense to create a custom solution, but I've seen situations where data comes from third parties. Trying to get data providers to build a custom RPC mechanism often is more trouble than it's worth, so a simple c:import mechanism that supports cookies authentication would be a simpler solution. I'm glad the decision isn't up to me because either way you go, some one is going to complain. peter Shawn Bayern wrote: On Wed, 21 Aug 2002, peter lin wrote: in the interest of discussion. I find it useful to have cookie, user-agent and other advanced capabilities in a web services context. As web services becomes more common place, supporting those features might become very important. But is it important to support this from within JSP pages, instead of Java-based components? -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- 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: JSTL in Action: first few chapters
Now if only I learned to proof read or type :P I skimmed through expression language portion of the book and found it easier to read than the official spec. peter David M. Karr wrote: Dave == Dave Newton writes: Dave Peter Lin wrote: reading the spec isn't always as simple as one would like. For example, the use of hashmap was totally clear to me, until I read the section in shawn's book. Dave Er... :D Dave Dave Yeah, yeah, we know what he meant :) . -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: For additional commands, e-mail: - Do You Yahoo!? Yahoo! Health - Feel better, live better
Re: JSTL in Action: first few chapters
Someone at work bought an electronic version and ordered a few copies. If you are serious about using JSTL, I would recommend it. reading the spec isn't always as simple as one would like. For example, the use of hashmap was totally clear to me, until I read the section in shawn's book. I must have read the spec a dozen times, but for some reason I just did get it. Once i saw shawn's example it was totally clear. peter --- Shawn Bayern [EMAIL PROTECTED] wrote: In case anyone's interested, I just found out that the first four chapters of JSTL in Action have been posted for free at http://www.codercoop.com These early chapters are ideal for novice page authors; if you're a developer, you might want to forward them to page authors you work with. The chapters cover the principles of web development, the JSTL expression language, and the JSTL conditional tags. -- Shawn Bayern JSTL in Action http://www.jstlbook.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: No more than 88 i18n:message tags in one page?
Vernon Wu wrote: 7/26/2002 5:48:15 AM, peter lin [EMAIL PROTECTED] wrote: search the list for past discussions about this. a short summary is this. if you're using a jsp compiler that makes one huge service method, it will rapidly exceed 64K per method limitation in java. As well, there's a bug in jdk1.4 with deeply nested try/catch statements, which would only be a problem if you coded scriptlets that way. try jasper2 which is in the latest 4.1.8 beta. it should improve performance, if you're using tomcat. If you're using some other server, you should talk to the company and get them to fix it. If the cause is in jdk1.4, why replace components in TC? the reason is jasper2 doesn't use com.sun.tools.javac.Main to compile jsp pages. Instead it uses ANT and native javac to compile. There's been a lot of discussion on this in jstl and tomcat-user forum. These are known problems and are already being addressed. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ! Unbearable memory consumption
You have a couple different options that will scale much better if the data in the resource files are static and do not change dynamically. 1. use the cache tag, which uses fmt tag 2. write a custom tag which caches it as someone else mentioned 3. write a custom tag that extends the fmt tag 4. patch fmt tag to cache it and submit the patch to shawn 5. you can write a custom extension to the resource bundle that does the caching. that will allow you to use fmt tag as is and have your resource extension do the caching I hope that helps peter Vernon Wu wrote: I use the jstl-fmt port of jstl in my current project. I have three resource files: default, en, and zh. About 440 entries in each file. When I open a page with about 250 items in the resource file, the memory consumption increases dramatically. To save the memory usage, I delete one of the three resource files. The initial memory usage is about 20m. During the translation process, the memory consumption glows to over 160m and exceeds the machine limit. And the session dies and server crashes. Any solution for this problem? The web container I use is TC 4.0.4. Thanks, Vernon -- 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: ! Unbearable memory consumption
Vernon Wu wrote: Peter, Thanks for your suggestion. Can you clarify the statement: the data in the resource files are static? In regarding of the five options you mentioned: 1. use the cache tag, which uses fmt tag 2. write a custom tag which caches it as someone else mentioned The caching mechanism only works when at least portion of data has be retrieved early. In my case, only a small among data, if there is any, has be retrieved before the page from the resource file. So these two approaches might not solve the problem hmm, if I am reading you correctly, from request to request, the cached data from the resouce files may be limited. Caching wouldn't really help, unless it doesn't expire any loaded data. If that is the case, you might be better off loading all the stuff statically when tomcat starts up and register file events on the resouce files to get dynamic updates. 3. write a custom tag that extends the fmt tag What is the goal of this extension? Is it to refine the fmt tag implemention so that it will not eat up the much memory? Or to have the caching mechanism on? You have several different ways of doing this right. If the default properties/resourcebundle class is too slow, you could write a custom bean that takes advantage of nbio to improve the performance. 4. patch fmt tag to cache it and submit the patch to shawn I would like to do that once I am free from current project. 5. you can write a custom extension to the resource bundle that does the caching. that will allow you to use fmt tag as is and have your resource extension do the caching For a set of large size resource files, this approache also comsumes a lot of memory and it will hold the memory during the life time of the application. Please point out if I am in any above statements. BTW, the reason of more than 200 items in the resource files is man sets of check boxes and pull down lists in the page. Is any way I can cut short the items in resource file? Another option is you can break your resource files into smaller chunks based on most-to-least used. The nvpair used 80% of the time can be cached and loaded at startup. you could then write a custom tag that first looks at the cache before getting it from the appropriate resource file. I hope that helps. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat crashes on too many custom tags in a jsp
Jasper2 does split tag calls to methods. Kinman, denis and remmy are the ones who worked on it. The way it works is if the tag body does not contain any scriptlet, it will make it into a method. Of course the catch is if your page uses scriplets in the body ie c:set...% some java code %/c:set, it won't break it out into it's own method. jasper2 is significantly different in many ways and implements tag pooling. You can read through all the posts on tomcat-dev if you care to know all the details. peter Martin Cooper wrote: Does Jasper2 actually split the JSP generated code into multiple methods, rather than one large service() method? If so, do you have any information on how it can do this? I'm curious, because I don't see how this could be done without a huge amount of work (unless there's an I swear there are no scriptlets in my pages mode :). Thanks. -- Martin Cooper -Original Message- From: peter lin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 09, 2002 4:16 AM To: Tag Libraries Users List Subject: Re: Tomcat crashes on too many custom tags in a jsp If tomcat is crashing because of out of memory it is a known problem with tomcat 4.0.1-4.0.3 as well as 3.3.x. The problem you are seeing is related to how jasper compiles the page. Jasper makes one huge service method, which causes several memory related problems. There is a new jasper called Jasper2 in 4.1.7 beta. Copy ant.jar, jasper-runtime.jar and jasper-compiler.jar into your tomcat/lib directory. See if that fixes your problems. If that isn't your problem, it may be your custom tag has a memory leak somewhere which only appears in certain conditions. if that's the case, use OptimizeIt to profile your web app. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4 .1.7-beta/RELEASE-NOTES peter Karthikeyan A wrote: Hi, I am working with tomcat 4.0.1 We have our own custom tag library. We display all the data using custom tags. We have noticed that when the number of custom tags for a jsp page is too large, our tomcat crashes. Our JSP has more than 125 bean:message key.../ tag apart from other custom tags. If we comment out some of the custom tags, tomcat does not crash. We hunted for the solution in mailing lists. We found a suggestion. As per suggestion, we should split the JSP into multiple JSPs and include the pieces by using jsp:include directive. We have split the JSPs but the problem persists. Can anybody suggest a work around? Thanks and Regards Karthik -- 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] -- 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]
stripping extra line feeds in choose tag
hey shawn, I was looking into different ways of stripping extra \r\n from the final output. I thought of a way, which is definitely non-compliant, but as an exercise I thought I'd post it. I don't actually plan on implementing it, but it might generate discussion about how JSTL 2.0 spec might handle this. From my understanding, c:choose x:choose both do not push out.write() to bodyContent. c:set on the other does set out = bodycontent when needed. Example from Jasper2 generated source below: javax.servlet.jsp.tagext.BodyContent _bc = pageContext.pushBody(); _bc.clear(); out = _bc; Therefore if one were to modify c:when and x:when to strip out extra line feeds, the output would have to pushBody in order to call .trim() within the tag. There are several issues I can see with this method of handling unwanted whitespace control line feed. 1. doesn't solve the real problem 2. it really should be addressed in JSP specification, not JSTL specification 3. it's better to not have dozens of extra out.write(\r\n); litering the compiled jsp class. 4. There should be a way to easily plug in filters for JSP page compilation. In the same way the latest servlet spec defines request filters, page compilation should have filters. 5. leaving the extra out.write() makes pages with lots of tag (100+) less scalable as seen with jasper1 on tomcat 4.0.3 and 3.3.x. 6. even though jasper2 now breaks tags without scriplet code into it's own method, pages that use both tag and scriplets will run into the 64K per method limitation in java. Even though some servlet containers uses jasper, and likely jasper2 once it is released, leaving in unwanted whitespace and control line feed make tag pages less portable across different servlet containers. There's no gaurantee a server will compile pages the way jasper2 does it. Of course there is always the option of writing a deployment tool that parses the JSP to a temp directory stripping out unwanted stuff and compile it to the server's working directory. peter __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to split results over multiple pages with DBtags ?
The proper way to do this is to only return n number of rows. Typically this is done with scrollable cursors. The driver you're using has to support the feature. I don't see support for it in dbtags, so your other option is to use stored procedures or prepared statements that handle the cursor yourself. fetching tons of rows to only display 20 will limit the scalability of your web application under load. Especially if your database server isn't beefy :) hope that helps. peter lin Soefara Redzuan wrote: If you have hundreds of records in your ResultSet, too many to show on one JSP, how do you split these over multiple pages. I mean, list a subset of these on one page, so that the user can go forward to the next results and back to the previous listings, or even jump to the n'th listing, like you see on many websites including search engine results ? I think it is unefficient to store a counter so you loop through the ResultSet but I can not find any batch-like attributes in the DBtags documentation. Am I missing it ? A simple example would be very useful. Thank you so much, Soefara. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com -- 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: JSTL: sql
this might not be the answer you're looking for, but in high end
databases, the recommended method of doing incremental unique ID is to
use a stored procedure which gets the next id and uses it in an insert
statement. The stored procedure then passes the unique id back.
autoincrement is typically used in low and medium level databases.
Managing ID in RDBMS is a large part of what DBA's handle. The reason
high end databases do this is because the data model is typically
complex where a simple transaction requires updates and inserts in
multiple tables.
Your other option is to get the last ID and increment it in a bean or
jsp. Of course this means changing the property of the ID column in
your table.
peter lin
Carole E. Mah wrote:
Does anyone know if the JSTL database tags (sql) provide any method for
retrieving the unique ID of the row that was inserted last (when you set
up you mySQL database table to AUTO_INCREMENT the unique id).
This is how I do it using PHP, which provides the mysql_insert_id()
function for just this purpose:
$query = INSERT INTO foo (name, phone) VALUES ('Jane Doe','555-1212');
$LINK = mysql_pconnect ($DB_SERVER, $DB_LOGIN, $DB_PASSWORD);
$result = mysql_db_query ($DB, $query);
$my_id = mysql_insert_id($LINK);
Thanks!
-carole
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carole E. Mah [EMAIL PROTECTED]
Senior Programmer/Analyst
Brown University Scholarly Technology Group
phn 401-863-2669
fax 401-863-9313
http://www.stg.brown.edu/
personal: http://www.stg.brown.edu/~carolem/
--
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: JSTL x:parse problems
I think you're problem is that xmlText expects String. Have you tried
xmlURL, isntead of xmlText. here is the way I use parse, which works
fine.
c:set var=xmlurlsample.xml/c:set
x:parse var=dom
c:import url=${xmlurl}/
/x:parse
peter lin
Steve Appling wrote:
I am having problems using the standard tag library x:parse tag using a
reader. The JSTL spec says that the xmlText attribute can take either a
String or a Reader. I am trying the following:
%
InputStream is = application.getResourceAsStream(/test.xml);
InputStreamReader reader = new InputStreamReader(is);
%
x:parse xmlText=${reader} var=doc/
This results in the following exception:
javax.servlet.ServletException: The xmlText attribute illegally
evaluated to null or in parse
Does anyone know how to do this?
If anyone from the expert group is monitoring this, it would be really nice
if there were usage examples for each of the tags. Also in the 1.0 Public
Draft ALL of the examples provided for x:parse are wrong, they use an older
syntax with a source attribute which is not allowed now.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL x:parse problems
The code that handles it does perform type checking, so it should work.
the code below is taken from the parsesupport.
if (xmlUrl != null)
d = parseURLWithFilter(xmlUrl, filter);
else {
if (xmlText instanceof String)
d = parseStringWithFilter((String) xmlText, filter);
else if (xmlText instanceof Reader)
d = parseReaderWithFilter((Reader) xmlText, filter);
else
throw new JspTagException(
Resources.getMessage(PARSE_INVALID_SOURCE));
}
can you post and example of the XML, it could be the XML isn't valid.
peter
Steve Appling wrote:
In section 11.2 of the JSTL 1.0 public draft specification it says that
xmlText can take a String or a Reader. I can't use xmlUrl (or body content
of the parse tag) because my xml is in a section of the web application that
is in a restricted security domain. I can't provide authentication
information in the url to use xmlUrl. I probably can read the entire
document into a single String myself, then use that in xmlText, but that
seems somewhat silly. If it really can take a Reader as the documentation
states, then I would rather use that approach - I was hoping there was
something simple I was missing that was keeping this from working.
- Original Message -
From: peter lin [EMAIL PROTECTED]
To: Tag Libraries Users List [EMAIL PROTECTED]
Sent: Thursday, April 18, 2002 8:42 AM
Subject: Re: JSTL x:parse problems
I think you're problem is that xmlText expects String. Have you tried
xmlURL, isntead of xmlText. here is the way I use parse, which works
fine.
c:set var=xmlurlsample.xml/c:set
x:parse var=dom
c:import url=${xmlurl}/
/x:parse
peter lin
Steve Appling wrote:
I am having problems using the standard tag library x:parse tag using a
reader. The JSTL spec says that the xmlText attribute can take either a
String or a Reader. I am trying the following:
%
InputStream is = application.getResourceAsStream(/test.xml);
InputStreamReader reader = new InputStreamReader(is);
%
x:parse xmlText=${reader} var=doc/
This results in the following exception:
javax.servlet.ServletException: The xmlText attribute illegally
evaluated to null or in parse
Does anyone know how to do this?
If anyone from the expert group is monitoring this, it would be really
nice
if there were usage examples for each of the tags. Also in the 1.0
Public
Draft ALL of the examples provided for x:parse are wrong, they use an
older
syntax with a source attribute which is not allowed now.
--
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSP tag limit on solaris with jdk1.4
I recently discovered that JSP Tags on Solaris 8 with jdk1.4 has a tag limit of 50. In case others encounter this bug, it's specific to 1.4 and isn't present with jdk1.3.1 or jdk1.4 for windows. peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: code too large for try statement
You're reaching the 64K compiled class file limit. You're choices are to break the page up into different files, or restructure so the compiled class files are smaller than 64K peter Andrea Grittini wrote: Have you ever heard about this problem?? I'm using JSTL standard tag library together with HP_AS to build a dinamic web site from a DB. I have developed my page with about 300 lines of html tags and jsp tag from 5 tag libraries.(JSTL + string + request + datetime) When I compile my file from the browser I got this incledible error: JspPage_actCercaBnProd_jsp_Impl.java:16223: code too large for try statement catch( Throwable thr ) ^ How can I do?? The page has to format a simple recordset. thank you in advance. Andrea Grittini -- 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: testing on empty string or null with jstl
according to the specs, I believe EL will evaulate null value to zero
length string.
if you treat zero length string and null as the same condition, does
that work for your situation?
I'm a little confused by the example you provide. the first when checks
to make sure name and email are not null or zero length. the otherwise
is supposed to send an email. but who is it suppose to send it to? the
friend's email address?
if you use request.getParameter(string), you're going to get null
pointer error if no value was given. shouldn't the page display an error
message, since it doesn't have the email address to send a message. is
the friend's email a gauranteed value that is always present?
a bit more information would make it easier to diagnose.
peter
Wim Bervoets wrote:
Hello,
I have the following code:
c:choose
c:when test=(${param.yourName} != '') and (${param.yourEmail} != '') and
(${param.friendsEmail1} != '')
email something
/c:when
c:otherwise
[c:out value=${param.yourName}/]
[c:out value=${param.yourEmail}/]
[c:out value=${param.friendsEmail1}/]
[%=request.getParameter(yourName)%]
[%=request.getParameter(yourEmail)%]
[%=request.getParameter(friendsEmail1)%]
/c:otherwise
/c:choose
If the request paramaters are not empty I would like to send a mail - eg.
execute the when.
- otherwise execute the otherwise.
Problem I have is that c:otherwise is always executed - even when the
parameters are set (I can see they are set because of the c:out's)
So how can I check for an empty string or null ? ${param.yourName} != null
or ${param.yourName} != '' doesn't work !
I'm using resin 2.0.5 - maybe it has something todo with the forEach
problem that was fixed recently in resin 2.1.0 ?
Thanks
Wim
--
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]
plans for include
Does anyone know if there are plans to improve jsp:include or create a
new include in jstl? The reason I ask is because jsp:include
page={url | %=expr%} / will only take simple strings. it would be
nice if one could dynamically build the appropriate include
path/filename and pass it to the include.
this way, it would reduce the need to use
c:choosec:when./c:otherwise/c:choose to determine what files
to include. It would also decrease the maintenance, as a person could
just add the html for their personal template and pass the value in the
request parameters.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: plans for include
thanks for reminding. I totally forgot about that. peter Shawn Bayern wrote: On Mon, 1 Apr 2002, peter lin wrote: Does anyone know if there are plans to improve jsp:include or create a new include in jstl? Yes, JSTL introduces c:import, which (as I think I say in my book) you can think of as jsp:include: the next generation. :-) -- Shawn Bayern Author, JSP Standard Tag Library http://www.jstlbook.com (coming this summer from Manning Publications) -- 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]
performance benchmarks of JSTL on Tomcat 4.0.3
I got side tracked for a few days, but I finally got time to run some benchmarks with JProbe, as well as repeat a few of my original tests to verify the performance. The tests were ran on the following systems. System I - 450mhz PIII, Win2K, 512mb RAM programs running - mcafee, aim Server - tomcat 4.0.3 additional connector - coyote beta 3 System II - 600mhz PIII, win2k, 256mb RAM programs running - none Server - tomcat 4.0.3 additional connector - coyote beta 3 load testing application Latest JMeter from jakarta Network - LAN JProbe 30 - added settings for Tomcat 4.0.3 test run - 2 threads 100 iterations The results below is the total number of Tag objects garbage collected for the entire duration of the test. Garbage collection was trigger right before and immediately after the run. The GC filter was set to taglibs*. The system used was #2 with 600mhz cpu and no other apps running besides JProbe and Tomcat. JProbe GC results - include directive - IfTag - 11,200 WhenTag - 4,200 ExprTag - 2,800 SetTag - 1,400 OtherwiseTag - 1,200 ChooseTag - 1,200 Logger - 16,600 Total - 38,600 General memory/GC behavior - GC spiked much more frequently than pages using action include. The duration between GC was approximately half that of action include. action include IfTag - 11,00 WhenTag - 2,800 ExprTag - 2,600 Logger - 16,600 Total - 33,000 General memory/GC behavior - GC frequency was less and the interval between GC was twice as long as pages using include directive. It generally took 2-4x more page hits to reach the heap max. scriptlet page no tags were garbage collected, since none were used. for the duration of the test, GC was trigger twice. In comparison, include directive for the duration of the test was called on average 30 times. action include called GC approximately 15 times. The results below were average from 3 runs of each setting. The machine running JMeter was a separate system. Only the HTML was retrieved. No images or other files were included in the calculation of the response times. Test performed on system #2 (600mhz, 256ram) were not heap optimized, since it is pointless with 256mb of ram. All times are in milliseconds. include directive - 1 thread 1000 -- httpconnector ave - 32 cpu usage - 45-80% coyote connector ave - 107 cpu-usage - 30-100% include directive - 2 threads 500 -- httpconnector ave - 403 cpu usage - 50-100% coyote connector ave - 378 cpu usage - 40-100% include directive - 4 threads 250 -- httpconnector ave - 974 cpu usage - 70-100% coyote connector - 474 cpu usage - 50-100% include directive - 8 threads 125 -- httpconnector ave - 2802 cpu usage - 100% coyote connector ave - 1660 cpu usage - 60-100% include directive - 16 threads 65 -- httpconnector ave - could not finish cpu usage - 100% coyote connector ave - 2994 cpu usage - 80-100% action include - 1 thread 1000 --- httpconnector ave - 48 cpu usage - 40-70% coyote connector ave - 49 cpu usage - 40-60% action include - 2 threads 500 --- httpconnector ave - 84 cpu usage - 55-95% coyote connector ave - 86 cpu usage - 40-80% action include - 4 threads 250 --- httpconnector ave - 190 cpu usage - 70-90% coyote connector ave - 175 cpu usage - 50-90% action include - 8 threads 125 --- httpconnector ave - 508 cpu usage - 70-100% coyote connector ave - 372 cpu usage - 60-95% action include - 16 threads 65 --- httpconnector ave - 1056 cpu usage - 90-100% coyote connector ave - 808 cpu usage - 70-100% action include - 32 threads 63 --- httpconnector ave - 2646 cpu usage - 100% coyote connector ave - 1036 cpu usage - 80-100% scriptlet page - 1 thread 1000 --- httpconnector ave - 22 cpu usage - 0-20% coyote connector ave - 21 cpu usage - 0-16% scriptlet page - 2 threads 500 --- httpconnector ave - 30 cpu usage - 20-40% coyote connector ave - 28 cpu usage - 0-25% scriptlet page - 4 threads 250 --- httpconnector ave - 49 cpu usage - 20-40% coyote connector ave - 47 cpu usage - 20-35% scriptlet page - 8 threads 125 --- httpconnector ave - 97 cpu usage - 20-40% coyote connector ave - 97 cpu usage - 20-40% scriptlet page - 16 threads 65 --- httpconnector ave - 179 cpu usage - 20-45% coyote connector ave - 171 cpu usage - 20-40% scriptlet page - 32 threads 63 --- httpconnector ave - 250 cpu usage - 30-60% coyote connector ave - 257 cpu usage -
Re: JSTL EL parser pool?
Here are some thoughts Shawn Bayern wrote: On Fri, 22 Mar 2002, peter lin wrote: Interesting thought, Peter. Given that instantiating an Evaluator object involves no specific logic on construction, the only cost of not having a pool is that of object creation itself, which should be exceptionally well optimized under any JIT. As a general rule, I strongly hesitate to pool objects unless there's a demonstrated reason it'll help. (Most products pool objects WAY too much, which leads to unnecessary complexity and -- indeed -- potential performance problems.) The performance you're experiencing doesn't sound too good, but do you have any reason to think that the logic within ExpressionEvaluatorManager (in particular) is to blame? actually I don't think ExpressionEvaluationManger by itself is the blame. I think it's the combination of a lot of little things that add up to a problem. I have no conclusive proof, but right now my guess is my test pages are using lots of local variables. Since the test system only has 256ram on win2K, at 4 concurrent requests it might be reaching the limit for local variables causing GC to start. The reason I suspect this is the dramatic CPU usage. The performance degrades as CPU usage increases from what I see. For minimal load, I seriously doubt there will be any benefit. In fact there's probably going to be decreased performance for 1-2 concurrent connections. The evaluator keeps a static cache of values, so literally the only benefit of pooling our interpreter instances would be to save the instantiation itself, which should take about ten low-level instructions on a modern JIT. (That is, the evaluator has an empty constructor, and all its work is done on the stack -- with the aid of a few static caches.) Thanks very much for the suggestion, though; I'd be curious if you have any data that does implicate one part of the JSTL RI over another. I doubt instantiation is the cause. The first candidate for improvemnet with the test pages I've written is recycling tag objects. For example the test page is broken up into 20-24 pages. When I count the number of times a new Tag is created I get: when - 22 otherwise - 7 if - 55 expr - 23 choose - 7 -- Total 114 Since the evalutor caches the values, I was thinking after all the other steps were done, it might be a candidate for pooling, though not by default. It wouldn't make sense to have the default expression manager to be pooled. Very few installation need to support 8-13million hits a day. In my mind, extreme performance requirements might benefit in stability and reduced GC from pooling the parsers. Another interesting fact is the source generated by jasper is 4320 lines long when using JSTL with include directive %@ include ..% :). If you look at the numbers I posted on tomcat-user, you'll see that using JSTL with action include performs better than JSTL with include directive. Once I get numbers with JProbe, I will post them for further discussion :) again thanks for taking time to read and respond. peter lin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Grouped Output
If you use c:set var= to set a variable to the name and then have it
check against it before printing out the name should work. ie,
c:set var=thenamefirst time it's zero length/c:set
c:if test=${oldname != newname}
c:set var=thenamethe name value/c:set
c:out value=${thename}/
/c:if
peter
Zvolensky, Thomas J {PDBI~Nutley} wrote:
I need to generate a report that looks something like this:
NameDates Visited
--- -
Anderau, Eoma 2002-03-07
Andersson, Lisa 2002-02-04
2002-02-25
2002-02-26
2002-03-08
2002-03-13
2002-03-14
2002-01-31
2002-03-15
Aylott, Bridget 2002-01-31
2002-02-18
Is it possible to generate a grouped report using taglibs without
resorting to using scriptlet logic to determine when the column Name has
changed in the record set?
TIA.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JSTL EL support for header?
I read through the JSTL spec and grepped org.apachelang.jstl to see if it has any calls to request.getHeader(string) and noticed JSTL EL does not support request header. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSTL EL support for header?
The closest thing I can think of to access request header values is
c:out value=${request.headers[host]}/, but [] are used to access
maps. Request.getHeaders() returns an Emueration, so it fails like it's
supposed to.
Thanks to shawn's fix yesterday to JSTL XML tags, i can use x:out
select=$header:user-agent/ to do browser detection. It would be nice
if JSTL EL also supports headers like parameters.
c:out value=${header.user-agent}/
when I use the example above, I get 0 as the output. Is that a bug
maybe or not supported as specified. I'm using nightly 3-18.
thanks.
peter
peter lin wrote:
I read through the JSTL spec and grepped org.apachelang.jstl to
see if it has any calls to request.getHeader(string) and noticed JSTL EL
does not support request header.
--
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]
xml bug?
has anyone tried the nightly 3-18 xml tags in jstl? I'm experiencing a
problem accessing request parameters and http headers. Here is the test
page I used.
%@ taglib prefix=x uri=http://java.sun.com/jstl/ea/xml; %
br$header:host = x:out select=$header:host/br
brS param = x:out select=$param:S/br
%
java.util.Enumeration enum = request.getHeaderNames();
while ( enum.hasMoreElements() ) {
out.println(enum.nextElement());
out.println(br);
}
out.println(request.getHeader(user-agent));
%
According to the JSTL spec, it states in 11.1.2:
expression | mapping
--
$param:foo | request.getParameter(foo)
$header:foo| request.getHeader(foo)
I took a quick look at tag.common.xml package and noticed all of the
support tags use XPathUtil to access the context. Within XPathUtil is a
inner class JstlVariableContext, which contains the call
hsr.getHeader(localName) in JstlVariableContext.getVariableValue().
when I tried to debug getVariableValue method, it appears it never gets
to hsr.getHeader(localname). In fact, valueOf(node,string) never
instantiates JstlVariableContext, instead getLocalContext(node) is the
only method that instantiates that class.
Should valueOf(node,string) check the result of
xp.valueOf(getLocalContext(n)) and call getLocalContext? I'm don't
completely understand XPathUtil. Any tips are greatly appreciated.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: xml bug?
reading over my last paragraph, it's not clear what I meant, so here's a
second attempt. The current 3-19 nightly of XPathUtil.valueOf is below:
public String valueOf(Node n, String xpath) throws SAXPathException
{
staticInit();
XPath xp = new XPath(xpath);
return xp.valueOf(getLocalContext(n));
}
when it calls return, it the result of getLocalContext(node) to
XPath.valueOf(). when I output that result, I get zero length string.
the source for getLocalContext(node) is below.
private Context getLocalContext(Node n) {
// set up instance-specific contexts
VariableContext vc = new JstlVariableContext();
ContextSupport cs = new ContextSupport(nc, fc, vc, dn);
Context c = new Context(cs);
List l = new ArrayList(1);
l.add(n);
c.setNodeSet(l);
return c;
}
an instance of JstlVariableContext is passed to the constructor of
ContextSupport, but I don't see where
JstlVariableContext.getVariableValue() is called. Within
getLocalContext, should it check to make sure context was created
correctly when it does Context c = new Context(cs)?
when I output the result of the hsr.getHeader(localName), it never
reaches that chunk of code in getVariableValue().
else if (namespace.equals(HEADER_NS_URL)) {
HttpServletRequest hsr =
(HttpServletRequest) pageContext.getRequest();
return hsr.getHeader(localName);
thanks.
peter lin
peter lin
Should valueOf(node,string) check the result of
xp.valueOf(getLocalContext(n)) and call getLocalContext? I'm don't
completely understand XPathUtil. Any tips are greatly appreciated.
peter lin
--
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]
