RE: mod_jk.dll Support
Thanks for the clarification. I happened to read some old documentation (on the Tomcat site) mentioning the DLL and got the wrong/confusing feelings. Dong -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Tuesday, 2 January 2007 6:44 PM To: Tomcat Users List Subject: Re: mod_jk.dll Support The tomcat connectors exist as a plugin for various web servers (Apache httpd 1.3, 2.0, 2.2, IIS and Sun). Depending on the web server you use, you have to download the appropriate file. All variants are in the directory http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2 .20/ At the bottom of the directory index view, there is an explanation, which file you will need: * mod_jk-apache-1.3.37.so is for Apache 1.3.x. Rename to mod_jk.so before putting it in your Apache/modules directory * mod_jk-apache-2.0.58.so is for Apache 2.0, and works with Apache 2.0.58 and later. Rename to mod_jk.so before putting it in your Apache2/modules directory. * mod_jk-apache-2.2.3.so is for Apache 2.2, and works with Apache 2.2.3 and later. Rename to mod_jk.so before putting it in your Apache2/modules directory. * isapi_redirect.dll is for IIS 5 and later Web Server. * nsapi_redirect.dll is for Sun ONE Web Server 6.1 and later (formerly Netscape iPlanet). * jk_symbols.zip contans debug (.pdb) information for all modules. Please note, that module files for Apache httpd traditionally have file names ending in .so, not in .dll. Regards, Rainer Jung JiaDong Huang wrote: Hi, This is a re-post as a new email thread. Thanks Mark pointing it out - I did not realize using reply would cause confusion to the mailing list. I can not find the mod_jk.dll from jk-1.2.20 build. Does it mean that is not supported any more? Or I should use the mod_jk-apache-2.2.3.so instead? Thanks! Dong - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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_jk.dll Support
Hi, I can not find the mod_jk.dll from jk-1.2.20 build. Does it mean that is not supported any more? Or I should use the mod_jk-apache-2.2.3.so instead? Thanks! Dong - 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_jk.dll Support
Hi, This is a re-post as a new email thread. Thanks Mark pointing it out - I did not realize using reply would cause confusion to the mailing list. I can not find the mod_jk.dll from jk-1.2.20 build. Does it mean that is not supported any more? Or I should use the mod_jk-apache-2.2.3.so instead? Thanks! Dong
RE: mod_jk.dll Support
Thanks Martin for the reply, I don't seem to be able to find the DLL from the Apache HTTP Server at http://httpd.apache.org/download.cgi. Something must be going not quite right - I have been trying to download mod_jk.dll from the link below, which is the proposed place, for Tomcat component. I can not find mod_jk.dll, but find the mod_jk-apache-2.2.3.so instead, with some confusing documentation. http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2 .20/ Dong -Original Message- From: JiaDong Huang [mailto:[EMAIL PROTECTED] Sent: Tuesday, 2 January 2007 11:54 AM To: users@tomcat.apache.org Subject: mod_jk.dll Support Hi, This is a re-post as a new email thread. Thanks Mark pointing it out - I did not realize using reply would cause confusion to the mailing list. I can not find the mod_jk.dll from jk-1.2.20 build. Does it mean that is not supported any more? Or I should use the mod_jk-apache-2.2.3.so instead? Thanks! Dong - 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: [OT] Multi processor issue
Maybe certain verification tool can be considered to develop for JSP/Servlet developer. Sun has the verifier.bat tool verifying the integrity of the .WAR file and environment. Since the Request Object usage has already been stated in the spec. Maybe Tomcat can have certain JSP verification tool. Is any thing like that available? Or it is not possible to do technically at all. Maybe it can that be part of JSP compiler... The MT issue like this is to do with Tomcat threads. It is an easy pointer people would point their finger to. The challenge is how to prevent that while you are coding/testing. Dong -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 December 2006 3:13 AM To: Tomcat Users List Subject: Re: [OT] Multi processor issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: [OT] Multi processor issue In that case, the OP could wrap their own request objects to actually prevent their bug in production while researching it in dev/test, The problem with doing so in this case is that while it might avoid this particular crash of the application, it would not have actually prevented the bug, and might well contribute to data corruption. Oh, I'm not suggesting that the real bug in the application shouldn't be fixed. I'm just suggesting a better band-aid than the current solution, which is basically to (somewhat) limit the possibility of encountering the Exception. The bug itself is completely unavoidable. Your point is well-taken, though: TC should not go out of it's way to provide the capability to run broken applications. We'll leave that capability to MSIE ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFgCac9CaO5/Lv0PARAkB0AJ0Z1Q26ZuLCB2hHA/m+626hG6msGwCfUea2 yrSHXhfoTmoJ1mP1zsuLQVA= =jKsw -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [OT] Multi processor issue
It would be pretty significant if it can get into the thread level clustering, especially for those database update threads group. What the real world is using for database connection clustering? Something like C-JDBC technology? Dong -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 December 2006 2:29 AM To: Tomcat Users List Subject: RE: [OT] Multi processor issue From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: [OT] Multi processor issue There is an OS called Clouds where threads could actually migrate between machines in a cluster. I suppose the thread doesn't really migrate, but all of the associated data (or handles to them) do migrate. Yeah, we built something like that too, some years back. Never made it to market. A solution in search of a problem. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Multi processor issue
-Original Message- From: Marziou, Gael [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 December 2006 9:21 PM To: Tomcat Users List Subject: RE: Multi processor issue Do you mean I should add a delay before the while loop to increase the length of the critical section? Yes. Before and maybe within the loop. That should get the MT issue reproduced much easier. What do you mean by yelding the CPU (sorry I'm French) ? Yielding the CPU means to let your thread give up the CPU so as to give the others thread a change to run. The delay call Thread.sleep() should yield the CPU. Sorry, I should have said in my previous email: make some time delay - and the thread should yield the CUP. Dong - 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: Multi processor issue
Great to see the bottom of the MT issue has been revealed/understood. I believe Gael may be able to fix his app now. Hope it can be an easy fix... Not sure if the app really cares which thread should do the parameterMap initialization. If it does not, then it would be a good idea for Tomcat to refine/enhance the parameterMap initialization procedure to be MT safe. Apparently, the current lock facility (isLocked() and setLocked()) does not protect MT case properly, while initializing. Is it worthwhile and appropriate to have certain MT synchronization facility like isInitialized() and setInitialized() around the code? In theory, the second thread can wait for isInitialized() there. Not sure if it will cause any concern to other apps, like having other racing condition. Really depend on the parameterMap usage/operation. MT issue fix can never be simple. Chuck understands parameterMap usage very well. Maybe he can make further comments/recommendation to the Tomcat dev team. Dong -Original Message- From: Marziou, Gael [mailto:[EMAIL PROTECTED] Sent: Wednesday, 13 December 2006 3:24 AM To: Tomcat Users List Subject: RE: Multi processor issue Anything dealing with a session must be careful not to expose a Request object to the session scope, since there's the risk another request for the same session may get confused with the first - I suspect that's what's happening here. Will do. You should take a careful look at all the com.hp code in the stack trace (not just the above three places) and verify that Request objects are not getting mixed up. Might want to add some trace code in various places to insure that a given thread is procesing the same Request object at all points. Yes, it makes sense. Could also try turning off APR (remove or rename tcnative-1.dll) and see if that has an effect. I already did at the beginning of our investigation as I suspected the JNI code but it had no effect. Gael - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Multi processor issue
Chuck, I am very clear about the whole thing. Please try to understand my point properly too. Your point can be right and valid and would be very significant to help Gael. Gael should be able to get to the point where his app might do wrong, or miss leading Tomcat threads. What I have been saying is that we should reconsider very carefully whether there should be any enhancement in Tomcat. From the Tomcat code you dug out, there is something not quite perfect, in term of MT safe while initializing. No argument. One of your posted messages did state that it is valid for two threads to access/operate on the ParameterMap once it has been established. So, it may be pretty hard and confusing what the app developer should be doing at the upper level. Whether it is appropriate to enhance Tomcat or not, and when, I don't think I am in the right position to justify. I guess once Gael has clarified his issue. He may be in a better position to make significant comments, and see if you can agree. Dong -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Wednesday, 13 December 2006 11:34 AM To: Tomcat Users List Subject: RE: Multi processor issue From: JiaDong Huang [mailto:[EMAIL PROTECTED] Subject: RE: Multi processor issue Not sure if the app really cares which thread should do the parameterMap initialization. You're missing the entire point of this exercise: no Request object should EVER be processed by more than one thread. No synchronization changes are needed within Tomcat. The most likely cause of the problem is code in the app itself exposing a Request object at the session or context level (e.g., storing it as a session attribute), thereby causing a thread working on a second, separate request to grab the wrong Request object. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Multi processor issue
Appreciate your reply analyzing my guessing cases. So it is just a case of simple MT issue - multiple threads have accessed/operated on a class/object that is not MT safe. I thought they had done certain code review and did not find any MT safe issue. If an effective stress test had been done on single CPU environment, the issue should have been revealed too. Dong -Original Message- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Monday, 11 December 2006 3:30 PM To: Tomcat Users List Subject: RE: Multi processor issue From: JiaDong Huang [mailto:[EMAIL PROTECTED] Subject: RE: Multi processor issue It is a MT issue, but MP specific. Strictly speaking, it's not MP-specific. If run long enough, the problem will appear on a single CPU. Its occurrence would require the first thread to exhaust its CPU time slice at a critical point, and have the second thread be dispatched immediately. (In most operating systems, when a thread uses up its time slice, it's placed at the end of the dispatch queue for its priority, thus allowing other threads of the same or higher priority to run ahead of it. Note that the OS-defined priority in this case often has little to do with the Java-specified priority for a thread.) That said, the situation is certainly much, much more likely to occur on an MP system. The Tomcat code you had dug out (having problem and throwing the exception) has been designed as single threaded. But in MP environment, multiple threads get in and cause issue like this. That means somewhere in Tomcat or JVM, the synchronization facility has already been broken While that would be true in general, it's not the case here. Objects of the Request class are never intended to be used concurrently by multiple threads, so there is no synchronization defined or implemented for them. No second thread - whatever its origin - should be operating on the same Request object that another thread is handling. As far as I understand, Tomcat connector may use JNI The APR and AJP connects are implemented with JNI, the standard HTTP and HTTPS ones are pure Java. not sure the threads we are talking about had run through the code implemented with JNI. They did not, but it's not really relevant, given the Tomcat requirement of only one thread manipulating a Request object at a time. Threads running through JNI may be re-marshaled between OS spaces - switching OS rings or VM. They can change ring (generically, the thread privilege level), but not VMs. If you're suggesting that one thread may change its process association, that is theoretically possible on some OS implementations (anybody remember Multics?), but it is certainly not happening here, and, in any event, is completely irrelevant. (Any such change from one process to another must be extremely tightly controlled for security purposes, and is a capability simply not available to typical user threads.) In another word, while switching between rings, the lock associated with the objects may have been lost, etc. That's erroneous, even if it were relevant to this situation, which it isn't. There's no synchronization issue involved, since the Request object is not intended to be manipulated concurrently by multiple threads. This problem is almost certainly an application problem, either starting an additional thread somewhere or exposing the Request object improperly (e.g., storing a reference to it in the session) so that another thread erroneously starts working with this Request instead of the one its supposed to be working on. Also, the JVM or OS API may need other synchronization facility underneath while switching rings. These are only my guess anyway. No code in the JVM depends on or expects to change privilege level (other than the privileges controlled entirely within the JVM), due to its platform independence. I think you may be trying to apply some rather esoteric capabilities of certain operating systems, but they really have no bearing on this situation. It could be the JVM's synchronization facility does not work properly in MP, for Tomcat. Or, Tomcat could be enhanced to prevent this sort synchronization issue from happening. You're ignoring one basic fact: this problem has been reported on only *one* system running *one* particular application. If there were a general synchronization problem in Tomcat, the JVM, or the OS, it would certainly show up on some of the thousands (millions?) of other multi-processor systems running Tomcat. As I stated earlier, we have zero problems running Tomcat on our 32x servers (of various architectures). There is a very small chance that something in the hardware on this particular system has gone bad (e.g., lock signal not being propagated on the bus), but such a problem would undoubtedly show up in more places than this one spot in Tomcat. After reviewing the messages, it is tomcat5.exe has been modified. That means it may be tomcat5.exe should
RE: Multi processor issue
From the description of the symptom - months' testing experience, we could pretty much confirm that it is a MP issue, not a MT issue. Chasing the stack dump of Java may not get to any significant point. If you try to fix the MP specific issue like this at the high level like Tomcat/JAVA app code, you will get to a situation like: fix one issue, another issue will come up eventually. The producer of MSVCR80.dll may be interested in knowing this. This may be Win32 OS or JVM specific. Appreciate your findings and solution! Dong -Original Message- From: Martin Gainty [mailto:[EMAIL PROTECTED] Sent: Saturday, 9 December 2006 6:18 AM To: Tomcat Users List Subject: Re: Multi processor issue the affinity 'trick' is a replacement dll for the 80 runtime stock libraries The individual most familiar with interfacing to the runtime is mladen turk I would make all attempts to ping him on the solution As a comparison between the 2 dlls Here are the binary characteristics of the stock msvcr80.dll that ships with retail windows packages Section contains the following exports for MSVCR80.dll 0 characteristics 40ECD724 time date stamp Thu Jul 08 01:09:56 2004 0.00 version 1 ordinal base 1367 number of functions 1367 number of names ordinal hint RVA name /*and the replacement msvcr80.dll provided in setaffinity*/ Section contains the following exports for MSVCR80.dll 0 characteristics 4333A455 time date stamp Fri Sep 23 02:44:37 2005 0.00 version 1 ordinal base 1459 number of functions 1459 number of names ordinal hint RVA name so the new msvcr80.dll from setaffinity has 92 new functions which allow it to work reliably with MP calls HTH, Martin-- --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. --- Le présent message électronique (y compris les pièces qui y sont annexées, le cas échéant) s'adresse au destinataire indiqué et peut contenir des renseignements de caractère privé ou confidentiel. Si vous n'êtes pas le destinataire de ce document, nous vous signalons qu'il est strictement interdit de le diffuser, de le distribuer ou de le reproduire. But the evidence seems to show two threads are manipulating the same request, otherwise you wouldn't get the error on the ParameterMap. Does a full thread dump show any threads that aren't part of the set started by Tomcat? either that, or a Request is reused before recycle() has been executed completely. We assumed this as well but after instrumenting more our code, we concluded it was not possible because the corruption seemed to occur before the end of the 2 requests processing and so before recycle() was called. I got some logs which sort of showed this but I can't find them right now, I have stopped working on this issue 3 weeks ago. Alas, you could do a test and check whether the method getParameter is actually ever called by two threads during one lifecycle (patching the ParameterMap class, storing last accessing thread, and checking whether another thread is already stored on access) We did it but for some reason the log statements did not get logged in our usual log file. Then after we tried the affinity trick which made the symptom to disappear and got no chance to try again. And Gael, the CPU is the most valuable resource in the production environment, are you really ready to give up your scaleability but simply not investigating further? Well, this application is load balanced on 4 servers and the load is currently pretty low on each of them even when running on a single CPU. We did add more logs to our application and we did also instrument Tomcat but with no luck and as we were unable to reproduce it in a dev environment, it's difficult to ask for short downtimes to restart a server in production. On top of that, my team is being moved to another project... Gael - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Is jsp designed for use by large websites
I believe SJAS 9 must be still using Tomcat. No reason for Sun to change the Servlet/JSP container. Agree? I can not comment about the stability of SJAS 9 as I am still using EJB2 - I did a quick try and realize I have to upgrade my EJB facility to EJB3. Would appreciate your findings! Dong -Original Message- From: Andre Prasetya [mailto:[EMAIL PROTECTED] Sent: Thursday, 7 December 2006 8:45 PM To: Tomcat Users List; [EMAIL PROTECTED] Subject: Re: Is jsp designed for use by large websites Is SJAS 9 really using tomcat inside ? its already 2.5 and the behaviour is slightly different like the getContextPath(), and other function which returns null at tomcat 5.5 has a return value at SJAS 9. Log log = Utility.getLogger(this); ServletContext context = evt.getServletContext(); log.info(servlet context name : + context.getServletContextName() ); log.info(server info : + context.getServerInfo()); log.info(servlet api + context.getMajorVersion() + '.' + context.getMinorVersion()); On 12/7/06, JiaDong Huang [EMAIL PROTECTED] wrote: As far as I know, JBoss/SunOne are all bundling Tomcat inside. Not sure where the feeling of the number of Tomcat users to attenuate over time comes from. Dong -Original Message- From: epyonne [mailto:[EMAIL PROTECTED] Sent: Thursday, 7 December 2006 3:07 PM To: Tomcat Users List Subject: Re: Is jsp designed for use by large websites Totally agree. PHP is no doubt an excellent tool, but primarily for hobbyists or standalone type of deployment. On the other hand, Java is widely used on enterprise application. If you open up the hood and look, all the expensive application like WebSphere are running Tomcat inside. epy. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, December 06, 2006 3:27 PM Subject: Re: Is jsp designed for use by large websites On 12/6/06, Peter Crowther [EMAIL PROTECTED] wrote: From: Martin Gainty [mailto:[EMAIL PROTECTED] As Tomcat is OpenSource (and not proprietary) and can be installed on any OS (vs just 1) I dont undertand What is causing the number of Tomcat users to attenuate over time? Ancient history, I know, but I'll respond anyway. A Model T Ford is a perfectly good car. However, if Ford don't innovate and other car manufacturers do, people buying new cars will switch away from Ford to vehicles that are cheaper, faster, have lower fuel costs or innovations like a roof. Tomcat and JSP is a perfectly good model for web applications. However, if the Java community and the Tomcat developers don't innovate and other communities do (for example the PHP community and Microsoft), people deploying new applications will switch away from Tomcat and JSP to systems that are cheaper, faster to develop, have lower hosting/running costs or innovations like per-webapp memory and CPU throttling. The issue is not that Tomcat is bad in absolute terms, it's simply that other communities are out-innovating it so it's becoming a (perceived) poorer *relative* choice. I'd too like to know which communities are out-innovating java? To stay in you example, comparing php (or ruby for this matter) to java is like comparing bicycles with cars. Sure its fun to make a ride on sunday. Sure it's ok to bike to the office on a sunny day, if the office is 30 minutes away. But trying to deliver a fridge to the customer with a bike is rather stupid. regards Leon Btw. I'm ashamed that I don't know it, but does C# has a similar concept to ThreadLocals? - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Andre- PCs are like air conditioner, if you open Windows, they don't work - 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: Minimum requirement to run/test the Tomcat Cluster
I have set up my own DNS server to have a play. My Tomcat cluster works well, including my Database Web App. Dong -Original Message- From: JiaDong Huang [mailto:[EMAIL PROTECTED] Sent: Wednesday, 6 December 2006 1:09 PM To: users@tomcat.apache.org Subject: Minimum requirement to run/test the Tomcat Cluster Hi, I would like to have a run/test with the Tomcat Cluster. Is that possible to setup the Tomcat Cluster without changing the DNS server, for the DNS Round Robin feature? I am wondering the functionality like load balancing and URL redirect within Tomcat itself might be able to support/configure for this purpose. Does Tomcat failover detection purely rely on DNS Round Robin? Any simplest and workable sample would be much appreciated. Dong - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: Is jsp designed for use by large websites
As far as I know, JBoss/SunOne are all bundling Tomcat inside. Not sure where the feeling of the number of Tomcat users to attenuate over time comes from. Dong -Original Message- From: epyonne [mailto:[EMAIL PROTECTED] Sent: Thursday, 7 December 2006 3:07 PM To: Tomcat Users List Subject: Re: Is jsp designed for use by large websites Totally agree. PHP is no doubt an excellent tool, but primarily for hobbyists or standalone type of deployment. On the other hand, Java is widely used on enterprise application. If you open up the hood and look, all the expensive application like WebSphere are running Tomcat inside. epy. - Original Message - From: Leon Rosenberg [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, December 06, 2006 3:27 PM Subject: Re: Is jsp designed for use by large websites On 12/6/06, Peter Crowther [EMAIL PROTECTED] wrote: From: Martin Gainty [mailto:[EMAIL PROTECTED] As Tomcat is OpenSource (and not proprietary) and can be installed on any OS (vs just 1) I dont undertand What is causing the number of Tomcat users to attenuate over time? Ancient history, I know, but I'll respond anyway. A Model T Ford is a perfectly good car. However, if Ford don't innovate and other car manufacturers do, people buying new cars will switch away from Ford to vehicles that are cheaper, faster, have lower fuel costs or innovations like a roof. Tomcat and JSP is a perfectly good model for web applications. However, if the Java community and the Tomcat developers don't innovate and other communities do (for example the PHP community and Microsoft), people deploying new applications will switch away from Tomcat and JSP to systems that are cheaper, faster to develop, have lower hosting/running costs or innovations like per-webapp memory and CPU throttling. The issue is not that Tomcat is bad in absolute terms, it's simply that other communities are out-innovating it so it's becoming a (perceived) poorer *relative* choice. I'd too like to know which communities are out-innovating java? To stay in you example, comparing php (or ruby for this matter) to java is like comparing bicycles with cars. Sure its fun to make a ride on sunday. Sure it's ok to bike to the office on a sunny day, if the office is 30 minutes away. But trying to deliver a fridge to the customer with a bike is rather stupid. regards Leon Btw. I'm ashamed that I don't know it, but does C# has a similar concept to ThreadLocals? - Peter - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Minimum requirement to run/test the Tomcat Cluster
Hi, I would like to have a run/test with the Tomcat Cluster. Is that possible to setup the Tomcat Cluster without changing the DNS server, for the DNS Round Robin feature? I am wondering the functionality like load balancing and URL redirect within Tomcat itself might be able to support/configure for this purpose. Does Tomcat failover detection purely rely on DNS Round Robin? Any simplest and workable sample would be much appreciated. Dong - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
