Re: Problem showing german characters
Am Dienstag, 11. März 2008 02:03:37 schrieb Stasa Jerinic: Hallo, I save some application specific settings in file, that will be readed from application. This file contains parameters that can contain german special characters like Ö, Ä, Ü, ß etc. I tested my application under windows 2000 professional with Tomcat 5.0 and under Linux and the german specific characters are shown correct. But by customer, that is running this web-application under Linux the german special characters are not shown correct, but they are replaced with other signs. The customer set the system variable LANG=en_US.UTF-8 (where is the file under linux where I can set the system variables?) and under Apache LANG=de_DE.UTF-8, as well as under Tomcat LANG=de_DE.UTF-8, NLS_LANG=german_germany.utf8. Are the settings wrong, so that the customer cann't see correct the special german characters or is there somer other trouble? Its not enough to set the systems LANG/Tomcat LANG and so on, but you need to include that in your HTTP headers too (meta HTTP_EQUIV tags and jsp content-type settings in the pages). Each page can have its own content type and the clients like to change it. Also you can tune apache with some config setting to apply utf-8 encoding as the default but I don't remember the exact syntax. Greetings, Stasa - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jkMount
Am Montag, 29. Oktober 2007 23:33:16 schrieb Christopher Schultz: Dale, BuildSmart wrote: As for only working on localhost, you need to check the rest of your Apache httpd and Tomcat configurations: you probably don't have the right virtual host config on either httpd or Tomcat or both. My guess is both. I only have one webapp in Tomcat as localhost and it's on port 8080 (with connector on 8009) what more do I need?? So, you have Tomcat configured to support the localhost virtual host and you expect it to work with other virtual hosts? Apache httpd doesn't do this, either. Why would you expect that an incorrect configuration would work properly? Don't tell me now that I have to add an entry in Tomcat for every virtualhost that wishes to access the webapp, that makes no logical sense to have multiple tomcat virtualhosts pointing to the same webapp/docroot. Aah, yes... but you're asking all virtual hosts in httpd to point to the same Tomcat instance. Why does the symmetric relation not hold for such an illogical statement? Tomcat, like Apache httpd, can be configured to use a default virtual host for all requests that do not match any of the explicitly-defined virtual hosts. Since you are so familiar with the documentation, I won't waste space in this post with the configuration. I'm using the mod_jk module and not a bastardized version so if it's not working per your configuration directives then it's the guys who coded mod_jk who are fault and you should bitch to them about it. I've never had a problem with mod_jk. No complaints required from my end. It's possible that mod_jk was written to support only virtual hosts, and not JkMount options at the top-level. I'd be surprised at this, but there's an easy workaround: use a global virtual host. In any event, if you need this global capability (and it sounds like you do), try asking for this capability instead of telling the mod_jk folks that they are bunch of idiots. You catch more flies... Actually I had BIG problems with JkMount at a time ... well I think there was a major flaw in communication between the module and the tomcat vm ... or somewhere else. Anyway these problems are thought to be gone in recent versions (I think). In your case, you have discrete virtual hosts. You may have to add JkMount /*.jsp workerX for each virtual host. It's not insane: it's what's required. You have to map DocumentRoot for each VirtualHost element. What's wrong with adding this mapping as well. The virtual host problem can be solved quite easily be apache configuration if you define you JkMount statements in a simple include file lets call it jkmount.conf and use them in your virtual host statements: VirtualHost bla:80 # [...] include jkmount.conf # [...] /VirtualHost Concerning vhosts, I didn't understand, what you try to achieve. Please try the above JkMount first. As soon as that works for you, we can discuss further requirements. I did, it doesn't work and it kills python and php functionality. No, you said that JkMount /* workerX kills Python and Php. Rainer is asking you to use JkMount /*.jsp workerX. workerX is not defined anywhere but I'll give it a try to satisfy you. OMGWTFBBQ. Nearly all of the mod_jk documentation surrounds creating workers that connect mod_jk to Tomcat. You should have gotten /that/ far. You must have a worker, or nothing works. workerX is a placeholder for the actual worker you want to use. Put your own worker's name in there, don't just type workerX and complain when it doesn't work. ouch, yes of course there should be workers. guess that doesn't work either, any more suggestion??? Yes: use the name of the worker that you actually configured (ajp13, as per the posted configuration). it wouldn't have been so bad but more than a week with incomplete directions hasn't help the frustration level, something is definitely broken if it wont work as people tell me to configure it and as you stated that is how everyone configures it and it works for them so either I'm not getting all of the information or it doesn't work. No, it just a bit insane. Nore more then anything else that is done with Java. Let's take a quick look at your configuration. workers.properties: worker.list=ajp13 worker.ajp13.host=localhost worker.ajp13.port=8019 worker.ajp13.type=ajp13 Note that you don't need the 'lbfactor' unless you are using a load-balanced worker. Now, to your httpd config: IfModule mod_jk.c JKWorkersFile /etc/httpd/workers.ajp13.properties JKLogFile /var/log/httpd/mod_jk.log JKLogLevel debug JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkMount /*.jsp ajp13 JkOptions +ForwardKeySize +ForwardURICompat /IfModule Your config is clearly being loaded, as you are getting messages in your log file regarding mod_jk. Where is this configuration located? Is it being put into a VirtualHost, or is it at the
Re: Tomcat - All threads (200) are currently busy
We happend to have similar problems when starting with tomcat. Our main error was a failing connection to the database, while the connector had it's retry flag on. So the answer to each request was, trying to connect to a unconnectable database until the timeout has been reached, which is too long for any busy site of course. Before you examine all your threads you should test your application for such errors that delay the answer to requests. Maybe you should also try to build a test setup, answering very simple to your requests (hello, world) and push in one application module each time to see at which state your application breaks. When you get this error very fast the error should occure at one quite central point in your code. Also consult access and error logs of the tomcat process (catalina.out and similar). Writing your own log files by your jsp pages is also quite helpfull sometimes. Am Donnerstag, 12. Juli 2007 15:02 schrieb André Vila Cova: Hi! I've this two processes: tomcat6404 0.0 2.6 484396 105456 ? Sl 01:05 0:14 /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Djava.util.logging.conf tomcat6555 0.1 3.8 516420 154452 ? Sl 01:09 0:39 /usr/local/java1.5/bin/java -Xms64m -Xmx200m -Xss512k - Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager - Djava.util.logging.conf Output is null when I execute the following command: [EMAIL PROTECTED] ~]# kill -QUIT 6404 [EMAIL PROTECTED] ~]# How can I see what thread is doing? Thank You On 7/11/07, Titi Wangsa [EMAIL PROTECTED] wrote: probably some threads are performing database operation and it takes too long so new threads are being spawned, the new threads are also taking too long, so newer threads are being spawned. too much spawning, that is what is causing the limit break. On 7/12/07, André Vila Cova [EMAIL PROTECTED] wrote: I don't think so... I will see..but, why i get the error? SEVERE: All threads (200) are currently *busy*, waiting. *Increase On 7/11/07, Mladen Turk [EMAIL PROTECTED] wrote: André Vila Cova wrote: Hello! I get lot of times the following error: SEVERE: All threads (200) are currently *busy*, waiting. *Increase maxThreads* ** *Strange is that i've configured in server.xml the following (maxThreads=400):* * You have probably done that for a wrong connector. Regards, Mladen. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- == Ingo Krabbe ASK UNIX Systems Burggrafenstraße 3 44139 Dortmund Telefon 0231 4770185 FAX 0231 4770186 E-Mail [EMAIL PROTECTED] Fingerprint EE5A 6533 EE5E 8F66 EC20 C56A 35FC B736 18FD EB5A == - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat - All threads (200) are currently busy
Am Donnerstag, 12. Juli 2007 19:12 schrieb André Vila Cova: Lot of waits... Could you help me? http-8085-Processor24 daemon prio=1 tid=0x082f1378 nid=0x19c6 in Object.wait() [0xde118000..0xde118e20] at java.lang.Object.wait(Native Method) - waiting on 0xe619f748 (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:474) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( ThreadPool.java:656) - locked 0xe619f748 (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:595) somehow this looks like a deadlock. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_proxy - tomcat 5.5 causing stutter
I managed to configure the tomcat proxy behind my apache 2.2 worker threads not to crash anymore, but still it stutters, while I observe the following conditions on my high load, complex site: When the users come in with 500-1500 request/second the apache process collects the incoming request within reading state R, as viewed by server-status. The bigger I make the apache thread configuration the heavier seems the impact on the tomcat behind mod_proxy (HTTP connector). So lets talk big: The apache process collects about 1000-5000 requests when the tomcat manages to start working, removing the requests from the queue. When it started working it is even able to reduce the pending requests to a few 5-20, which is nothing of course. But the users already come in again and start populating the queue of the apache reinventing the stuttering condition. Are there any hints how I can configure the tomcat/apache team to stop this condition ? May prefork or a smaller worker configuration help the tomcat to react (apache config) ? Are there possible tunings in web.xml, server.xml or other paramters that help me to react on requests faster ? May it help to drop the apache in front at all, giving the tomcat even more requests of course, since it has to answer to the static contents too ? Any hints will help. TIA bye ingo -- == Ingo Krabbe ASK UNIX Systems Burggrafenstraße 3 44139 Dortmund Telefon 0231 4770185 FAX 0231 4770186 E-Mail [EMAIL PROTECTED] Fingerprint EE5A 6533 EE5E 8F66 EC20 C56A 35FC B736 18FD EB5A == - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
