Config FAQ
From Resin 3.0
(New page: === Where is the configuration GUI === <p> Resin deliberately does not include any kind of GUI for deployment or management. Or philosophy is: </p> <ul> <li>a single xml configuration f...) |
|||
Line 1: | Line 1: | ||
+ | {{Cleanup}} | ||
+ | |||
=== Where is the configuration GUI === | === Where is the configuration GUI === | ||
Latest revision as of 15:49, 2 December 2011
This article requires cleanup and may refer to a legacy version of Resin.
Please visit http://www.caucho.com/documentation/ for the most up-to-date documentation. |
Contents |
Where is the configuration GUI
Resin deliberately does not include any kind of GUI for deployment or management. Or philosophy is:
- a single xml configuration file for the server (
resin.conf
) - changes to the server configuration file (
resin.conf
) are automatically detected and cause a restart of the server - changes to the
WEB-INF/web.xml
configuration file for a web application are automatically detected and cause a restart of the web application - new web applications are added either with
resin.conf
file changes, or by adding a.war
or subdirectory to awebapps/
directory - new <a href="http://caucho.com/resin/doc/virtual-host.xtp">virtual hosts</a> are added either
with
resin.conf
file changes, or by adding a.jar
or subdirectory in ahosts
directory.
Where can I find the .rnc files that Resin uses for validating configuration files?
- com/caucho/server/resin/resin.rnc
- com/caucho/server/webapp/web-xml.rnc
- com/caucho/server/webapp/resin-web-xml.rnc
- com/caucho/server/resin/env.rnc
- com/caucho/jsp/cfg/jsp-tld.rnc
- com/caucho/jsp/cfg/jsp11-tld.rnc
- com/caucho/jsp/cfg/jsp12-tld.rnc
- com/caucho/jsp/cfg/jsp1_2-tld.rnc
- com/caucho/jsp/cfg/jsp20-tld.rnc
Can I precompile JSPs?
See the <a href="http://wiki.caucho.com/Maven2">Maven2</a> and <a href="http://wiki.caucho.com/Ant">Ant"</a> entries in the wiki.
How can I disable directory listings?
Directory listing is performed by a servlet named 'directory'. The standard resin.conf contains a definition of that servlet:
resin.conf definition of directory servlet
<web-app-default>
...
<servlet servlet-name="directory"
servlet-class="com.caucho.servlets.DirectoryServlet"/>
Directory listing is disabled by removing or commenting out this definition.
resin.conf disabled directory servlet
<web-app-default>
...
<!-- disabled:
<servlet servlet-name="directory"
servlet-class="com.caucho.servlets.DirectoryServlet"/>
-->
What impact does always-save-session have on performance?
We've seen significant performance issues when distributed sessions are enabled, and are trying to find some clues as to the cause. We've seen as much as 30% increase in cpu utilization when disttributed sessions are enabled, and we are using <always-save-session>
<always-save-session> has a significant impact on performance.
When using <always-save-session>, Resin can't know if an internal bean value has changed, so the session is serialized with every request. That's a pretty significant amount of work, depending on how much is stored in the session.
It is far more efficient to design the session to avoid the need for <always-save-session>, so session values are only saved once and then are read-only.
You can avoid <always-save-session> if you call setAttribute()
each time the session state changes. If your web application calls
session.setAttribute("key",value) everytime you change the value
object,
then Resin can intercept that call and realize that the session needs to be
written to the distributed store again.
Resin 3.0 is a little more efficient thatn Resin 2.1. Resin 3.0 compares the crc sum of the serialization; it compares the crc value of the serialization of current session objects with the objects in the backing store, and if there is no change the session is not written.