<title>Miscellaneous</title>

<summarylist/>

<section title='Resin Freezes'>

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

<p/>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.

<p/>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.

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

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

</section>

<section title="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.

</section>

<section title="Can you recommend any JDBC drivers?">

Arun Jamwal writes:

<p/>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....

<p/>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:

<p/><href/http://www.beasys.com/products/weblogic/drivers.html/><br/>
<href/http://www.javasoft.com/products/jdbc/drivers.html/>

</section>

<section title="How should I use XSL?">
Scott Ferguson writes:

<p/>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.

<p/>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.

<p/>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.

<p/>Here some useful areas I've found helpful:
<ol>
<li>automatic insertion of response.encodeURL in &lt;a href> and &lt;form action>
<li>calculating the image size from &lt;img src> and filling in width and height
<li>some well-defined formatting primitives: &lt;example>, &lt;callout>, &lt;var>, &lt;section>.  An &lt;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.
<li>page formatting.  It's nice to have the stylesheet create the navigation, breadcrumbs, meta tags, etc.
<li>user preferences.  Call a jsp:useBean at the top of the page and use as simple as possible bean methods in 
the XSL.
</ol>

<p/>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.

<p/>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.

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

</section>

<section title="What value does caching add when I'm already using Apache?">

<em><pre>
> 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.
</pre></em>

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:

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

<p/>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.

<p/>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.


</section>

<section title="How do I prevent cached pages from the back button?">

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

<p>Jean-Francois Lamy replies:

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

<example>
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
</example>

</section>
