Resin Freezes

Normally, this is not actually a Resin problem, but a deadlock in the application code.

To get anywhere you need to produce a thread dump. Getting a thread dump is system dependent. On Unix, "kill -QUIT" for the Java process will produce a thread dump.

On Solaris with JDK 1.2, you need to start Resin from a console, i.e. you need to use "httpd.sh" instead or "httpd.sh start". When you use "kill -QUIT", the JDK will ask you questions to get more detailed information.

On Windows, you need to start Resin from a command line, not from http.exe. ctrl-\ will then give you the dump.

By looking at the thread dump you should be able to see what lock is getting stuck.

Why so many processes on Linux?

On Linux, each native thread is displayed as a separate process by 'ps -auxw'. Don't worry, those processes are extremely lightweight.

Can you recommend any JDBC drivers?

Arun Jamwal writes:

I have used Weblogic's type 2 JDBC driver (formerly known as FastForward) on two big projects. Oracle's type 4 JDBC driver was crashing against a big query...and type 2 couldn't be used with M$ VM. Weblogic bundles these drivers with Tengah but you can ask them just for the JDBC drivers....

I had used Openlink's type 3 JDBC drivers too (about 2.5+ years ago) but I didn't like them much.

PS: Check out these links for more info:

http://www.beasys.com/products/weblogic/drivers.html
http://www.javasoft.com/products/jdbc/drivers.html

What value does caching add when I'm already using Apache?

> What value does caching provide when Resin is behind another web server like > IIS. Do I want caching on? Presumably, most jsp pages and all servlets are > dynamic.

True, but many pages are only quasi-dynamic. For example, cnn.com's home page is dynamically generated, but it changes only every 15 minutes or so. cnn.com probably has a 15 minute cron job that updates a static file and you could develop something like that yourself or spend time caching database results. Resin's caching just makes that easier. If cnn.com used Resin, it could do all that very easily by adding:

<% long now = System.currentTimeMillis(); response.setDateHeader("Expires", now + 15 * 60000); %>

Also, sophisticated sites have top pages that change for logged in users, but dynamic sub-pages that are common. Because a include() page is treated as a separate request, you can cache just the subpage.

The database is often the bottleneck for latency and also for database licenses and hardware. If you can avoid 75% of your Oracle calls by setting a simple header, you can delay buying Sun's high-end enterprise servers for a couple of months.

How do I prevent cached pages from the back button?

This isn't actually a Resin question, but it's a common issue.

Jean-Francois Lamy replies:

We use the following, which does seem to force reload in case of a Back as well.

response.setHeader("Cache-Control","no-cache"); //HTTP 1.1 response.setHeader("Pragma","no-cache"); //HTTP 1.0 response.setDateHeader ("Expires", 0); //prevents caching at the proxy server

Copyright © 1998-2002 Caucho Technology, Inc. All rights reserved. Resin® is a registered trademark, and HardCoretm and Quercustm are trademarks of Caucho Technology, Inc.