Re: Windows Domain authentication with Vista (and Tomcat)
Caldarale, Charles R wrote: From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Subject: RE: Windows Domain authentication with Vista (and Tomcat) Even if you're not using the NTLM HTTP filter Are you using the current version of jCIFS? Only 1.3 and above support NTLMv2. You may want to post your question on the jCIFS mailing list; Mike will likely want Wireshark traces of the NTLMv2 negotiations if you do. Many thanks for the info. I had completely overlooked the latest 1.3.1 version. I did try the 1.3.0 and it didn't work, but I see now a comment to the effect that it was broken for HTTP authentication (which I do use). I'll go and try it again. And I understand why Mike would want a Wireshark trace with that stuff. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP vs HTTP connectors?
On 02.02.2009 21:20, Eric B. wrote: I was listening to a webinar on spring source by Filip Hanik& Mark Thomas regarding tuning Tomcat for production in which they indicate that the Http connector is recommended vs an AJP connector (http://www.springsource.com/node/555). My question, then becomes, if someone wants to use Tomcat to serve up pages behind Apache Httpd, how to configure it to use the http connector? So far, the only thing I found is to use proxy/reverse proxy which is slow and can be problematic. To date, I've always been using mod_jk with AJP connector, but is there a better/preferred way to do this? I'll make a couple of comments, but keep in mind that I might be biased towards mod_jk. Historically a few years ago Mladen Turk, who at that time more or less was the only remaining active committer on mod_jk and who is also a committer to httpd, initiated porting mod_jk to the mod_proxy framework, which he did as I remember mostly together with Jean Frederic Clere. Some initial goals were: a) creating a bigger developer community b) making the module available by default with httpd c) creating a more unified configuration style d) making the code easier by using the APR libraries Goals a), c) and d) have been achieved. Concerning b) one can have some doubts, because although all configuration is done in httpd style configuration files, you also end up with long attribute lists when actually defining the workers. The configuration complexity for complex production environments doesn't go away. Another thing turned out to be more important: The porting to mod_proxy was done at about the time of version 1.2.15 of mod_jk and got its first production release with httpd 2.2.0. Now the release policy of httpd has to be very conservative. The thing runs the majority of the web and you really need to be very careful not breaking it. So any bundled evmodule can only improve very slowly once it is in a production release of httpd. This changes whenever httpd gets a major update, like expected this year (2.4 comes closer). On the contrary I had the opportunity to join Mladen in the development of mod_jk shortly after the mod_proxy_ajp port, and together we were able to add a lot of features and to release a lot of versions. Triggered by this improved dynamics more developers contributed enhancements and patches. So we are now at version 1.2.27, though release pace somewhat slowed down recently. So though mod_jk and mod_proxy_ajp/mod_proxy_balancer once were very close, mod_jk moved faster. Don't get me wrong: a lot of people were happy with mod_jk 1.2.15 and are very happy with mod_proxy_ajp. Especially if your setup doesn't get too complex and if you already have some basic familiarity with mod_proxy, it's a good choice. I hope we will find time to merge back our mod_jk improvements to mod_proxy before 2.4 gets released. mod_jk can still be the faster moving target, but it would be nice to merge back soon. So what does all that mean? I expect that neither mod_proxy_http, nor mod_proxy_ajp or mod_jk do differ very much in performance on modern hardware. I think the differences in robustness are not very huge. mod_jk has some more features, but in simple setups you won't need them. Whichever way you go, for a good result you really need to read carefully through the various configuration options and try to understand the consequences. None of the modules provides an excellent result in a high-performance or complex architecture situation by default. At the end it comes down to knowledge. BTW: This is the Tomcat users list. People here might be a bit more focused towards mod_jk. You can also ask around on the httpd list to check out the opinion of that community. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: proxy: AJP: failed to make connection to backend
On 27.01.2009 21:24, Jim Goodspeed wrote: I am seeing the following error in my HTTP Apache error_log. I think this is OK (I assume the timeout has expired and that it will create a new connection when it is needed), but I wanted a second opinion. We are having a problem with some dropped connections and I think it is either network or database related, but I want to eliminate the tomcat and apache setup to be safe. Thank you in advance for your help. I have two web servers in front of two tomcat servers - 2.2.10 for the web servers and 6.0.16 for the tomcat servers. Error from apache error_log: [Mon Jan 26 12:00:56 2009] [error] (70007)The timeout specified has expired: proxy: AJP: attempt to connect to 10.222.4.30:55330 ( noandvtc02b.noandv.btbpo.net) failed [Mon Jan 26 12:00:56 2009] [error] ap_proxy_connect_backend disabling worker for (noandvtc02b.noandv.btbpo.net) [Mon Jan 26 12:00:56 2009] [error] proxy: AJP: failed to make connection to backend: noandvtc02b.noandv.btbpo.net Those messages should not occur in a sane environment. They tell you, that httpd was not able to connect to the backend (create a new connection) before a timeout fired. If you didn't configure any special timeout I think it is by default 300 seconds! So either there's a network problem between the httpd server and 10.222.4.30, or all threads in your Tomcat at 10.222.4.30 were busy, so Tomcat couldn't accept a new connection. In this case a thread dump (kill -QUIT to the Tomcat process) would reveal in catalina.out, what all those threads are doing. My configuration is the following on apache: ProxyRequests Off ProxyPreserveHost On Order deny,allow Allow from all BalancerMember ajp://server1:8009 route=app-a loadfactor=5 BalancerMember ajp://server2:8009 route=app-b loadfactor=5 ProxyPass balancer://app/ stickysession=JSESSIONID My AJP configuration on each tomcat server is below: connectionTimeout is a bit low, because usually you want to persist connections in server to server communication a bit longer, even when idle. But first you need to find out, why creating new connections fails every now and then (changing the connectionTimeout decreases the frequency with which you need to create new connections [good for your problem] but also increases the amount of time threads inside Tomcat will be held busy [bad for your problem]). I have the following jvmRoutes defined on each tomcat server in the server.xml file: Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fun with the JVM crashing.
On 06.02.2009 02:37, Bill Davidson wrote: I've submitted this to Sun a few times. No response. I was hoping someone here might have an idea of what to look for. Tomcat 6.0.18 RedHat 5.2Server Sun JVM # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2b68e6a1db57, pid=10229, tid=1103006016 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x564b57] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x4bfe5c00): JavaThread "CompilerThread0" daemon [_thread_in_native, id=10244, stack(0x41ae8000,0x41be9000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x . Current CompileTask: C2:2525 com.myCompany.servlets.sales.blah.some.method(Lcom/myCompany/servlets/someClass;Lcom/myCompany/servlets/otherClass;Lcom/oreilly/servlet/ParameterParser;)V (425 bytes) .. - I'm wondering if that CompileTask is what's causing the problem. I'm thinking that the JVM shouldn't be getting SIGSEGV's. You can track compilation with -XX:+PrintCompilation. Once you have an idea which class and method produces the crash, you can disable compilation for it with a file called .hotspot_compiler. It contains entries like exclude com/myCompany/servlets/sales/blah/some method and has to be put into the working directory of the JVM before starting it. If you want to use a different file with such command or a different place, you can use -XX:CompileCommandFile=/my/hotspot/compiler/file In case you only want to exclude few methods from compilation, -XX:CompileCommand=exclude,com/myCompany/servlets/sales/blah/some,method will do it. See http://futuretask.blogspot.com/2005/01/java-tip-7-use-hotspotcompiler-file-to.html or http://forums-beta.sun.com/thread.jspa?messageID=4273845 Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Want to learn Everything on Tomcat. 23/24 March in Amsterdam.
Hi, A new tutorial has been added to the ApacheCon Web site: "Everything Tomcat - Administering, Tuning, Troubleshooting and Develop". That is a 2 day tutorial given by Mark Thomas who is one of the greatest tomcat developers. Getting a tutorial during the ApacheCon is the oportunity to get more than a "standard" tutorial because most of the tomcat committers are also around at the conference so any question can be answered during the tutorial. See http://eu.apachecon.com/c/aceu2009/ and join us at that great event. Cheers Jean-Frederic - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Deadlock situation detected/avoided with jk_log_lock
On 06.02.2009 20:40, fredk2 wrote: Do I understand you correctly that when Mr. Orton said to never use pthread nor posixsem mutex (http://marc.info/?l=apr-dev&m=108720968023158&w=2) that is now obsolete news and that Solaris perfected pthread mutex support since. Joe Orton is always very careful with his statements, precise and correct. My personal experience with pthread mutexes on Solaris was fine, but I must confess, that I didn't do specialized tests to determine behaviour in crash situations. I now did some searching and it turns out that the implementation of pthread mutexes for Solaris 10 has very recently changed quite a bit. So all speculations about improved pthread mutex behaviour (especially for "robust" mutexes) in the last years might have become obsolete. The new implementation is contained in Solaris kernel patch 137137-09 and most likely also in Solaris 10 Update 6 (10/08). I didn't check, whether that update simply contains the kernel patch or the fix is included independently. Some detail is logged in Sunsolve under the bug IDs 6296770 2160259 6664275 6697344 6729759 6564706 You mention that mod_jk uses pthread is that the same as the httpd itself? mod_jk uses a global mutex provided by the apr libraries for access to the log file. It gets a default mutex, i.e. it lets APR decide, which type of mutex to use (APR_LOCK_DEFAULT, for Solaris it should be fcntl). You can't configure like for httpd's accept or ssl mutex. mod_jk uses a couple of more locks, which are all not APR provided, but instead directly coded to use pthreads. All of those mutexes are only thread mutexes, so used locally in each process and not shared between processes. They won't have a problem with crashing processes. They are: - one mutex for each AJP worker, synchronizing access to the connection pool, which exists per process - one mutex for each lb worker - a mutex for access to the shared memory when changing or reading configuration parameters. That might be a little unsafe, because it actually should be a global mutex, not a process local, but those config changes are only done due to interaction with the status worker, so there's very little chance for unwanted concurrency here. All dynamic runtime data are already marked as being volatile. - a mutex used during dynamic update of uriworkermap.properties to prevent concurrent updates. Updates are done per process. - a mutex to prevent concurrent execution of the process local internal maintenance task Some fellow at Covalent back in the early Apache 2.0 days, posted a white paper about his various mutex testing, but it does not appear to be available anymore. Would be interesting to know how it was tested and how it would playout today. Lots of the Covalent people are still around in various projects, like William (Bill) A. Rowe and Jim Jagielski. You could post at apr-dev, because Apache httpd uses the mutex implementations coming from the APR libraries. Rainer Jung-3 wrote: On 06.02.2009 18:13, fredk2 wrote: I was doing some stress test (with apache ab, 100 users, 100K requests) to compare an Apache prefork and worker mpm. The test url is a simple hello servlet on Tomcat 6.0.x via mod_jk. On my Sparc Solaris 10 server with only the Apache set to worker mpm I see following error messages in my jk log: Apache/2.2.11 (Unix) with mod_jk/1.2.26 on Solaris 10. . . . [Thu Jan 08 11:42:28 2009] [error] (45)Deadlock situation detected/avoided: apr_global_mutex_lock(jk_log_lock) failed . . . [Thu Jan 08 11:42:29 2009] [emerg] (45)Deadlock situation detected/avoided: apr_proc_mutex_lock failed. Attempting to shutdown process gracefully. [Thu Jan 08 11:42:29 2009] [error] (45)Deadlock situation detected/avoided: apr_global_mutex_lock(jk_log_lock) failed . . . these errors do not appear to impact the test results and the jk log file seems complete. I can suppress the errors by choosing another Mutex in the Apache directive AcceptMutex, such as sysvsem or pthread. For Solaris 10 the default mutex for worker MPM is fcntl. Setting the Mutex sysvsem (also the default on Linux) marginally improves the request time. Can someone explain what exactly these errors means? when does it occur? I would have almost expect a "detected/avoided" to be a [warn] instead of an [error]. I have seen the trail http://markmail.org/message/dedqpmrrkpa224ns but I'd like to hear updated experiences that people have with sysvsem mutexes on Solaris 10 - what is the better mutex? sysvsme, posixsem, pthread **? any comment will be appreciated. I experienced this too a couple of times and once wrote a small C program to reproduce the problem. On Solaris the algorithm to detect a possible deadlock is very careful and returns EDEADLOCK even in situations were you can mathematically prove, that a deadlock is not possible. This happens in a multi-threaded environment when more than one mutex is used. Apache httpd and mod_jk use such a m
RE: Windows Domain authentication with Vista (and Tomcat)
> From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] > Subject: RE: Windows Domain authentication with Vista (and Tomcat) > > Even if you're not using the NTLM HTTP filter Are you using the current version of jCIFS? Only 1.3 and above support NTLMv2. You may want to post your question on the jCIFS mailing list; Mike will likely want Wireshark traces of the NTLMv2 negotiations if you do. - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Windows Domain authentication with Vista (and Tomcat)
> From: André Warnier [mailto:a...@ice-sa.com] > Subject: Windows Domain authentication with Vista (and Tomcat) > > https://issues.apache.org/bugzilla/show_bug.cgi?id=46323 > This would seem to indicate that there is something going on at the > Tomcat level about NTLM/AD authentication. Not that there /is/ something going on, but the submitter would like something /to be/ going on. I doubt that the above enhancement request would be accepted as is, since it modifies the permitted values for and is therefore out of compliance with the servlet spec. But we'll see... > For a Tomcat application, I use an authentication/SSO > mechanism partly composed of jCIFS (jcifs.samba.org), > partly self-built. Are you using the NTLM HTTP filter that is available with jCIFS? If so, it cannot be used in conjunction with NTLMv2, which the Vista box may well be insisting on. Examine the LmCompatibilityLevel setting in the Vista system registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa; make sure it's no higher than 3. Even if you're not using the NTLM HTTP filter, we've had trouble with Vista connecting to non-Microsoft SMB servers when the above registry setting is higher than 3; XP works fine when at 5 (the highest setting), so Vista is doing something weird that we haven't figured out yet. - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Windows Domain authentication with Vista (and Tomcat)
Hi. I have an issue with Windows Domain authentication, Vista and (probably) NTLMv2. It is under Tomcat too. ;-) I was browsing Google and the various lists at marc.info, and happened to find what looks like a promising link as follows : https://issues.apache.org/bugzilla/show_bug.cgi?id=46323 This would seem to indicate that there is something going on at the Tomcat level about NTLM/AD authentication. But I have no clue about how to follow the above.. clue. Basically, I'm picking at straws and trying to gather information and find someone, or some place, which can provide more. Can anyone provide ideas as to where I should go, whom to get in touch with, anything ? Thanks in advance. P.S. Short description : For a Tomcat application, I use an authentication/SSO mechanism partly composed of jCIFS (jcifs.samba.org), partly self-built. It has worked nicely so far, but appears to have problems at one customer, with Vista workstations recently introduced. I'm trying to solve this. The application also uses Apache httpd 2.2, and I could do the authentication either there or at the Tomcat level. At this problem site, both Apache and Tomcat run on the same Windows 2003 host. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat Domain for redirects
Problem is that I also host some PHP and RubyOnRails apps on the same server and I'd like to keep them running ^^ Caldarale, Charles R wrote: > >> From: Christian Decker [mailto:decker.christ...@gmail.com] >> Subject: Tomcat Domain for redirects >> >> I have a server that is running Tomcat 5.5 and an >> Apache server that runs on port 80 and uses mod_jk >> to redirect all incoming requests to the tomcat server. > > So let's start at the beginning. Why do you have httpd in the picture at > all, if everything's being sent to Tomcat? Simplify your life. > > - 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - Christian Decker http://blog.snyke.net -- View this message in context: http://www.nabble.com/Tomcat-Domain-for-redirects-tp21874907p21889861.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Domain for redirects
This seems to have done the trick, the redirects now finally work properly ^^ It would be nice for it to autodiscover the domain a request came from, but that's fine by me because it's just a test machine, and I'll have my sysadmin bothering with the deployment later ^^ Konstantin Kolinko wrote: > > 2009/2/6 Christian Decker : >> >> Hi all, >> >> I'm not that good at configuring Tomcat so I thought I'd ask here. My >> problem is that I have a server that is running Tomcat 5.5 and an >> Apache server that runs on port 80 and uses mod_jk to redirect all >> incoming requests to the tomcat server. >> >> So far, so good. The problem is that I want to access the server from >> outside my local network, so instead of accessing http://server1/app/ >> I now have http://server1.example.com/app/ which automatically >> redirects to an index page, but on the wrong address (http://server1/ >> app/welcome instead of http://server1.example.com/app/welcome) which >> is kind of annoying. >> >> As this happens in many different places I assume that the tomcat >> server somehow believes that he is server1 instead of >> server1.example.com. >> >> Any directions on where to look? >> >> Regards, >> Chris > > Read Apache HTTPD docs on how it determines its server name. I guess > it should have been the ServerName directive, > http://httpd.apache.org/docs/2.2/mod/core.html#servername > > If I remember correctly, mod_jk passes that information to Tomcat, but if > that > does not work, it can be overwritten in element by setting > proxyName and proxyPort attributes, > http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - Christian Decker http://blog.snyke.net -- View this message in context: http://www.nabble.com/Tomcat-Domain-for-redirects-tp21874907p21889858.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Location of properties file for web app in Tomcat
Christopher Schultz wrote: Flavius, Flavius wrote: My ultimate goal is to give these instructions to a network admin: 1. Download and install Tomcat 2. Place war file in /webapps 3. Put the app.properties file at __ and set your database and email server info. 4. Start tomcat Something even cooler would be to provide a simple text editor that would load your properties file from the WAR and write it back into the WAR when you saved it. Then you get the best of both worlds. - -chris Just to mention, there are cases when a JNDI would do the trick and sometimes (not always) like a system property would do. regards Flavio - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Location of properties file for web app in Tomcat
Christopher Schultz wrote: Flavius, Flavius wrote: My ultimate goal is to give these instructions to a network admin: 1. Download and install Tomcat 2. Place war file in /webapps 3. Put the app.properties file at __ and set your database and email server info. 4. Start tomcat Something even cooler would be to provide a simple text editor that would load your properties file from the WAR and write it back into the WAR when you saved it. Then you get the best of both worlds. - -chris Just to mention, there are cases when a JNDI would do the trick and sometimes (not always) like a system property would do. regards Flavio
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
2009/2/7 André Warnier : > You may even find a ready-made servlet filter that could do that (and many > other things besides) here : > http://www.tuckey.org/urlrewrite/ Looks useful. Tks > > A servlet filter does not modify (or require you to modify) the application > in any way; it just sees the request before your application does, and can > do something to it before the application sees it; Yes, that would do. Thanks Andre. regards -- Dave Pawson XSLT XSL-FO FAQ. Docbook FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC6 ${CATALINA_HOME}/conf/web.xml Is this the place to constrain the mime type?
Dave Pawson wrote: Rob, Christopher, Andre. Thanks for the input. As I said to Rob, security is not an issue at the present time. There is no value in the content returned by the 'server' / end point; I'm not trying to make it secure. Just respond less than I otherwise might. Ok, then let me make one final guess and suggestion. If the point is just for your server application to avoid wasting time sending a response to a client that is not "yours", and which would not be able to do something useful with it anyway, then the easiest route would probably still be a simple "servlet filter". That servlet filter would examine the request headers (say the "User-Agent" header, which your client would set appropriately), determine if it is or not the appropriate client, and if not send an appropriate HTTP 4xx error response right away, without even letting the request go to the servlet or restlet or whatever. By sending the correct 4xx kind of response, you would let this "client" know right away, without a doubt, that there is no content here for him, and that he should not even retry, thus avoiding further waste of time for everyone. Google for "HTTP response codes" to find the most appropriate response in your case. You may even find a ready-made servlet filter that could do that (and many other things besides) here : http://www.tuckey.org/urlrewrite/ A servlet filter does not modify (or require you to modify) the application in any way; it just sees the request before your application does, and can do something to it before the application sees it; it also sees the response of your application after it is produced and can do something to it before it is passed to the client. Also, servlet filters are an entirely portable mechanism, defined in the Servlet Specification, so this would work on any servlet engine. Note again that the above is not in any way a security mechanism, because any client can send whatever User-Agent header it very well pleases. But it would be a very HTTP RFC-compliant way of kindly asking inappropriate clients to just go away and not come back. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk
Mohit Anchlia wrote: Sorry I am little confused about couple of things: 1. Based on what I read it looks like workers.properties is not loaded dynamically. And JkMountFileReload doesn't work for worker.properties but it works for uriworkermap.properties. Correct, that is what was said. In clear it means that you can to a certain extent dynamically change the URI's that will be redirected to Tomcat, but you cannot change the kind of properties that are in workers.properties (the address of the back-end Tomcats etc..) 2. Wouldn't setting prepost timeout ensure that a check is made to see if remote machine is up before forwarding the request? Yes. But if you have only one Tomcat to send requests to, then all this tells you is that this Tomcat is not responding. So now what do you do ? I'll use an image : finding out that the back-end Tomcat does not even respond to a ping, rather than sending the whole request and getting an error then (which is more time-consuming), is a way to know faster that there is a problem. But you still have this hot client request in your lap, so now what do you do with it ? If you have 2 or more Tomcats, then it really helps, because mod_jk can redirect the request to a Tomcat which still works. But if there is only one anyway, you're cooked. On Fri, Feb 6, 2009 at 11:01 AM, fredk2 wrote: Hi Rainer, your comment about the watchdog sounds interesting. When you load balance it would seem useful to get feedback from Tomcat itself about its load so that the module can adjust dynamically its load (lbfactor) based on the Tomcat's performance rather than a session/socket count. One can wonder if such added complexity would be detrimental to the mod_jk stability. Rgds - Fred Rainer Jung-3 wrote: On 06.02.2009 18:23, André Warnier wrote: gerhardus.geldenh...@gta-travel.com wrote: 1) As far as I know, no, mod_jk does not read workers.properties dynamically. 2) Yes and no, it will not send a request unless communication has been established with the worker, it may happen that the worker fails, or someone shut it down. Depending on how you configure the workers and the number of workers, it can retry the request and/or try a different worker. Mod_jk will mark the worker on error when it does not respond, and it will try again after a configurable time -but it tries again with an actual request-. It would be really nice if you could test availability of a node with a configurable request instead of a live production request... (hint, hint) Isn't that what "ping" is about ? Ping tests, whether there is something able to still process AJP on the other side of the connection. A configurable request would be able to talk to the application, so one could detect, whether it is still deployed, and if the request would be handled by an intelligent servlet it could respond with some sort of application layer health status. Worth filing an enhancement request, since Mladen put the Watchdog thread into 1.2.27, we can easily add more logic of that type. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://www.nabble.com/mod_jk-tp21856049p21878692.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
