Re: Confusing - Compression 5.0.16 - Filter or connector???
Also, be aware of some bugs in IE with some formats: PDF - http://www.15seconds.com/issue/020314.htm I read somewhere that css and javascript files have issues too. In this case, the filter option is better since you can specify which extension to compress. Aymeric. [EMAIL PROTECTED] 12/09/03 10:59AM You will be compressing images?! :( Remember that most image formats - gif, jpeg, png, etc, are already compressed. In most cases compressing them again will only gain you 2-3% improvement if anything at all. So you will be spending time compressing for nothing. Notice that the compressableMimeType attribute that you copied below does not include image/jpeg. That is because whoever configured this example file rightly excluded compression of objects that would not benefit at all. If you are expecting compression to make up for a web site that is graphic heavy, you will be sorely disappointed. If, however, you have a website with significant amounts of text (i.e., large database result sets) then you will probably benefit. -Erik Ron Andersen wrote: I am only using one platform and I need the best performance, since I will be compressing images. Therefore, if I use the connector compression, shall I turn the filter compression off(in web.xml). Also, does the connector(in server.xml) support the following attributes?? compression=on compressionMinSize=2048 noCompressionUserAgents=gozilla, traviata compressableMimeType=text/html,text/xml Remy Maucherat [EMAIL PROTECTED] wrote: Shapira, Yoav wrote: Howdy, Yup, it would be attempted twice (if the request matches both the filter and the connector, which is the default setup). Personally I prefer the filter, as it's more portable and not tomcat-specific. I prefer the connector, since it's faster and more powerful (you get the regexp based exception list Henri added, etc) :) If we (ever) get a gz impl that isn't an output stream and could work on straight byte arrays, we'd also be able to do the compression without facade objects at all, which would have the best performance. -- http://www.spectacle.ca/ The Online Source for Live Music in Montreal .::514.286.1699::.
RE: Best JVM for Tomcat
We are running Tomcat under Solaris 8 and tried to use the '-server' option.The option improved greatly the performances, but unfortunately load testing showed that the JVM would crash systematically under heavy load. No problem running with the '-client' option. Aymeric. [EMAIL PROTECTED] 12/03/03 03:08PM Can you tell us more about issues using -server mode? --- Shapira, Yoav [EMAIL PROTECTED] wrote: Howdy, I use Sun's latest on various platforms (Solaris 8, 9, SuSe, Intel) without a problem for both tomcat 4 and 5. The only caveat is the -server mode, which used to reduce stability. I knew there would be a jRockit response from Senor Cekvenich even before expanding this thread ;) Yoav Shapira Millennium ChemInformatics -Original Message- From: David Rees [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 03, 2003 7:09 AM To: Tomcat Users List Subject: Re: Best JVM for Tomcat On Wed, Dec 03, 2003 at 08:43:34AM -0300, Walter do Valle wrote: What is the best version of J2SDK to run Tomcat 4.1.29 over Linux? On Linux, I've been using the latest from Sun, 1.4.2_02 without any issues. There may be others which are faster, but performance hasn't been an issue for me. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Regarding Tomcat Start
Your server failed to start. You can see errors by opening a DOS prompt and run 'catalina.bat run' from the tomcat bin directory. This should start the server in the same window instead of opening a new window that will closed itself if startup fails. Aymeric. [EMAIL PROTECTED] 09/27/03 11:53AM I have installed jakarta-tomcat-5.0.12. I set jdk and catalina path. I open a command prompt, move to the bin directory of tomcat. I run startup.bat. It opens another prompt that vanishes in seconds. I dont see anything wrong (warning or error message) at original command prompt. I move to localhost in browser. Nothing loads up on browser ! How do i know whether tomcat has really started or not ? (I tried to look at services running, it does not show up there) I tried to see log floder, but it is just empty. I tried to run shutdown bat file. It says, connection not found ! Does it help in answering my question? I am using Windows XP Operating System. Regards ~Vishal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sharing session between webapps
Hi, I have two web applications running on the same Tomcat server. One is used for administration (webapp1) of the other one (webapp2). I would like my administration application to be able to set some session values in 'webapp2' and then redirect to 'webapp2'. The goal is to bypass the login page by directly setting-up the userid. Is there any way to share sessions information between app? Any other suggestion? Thanks, Aymeric.
Re: invalid reference to form login page error
You cannot access you logon page directly, try to access a page protected by you security constraints instead. This is an issue with the servlet 2.3 specs. Let's say you secured the domain /mysecuresite in your web.xml and you created a logon.jsp page for Tomcat form-based authentication. If you access /mysecuresite/mysecurepage.jsp, tomcat will redirect you to logon.jsp. If logon is successful, you get redirected back to the mysecurepage.jsp page. If you access logon.jsp directly, tomcat doesn't know where to send you on successful logon. Unfortunately, there is no notion of default page in the specs. Aymeric. [EMAIL PROTECTED] 06/22/03 04:46PM Hello, I'm using container-managed security features in TC 4.1, and I'm receiving error: invalid reference to form login page when trying to login user. I use form-based authentication and have a page with appropriate configured form (j_username,j_password, etc). Where is the problem? Thanks, Jan Peknik. Stydím se ho vytáhnout! A jaký je vá* dùvod vymìnit svùj telefon za nový? Nokia 6610 ji* od 6977 Kè. http://www.atlas.cz/clickAD.asp?ad=32086 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 4.1.17 Problems - Possibly Coyote Connector?
I had that problem with 4.1.16 and I opened a bug in bugzilla. But I couldn't come up with a test case and the bug got closed. Maybe you can add your experience to the bug report and reopen it: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15251 Aymeric. [EMAIL PROTECTED] 12/18/02 02:14PM The actual web application did not seem to have a problem on the front side. Everything went on as normal on 4.1.12 Pages failed to be served correctly on 4.1.17 ( they are blank ) though logging on with a new session will serve the first couple pages then start blanking. This looks like exactly what is happening to me. 4.1.12 works, 4.1.17 gives me the problem. One thing to note is that my application does not use JSP so must be a catalina or coyote issue. Are you using the stock Coyote/HTTP 1.1 connector or are you using one of the JK connectors? I am using whatever 4.1.x is set to use by default. Which I am pretty sure is the Coyote/HTTP 1.1 connectors. The problem is still there for both 4.1.12 and 4.1.17, it's just not very visible up front on x.12 And monitoring the logs for that context tells me my pages start returning blank at the exact same time that exception happens. I have not seen any sort of socket exception, but possibly my logging is not configured to see that. Perhaps try to add a log file dump for that specific context as I did in my little context blurb. Then check that file out after your pages start returning blank pages. Then perhaps it will be a little more filtered from the rest of the context serving... Luc -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: TC 4.1 and VM crash: how to report issue?
Actually, I thought I had LWP set for this run. But I can't see any reference to /usr/lib/lwp in the VM crash report , so I might have goofed my Tomcat set-up. I will try again. Thanks. Aymeric [EMAIL PROTECTED] 12/11/02 07:18AM Hi, Hmm. I've seen more VM crash logs than I care to count, but I've never seen one where it didn't have the internal function name. Interesting. That in itself may give Sun some information. Have you tried the same tests with the alternate thread library (LWP) if it's available for your version of Solaris?? Yoav Shapira Millennium ChemInformatics -Original Message- From: Aymeric Alibert [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 7:37 PM To: [EMAIL PROTECTED] Subject: RE: TC 4.1 and VM crash: how to report issue? Thanks for the feedback. When I ran my load tests I used -Xmx512m -Xms512m as heap settings. I also tried increasing or decreasing it but it didn't change the results. I am running on Solaris and I have all the recommended patches for JDK1.4.1 installed. I can reproduce the problem: it is always crashing during the test, but it can be after 2 minutes or 20 minutes depending on the run. My problem is that I cannot create a simple test case that will crash the server because of the complexity of our environment ( it includes multiples Oracle databases and LDAP connectivity). I tried to isolate the problem to a single jsp like you recommend it but that didn't work. (I could fine several combinations that would trigger the crash). So I am not sure what I could provide as a test case except our full dev environment. I can deploy the same application on TC4.0.4 and it runs fine. I tried many versions of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing. I attached the VM log. Thanks, Aymeric [EMAIL PROTECTED] 12/10/02 04:48PM Howdy, If your OS requires patches in order to run the JDK (whatever version you're trying to run), make sure those patches are installed. I had this exact issue happen on Solaris, and installing the proper Solaris patches made it go away. You say The same behavior can be reproduced with both JDK1.4.0 and JDK1.4.1 and yet I cannot create a test case to reproduce my problem. Which one is it? ;) If you can reproduce it, the full details of how to reproduce it can be posted to Sun's bug parade, and they'll track down whatever tools they need in order to mimic your environment. If you can't reproduce it, there's no bug as far as they're concerned. Finally, I'm not sure I understand this bullet: - I works fine with TC4.1 So your app works fine on TC 4.1? I thought that was the whole problem? Or did you mean it works fine with TC 4.0 and not 4.1? If it's the latter, as I suspect, perhaps you could start by deploying a very small subset of your app and repeating the test. Then increase the deployed subset and retest. The idea is that a certain feature of tomcat as used by your app is crashing the VM, and to find out which section of your app is causing this. The more you can narrow it down, the better. Yoav Shapira Millennium ChemInformatics -- 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: TC 4.1 and VM crash: how to report issue?
0x7c00 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libverify.so 0x7be0 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libjava.so 0x7bb0 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libzip.so 0x13a0 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.ISO8859-1.so.2 0x10a0 /SunQA/youraccount/j2sdk1.4.1_01/jre/lib/sparcv9/libnet.so Local Time = Tue Oct 31 11:58:52 2000 Elapsed Time = 317 # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002E6 01 # Please report this error at # http://java.sun.com/cgi-bin/bugreport.cgi # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.1_01-b01 mixed mode) # # An error report file has been saved as hs_err_pid1694.log. # Please refer to the file for further information. # [EMAIL PROTECTED] 12/10/02 06:53PM Have you try running your test and verbosing as much as possible information inside the log file (increase the debug level in server.xml)? Try it to see if Tomcat 4.1.x output something useful to trace the problem. Post your result (ot the last couple of lines). Maybe it will help. -- Jeanfrancois Aymeric Alibert wrote: Thanks for the feedback. When I ran my load tests I used -Xmx512m -Xms512m as heap settings. I also tried increasing or decreasing it but it didn't change the results. I am running on Solaris and I have all the recommended patches for JDK1.4.1 installed. I can reproduce the problem: it is always crashing during the test, but it can be after 2 minutes or 20 minutes depending on the run. My problem is that I cannot create a simple test case that will crash the server because of the complexity of our environment ( it includes multiples Oracle databases and LDAP connectivity). I tried to isolate the problem to a single jsp like you recommend it but that didn't work. (I could fine several combinations that would trigger the crash). So I am not sure what I could provide as a test case except our full dev environment. I can deploy the same application on TC4.0.4 and it runs fine. I tried many versions of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing. I attached the VM log. Thanks, Aymeric [EMAIL PROTECTED] 12/10/02 04:48PM Howdy, If your OS requires patches in order to run the JDK (whatever version you're trying to run), make sure those patches are installed. I had this exact issue happen on Solaris, and installing the proper Solaris patches made it go away. You say The same behavior can be reproduced with both JDK1.4.0 and JDK1.4.1 and yet I cannot create a test case to reproduce my problem. Which one is it? ;) If you can reproduce it, the full details of how to reproduce it can be posted to Sun's bug parade, and they'll track down whatever tools they need in order to mimic your environment. If you can't reproduce it, there's no bug as far as they're concerned. Finally, I'm not sure I understand this bullet: - I works fine with TC4.1 So your app works fine on TC 4.1? I thought that was the whole problem? Or did you mean it works fine with TC 4.0 and not 4.1? If it's the latter, as I suspect, perhaps you could start by deploying a very small subset of your app and repeating the test. Then increase the deployed subset and retest. The idea is that a certain feature of tomcat as used by your app is crashing the VM, and to find out which section of your app is causing this. The more you can narrow it down, the better. Yoav Shapira Millennium ChemInformatics -- 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]
TC 4.1 and VM crash: how to report issue?
We are running a Tomcat 4.0 server in our production environment and I am trying to upgrade to Tomcat 4.1. I ran some load test recently and was horrified to see the server crashing even under moderate load. After more testing, I found that starting the VM with the -server option systematically crash the VM after few minutes of load test. The server works fine even under heavy load with the -client option. The same behavior can be reproduced with both JDK1.4.0 and JDK1.4.1. My TC4.0 server runs fine with the -server option. Now, this is obviously a JVM problem but probably won't have any help from SUN since: - I cannot create a test case to reproduce my problem. - I works fine with TC4.1 Can someone help me with this issue or at least guide me to the right contact? I found several tickets opened on the SUN bug database with similar issues but none of them had a resolution or people assigned to work on them. Thanks! Aymeric
RE: TC 4.1 and VM crash: how to report issue?
Thanks for the feedback. When I ran my load tests I used -Xmx512m -Xms512m as heap settings. I also tried increasing or decreasing it but it didn't change the results. I am running on Solaris and I have all the recommended patches for JDK1.4.1 installed. I can reproduce the problem: it is always crashing during the test, but it can be after 2 minutes or 20 minutes depending on the run. My problem is that I cannot create a simple test case that will crash the server because of the complexity of our environment ( it includes multiples Oracle databases and LDAP connectivity). I tried to isolate the problem to a single jsp like you recommend itbut that didn't work. (I could fine several combinations that would trigger the crash). So I am not sure what I could provide as a test case except our full dev environment. I can deploy the same application on TC4.0.4 and it runs fine. I tried many versions of Tomcat 4.1 (4.1.7, 4.1.12, 4.1.14 and 4.1.16) and are all failing. I attached the VM log. Thanks, Aymeric [EMAIL PROTECTED] 12/10/02 04:48PM Howdy,If your OS requires patches in order to run the JDK (whatever versionyou're trying to run), make sure those patches are installed. I hadthis exact issue happen on Solaris, and installing the proper Solarispatches made it go away.You say "The same behavior can be reproduced with both JDK1.4.0 andJDK1.4.1" and yet "I cannot create a test case to reproduce my problem."Which one is it? ;) If you can reproduce it, the full details of howto reproduce it can be posted to Sun's bug parade, and they'll trackdown whatever tools they need in order to mimic your environment. Ifyou can't reproduce it, there's no bug as far as they're concerned.Finally, I'm not sure I understand this bullet:- I works fine with TC4.1So your app works fine on TC 4.1? I thought that was the whole problem?Or did you mean it works fine with TC 4.0 and not 4.1? If it's thelatter, as I suspect, perhaps you could start by deploying a very smallsubset of your app and repeating the test. Then increase the deployedsubset and retest. The idea is that a certain feature of tomcat as usedby your app is crashing the VM, and to find out which section of yourapp is causing this. The more you can narrow it down, the better.Yoav ShapiraMillennium ChemInformatics--To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]For additional commands, e-mail: mailto:[EMAIL PROTECTED] hs_err_pid13559.log Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
