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, 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

How should I use XSL?

Scott Ferguson writes:

Since my experience with XSLT is only with simple examples, you'll want to take it with a shaker of salt. And, of course, it really depends on the application. Some applications are a perfect fit for XSLT and others should avoid it. For what it's worth, here's my current thinking on XSLT.

XSLT is a very new technology; the spec was only finished in December. There really hasn't been enough time for people to discover what works and what doesn't work. Be very careful of new technologies, especially radical new technologies. Even Java, which has turned out to be a great language, was a disaster in the 1.0.2 timeframe, and Java on the client is still less-than-optimal and applets are nightmarish. When C++ was the hot new thing, many projects jumped full into C++ implementations and created huge unmanageable disasters.

Now, I'm not suggesting that you avoid XSLT entirely, just that you be careful in using it and avoid placing it at the center of your architecture. I'd suggest you limit XSLT to places where it's a clear win. Otherwise you can waste lots of time coming up with the perfect tag library or debugging an architecture that will turn out, in hindsight, to have been an anti-design pattern.

Here some useful areas I've found helpful:

1. automatic insertion of response.encodeURL in <a href> and <form action>
2. calculating the image size from <img src> and filling in width and height
3. some well-defined formatting primitives: <example>, <callout>, <var>, <section>. An <artist> tag is a good example. But, again, be careful of inventing the perfect tag library, stick to obvious tags, and define them only after you really need them.
4. page formatting. It's nice to have the stylesheet create the navigation, breadcrumbs, meta tags, etc.
5. user preferences. Call a jsp:useBean at the top of the page and use as simple as possible bean methods in the XSL.

So my approach, if I were starting a project, would be to select either straight JSP or servlet->JSP templates as a basic architecture, depending on the actual project needs. I'd replace JSP with XTP, but only use a defaultcopy.xsl and a header.xsl stylesheet. So far, this use of XTP is essentially identical to JSP. Only after common idioms and formatting kruft start filling up the JSP and become error-prone would I put them into the stylesheet. With XSLT such a new technology, a waterfall-style "design before you implement" approach is likely to get you into lots of trouble with XSLT.

I'd avoid putting lots of Java code in the stylesheets. Put them in beans instead. Debugging Java code that comes from stylesheets into a JSP file is hard. Really hard.

Your mileage will vary. Any discussion of XSLT architecture will be theoretical until several full-sized projects succeed with XSLT and several fail.

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.

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.

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