Does anyone know who wrote the tag pool implementation for TC3.3? I am
considering port/merging the TC3.3 tag pool code to TC4.0.x jasper. I've
been doing benchmarks with TC4.0.3 with and without coyote. With JSTL
getting close to release, I feel it would be a great benefit, since
pages that
that barely
squeezes under the 64K limit. Under moderate load it runs like a dog.
When I break it up into smaller pages using action include, it runs much
better.
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg24054.html
Cheers,
Larry
Peter lin
--
To unsubscribe, e-mail: mailto
.
peter lin
[EMAIL PROTECTED] wrote:
The most usefull tools are OptimizeIt and ab.
Simple pages would help much better then complex pages - first find
out what's the overhead of executin a simple JSP page, with no tags,
compare it with the equivalent servlet ( HelloWorld ), and find out
what's
I don't mind. I plan on writing a clean site from scratch for doing the
performance evaluation. The test pages I used to perform the previous
tests will only work for tomcat 4.0. Which is why I plan on writing a
new demo site from scratch for my own testing purposes.
My existing test pages are
commands, e-mail: mailto:[EMAIL PROTECTED]
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
a dozen or so tags.
I will do more tests using coyote a later in the week. Once I have that
data, I will post it.
peter lin
Remy Maucherat wrote:
I just ran a quick test using the test pages I used earlier for
benchmarking, and the results are very positive. Thanks to Denis for
patch
at the work on jasper recently and comparing
it to the older tag pooling in 3.3, I lean towards
using the state machine idea. Though it also has a
limit for high concurrency, but those situations
really should go with a non-tag solution to reduce
overhead.
peter lin
Remy Maucherat wrote:
I've been giving this topic considerable thought for
the last month. Now that JSTL is getting close to
official release, performance may become a bigger
issue.
I've been evaluating JSTL and experimenting with using
it for complex rendering logic. From what
hey remy,
is this patch included in 4.1.3? If so I'll test it out with the JSTL
pages I have.
peter
[EMAIL PROTECTED] wrote:
remm02/05/29 17:02:35
Modified:jasper2/src/share/org/apache/jasper Constants.java
Log:
- The suggested amount was actually 512.
- Patch
I'll give it a run through later today when I get home. too many things
to do at work right now. thanks for the info.
peter
Remy Maucherat wrote:
hey remy,
is this patch included in 4.1.3?
No.
Reusing the buffers and tags is the more interesting optimization. However,
it still
due to GC as everyone already knows. Increasing the heap
size to 512 from the default results in increasing 2-3x the concurrent
requests.
peter lin
Kin-Man Chung wrote:
I think it a good idea to limit the stacks to some reasonable value. One
easy way of accomplishing this is to add a tag
I'll test it against my JSTL tag pages and see how it works.
peter
Remy Maucherat wrote:
Hi,
The recent tag reuse changes appear to be great, but seem to have the
disadvantage of breaking existing tags (for example, the Foo tag in the
examples, as well as two of the tags from the admin
I ran a quick test of 4.1.4 with JSTL tags and I am getting an exception
with import tag.
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated
Is there any particular reason the pages are
recompiled frequently? If you're using tomcat 4.1.12
or newer, it should use Ant to compile the pages,
which should get around the issue of memory leak due
to page compilation.
peter
--- Aditya [EMAIL PROTECTED] wrote:
I have the following JSP
I just ran a half dozen benchmarks with bea JRockit jdk1.4.1 for linux. The
performance was better until it locked up bad and required a hard reset. One thing I
noticed is the memory usage was almost double and the CPU usage was also higher. The
numbers were consistently better than both sun
Costin Manolache [EMAIL PROTECTED] wrote:
On the other hand, I've seen pages where JSP tag pooling was worse.
That's why I think per page customization, and supporting per-thread pooling
are very important. This is a fine-tune operation for pages that are
frequently accessed, not a one size
i just did some quick tests with scriptlet and jsp tag pages. Both
result in out of memory error after a couple hundred hits using JMeter
for benchmarking. Has anyone else seen this?
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
,
though it could be a combination of changes to catalina and jasper2.
if I have time later today or tomorrow I will try to use JProbe and
profile the memory usage. I'll post any useful data I find.
peter
--- Remy Maucherat [EMAIL PROTECTED] wrote:
peter lin wrote:
i just did some quick tests
hey remy,
did this CVS commit
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg29253.html,
fix the bug where FileNotFoundException is thrown because the working
directory was deleted for force a refresh?
peter
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
hey remy,
I'll send you more information in a hour with more details. I haven't
been able to find time to run the JProbe thread analyzer tests, but I
can atleast send you the test JSTL pages and JMeter settings I am using
to reproduce it.
If that is cool with you, I'll get the files together
I haven't ruled out JSTL as a cause since my test show it is memory
intensive. I doubt it is JSTL alone, but it could be a combination.
I've produced the bug with jdk1.3.1 on both windows and solaris. I sent
you additional information and the exception I am getting. It's probably
not going to
Here is a bit more information on why I haven't ruled out JSTL or 1.2
JSP tags as a possible cause.
1. the standard examples all run fine and do not exhibit a memory leak,
including the simpletag example.
2. the other person experiencing memory leak is also using JSP tags
extensively.
3. my
hey remy,
I am running JProbe now. finally I have time to run
the test. If I find anything I'll post it.
peter
--- Remy Maucherat [EMAIL PROTECTED] wrote:
Glenn Nielsen wrote:
I have been able to reproduce the memory leak with
the following config:
Apache
after 3 hours of trying to get JProbe to run correctly
I give up. It's 12am and I'm too tired. If anyone
knows how to get tomcat 4.1.5, jasper2 and JProbe
profiler to work correctly I'll try to run the tests.
since jasper2 uses ANT and I don't see how to pass
Java_home from jprobe to the shell
, ValveContext context)
Also, why are you casting HttpSession to HttpRequest?
That should cause an exception since
HttpServletRequest extends ServletRequest and
HttpSession doesn't extend either interface.
peter lin
__
Do You Yahoo!?
Yahoo
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie to
use yourbiz.com.
peter
John Baker wrote:
It appears if you don't set a path
is supposed to be
set. Some one correct me if I am wrong.
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1
John Baker wrote:
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be
Some interesting performance results. I found some time to test my
webapp a bit more with 4.1.7 and discovered a performance difference.
when I benchmark my webapp using 4.1.7 w/ jdk131 on solaris 8 I get an
average response time of 490ms, and a low number of 460ms. when I swith
to jdk141, I
which
contribute to the performance enhancement.
peter
Remy Maucherat wrote:
peter lin wrote:
Some interesting performance results. I found some time to test my
webapp a bit more with 4.1.7 and discovered a performance difference.
when I benchmark my webapp using 4.1.7 w/ jdk131
I was considering extending AccessLogValve to add the responsetime to
the access log, but it looks like the class is declared final. Is there
a reason why this is so? Is there a more appropriate logvalve that is
designed to be extended?
thanks in advance.
peter
--
To unsubscribe, e-mail:
to specific path in server.xml.
thanks in advance.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
to specific path in server.xml.
thanks in advance.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
twice.
If I print out event.getSource() the objects are different. Can someone
verify if this is a bug?
peter lin
peter lin wrote:
Does anyone know how to get the webapp name from ServletContext? Here
is a quick description of what i am trying to do.
I have a webapp that i want to load
can any provide a link to a working draft of the spec if it is
availabe? I'd like to compare the Expression language portion against
the JSTL spec.
peter lin
Mark Roth wrote:
For those of you tracking the JSP 2.0 specification, we are pleased to
announce the availability of an Early
finally found the page for the spec.
http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html
in case anyone else doesn't want to spend 10 minutes looking for the
spec.
peter
peter lin wrote:
can any provide a link to a working draft of the spec if it is
availabe? I'd like
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11043
hey remmy,
I was thinking of debugging the bug I reported earlier this week. Can
you give me any tips as to where to look, so that I can fix it and
submit a patch for it this weekend?
thanks
peter lin
--
To unsubscribe, e-mail
in web.xml and
fires the event twice.
peter lin
peter lin wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11043
hey remmy,
I was thinking of debugging the bug I reported earlier this week. Can
you give me any tips as to where to look, so that I can fix it and
submit a patch
changing the default
root path from ROOT to some other myapp path?
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
in server.xml.
Greetings!
Simon
the bug appears in 4.0.3, 4.0.4 and 4.1.8. Perhaps someone with better
knowledge of how tomcat loads the webapps could chime in. I am willing
to dedicate my own time to patching this.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED
thanks craig for clarifying that. I'll stick with using symlinks, since
a fix would be a big task.
peter lin
Craig R. McClanahan wrote:
What you describe isn't a bug -- it's a direct consequence of the way
auto-mount works in the appBase directory of a Host (i.e. the webapps
directory
I believe remmy is on vacation and is moving to france :)
I guess someone else will have to do it.
peter
Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like
jakarta-tomcat-connectors has been branched yet. I checked the archives
and saw the vote results
of the config related pages and didn't see any
documentation on it.
peter lin
__
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
servers also.
peter
--- Craig R. McClanahan [EMAIL PROTECTED] wrote:
On Fri, 2 Aug 2002, Peter Lin wrote:
Date: Fri, 2 Aug 2002 12:31:28 -0700 (PDT)
From: Peter Lin [EMAIL PROTECTED]
Reply-To: Tomcat Developers List
[EMAIL PROTECTED]
To: Tomcat Developers List
[EMAIL PROTECTED
the documentation, though one would
think having it on the same site would make life
easier for developers.
not everyone has the time to search the net for
information, especially if they have a deadline.
peter
--- Peter Lin [EMAIL PROTECTED] wrote:
I've written a short document on configuring
-man, Luehe or Remy can answer this question.
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
I just figured it out. In JSTL's standard.jar it contains a copy of the
.tld files. Even though I added varStatus as an attribute to the copy
in /WEB-INF/x.tld, it was going by the copy in the jar.
Once I deleted the tld file in the jar, it worked fine. why the change
in 4.1.10?
peter lin
I would also like to see the comments in jasper1 ported over to
jasper2. Now if only I didn't need sleep, I'd do it myself and submit a
patch. the code changed quite a bit between jasper1 and jasper2. the
class responsible is in jasper/compiler/Generator in case you get the
urge to port the
if you're using jdk 1.4, you have to have package names for your
classes. If you do not, it won't load the class correctly.
have you tried giving your classes a package name and trying it again?
peter
Sexton, George wrote:
I posted this several days ago on tomcat-user and haven't gotten
provide any insight?
peter lin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
.
peter lin wrote:
I spent the last two days trying to use JspC to compile an entire webapp
and came across a problem. I'm not sure if this is a bug or not, but I
can reproduce it every time. I'm still trying to track down the cause,
but I thought I'd post a question and maybe some one
.
peter lin
peter lin wrote:
after a lot of digging, I tracked part of the problem down to jakarta
string taglib. once I removed that from my file, it correctly compiles
the jsp page. I'm working on tracking down the exact cause, but it
might be an issue with jsp 1.1 tags. JSTL 1.2 compliant
release() would be an
quick and easy fix. maybe I'm just over simplifying the problem.
peter lin
[EMAIL PROTECTED] wrote:
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.cgi?id=13392.
ANY
/4.7 [en] (WinNT;
U)
Now it gets more complicated. If I use Mozilla, or IE6, this behavior is
not present and the access log only has one entry per page view. Is
this a HTTP1.0 spec, netscape 4.7 or tomcat issue/bug? Thanks in
advance to anyone that provides a clue.
peter lin
--
To unsubscribe
Although I'm just a user, I would like to warnings also. On a related
note, --compile isn't covered in the documentation. I stumbled across
it when I look at the source code a month back. It might be nice to
output the warnings to a file for those who have large webapps with
thousands of jsp
in the buffer
if the
response is not committed without clearing the headers and status code.
does someone know what the correct behavior should be?
peter lin
Costin Manolache wrote:
Remy Maucherat wrote:
Can you point me to the code doing this extra processing ?
I'm a bit confused
buffer to an
arbitrarily large 64K or 100K.
peter lin
Remy Maucherat wrote:
peter lin wrote:
On a related note to flushing. I've discovered a bug, but don't want to
file one until I know for sure it's not a duplicate of the other flush
bugs already in bugzilla.
The bug
thanks again for the information. I will go with setting the buffer
then.
peter
Remy Maucherat wrote:
peter lin wrote:
thanks remy for the information that helps. What if I decide to buffer
the response myself in a response wrapper? Does catalina try to call
clearBuffer, reset
Oracle comes with it's own JDK and sets some environment variables.
if you want both to coexist, hardcode the JDK in your catalina script.
when you uninstall, it reverts the environment settings and fixes your
tomcat problem.
usually, that's the cause.
peter
[EMAIL PROTECTED] wrote:
Hi
I haven't seen the memory leak on solaris or windows, but isn't the leak
only on linux?
I thought jasper2 fixes the problem with com.sun.tools.javac.Main since
it uses the system native javac?
peter
John Trollinger wrote:
Does anyone know if the javac memory leak still exists (1.4.1 docs
Hmm, that sounds bizzare. I'm been using/testing 4.1.10-4.1.12 on both
solaris and windows with jdk1.4.1. I've ran several stress test using
JMeter simulating light to medium (64 concurrent connections) load for
1-10K requests without any problems. My pages are heavy on JSTL, so they
are fairly
text from resourceBundles and parse the
XML.
I'm on win2K also.
peter
John Trollinger wrote:
If the pages are precompiled I do not have any problems at all, it is
only when the jsp cache has been deleted that this shows up.
John
-Original Message-
From: peter lin [mailto
John Trollinger wrote:
We have 2, one is webdav and the other is our actual application. We
use a lot of custom tags and a lot of both types of includes (when I say
a lot we have jsp pages that include over 500 other jsp pages, and no,
this is not my design :) )
I'm guessing there's
you never know. if it's a slow leak, precompiled pages may not exhibit
the leak. I only discovered the leak in our custom tag when I put the
app under moderate/medium load. Under light load the bug wasn't
apparent.
I'm guessing if you hit each page individuall slowly, the bug doesn't
appear. If
that is unusual. I've done baseline performance tests with the standard
examples and haven't seen that kind of behavior with 4.1.10-12. Can you
start tomcat with verbose:gc and see what kind of output you're
getting. Just because the memory allocated to Java is 58megs at the
end, it doesn't
/ directory, the memory
allocated to java is 40megs.
I even ran it with OptimizeIt and I don't see any memory leaks.
peter
peter lin wrote:
that is unusual. I've done baseline performance tests with the standard
examples and haven't seen that kind of behavior with 4.1.10-12. Can you
start
This is from the examples jsp right? or are they from your webapp?
the latest optimizeit has a leak finder feature. you may want to
download the trail version and give it a shot. from the data it looks
like a lot of objects are promoted to old memory from heap. It doesn't
necessarily constitute
actively :)
cross my fingers.
peter lin
Kin-Man Chung [EMAIL PROTECTED] wrote:I am designing a framework in Jasper
for enabling plugins that
work closely with Jasper to generate Java codes instead of calls
to tag handlers. The main idea is to take take JSTL tags, such as
${i}
and generates
in resources.
peter lin
Peter Romianowski [EMAIL PROTECTED] wrote:Just a thought: Doesn't this breack the
standard conformance
tomcat is all about? One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
I think there is no way to assure
, but it should provide significant improvement for pages with lots and lots of
tags.
peter lin
Craig R. McClanahan [EMAIL PROTECTED] wrote:Building the pluggability framework
pretty much has to be done by the
Jasper developers. Implementing plugins for a particular type of
optimization
I sent the suggestion a while back to the expert group.
AFAIK, the and other tags don't actually generate *any* output
of their own -- the extra line breaks you are seeing are undoubtedly those
you've put in the source JSP page itself.
Yes, I was referring to the spaces that are generated
Yeah, I actually use that in some places, but it is a bit harder to read with pages
that have a lot of tags. Actually, the whole page is tags with very little HTML and
everything that is text is in resource bundles.
Using that syntax doesn't really bother in when used sparsely, but with
yeah, I can do that on a simple set this weekend and on a large webapp
next week :)
peter
Remy Maucherat wrote:
Could someone (Peter ?) do some quick benchmarks (with the HTTP/1.1
connector preferably) comparing 4.1.12 to 4.1.16 ? I'd like to see if
my OptimizeIt work is translating into
I wasn't able to run the additional benchmarks like I wanted, since the cpu fan on my
workstation is dying and causing BSOD. I'm in the process of setting up my X1, so I
will re-run the benchmarks on that server and post the results.
peter lin
Remy Maucherat [EMAIL PROTECTED] wrote:I
My 2 cents. I rather a server deny connections and keep on running than accept
connections until it dies :)
peter lin
Remy Maucherat [EMAIL PROTECTED] wrote:Glenn Nielsen wrote:
Is there a reported bug you are trying to address?
Not really. The test here reported a lot of connection
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
.
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
I don't know about others, but my feeling is chunking is useful for large files and
not necessarily where the size of the content is unknown at the beginning of the
response. I seriously doubt a 2-5K static file would see a real benefit. We all know
the internet has a ton of packet collision.
maybe I'm missing something, but http1.0 doesn't
support chunking. isn't it feasible to just make
tomcat respond with http1.0 instead for this
particular problem?
I'm probably being naive here, but you could use the
older connector instead.
peter
--- Remy Maucherat [EMAIL PROTECTED] wrote:
interesting results. By any chance did you compare it
to Perl regexp to see the difference? :)
peter
--- Chad Johnson [EMAIL PROTECTED] wrote:
Some regex benchmark's I ran across:
http://tusker.org/regex/regex_benchmark.html
-Chad Johnson
-Original Message-
From: Henri
as someone else mentioned, these types of seg fault errors have been the result of
database drivers in the past. Specifically, using native drivers.
I am aware of this type of behavior occuring with other drivers like JMS that wrap
native code. Make sure your database driver isn't the cause.
likely not the cause.
that still leaves a lot of variables you have to track down. what are the exact system
specs again?
peter
jean-frederic clere [EMAIL PROTECTED] wrote:
Peter Lin wrote:
as someone else mentioned, these types of seg fault errors have been the
result of database drivers
I would have to concur with Remy on this one. The performance benefit is minimal and
depending on how your JSP is written possibly no benefit at all.
I know for a fact there are sites handling 10million+ pageviews a day using Tomcat.
This is commercial sites and not some development/demo
to put things in better context. Most of my work experience has been building complex
applications with web front ends. In my case, most of the content is dynamic and the
static html is minimal. Therefore, my experience with regard to performance is biased
by the type of applications I work
Remy Maucherat [EMAIL PROTECTED] wrote:
I feel like starting working on the possible new codebase for Tomcat,
now that Tomcat 5 is more or less stabilized. I have a few obvious
items, but while a lot could be done to make the code more modern, it
wouldn't make Tomcat actually run better, so
what does the mail header say?
or maybe some one else already unsubscribed the address :)
peter lin
Remy Maucherat [EMAIL PROTECTED] wrote:
Anyone could find a good explanation as to why unsubscribing the address
didn't work ? (the list manager says [EMAIL PROTECTED] is not subscribed
I see your back from vacation. I hope it was restful. I've started
working on porting CLIPS 6.2 from C to Java. Once that is done, I will
donate it back to CLIPS community (since it's public domain software),
donate it as a project to apache and use it in RuleML development.
JBoss should be able
http://www.webperformanceinc.com/library/ServletReport/
I'd like to thank all the developers for working so hard to improve tomcat.
peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
from where I am sitting, sounds like the project doesn't have enough
information to make a good decision. Why move from MML/TCP to
VXML/HTTP?
if you read my performance article on the resources page, XML is very
CPU and memory intensive. Even with XStream java-xml binding library,
handling
On Thu, 8 Jul 2004 18:59:23 -0700, Darshan Rawal [EMAIL PROTECTED] wrote:
Hello Peter,
I completely agree on this, but this interpretation of VXML pages is
going to happen on the Media Server side. Hence as of now I am just
concerned with generation of VXML pages and transporting them to
on Google, which was not Objective enough.
Thanks again for all you help, it was really valuable...
Regards,
Darshan Rawal.
On Thu, 8 Jul 2004 21:23:52 -0500, Peter Lin [EMAIL PROTECTED] wrote:
On Thu, 8 Jul 2004 18:59:23 -0700, Darshan Rawal [EMAIL PROTECTED] wrote:
Hello Peter
in case, do you know of any objective comparision of JAVA C/C++ ?
I could not find one on Google, which was not Objective enough.
Thanks again for all you help, it was really valuable...
Regards,
Darshan Rawal.
On Thu, 8 Jul 2004 21:23:52 -0500, Peter Lin [EMAIL PROTECTED] wrote
although I'm not a commiter, I like to add 2 cents to the discussion.
I like the idea of supporting JMX and the capbility of deploying a
webapp without restarting the server. From the discussions so far, the
task isn't simple, and may not fit the majority of users.
if 80% of the users don't have
the nightly build of jmeter has an alpha sampler that uses Commons
HTTPClient. you may want to try that one instead, if you use jmeter
peter
On Thu, 22 Jul 2004 15:09:19 +0200, Henri Gomez [EMAIL PROTECTED] wrote:
Remy Maucherat wrote:
Henri Gomez wrote:
I made some benchs on my Linux
you can run it in non-Gui mode with -n option.
http://jakarta.apache.org/jmeter/usermanual/get-started.html#non_gui
might help, or not.
peter
On Thu, 22 Jul 2004 15:33:41 +0200, Henri Gomez [EMAIL PROTECTED] wrote:
Peter Lin wrote:
the nightly build of jmeter has an alpha sampler
hey remy,
have you tried XStream? the API is super simple and it's quite fast.
Not sure if it would work, but we recently changed JMeter to use
XStream instead.
peter
-Original Message-
From: [EMAIL PROTECTED]
Sent: 7/29/2004 6:56:40 AM
To: [EMAIL PROTECTED]
Subject: [5.next]
On Thu, 29 Jul 2004 16:55:39 +0200, Remy Maucherat [EMAIL PROTECTED] wrote:
I think it's a start. You identified the downsides well enough, but
unfortunately, they're a showstopper for me. Additional tweaks are
needed. I see that others suggested other technologies, but we'd have
many issues
the only way is to reorganize your jsp. this is an old issue dating
back quite a bit. are you using tomcat4 or 5?
if you're using tc4, I would recommend upgrading to tc4.1.x or 5.x.
the original jasper generated code which would easily exceed the
limit. the newer jasper2 which is used with
what I meant was what Tim said.
peter
On Thu, 19 Aug 2004 12:59:59 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
Thanks, Tim,
The file actually is quite simple. It is a simple form with HTML radio
buttons for choosing colors. There are a LOT of colors, but the code is
pretty
great strides and remy has
worked his butt off. I won't bother pointing out flaws in other servlet containers,
since it leads to flame wars. you can google for that information yourself.
peter lin
Remy Maucherat [EMAIL PROTECTED] wrote:
Jess Holle wrote:
Any and all performance improvements would
1 - 100 of 149 matches
Mail list logo
