Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
I could be wrong given I don't know the full context, but the code from the article on this page: http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html isn't thead safe, multiple requests coming in on different threads at the same time would cause init() to be called multiple times. -Matthew
Re: Some benchmarks
Suggestions for improving the tests are welcome. Ah! I think I have the solution to the poor showing for the Sun SDK 1.3 I ran into this same doing my own tests with Synchronization object creation/GC on Linux, Solaris using Sun + IBM JDKs. Sun decided to ship their SDK with the JIT defaulted to "client" mode rather than "server". If I were to say "server" is provides a dramatic speed boost, I'd be understating the situation. Put a "-server" in the command line for running tomcat when using the sun jdk. This should be on by default IMHO, unfortunately other VM's complain about this. Requiring a bit of fancy work to eval the JDK you're running on. For now, just hand hack it in there and run the Sun tests again! :) I believe you will see the SDK perform at nearly that of IBM when you do. (My own tests show IBM is still a more efficient at object creation that sun, but the margin narrows considerably) -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tools.jar
REanother option is Jikes. Dare I say, better? I think most would agree. -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4.0 w/Apache question
Couple of simple questions to help us get TC 4.0 going like we had for Tomcat 3.1 1. Which Apache connectors can we use to talk to TC 4.0? I know of mod_jserv, mod_jk, and mod_webapp. Which of these work with TC4.0 and which one is best given our requirements. 2. I need to set up the connector to to forward ".jsp"and ".myservletsuffix" to TC4.0 while letting .gifs + .html be served up by Apache. Which connector is best for this? 3. My app context is the ROOT context "/" under 3.1 I need this functionality under TC4.0 as well. Which connector is best for this? Thanks guys! -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session Serialize code
Hi Guys, I worked quite a bit with apache serialization code a several months back on various VM's speeding it up. I think I have several observations that I hope you'll consider before using the code I just saw fly by on the list. Basically, I'm a proponent of using externalizable for the session object. My tests show the objects are smaller and less resources are required to serialize/deserialize the object. Use the strategy in class TestObject_D and you'll serialize objects in less time with less storage. The simple proof of the idea is in the attached file SerialDemo1.java. Here you'll find your basic contendors for the "I'm best way to serialize sessions" contest: TestObject_A is your standard no frills serializable object. What most people do. What 3.1 did. TestObject_B is what happen's when you attempt to speed things up a bit. (Like the code I just saw on mailing list) TestObject_C is shows how String writing can be made better. (HUGE difference with JDK 1.1, less for 1.2/1.3) TestObject_D shows the power of fully managing the serialization process. Test results on a couple of platforms: Results of SerialDemo1.java when run on Pentium II 450mhz w/Linux IBM'S JDK: Test results for test.TestObject_A: Total time required- 4540, size of pickled object:99 Test results for test.TestObject_B: Total time required- 2743, size of pickled object:100 Test results for test.TestObject_C: Total time required- 2699, size of pickled object:101 Test results for test.TestObject_D: Total time required- 1755, size of pickled object:70 Results of SerialDemo1.java when run on 600mhz celery laptop in JBuilder's JDK 1.3: Test results for test.TestObject_A: Total time required- 1763, size of pickled object:99 Test results for test.TestObject_B: Total time required- 1512, size of pickled object:100 Test results for test.TestObject_C: Total time required- 1412, size of pickled object:101 Test results for test.TestObject_D: Total time required- 1012, size of pickled object:70 -- Now, if you're on board with the approach of TestObject_D. Take a look at a class I wrote last summer. It's called SerializationDemo.java. This is a full blown implementation/rewrite of the serialization process for sessions. (Sorry about the name, I didn't have time to change this class.) It provide custom optimizations for all the popular data types that might occur in a session and can be easily extended for custom types. The class is called MattWay() (Again-- sorry about the name, this was for my own tests) and is intended to serve as an example of how to fully manage the serialization/deserialization of all the stuff a session might have in it. Anyway, use this method, and you've got lean mean serialized objects that take up the least amount of space possible and have the lowest overhead to serialize/deserialize. Warm regards, -Matthew PS Test results for SerializationDemo.java on a 450 mhz pentinum using jdk1.3: Test=test.ApacheWay, testTime=34238, testSize=5021 Test=test.MattWay, testTime=12830, testSize=2351 Serialization peformance summary=166.85893% faster Size peformance summary=2670 bytes smaller jdk 1.1: Test=test.ApacheWay, testTime=33992, testSize=5037 Test=test.MattWay, testTime=11785, testSize=2336 Serialization peformance summary=188.43446% faster Size peformance summary=2701 bytes smaller code.zip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Make rant
Hi Roy! If someone can provide a link to something like "Make for Dummies" I'd appreciate it. You betcha, and fyi-- this format is VERY similar to the make file Nick Bauman, myself and others use at our place of employment. (Some might say better!?) At the very least, it's well documented. http://geosoft.no/javamake.html enjoy. -Matthew PSI've been resisting the temptation to get involved on the ant rant thread, but this link might suggest I'm a Make fan. PPS I'm not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
In our situation, we plan to use multiple virtual hosts, each with its own root context. That makes the URLs shorter and easier for people to work with. It also lets you more easily move/copy one context to another without having to fix all the links. We use many virtual hosts today in production, however they all share the same root context. To some this might seem counter-intuitive. It actually does make sense if you're using the MVC pattern and you use virtual hosts to define a cluster of alternate views. Just because the "View" is changing doesn't mean the serlvet (controller) isn't identical. We like to avoid loading lots of VM's. In fact, we have base servlets than are extended by host specific servlets for specific views. It also gives you flexibility in the "route" people take to your servers. Hostname A might have hot spares, while hostname B has a cluster of servers behind it. If anybody is interested in the patches, let me know and I'll post them to the list again. Would your patches work in the above scenario as well? If so, I'd love to have them! Is their any reason their not merged into the core 3.2 code? I'd also like to cast my vote for a production quality release and continued development of tomcat 3.x for production use. Definitely want to chime in and agree on this. We're still running 3.1 in production on 8 web servers. It's slow, it doesn't let us do sessions (aforementioned reasons) but hey-- It's stable. -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
umm...it does. i use it. -Ys- My understanding is it DOES work for app contexts mapped to a URL like "/myapp" but it does NOT work for the root context. "/" Many of us have webapps that mount to the root context. I spent WAY to much time figuring this out, I'd love to be proven wrong. But the mailing list supports what I'm saying if you search for "load balancing" -Matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
reOur site (http://www.spun.com) runs multiple Apache servers with load
balancers ("rotator box like BigIP") that distribute traffic over the Apache
servers. We have a farm of Tomcat servers. The session API's work for us.
The only problem is that Tomcat, as distributed, does not allow load
balancing persistence for the root context. We hacked a way around that
(search the archives if you're interested) - but it's an admitted kludge.
--
Yes, I did see that, and while i admired the hack, it wont work in our
situation. :)
I'd really like to see this very old bug fixed.
If for no other reason, it was stated it would work, and does not.
-Matthew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: No revolution today
Well, but if you don't need the root-context, then the load balancing *should* work with other contexts. You are using mod_jserv with APJ Balancesets, right? Right Jospeh! So how important is it to support load balancing of root contexts? How many users use the root context? From where I sit, it's a requirement, I have no other option. I don't want to go into the reasons as to why this is, (Unless there is a great deal of interest) but I do wonder how many others are doing it like I am? its a big change. fix for 3.3 ? This would seriously nuke loadbalancing for 3.2 if something was screwed up. besides, i'd rather see 3.2 stable out after so many months (years?). I wish I knew if it was a big change or not. When I was trying to do it, it felt like it was more of a mod_jserv issue and had little/nothing to do with tomcat. It seemed like mod_serv config parser just couldn't grok what I was telling it. (Kudos to the designer(s) of the API for mod_jserv, I thought it well thought out and easy to config given the amount of power/flexibility they were giving me.) 3.2 Stable is very important, at a minimum however, documentation should be updated to state it's not supported in 3.2 root context. -matthew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
