I'm sorry, I didn't realize you were going to argue with me and criticize my reply. I thought you were asking for an opinion.
First, Ajp13Connector is not the recommended connector to use for 4.1.18. CoyoteConnector is the recommended connector. Second, the compatibility problems between Ajp13Connector and JMX are well-known, at least on this list. Since you seem so adept at searching the list, I'm sure you would have seen this. Third, we have several production sites right now with 4.1.18, Apache 2, and mod_jk. We have a couple dozen more with Apache 1.3, mod_jserv, and Tomcat 3.x. All are under fairly heavy load, approx. 100,000 page views per day during the week. The apps are all heavily graphic-intensive, that is, lots of file I/O, lots of RAM, lots of CPU. We don't have any problems with mod_jserv or mod_jk. Uptime is in the many months timeframe, each and every site and webapp is monitored for availability every 60 seconds, 24/7 and there have been no alerts that weren't initiated by us for maintenance...I consider that stable. You may not. You may have problems, I can only reply to your questions with comments and opinions based on my personal experience. If you don't like that, my advice is to refrain from posting the question in the first place, or, if you must post, clearly state in your post the parameters within which you will consider a reply to be "valid" such as "I want your opinion, but only if you agree with me". Fourth, you've got some Charset errors in there. Our apps don't use anything but standard Western charsets (our apps are all in English except for a few that are in French), so I am not familiar with those errors. I don't think I would blame them on JK, though. Fifth, I'm not a developer. I'm a systems administrator. It's simple: if you don't want to use a connector, THEN DON'T. Nobody is twisting your arm, and the use of Apache with Tomcat is NOT REQUIRED. Arguing about connector stability or problems is a waste of time...they're open source. Either pitch in and fix them to your heart's content, help others to do so, or be quiet. If you must use Apache with Tomcat for some reason, there are a number of ways to do this, all of which have been discussed to death on this list, and if I had to rank them I would rank them thusly: 1) JK, 2) JK2, 3) mod_proxy/mod_rewrite, 4) external redirection (ipchains, for example, or some other software). I doubt anyone will tell you differently, but I've been wrong plenty of times before and you are certainly welcome to disagree. Perhaps others will answer your other questions. Arguing is a waste of my time, I apologize for replying in the first place and wasting yours. John > -----Original Message----- > From: Tomasz Nowak [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 27, 2003 10:28 AM > To: Tomcat Users List > Subject: Re: Four questions (about logging, connectors and manager) > > > Turner, John <[EMAIL PROTECTED]> wrote: > > > > A #2: I don't feel the connectors are complex. JK is easy to > > configure, easy to get working (once you understand how it works), > > and stable. > > Hi, John. Browsing the archive I've remebered you as a very competent > developer/user, so I'm really very glad you answered my letter :) > I would like to tell you about mod_jk complexibility and stability > from my point of view. > > 1. Starting Tomcat 4.1.18 with org.apache.ajp.tomcat4.Ajp13Connector, > catalina.out: > > ServerLifecycleListener: createMBeans: MBeanException > java.lang.Exception: ManagedBean is not found with Ajp13Connector > at > org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:224) > at > org.apache.catalina.mbeans.ServerLifecycleListener.createMBean > s(ServerLifecycleListener.java:369) > at > org.apache.catalina.mbeans.ServerLifecycleListener.createMBean > s(ServerLifecycleListener.java:777) > at > org.apache.catalina.mbeans.ServerLifecycleListener.createMBean > s(ServerLifecycleListener.java:751) > at > org.apache.catalina.mbeans.ServerLifecycleListener.createMBean > s(ServerLifecycleListener.java:339) > at > org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEv > ent(ServerLifecycleListener.java:206) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(L ifecycleSupport.java:166) > at > org.apache.catalina.core.StandardServer.start(StandardServer.j ava:2182) > at > org.apache.catalina.startup.Catalina.start(Catalina.java:512) > at > org.apache.catalina.startup.Catalina.execute(Catalina.java:400) > at > org.apache.catalina.startup.Catalina.process(Catalina.java:180) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess orImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth odAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at > org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) > > Tada! Seems they dont like with JMX each other. > > 2. But let's request some simple pages (ROOT/index.jsp couple > of times, > list webapp in manager, etc). Pages in fact work well, but after > only a few requests I find in logs such a mess: > > catalina.out: > ============ > java.lang.IllegalStateException: Current state = FLUSHED, new > state = CODING_END > at > java.nio.charset.CharsetEncoder.throwIllegalStateException(Cha rsetEncoder.java:933) > at > java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529) > at > sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnc > oder.java:356) > at > sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:412) > at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158) > at > java.io.OutputStreamWriter.close(OutputStreamWriter.java:222) > at java.io.PrintWriter.close(PrintWriter.java:137) > at > org.apache.catalina.connector.ResponseBase.finishResponse(Resp > onseBase.java:483) > at > org.apache.catalina.connector.HttpResponseBase.finishResponse( HttpResponseBase.java:253) > at > org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Respo > nse.java:191) > at > org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) > at > org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) > at java.lang.Thread.run(Thread.java:536) > (x12 times) > > engine log: > =========== > java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) > at > java.net.SocketOutputStream.write(SocketOutputStream.java:136) > at org.apache.ajp.Ajp13.send(Ajp13.java:525) > at > org.apache.ajp.RequestHandler.finish(RequestHandler.java:501) > at org.apache.ajp.Ajp13.finish(Ajp13.java:395) > at > org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Respo > nse.java:196) > at > org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) > at > org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) > at java.lang.Thread.run(Thread.java:536) > (multiple) > > 2003-02-27 16:01:47 Ajp13Processor[8009][1] process: invoke > java.net.SocketException: Broken pipe > at java.net.SocketOutputStream.socketWrite0(Native Method) > at > java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) > at > java.net.SocketOutputStream.write(SocketOutputStream.java:136) > at org.apache.ajp.Ajp13.send(Ajp13.java:525) > at > org.apache.ajp.RequestHandler.finish(RequestHandler.java:501) > at org.apache.ajp.Ajp13.finish(Ajp13.java:395) > at > org.apache.ajp.tomcat4.Ajp13Response.finishResponse(Ajp13Respo > nse.java:196) > at > org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:464) > at > org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:551) > at java.lang.Thread.run(Thread.java:536) > (multiple) > > > 3. Let's see what mod_jk.log says: > > [jk_ajp_common.c (970)]: ERROR sending data to client. > Connection aborted or network problems > [jk_ajp_common.c (681)]: ERROR: can't receive the response > message from tomcat, network problems o > r tomcat is down. > [jk_ajp_common.c (1050)]: Error reading reply from tomcat. > Tomcat is down or network problems. > [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat > failed, recoverable operation. err=0 > [jk_ajp_common.c (681)]: ERROR: can't receive the response > message from tomcat, network problems o > r tomcat is down. > [jk_ajp_common.c (1050)]: Error reading reply from tomcat. > Tomcat is down or network problems. > [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat > failed, recoverable operation. err=0 > [jk_ajp_common.c (970)]: ERROR sending data to client. > Connection aborted or network problems > > Tomcat is down? Network problems?? Hello! > That's just a locahost with stable Tomcat instance and few > requests to it! > I even can't imagine how would my logs look in a productive > environment. > > So, John, you call all of this as "simple and stable"? :-) > > > If you don't want to use a connector, don't even deal with > > mod_rewrite or mod_proxy, just run Tomcat on port 80 and be > > done with it. > > I can't because of at least two reasons: > - I must have Apache HTTPd on port 80 on this machine > - I won't run Tomcat as root user > > > Or better yet, run it on 8080 and use iptables/ipchains > > to redirect 80 to 8080. > > Impossible[*] with name-based virtual hosts (mind I need to > have Apache HTTP don port 80). > * Well, almost impossible. There is a possibility of filtering > tcp packets in iptables as far as I know. But such solution > I would not call a "good practice" for serving web pages. > > -- > Tomasz Nowak > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
