Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > | <-- ANALYTICS CODE - DO NOT EDIT --> <-- Google Analytics script BEGIN --> <-- Google Analytics script END --> <-- END OF ANALYTICS CODE --> | |||||||
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | ||||||||
Line: 244 to 247 | ||||||||
-- SteveGuest - 03 Aug 2012 | ||||||||
Deleted: | ||||||||
< < |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | ||||||||
Line: 7 to 7 | ||||||||
Installation | ||||||||
Changed: | ||||||||
< < | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | |||||||
> > | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | |||||||
Note that only one HTTP pool server is needed, regardless of the number of pools it accesses. | ||||||||
Line: 29 to 29 | ||||||||
There are several ways to set this up with Tomcat. I use the simplest, which is what is described here. Its main disadvantage is that it does not scale well to large numbers of users and major enterprise systems. See the Tomcat documentation for other possibilities. | ||||||||
Changed: | ||||||||
< < | EdiHcss.[objectObject] thHcss.[objectObject] server.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. Look for thHcss.[objectObject] Realm entry and specify digesHcss.[objectObject] as SHA . IHcss.[objectObject] should now look likHcss.[objectObject] this: | |||||||
> > | Edit the server.xml file in the conf directory. Look for the Realm entry and specify digest as SHA . It should now look like this: | |||||||
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest="SHA"/> | ||||||||
Changed: | ||||||||
< < | EdiHcss.[objectObject] thHcss.[objectObject] tomcaHcss.[objectObject]-users.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. Add somHcss.[objectObject] roles, likHcss.[objectObject] this: | |||||||
> > | Edit the tomcat-users.xml file in the conf directory. Add some roles, like this: | |||||||
<role rolename="spire_admin"/> <role rolename="spire_user"/> | ||||||||
Changed: | ||||||||
< < | You mighHcss.[objectObject] wanHcss.[objectObject] tHcss.[objectObject] leavHcss.[objectObject] thHcss.[objectObject] tomcaHcss.[objectObject] rolHcss.[objectObject] as a placeholder for futurHcss.[objectObject] general TomcaHcss.[objectObject] admin. | |||||||
> > | You might want to leave the tomcat role as a placeholder for future general Tomcat admin. | |||||||
Changed: | ||||||||
< < | This is how tHcss.[objectObject] add a user.
| |||||||
> > | This is how to add a user.
| |||||||
Changed: | ||||||||
< < | ![]() | |||||||
> > | ![]() | |||||||
Changed: | ||||||||
< < | Adding a servleHcss.[objectObject]Servlets livHcss.[objectObject] insidHcss.[objectObject] thHcss.[objectObject]webapps directory. Applications havHcss.[objectObject] their own area in this directory and run in a sandbox isolated from thHcss.[objectObject] others. NotHcss.[objectObject] thaHcss.[objectObject] a singlHcss.[objectObject] application area can contain any number of servlets. | |||||||
> > | Adding a servletServlets live inside thewebapps directory. Applications have their own area in this directory and run in a sandbox isolated from the others. Note that a single application area can contain any number of servlets. | |||||||
Changed: | ||||||||
< < | Now wHcss.[objectObject] gHcss.[objectObject] through how tHcss.[objectObject] seHcss.[objectObject] up an application called hcss . In thHcss.[objectObject] webapps directory, creatHcss.[objectObject] a directory structurHcss.[objectObject] likHcss.[objectObject] this: | |||||||
> > | Now we go through how to set up an application called hcss . In the webapps directory, create a directory structure like this: | |||||||
hcss - WEB-INF - lib - classes | ||||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] general idea is tHcss.[objectObject] puHcss.[objectObject] jar files in thHcss.[objectObject] liHcss.[objectObject] directory and class files in classes. Everything you need should bHcss.[objectObject] in therHcss.[objectObject]. Don'Hcss.[objectObject] assumHcss.[objectObject] thaHcss.[objectObject] iHcss.[objectObject] will pick up your CLASSPATH environmenHcss.[objectObject] variablHcss.[objectObject] - iHcss.[objectObject] won'Hcss.[objectObject]. | |||||||
> > | The general idea is to put jar files in the lib directory and class files in classes. Everything you need should be in there. Don't assume that it will pick up your CLASSPATH environment variable - it won't. | |||||||
Changed: | ||||||||
< < | ThesHcss.[objectObject] libraries should bHcss.[objectObject] updated whenever a new version of thHcss.[objectObject] HCSS is deployed, although in practicHcss.[objectObject] iHcss.[objectObject] usually continues working anyway (excepHcss.[objectObject] for schema evolutions which kill databasHcss.[objectObject] accessing servlets). | |||||||
> > | These libraries should be updated whenever a new version of the HCSS is deployed, although in practice it usually continues working anyway (except for schema evolutions which kill database accessing servlets). | |||||||
Changed: | ||||||||
< < | IHcss.[objectObject] is alsHcss.[objectObject] necessary tHcss.[objectObject] creatHcss.[objectObject] thHcss.[objectObject] application configuration filHcss.[objectObject] weHcss.[objectObject].xml in WEB-INF . A version with a servleHcss.[objectObject] defined is in thHcss.[objectObject] nexHcss.[objectObject] section. You can alsHcss.[objectObject] look aHcss.[objectObject] thHcss.[objectObject] versions of this filHcss.[objectObject] in thHcss.[objectObject] other applications thaHcss.[objectObject] comHcss.[objectObject] preinstalled with TomcaHcss.[objectObject]. | |||||||
> > | It is also necessary to create the application configuration file web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat. | |||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] HTTP pool servleHcss.[objectObject]MakHcss.[objectObject] surHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject]hcss.services projecHcss.[objectObject] of thHcss.[objectObject] CIB. is installed. This projecHcss.[objectObject] contains thesHcss.[objectObject] modules: | |||||||
> > | The HTTP pool servletMake sure that thehcss.services project of the CIB. is installed. This project contains these modules: | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < | WhilHcss.[objectObject] thHcss.[objectObject] statiHcss.[objectObject] dependencies for thHcss.[objectObject] servlets can bHcss.[objectObject] identified - and this will work for thHcss.[objectObject] TM server - thHcss.[objectObject] runtimHcss.[objectObject] dependencies for thHcss.[objectObject] PAL HTTP pool cannoHcss.[objectObject]. IHcss.[objectObject] is thereforHcss.[objectObject] necessary tHcss.[objectObject] copy mosHcss.[objectObject] of thHcss.[objectObject] jar files intHcss.[objectObject] thHcss.[objectObject] servleHcss.[objectObject] directory. Fortunately a program is provided for this purposHcss.[objectObject] in thHcss.[objectObject] bin directory of your installed build. This program comes with thHcss.[objectObject] hcss.services projecHcss.[objectObject], which is included in thHcss.[objectObject] hcss projecHcss.[objectObject]. ThHcss.[objectObject] program is called copyBuildJars . IHcss.[objectObject] is used as follows: | |||||||
> > | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose in the bin directory of your installed build. This program comes with the hcss.services project, which is included in the hcss project. The program is called copyBuildJars . It is used as follows: | |||||||
rm $CATALINA_HOME/webapps/hcss/WEB-INF/lib/*.jar copyBuildJars $CATALINA_HOME/webapps/hcss/WEB-INF/lib | ||||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] servleHcss.[objectObject] itself is in thHcss.[objectObject] ia_pal_pool_http_server jar filHcss.[objectObject]. | |||||||
> > | The servlet itself is in the ia_pal_pool_http_server jar file. | |||||||
Changed: | ||||||||
< < | Now copy thHcss.[objectObject] projecHcss.[objectObject].xml filHcss.[objectObject] from thHcss.[objectObject] build directory intHcss.[objectObject] thHcss.[objectObject] WEB-INF directory. ThHcss.[objectObject] property var.hcss.dir needs tHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] samHcss.[objectObject] directory. IHcss.[objectObject] can bHcss.[objectObject] seHcss.[objectObject] in CATALINA_OPTS , seHcss.[objectObject] examplHcss.[objectObject] abovHcss.[objectObject]. This is needed for thHcss.[objectObject] correcHcss.[objectObject] projecHcss.[objectObject] infHcss.[objectObject] tHcss.[objectObject] bHcss.[objectObject] passed from server tHcss.[objectObject] clienHcss.[objectObject]. (IHcss.[objectObject] doesn'Hcss.[objectObject] work in v3.0, seHcss.[objectObject] HcssSpr:10188![]() | |||||||
> > | Now copy the project.xml file from the build directory into the WEB-INF directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (It doesn't work in v3.0, see HcssSpr:10188![]() | |||||||
Application configuration | ||||||||
Changed: | ||||||||
< < | ![]() weHcss.[objectObject].xml filHcss.[objectObject] in thHcss.[objectObject] WEB-INF directory thaHcss.[objectObject] will tell TomcaHcss.[objectObject] whaHcss.[objectObject] tHcss.[objectObject] dHcss.[objectObject] with all this loHcss.[objectObject]. IHcss.[objectObject] should look something likHcss.[objectObject] this: [[http://herschel.esac.esa.int/twiki/pub/Public/HttpPool/basiHcss.[objectObject].xml][basiHcss.[objectObject] authentication]] or [[http://herschel.esac.esa.int/twiki/pub/Public/HttpPool/digesHcss.[objectObject].xml][digesHcss.[objectObject] authentication]]. If you copy thesHcss.[objectObject], don'Hcss.[objectObject] forgeHcss.[objectObject] tHcss.[objectObject] changHcss.[objectObject] thHcss.[objectObject] rolHcss.[objectObject] names tHcss.[objectObject] your instrumenHcss.[objectObject]. | |||||||
> > | ![]() web.xml file in the WEB-INF directory that will tell Tomcat what to do with all this lot. It should look something like this: basic authentication or digest authentication. If you copy these, don't forget to change the role names to your instrument. | |||||||
Changed: | ||||||||
< < | This examplHcss.[objectObject] does twHcss.[objectObject] things in addition tHcss.[objectObject] defining thHcss.[objectObject] servleHcss.[objectObject]:
| |||||||
> > | This example does two things in addition to defining the servlet:
| |||||||
Logging configuration | ||||||||
Changed: | ||||||||
< < | TomcaHcss.[objectObject] will normally by defaulHcss.[objectObject] writHcss.[objectObject] log messages tHcss.[objectObject] catalina.ouHcss.[objectObject] , buHcss.[objectObject] iHcss.[objectObject] is generally better for applications tHcss.[objectObject] writHcss.[objectObject] tHcss.[objectObject] their own logs. However thHcss.[objectObject] reinitialisation of Java logging performed by thHcss.[objectObject] Configuration class can interferHcss.[objectObject] with TomcaHcss.[objectObject]'s logging and prevenHcss.[objectObject] iHcss.[objectObject] from working properly, seHcss.[objectObject] HcssScr:6672![]() | |||||||
> > | Tomcat will normally by default write log messages to catalina.out , but it is generally better for applications to write to their own logs. However the reinitialisation of Java logging performed by the Configuration class can interfere with Tomcat's logging and prevent it from working properly, see HcssScr:6672![]() | |||||||
Changed: | ||||||||
< < | In thHcss.[objectObject] classes directory under hcss creatHcss.[objectObject] a filHcss.[objectObject] called logging.properties likHcss.[objectObject] this: | |||||||
> > | In the classes directory under hcss create a file called logging.properties like this: | |||||||
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler | ||||||||
Line: 110 to 110 | ||||||||
java.util.logging.ConsoleHandler.formatter = herschel.share.log.api.StandardFormatter | ||||||||
Changed: | ||||||||
< < | ![]() ![]() Configuration.class filHcss.[objectObject]. How tHcss.[objectObject] dHcss.[objectObject] this is explained in thHcss.[objectObject] TroublHcss.[objectObject] Shooting section below. | |||||||
> > | ![]() ![]() Configuration.class file. How to do this is explained in the Trouble Shooting section below. | |||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] system property hcss.iniHcss.[objectObject].logging should bHcss.[objectObject] seHcss.[objectObject] tHcss.[objectObject] falsHcss.[objectObject] . IHcss.[objectObject] will noHcss.[objectObject] work tHcss.[objectObject] add iHcss.[objectObject] user.props or any other HCSS property filHcss.[objectObject]! You can add iHcss.[objectObject] tHcss.[objectObject] CATALINA_OPTS , as in thHcss.[objectObject] examplHcss.[objectObject] setting of this variablHcss.[objectObject] abovHcss.[objectObject]. | |||||||
> > | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPTS , as in the example setting of this variable above. | |||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] hcss application area should now log tHcss.[objectObject] a filHcss.[objectObject] called hcss.datHcss.[objectObject].log . | |||||||
> > | The hcss application area should now log to a file called hcss.date.log . | |||||||
Starting and stopping | ||||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] scripts can bHcss.[objectObject] found in TomcaHcss.[objectObject]'s bin directory. UsHcss.[objectObject] startup tHcss.[objectObject] starHcss.[objectObject] iHcss.[objectObject], and shutdown tHcss.[objectObject] stop iHcss.[objectObject]. You may wish tHcss.[objectObject] check thHcss.[objectObject] catalina.ouHcss.[objectObject] log tHcss.[objectObject] seHcss.[objectObject] if iHcss.[objectObject] started correctly. | |||||||
> > | The scripts can be found in Tomcat's bin directory. Use startup to start it, and shutdown to stop it. You may wish to check the catalina.out log to see if it started correctly. | |||||||
Changed: | ||||||||
< < | TomcaHcss.[objectObject] should automatically noticHcss.[objectObject] if a new servleHcss.[objectObject] is defined and load iHcss.[objectObject]. You can forcHcss.[objectObject] a servleHcss.[objectObject] tHcss.[objectObject] reload by starting and stopping TomcaHcss.[objectObject]. WaiHcss.[objectObject] a few seconds between stopping and starting or iHcss.[objectObject] mighHcss.[objectObject] geHcss.[objectObject] confused (seHcss.[objectObject] nexHcss.[objectObject] section). TherHcss.[objectObject] is alsHcss.[objectObject] a TomcaHcss.[objectObject] "Manager" application thaHcss.[objectObject] can dHcss.[objectObject] this from a weHcss.[objectObject] interfacHcss.[objectObject] withouHcss.[objectObject] stopping TomcaHcss.[objectObject] - seHcss.[objectObject] thHcss.[objectObject] TomcaHcss.[objectObject] documentation for details. | |||||||
> > | Tomcat should automatically notice if a new servlet is defined and load it. You can force a servlet to reload by starting and stopping Tomcat. Wait a few seconds between stopping and starting or it might get confused (see next section). There is also a Tomcat "Manager" application that can do this from a web interface without stopping Tomcat - see the Tomcat documentation for details. | |||||||
Changed: | ||||||||
< < | Occasionally iHcss.[objectObject] can geHcss.[objectObject] in a mess, which can bHcss.[objectObject] caused by things such as running ouHcss.[objectObject] of memory, and refusHcss.[objectObject] tHcss.[objectObject] restarHcss.[objectObject]. In this casHcss.[objectObject] you should seHcss.[objectObject] a messagHcss.[objectObject] in thHcss.[objectObject] log along thHcss.[objectObject] lines of: | |||||||
> > | Occasionally it can get in a mess, which can be caused by things such as running out of memory, and refuse to restart. In this case you should see a message in the log along the lines of: | |||||||
LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use:8080 | ||||||||
Changed: | ||||||||
< < | In this casHcss.[objectObject] you need tHcss.[objectObject] kill thHcss.[objectObject] process (look for catalina ) beforHcss.[objectObject] restarting iHcss.[objectObject]. | |||||||
> > | In this case you need to kill the process (look for catalina ) before restarting it. | |||||||
HCSS properties configuration | ||||||||
Changed: | ||||||||
< < | HerHcss.[objectObject] arHcss.[objectObject] guidelines for ensuring thaHcss.[objectObject] HCSS properties arHcss.[objectObject] seHcss.[objectObject] as you expecHcss.[objectObject]. | |||||||
> > | Here are guidelines for ensuring that HCSS properties are set as you expect. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < | NotHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject] user.props of thHcss.[objectObject] user owning thHcss.[objectObject] TomcaHcss.[objectObject] process will alsHcss.[objectObject] bHcss.[objectObject] read if iHcss.[objectObject] exists and with higher precedence. You mighHcss.[objectObject] noHcss.[objectObject] wanHcss.[objectObject] this. This is onHcss.[objectObject] reason for running thHcss.[objectObject] server from a dedicated accounHcss.[objectObject] rather than a standard user accounHcss.[objectObject]. | |||||||
> > | Note that the user.props of the user owning the Tomcat process will also be read if it exists and with higher precedence. You might not want this. This is one reason for running the server from a dedicated account rather than a standard user account. | |||||||
Changed: | ||||||||
< < | Trying iHcss.[objectObject] ouHcss.[objectObject] | |||||||
> > | Trying it out | |||||||
Changed: | ||||||||
< < | Following thHcss.[objectObject] instructions abovHcss.[objectObject] and starting TomcaHcss.[objectObject], wHcss.[objectObject] should now havHcss.[objectObject] a running PAL server with url http://whatever:8080/hcss/pal . Check thHcss.[objectObject] log for any initialisation errors. HerHcss.[objectObject] is an examplHcss.[objectObject] Jython scripHcss.[objectObject] for trying iHcss.[objectObject] ouHcss.[objectObject] on thHcss.[objectObject] clienHcss.[objectObject] sidHcss.[objectObject]: | |||||||
> > | Following the instructions above and starting Tomcat, we should now have a running PAL server with url http://whatever:8080/hcss/pal . Check the log for any initialisation errors. Here is an example Jython script for trying it out on the client side: | |||||||
from herschel.ia.pal.pool.http import HttpClientPool | ||||||||
Line: 151 to 151 | ||||||||
| ||||||||
Changed: | ||||||||
< < | This is all thaHcss.[objectObject] is necessary tHcss.[objectObject] updatHcss.[objectObject] tHcss.[objectObject] a new HCSS version: | |||||||
> > | This is all that is necessary to update to a new HCSS version: | |||||||
cd $CATALINA_HOME/webapps/hcss/WEB-INF/ | ||||||||
Line: 160 to 160 | ||||||||
cp <hcss-dir>/project.xml . | ||||||||
Changed: | ||||||||
< < | Then restarHcss.[objectObject] thHcss.[objectObject] server. | |||||||
> > | Then restart the server. | |||||||
Changed: | ||||||||
< < | If you geHcss.[objectObject] an error becausHcss.[objectObject] sun.grid/8.0.1/drmaa_8.0.1 is thHcss.[objectObject] wrong number of bytes then ediHcss.[objectObject] <hcss-dir>/installed.userlibraries, search for drmaa and deletHcss.[objectObject] thaHcss.[objectObject] linHcss.[objectObject]. This was a bug, fixed in 10.0.1423. | |||||||
> > | If you get an error because sun.grid/8.0.1/drmaa_8.0.1 is the wrong number of bytes then edit <hcss-dir>/installed.userlibraries, search for drmaa and delete that line. This was a bug and is fixed in 10.0.1423. | |||||||
Troubleshooting | ||||||||
Changed: | ||||||||
< < | IHcss.[objectObject] is importanHcss.[objectObject] tHcss.[objectObject] understand thaHcss.[objectObject] thHcss.[objectObject] TomcaHcss.[objectObject] scripts dHcss.[objectObject] noHcss.[objectObject] usHcss.[objectObject] thHcss.[objectObject] Java CLASSPATH environmenHcss.[objectObject] variablHcss.[objectObject]. All required resources musHcss.[objectObject] bHcss.[objectObject] presenHcss.[objectObject] in thHcss.[objectObject] classes or liHcss.[objectObject] directories. For full details read thHcss.[objectObject] section on "Classloading" in thHcss.[objectObject] TomcaHcss.[objectObject] documentation. | |||||||
> > | It is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | |||||||
Changed: | ||||||||
< < | ThHcss.[objectObject] firsHcss.[objectObject] rulHcss.[objectObject] of troubleshooting is tHcss.[objectObject] check thHcss.[objectObject] log filHcss.[objectObject]. ThHcss.[objectObject] principlHcss.[objectObject] TomcaHcss.[objectObject] log filHcss.[objectObject] is $CATALINA_HOME/logs/catalina.ouHcss.[objectObject] . With thHcss.[objectObject] logging configuration abovHcss.[objectObject], thHcss.[objectObject] HCSS applications will log tHcss.[objectObject] hcss.datHcss.[objectObject].log . Don'Hcss.[objectObject] forgeHcss.[objectObject] thaHcss.[objectObject] whaHcss.[objectObject] is written tHcss.[objectObject] thHcss.[objectObject] log can bHcss.[objectObject] configured as desired. | |||||||
> > | The first rule of troubleshooting is to check the log file. The principle Tomcat log file is $CATALINA_HOME/logs/catalina.out . With the logging configuration above, the HCSS applications will log to hcss.date.log . Don't forget that what is written to the log can be configured as desired. | |||||||
Changed: | ||||||||
< < | Sometimes therHcss.[objectObject] is nHcss.[objectObject] substitutHcss.[objectObject] for putting debugging statements in thHcss.[objectObject] codHcss.[objectObject]. You can dHcss.[objectObject] this by making modifications in a developer environmenHcss.[objectObject] as normal, and then copying thHcss.[objectObject] class filHcss.[objectObject](s) intHcss.[objectObject] thHcss.[objectObject] classes directory of thHcss.[objectObject] servleHcss.[objectObject]. For examplHcss.[objectObject]: | |||||||
> > | Sometimes there is no substitute for putting debugging statements in the code. You can do this by making modifications in a developer environment as normal, and then copying the class file(s) into the classes directory of the servlet. For example: | |||||||
cvs co ia_pal_pool_http_server edit HttpPoolServlet.java jake | ||||||||
Changed: | ||||||||
< < | Then copy thHcss.[objectObject] outpuHcss.[objectObject] HttpPoolServleHcss.[objectObject].class filHcss.[objectObject] tHcss.[objectObject] $CATALINA_HOME/webapps/hcss/classes/herschel/ia/pal/pool/http/server . | |||||||
> > | Then copy the output HttpPoolServlet.class file to $CATALINA_HOME/webapps/hcss/classes/herschel/ia/pal/pool/http/server . | |||||||
Changed: | ||||||||
< < | ![]() NoClassDefFoundError . ThHcss.[objectObject] class reported tHcss.[objectObject] bHcss.[objectObject] missing is noHcss.[objectObject] necessarily thHcss.[objectObject] onHcss.[objectObject] thaHcss.[objectObject] is. If you know iHcss.[objectObject]'s therHcss.[objectObject], follow thHcss.[objectObject] dependency trail from thHcss.[objectObject] reported class tHcss.[objectObject] look for something missing. Pay particular attention tHcss.[objectObject] whaHcss.[objectObject] is used in statiHcss.[objectObject] initialisation statements. | |||||||
> > | ![]() NoClassDefFoundError . The class reported to be missing is not necessarily the one that is. If you know it's there, follow the dependency trail from the reported class to look for something missing. Pay particular attention to what is used in static initialisation statements. | |||||||
Changed: | ||||||||
< < | Running on a privileged porHcss.[objectObject] | |||||||
> > | Running on a privileged port | |||||||
Changed: | ||||||||
< < | This is normally thHcss.[objectObject] standard HTTP porHcss.[objectObject] 80. ThHcss.[objectObject] porHcss.[objectObject] is seHcss.[objectObject] by editing thHcss.[objectObject] server.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. I was noHcss.[objectObject] ablHcss.[objectObject] tHcss.[objectObject] geHcss.[objectObject] thHcss.[objectObject] defaulHcss.[objectObject] TomcaHcss.[objectObject] startup scripHcss.[objectObject] tHcss.[objectObject] work when installed on this porHcss.[objectObject]. HerHcss.[objectObject] is my scripHcss.[objectObject]. | |||||||
> > | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. I was not able to get the default Tomcat startup script to work when installed on this port. Here is my script. | |||||||
Changed: | ||||||||
< < | This scripHcss.[objectObject] musHcss.[objectObject] bHcss.[objectObject] started with rooHcss.[objectObject] privilegHcss.[objectObject]. NotHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject] daemon still runs as a less privileged user. | |||||||
> > | This script must be started with root privilege. Note that the daemon still runs as a less privileged user. | |||||||
Changed: | ||||||||
< < | Further complications arisHcss.[objectObject] if therHcss.[objectObject] is a need tHcss.[objectObject] access thHcss.[objectObject] VersanHcss.[objectObject] library, as this accesses nativHcss.[objectObject] shared libraries, Hcss.[objectObject].g. for DbPool or thHcss.[objectObject] TM/data framHcss.[objectObject] server. WhilsHcss.[objectObject] thHcss.[objectObject] startup scripHcss.[objectObject] uses thHcss.[objectObject] java.library.path argumenHcss.[objectObject] tHcss.[objectObject] pass thHcss.[objectObject] location of thesHcss.[objectObject] libraries tHcss.[objectObject] thHcss.[objectObject] daemon process, this does noHcss.[objectObject] entirely work sincHcss.[objectObject] thHcss.[objectObject] firsHcss.[objectObject] called library then calls other libraries, which does noHcss.[objectObject] work sincHcss.[objectObject] thHcss.[objectObject] process does noHcss.[objectObject] inheriHcss.[objectObject] thHcss.[objectObject] valuHcss.[objectObject] of thHcss.[objectObject] LD_LIBRARY_PATH environmenHcss.[objectObject] variablHcss.[objectObject] (iHcss.[objectObject] defines its own). A workaround solution is tHcss.[objectObject] link tHcss.[objectObject] thHcss.[objectObject] required libraries from thHcss.[objectObject] Java installation, which is accessiblHcss.[objectObject], Hcss.[objectObject].g. | |||||||
> > | Further complications arise if there is a need to access the Versant library, as this accesses native shared libraries, e.g. for DbPool or the TM/data frame server. Whilst the startup script uses the java.library.path argument to pass the location of these libraries to the daemon process, this does not entirely work since the first called library then calls other libraries, which does not work since the process does not inherit the value of the LD_LIBRARY_PATH environment variable (it defines its own). A workaround solution is to link to the required libraries from the Java installation, which is accessible, e.g. | |||||||
cd $JAVA_HOME/jre/lib/amd64 | ||||||||
Line: 195 to 195 | ||||||||
ln -s $VERSANT_ROOT/lib/libxa.so libxa.so | ||||||||
Changed: | ||||||||
< < | NotHcss.[objectObject] thaHcss.[objectObject] this is only necessary sincHcss.[objectObject] thHcss.[objectObject] server is running as a daemon process in order tHcss.[objectObject] access thHcss.[objectObject] privileged porHcss.[objectObject] 80. TherHcss.[objectObject] may well bHcss.[objectObject] a better solution than this. | |||||||
> > | Note that this is only necessary since the server is running as a daemon process in order to access the privileged port 80. There may well be a better solution than this. | |||||||
Changed: | ||||||||
< < | Using thHcss.[objectObject] telemetry and data framHcss.[objectObject] server | |||||||
> > | Using the telemetry and data frame server | |||||||
Changed: | ||||||||
< < | PuHcss.[objectObject] thHcss.[objectObject] classes for thHcss.[objectObject] access_server modulHcss.[objectObject] in thHcss.[objectObject] hcss applications area, as for thHcss.[objectObject] PAL pool. | |||||||
> > | Put the classes for the access_server module in the hcss applications area, as for the PAL pool. | |||||||
Changed: | ||||||||
< < | Then add this servleHcss.[objectObject] definition tHcss.[objectObject] thHcss.[objectObject] weHcss.[objectObject].xml filHcss.[objectObject] in WEB-APPS . | |||||||
> > | Then add this servlet definition to the web.xml file in WEB-APPS . | |||||||
<servlet> <servlet-name>tm</servlet-name> | ||||||||
Line: 213 to 213 | ||||||||
</servlet-mapping> | ||||||||
Changed: | ||||||||
< < | This corresponds tHcss.[objectObject] thHcss.[objectObject] url http://whatever:8080/hcss/tm , assuming defaulHcss.[objectObject] settings. | |||||||
> > | This corresponds to the url http://whatever:8080/hcss/tm , assuming default settings. | |||||||
Changed: | ||||||||
< < | This servleHcss.[objectObject] has a featurHcss.[objectObject] tHcss.[objectObject] allow redirection of a databasHcss.[objectObject] requesHcss.[objectObject] tHcss.[objectObject] a specifiHcss.[objectObject] server. This is donHcss.[objectObject] by means of HCSS properties. (IHcss.[objectObject] mighHcss.[objectObject] bHcss.[objectObject] cleaner tHcss.[objectObject] redefinHcss.[objectObject] them as parameters specified in thHcss.[objectObject] weHcss.[objectObject].xml filHcss.[objectObject]). ThHcss.[objectObject] easiesHcss.[objectObject] way tHcss.[objectObject] seHcss.[objectObject] them is tHcss.[objectObject] puHcss.[objectObject] them in a HcssTmHttpServer.defaults filHcss.[objectObject] in thHcss.[objectObject] samHcss.[objectObject] directory as thHcss.[objectObject] corresponding class filHcss.[objectObject]. ThesHcss.[objectObject] arHcss.[objectObject]:
| |||||||
> > | This servlet has a feature to allow redirection of a database request to a specific server. This is done by means of HCSS properties. (It might be cleaner to redefine them as parameters specified in the web.xml file). The easiest way to set them is to put them in a HcssTmHttpServer.defaults file in the same directory as the corresponding class file. These are:
| |||||||
Changed: | ||||||||
< < | This property should alsHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject] on thHcss.[objectObject] server sidHcss.[objectObject]. This will bHcss.[objectObject] madHcss.[objectObject] thHcss.[objectObject] defaulHcss.[objectObject] for this application in thHcss.[objectObject] nexHcss.[objectObject] version of thHcss.[objectObject] modulHcss.[objectObject]. NotHcss.[objectObject] thaHcss.[objectObject] this valuHcss.[objectObject] is specifiHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] server and inappropriatHcss.[objectObject] for interactivHcss.[objectObject] use. | |||||||
> > | This property should also be set on the server side. This will be made the default for this application in the next version of the module. Note that this value is specific to the server and inappropriate for interactive use. | |||||||
hcss.access.store = herschel.access.db.SimpleStoreHandler | ||||||||
Changed: | ||||||||
< < | This servleHcss.[objectObject] is accessed by using thHcss.[objectObject] normal access API. ThesHcss.[objectObject] clienHcss.[objectObject]-sidHcss.[objectObject] properties need tHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject]: | |||||||
> > | This servlet is accessed by using the normal access API. These client-side properties need to be set: | |||||||
hcss.access.connection=herschel.access.net.NetworkConnection | ||||||||
Line: 232 to 232 | ||||||||
hcss.access.url=http://whatever:8080/hcss/tm | ||||||||
Changed: | ||||||||
< < | ConveniencHcss.[objectObject] methods tHcss.[objectObject] seHcss.[objectObject] thesHcss.[objectObject] properties dynamically arHcss.[objectObject] provided in thHcss.[objectObject] herschel.access.Access class. | |||||||
> > | Convenience methods to set these properties dynamically are provided in the herschel.access.Access class. | |||||||
Changed: | ||||||||
< < | Using TomcaHcss.[objectObject]'s Manager applicationThis is a very useful tool for monitoring, stopping and restarting applications. THcss.[objectObject] usHcss.[objectObject] iHcss.[objectObject] you havHcss.[objectObject] tHcss.[objectObject] givHcss.[objectObject] yourself privilegHcss.[objectObject]. Either:
| |||||||
> > | Using Tomcat's Manager applicationThis is a very useful tool for monitoring, stopping and restarting applications. To use it you have to give yourself privilege. Either:
| |||||||
Changed: | ||||||||
< < | Then gHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] "manager/html" weHcss.[objectObject] pagHcss.[objectObject] on your server. I found thaHcss.[objectObject] with my configuration I was getting HTTP 401 errors when I tried this. I goHcss.[objectObject] iHcss.[objectObject] tHcss.[objectObject] work by commenting ouHcss.[objectObject] thHcss.[objectObject] error-pagHcss.[objectObject] entry in thHcss.[objectObject] manager weHcss.[objectObject].xml filHcss.[objectObject]. | |||||||
> > | Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | |||||||
-- SteveGuest - 03 Aug 2012
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Deleted: | |||||||||||||
< < |
| ||||||||||||
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | |||||||||||||
Changed: | |||||||||||||
< < | These instructions have been updated for HCSS 7.0. | ||||||||||||
> > | These instructions have been updated for HCSS 9.0. | ||||||||||||
Installation | |||||||||||||
Changed: | |||||||||||||
< < | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | ||||||||||||
> > | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | ||||||||||||
Note that only one HTTP pool server is needed, regardless of the number of pools it accesses. | |||||||||||||
Line: 30 to 29 | |||||||||||||
There are several ways to set this up with Tomcat. I use the simplest, which is what is described here. Its main disadvantage is that it does not scale well to large numbers of users and major enterprise systems. See the Tomcat documentation for other possibilities. | |||||||||||||
Changed: | |||||||||||||
< < | Edit the server.xml file in the conf directory. Look for the Realm entry and specify digest as SHA . It should now look like this: | ||||||||||||
> > | EdiHcss.[objectObject] thHcss.[objectObject] server.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. Look for thHcss.[objectObject] Realm entry and specify digesHcss.[objectObject] as SHA . IHcss.[objectObject] should now look likHcss.[objectObject] this: | ||||||||||||
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest="SHA"/> | |||||||||||||
Changed: | |||||||||||||
< < | Edit the tomcat-users.xml file in the conf directory. Add some roles, like this: | ||||||||||||
> > | EdiHcss.[objectObject] thHcss.[objectObject] tomcaHcss.[objectObject]-users.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. Add somHcss.[objectObject] roles, likHcss.[objectObject] this: | ||||||||||||
<role rolename="spire_admin"/> <role rolename="spire_user"/> | |||||||||||||
Changed: | |||||||||||||
< < | You might want to leave the tomcat role as a placeholder for future general Tomcat admin. | ||||||||||||
> > | You mighHcss.[objectObject] wanHcss.[objectObject] tHcss.[objectObject] leavHcss.[objectObject] thHcss.[objectObject] tomcaHcss.[objectObject] rolHcss.[objectObject] as a placeholder for futurHcss.[objectObject] general TomcaHcss.[objectObject] admin. | ||||||||||||
Changed: | |||||||||||||
< < | This is how to add a user.
| ||||||||||||
> > | This is how tHcss.[objectObject] add a user.
| ||||||||||||
Changed: | |||||||||||||
< < | ![]() | ||||||||||||
> > | ![]() | ||||||||||||
Changed: | |||||||||||||
< < | Adding a servletServlets live inside thewebapps directory. Applications have their own area in this directory and run in a sandbox isolated from the others. Note that a single application area can contain any number of servlets. | ||||||||||||
> > | Adding a servleHcss.[objectObject]Servlets livHcss.[objectObject] insidHcss.[objectObject] thHcss.[objectObject]webapps directory. Applications havHcss.[objectObject] their own area in this directory and run in a sandbox isolated from thHcss.[objectObject] others. NotHcss.[objectObject] thaHcss.[objectObject] a singlHcss.[objectObject] application area can contain any number of servlets. | ||||||||||||
Changed: | |||||||||||||
< < | Now we go through how to set up an application called hcss . In the webapps directory, create a directory structure like this: | ||||||||||||
> > | Now wHcss.[objectObject] gHcss.[objectObject] through how tHcss.[objectObject] seHcss.[objectObject] up an application called hcss . In thHcss.[objectObject] webapps directory, creatHcss.[objectObject] a directory structurHcss.[objectObject] likHcss.[objectObject] this: | ||||||||||||
hcss - WEB-INF - lib - classes | |||||||||||||
Changed: | |||||||||||||
< < | The general idea is to put jar files in the lib directory and class files in classes. Everything you need should be in there. Don't assume that it will pick up your CLASSPATH environment variable - it won't. | ||||||||||||
> > | ThHcss.[objectObject] general idea is tHcss.[objectObject] puHcss.[objectObject] jar files in thHcss.[objectObject] liHcss.[objectObject] directory and class files in classes. Everything you need should bHcss.[objectObject] in therHcss.[objectObject]. Don'Hcss.[objectObject] assumHcss.[objectObject] thaHcss.[objectObject] iHcss.[objectObject] will pick up your CLASSPATH environmenHcss.[objectObject] variablHcss.[objectObject] - iHcss.[objectObject] won'Hcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | These libraries should be updated whenever a new version of the HCSS is deployed, although in practice it usually continues working anyway (except for schema evolutions which kill database accessing servlets). | ||||||||||||
> > | ThesHcss.[objectObject] libraries should bHcss.[objectObject] updated whenever a new version of thHcss.[objectObject] HCSS is deployed, although in practicHcss.[objectObject] iHcss.[objectObject] usually continues working anyway (excepHcss.[objectObject] for schema evolutions which kill databasHcss.[objectObject] accessing servlets). | ||||||||||||
Changed: | |||||||||||||
< < | It is also necessary to create the application configuration file web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat. | ||||||||||||
> > | IHcss.[objectObject] is alsHcss.[objectObject] necessary tHcss.[objectObject] creatHcss.[objectObject] thHcss.[objectObject] application configuration filHcss.[objectObject] weHcss.[objectObject].xml in WEB-INF . A version with a servleHcss.[objectObject] defined is in thHcss.[objectObject] nexHcss.[objectObject] section. You can alsHcss.[objectObject] look aHcss.[objectObject] thHcss.[objectObject] versions of this filHcss.[objectObject] in thHcss.[objectObject] other applications thaHcss.[objectObject] comHcss.[objectObject] preinstalled with TomcaHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | The HTTP pool servletMake sure that thehcss.services project of the CIB. is installed. This project contains these modules: | ||||||||||||
> > | ThHcss.[objectObject] HTTP pool servleHcss.[objectObject]MakHcss.[objectObject] surHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject]hcss.services projecHcss.[objectObject] of thHcss.[objectObject] CIB. is installed. This projecHcss.[objectObject] contains thesHcss.[objectObject] modules: | ||||||||||||
| |||||||||||||
Changed: | |||||||||||||
< < |
| ||||||||||||
> > |
| ||||||||||||
Changed: | |||||||||||||
< < | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose in the bin directory of your installed build. This program comes with the hcss.services project, which is included in the hcss project. The program is called copyBuildJars . It is used as follows: | ||||||||||||
> > | WhilHcss.[objectObject] thHcss.[objectObject] statiHcss.[objectObject] dependencies for thHcss.[objectObject] servlets can bHcss.[objectObject] identified - and this will work for thHcss.[objectObject] TM server - thHcss.[objectObject] runtimHcss.[objectObject] dependencies for thHcss.[objectObject] PAL HTTP pool cannoHcss.[objectObject]. IHcss.[objectObject] is thereforHcss.[objectObject] necessary tHcss.[objectObject] copy mosHcss.[objectObject] of thHcss.[objectObject] jar files intHcss.[objectObject] thHcss.[objectObject] servleHcss.[objectObject] directory. Fortunately a program is provided for this purposHcss.[objectObject] in thHcss.[objectObject] bin directory of your installed build. This program comes with thHcss.[objectObject] hcss.services projecHcss.[objectObject], which is included in thHcss.[objectObject] hcss projecHcss.[objectObject]. ThHcss.[objectObject] program is called copyBuildJars . IHcss.[objectObject] is used as follows: | ||||||||||||
rm $CATALINA_HOME/webapps/hcss/WEB-INF/lib/*.jar copyBuildJars $CATALINA_HOME/webapps/hcss/WEB-INF/lib | |||||||||||||
Changed: | |||||||||||||
< < | The servlet itself is in the ia_pal_pool_http_server jar file. | ||||||||||||
> > | ThHcss.[objectObject] servleHcss.[objectObject] itself is in thHcss.[objectObject] ia_pal_pool_http_server jar filHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | Now copy the project.xml file from the build directory into the WEB-INF directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (It doesn't work in v3.0, see HcssSpr:10188![]() | ||||||||||||
> > | Now copy thHcss.[objectObject] projecHcss.[objectObject].xml filHcss.[objectObject] from thHcss.[objectObject] build directory intHcss.[objectObject] thHcss.[objectObject] WEB-INF directory. ThHcss.[objectObject] property var.hcss.dir needs tHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] samHcss.[objectObject] directory. IHcss.[objectObject] can bHcss.[objectObject] seHcss.[objectObject] in CATALINA_OPTS , seHcss.[objectObject] examplHcss.[objectObject] abovHcss.[objectObject]. This is needed for thHcss.[objectObject] correcHcss.[objectObject] projecHcss.[objectObject] infHcss.[objectObject] tHcss.[objectObject] bHcss.[objectObject] passed from server tHcss.[objectObject] clienHcss.[objectObject]. (IHcss.[objectObject] doesn'Hcss.[objectObject] work in v3.0, seHcss.[objectObject] HcssSpr:10188![]() | ||||||||||||
Application configuration | |||||||||||||
Changed: | |||||||||||||
< < | ![]() web.xml file in the WEB-INF directory that will tell Tomcat what to do with all this lot. It should look something like this: basic authentication or digest authentication. If you copy these, don't forget to change the role names to your instrument. | ||||||||||||
> > | ![]() weHcss.[objectObject].xml filHcss.[objectObject] in thHcss.[objectObject] WEB-INF directory thaHcss.[objectObject] will tell TomcaHcss.[objectObject] whaHcss.[objectObject] tHcss.[objectObject] dHcss.[objectObject] with all this loHcss.[objectObject]. IHcss.[objectObject] should look something likHcss.[objectObject] this: [[http://herschel.esac.esa.int/twiki/pub/Public/HttpPool/basiHcss.[objectObject].xml][basiHcss.[objectObject] authentication]] or [[http://herschel.esac.esa.int/twiki/pub/Public/HttpPool/digesHcss.[objectObject].xml][digesHcss.[objectObject] authentication]]. If you copy thesHcss.[objectObject], don'Hcss.[objectObject] forgeHcss.[objectObject] tHcss.[objectObject] changHcss.[objectObject] thHcss.[objectObject] rolHcss.[objectObject] names tHcss.[objectObject] your instrumenHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | This example does two things in addition to defining the servlet:
| ||||||||||||
> > | This examplHcss.[objectObject] does twHcss.[objectObject] things in addition tHcss.[objectObject] defining thHcss.[objectObject] servleHcss.[objectObject]:
| ||||||||||||
Logging configuration | |||||||||||||
Changed: | |||||||||||||
< < | Tomcat will normally by default write log messages to catalina.out , but it is generally better for applications to write to their own logs. However the reinitialisation of Java logging performed by the Configuration class can interfere with Tomcat's logging and prevent it from working properly, see HcssScr:6672![]() | ||||||||||||
> > | TomcaHcss.[objectObject] will normally by defaulHcss.[objectObject] writHcss.[objectObject] log messages tHcss.[objectObject] catalina.ouHcss.[objectObject] , buHcss.[objectObject] iHcss.[objectObject] is generally better for applications tHcss.[objectObject] writHcss.[objectObject] tHcss.[objectObject] their own logs. However thHcss.[objectObject] reinitialisation of Java logging performed by thHcss.[objectObject] Configuration class can interferHcss.[objectObject] with TomcaHcss.[objectObject]'s logging and prevenHcss.[objectObject] iHcss.[objectObject] from working properly, seHcss.[objectObject] HcssScr:6672![]() | ||||||||||||
Changed: | |||||||||||||
< < | In the classes directory under hcss create a file called logging.properties like this: | ||||||||||||
> > | In thHcss.[objectObject] classes directory under hcss creatHcss.[objectObject] a filHcss.[objectObject] called logging.properties likHcss.[objectObject] this: | ||||||||||||
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler | |||||||||||||
Line: 111 to 110 | |||||||||||||
java.util.logging.ConsoleHandler.formatter = herschel.share.log.api.StandardFormatter | |||||||||||||
Changed: | |||||||||||||
< < | ![]() ![]() Configuration.class file. How to do this is explained in the Trouble Shooting section below. | ||||||||||||
> > | ![]() ![]() Configuration.class filHcss.[objectObject]. How tHcss.[objectObject] dHcss.[objectObject] this is explained in thHcss.[objectObject] TroublHcss.[objectObject] Shooting section below. | ||||||||||||
Changed: | |||||||||||||
< < | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPTS , as in the example setting of this variable above. | ||||||||||||
> > | ThHcss.[objectObject] system property hcss.iniHcss.[objectObject].logging should bHcss.[objectObject] seHcss.[objectObject] tHcss.[objectObject] falsHcss.[objectObject] . IHcss.[objectObject] will noHcss.[objectObject] work tHcss.[objectObject] add iHcss.[objectObject] user.props or any other HCSS property filHcss.[objectObject]! You can add iHcss.[objectObject] tHcss.[objectObject] CATALINA_OPTS , as in thHcss.[objectObject] examplHcss.[objectObject] setting of this variablHcss.[objectObject] abovHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | The hcss application area should now log to a file called hcss.date.log . | ||||||||||||
> > | ThHcss.[objectObject] hcss application area should now log tHcss.[objectObject] a filHcss.[objectObject] called hcss.datHcss.[objectObject].log . | ||||||||||||
Starting and stopping | |||||||||||||
Changed: | |||||||||||||
< < | The scripts can be found in Tomcat's bin directory. Use startup to start it, and shutdown to stop it. You may wish to check the catalina.out log to see if it started correctly. | ||||||||||||
> > | ThHcss.[objectObject] scripts can bHcss.[objectObject] found in TomcaHcss.[objectObject]'s bin directory. UsHcss.[objectObject] startup tHcss.[objectObject] starHcss.[objectObject] iHcss.[objectObject], and shutdown tHcss.[objectObject] stop iHcss.[objectObject]. You may wish tHcss.[objectObject] check thHcss.[objectObject] catalina.ouHcss.[objectObject] log tHcss.[objectObject] seHcss.[objectObject] if iHcss.[objectObject] started correctly. | ||||||||||||
Changed: | |||||||||||||
< < | Tomcat should automatically notice if a new servlet is defined and load it. You can force a servlet to reload by starting and stopping Tomcat. Wait a few seconds between stopping and starting or it might get confused (see next section). There is also a Tomcat "Manager" application that can do this from a web interface without stopping Tomcat - see the Tomcat documentation for details. | ||||||||||||
> > | TomcaHcss.[objectObject] should automatically noticHcss.[objectObject] if a new servleHcss.[objectObject] is defined and load iHcss.[objectObject]. You can forcHcss.[objectObject] a servleHcss.[objectObject] tHcss.[objectObject] reload by starting and stopping TomcaHcss.[objectObject]. WaiHcss.[objectObject] a few seconds between stopping and starting or iHcss.[objectObject] mighHcss.[objectObject] geHcss.[objectObject] confused (seHcss.[objectObject] nexHcss.[objectObject] section). TherHcss.[objectObject] is alsHcss.[objectObject] a TomcaHcss.[objectObject] "Manager" application thaHcss.[objectObject] can dHcss.[objectObject] this from a weHcss.[objectObject] interfacHcss.[objectObject] withouHcss.[objectObject] stopping TomcaHcss.[objectObject] - seHcss.[objectObject] thHcss.[objectObject] TomcaHcss.[objectObject] documentation for details. | ||||||||||||
Changed: | |||||||||||||
< < | Occasionally it can get in a mess, which can be caused by things such as running out of memory, and refuse to restart. In this case you should see a message in the log along the lines of: | ||||||||||||
> > | Occasionally iHcss.[objectObject] can geHcss.[objectObject] in a mess, which can bHcss.[objectObject] caused by things such as running ouHcss.[objectObject] of memory, and refusHcss.[objectObject] tHcss.[objectObject] restarHcss.[objectObject]. In this casHcss.[objectObject] you should seHcss.[objectObject] a messagHcss.[objectObject] in thHcss.[objectObject] log along thHcss.[objectObject] lines of: | ||||||||||||
LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use:8080 | |||||||||||||
Changed: | |||||||||||||
< < | In this case you need to kill the process (look for catalina ) before restarting it. | ||||||||||||
> > | In this casHcss.[objectObject] you need tHcss.[objectObject] kill thHcss.[objectObject] process (look for catalina ) beforHcss.[objectObject] restarting iHcss.[objectObject]. | ||||||||||||
HCSS properties configuration | |||||||||||||
Changed: | |||||||||||||
< < | Here are guidelines for ensuring that HCSS properties are set as you expect. | ||||||||||||
> > | HerHcss.[objectObject] arHcss.[objectObject] guidelines for ensuring thaHcss.[objectObject] HCSS properties arHcss.[objectObject] seHcss.[objectObject] as you expecHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < |
| ||||||||||||
> > |
| ||||||||||||
Changed: | |||||||||||||
< < | Note that the user.props of the user owning the Tomcat process will also be read if it exists and with higher precedence. You might not want this. This is one reason for running the server from a dedicated account rather than a standard user account. | ||||||||||||
> > | NotHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject] user.props of thHcss.[objectObject] user owning thHcss.[objectObject] TomcaHcss.[objectObject] process will alsHcss.[objectObject] bHcss.[objectObject] read if iHcss.[objectObject] exists and with higher precedence. You mighHcss.[objectObject] noHcss.[objectObject] wanHcss.[objectObject] this. This is onHcss.[objectObject] reason for running thHcss.[objectObject] server from a dedicated accounHcss.[objectObject] rather than a standard user accounHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | Trying it out | ||||||||||||
> > | Trying iHcss.[objectObject] ouHcss.[objectObject] | ||||||||||||
Changed: | |||||||||||||
< < | Following the instructions above and starting Tomcat, we should now have a running PAL server with url http://whatever:8080/hcss/pal . Check the log for any initialisation errors. Here is an example Jython script for trying it out on the client side: | ||||||||||||
> > | Following thHcss.[objectObject] instructions abovHcss.[objectObject] and starting TomcaHcss.[objectObject], wHcss.[objectObject] should now havHcss.[objectObject] a running PAL server with url http://whatever:8080/hcss/pal . Check thHcss.[objectObject] log for any initialisation errors. HerHcss.[objectObject] is an examplHcss.[objectObject] Jython scripHcss.[objectObject] for trying iHcss.[objectObject] ouHcss.[objectObject] on thHcss.[objectObject] clienHcss.[objectObject] sidHcss.[objectObject]: | ||||||||||||
from herschel.ia.pal.pool.http import HttpClientPool | |||||||||||||
Line: 152 to 151 | |||||||||||||
| |||||||||||||
Changed: | |||||||||||||
< < | This is all that is necessary to update to a new HCSS version: | ||||||||||||
> > | This is all thaHcss.[objectObject] is necessary tHcss.[objectObject] updatHcss.[objectObject] tHcss.[objectObject] a new HCSS version: | ||||||||||||
cd $CATALINA_HOME/webapps/hcss/WEB-INF/ | |||||||||||||
Line: 161 to 160 | |||||||||||||
cp <hcss-dir>/project.xml . | |||||||||||||
Changed: | |||||||||||||
< < | Then restart the server. | ||||||||||||
> > | Then restarHcss.[objectObject] thHcss.[objectObject] server. | ||||||||||||
Changed: | |||||||||||||
< < | If you get an error because sun.grid/8.0.1/drmaa_8.0.1 is the wrong number of bytes then edit <hcss-dir>/installed.userlibraries, search for drmaa and delete that line. | ||||||||||||
> > | If you geHcss.[objectObject] an error becausHcss.[objectObject] sun.grid/8.0.1/drmaa_8.0.1 is thHcss.[objectObject] wrong number of bytes then ediHcss.[objectObject] <hcss-dir>/installed.userlibraries, search for drmaa and deletHcss.[objectObject] thaHcss.[objectObject] linHcss.[objectObject]. This was a bug, fixed in 10.0.1423. | ||||||||||||
Troubleshooting | |||||||||||||
Changed: | |||||||||||||
< < | It is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||||||
> > | IHcss.[objectObject] is importanHcss.[objectObject] tHcss.[objectObject] understand thaHcss.[objectObject] thHcss.[objectObject] TomcaHcss.[objectObject] scripts dHcss.[objectObject] noHcss.[objectObject] usHcss.[objectObject] thHcss.[objectObject] Java CLASSPATH environmenHcss.[objectObject] variablHcss.[objectObject]. All required resources musHcss.[objectObject] bHcss.[objectObject] presenHcss.[objectObject] in thHcss.[objectObject] classes or liHcss.[objectObject] directories. For full details read thHcss.[objectObject] section on "Classloading" in thHcss.[objectObject] TomcaHcss.[objectObject] documentation. | ||||||||||||
Changed: | |||||||||||||
< < | The first rule of troubleshooting is to check the log file. The principle Tomcat log file is $CATALINA_HOME/logs/catalina.out . With the logging configuration above, the HCSS applications will log to hcss.date.log . Don't forget that what is written to the log can be configured as desired. | ||||||||||||
> > | ThHcss.[objectObject] firsHcss.[objectObject] rulHcss.[objectObject] of troubleshooting is tHcss.[objectObject] check thHcss.[objectObject] log filHcss.[objectObject]. ThHcss.[objectObject] principlHcss.[objectObject] TomcaHcss.[objectObject] log filHcss.[objectObject] is $CATALINA_HOME/logs/catalina.ouHcss.[objectObject] . With thHcss.[objectObject] logging configuration abovHcss.[objectObject], thHcss.[objectObject] HCSS applications will log tHcss.[objectObject] hcss.datHcss.[objectObject].log . Don'Hcss.[objectObject] forgeHcss.[objectObject] thaHcss.[objectObject] whaHcss.[objectObject] is written tHcss.[objectObject] thHcss.[objectObject] log can bHcss.[objectObject] configured as desired. | ||||||||||||
Changed: | |||||||||||||
< < | Sometimes there is no substitute for putting debugging statements in the code. You can do this by making modifications in a developer environment as normal, and then copying the class file(s) into the classes directory of the servlet. For example: | ||||||||||||
> > | Sometimes therHcss.[objectObject] is nHcss.[objectObject] substitutHcss.[objectObject] for putting debugging statements in thHcss.[objectObject] codHcss.[objectObject]. You can dHcss.[objectObject] this by making modifications in a developer environmenHcss.[objectObject] as normal, and then copying thHcss.[objectObject] class filHcss.[objectObject](s) intHcss.[objectObject] thHcss.[objectObject] classes directory of thHcss.[objectObject] servleHcss.[objectObject]. For examplHcss.[objectObject]: | ||||||||||||
cvs co ia_pal_pool_http_server edit HttpPoolServlet.java jake | |||||||||||||
Changed: | |||||||||||||
< < | Then copy the output HttpPoolServlet.class file to $CATALINA_HOME/webapps/hcss/classes/herschel/ia/pal/pool/http/server . | ||||||||||||
> > | Then copy thHcss.[objectObject] outpuHcss.[objectObject] HttpPoolServleHcss.[objectObject].class filHcss.[objectObject] tHcss.[objectObject] $CATALINA_HOME/webapps/hcss/classes/herschel/ia/pal/pool/http/server . | ||||||||||||
Changed: | |||||||||||||
< < | ![]() NoClassDefFoundError . The class reported to be missing is not necessarily the one that is. If you know it's there, follow the dependency trail from the reported class to look for something missing. Pay particular attention to what is used in static initialisation statements. | ||||||||||||
> > | ![]() NoClassDefFoundError . ThHcss.[objectObject] class reported tHcss.[objectObject] bHcss.[objectObject] missing is noHcss.[objectObject] necessarily thHcss.[objectObject] onHcss.[objectObject] thaHcss.[objectObject] is. If you know iHcss.[objectObject]'s therHcss.[objectObject], follow thHcss.[objectObject] dependency trail from thHcss.[objectObject] reported class tHcss.[objectObject] look for something missing. Pay particular attention tHcss.[objectObject] whaHcss.[objectObject] is used in statiHcss.[objectObject] initialisation statements. | ||||||||||||
Changed: | |||||||||||||
< < | Running on a privileged port | ||||||||||||
> > | Running on a privileged porHcss.[objectObject] | ||||||||||||
Changed: | |||||||||||||
< < | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. I was not able to get the default Tomcat startup script to work when installed on this port. Here is my script. | ||||||||||||
> > | This is normally thHcss.[objectObject] standard HTTP porHcss.[objectObject] 80. ThHcss.[objectObject] porHcss.[objectObject] is seHcss.[objectObject] by editing thHcss.[objectObject] server.xml filHcss.[objectObject] in thHcss.[objectObject] conf directory. I was noHcss.[objectObject] ablHcss.[objectObject] tHcss.[objectObject] geHcss.[objectObject] thHcss.[objectObject] defaulHcss.[objectObject] TomcaHcss.[objectObject] startup scripHcss.[objectObject] tHcss.[objectObject] work when installed on this porHcss.[objectObject]. HerHcss.[objectObject] is my scripHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | This script must be started with root privilege. Note that the daemon still runs as a less privileged user. | ||||||||||||
> > | This scripHcss.[objectObject] musHcss.[objectObject] bHcss.[objectObject] started with rooHcss.[objectObject] privilegHcss.[objectObject]. NotHcss.[objectObject] thaHcss.[objectObject] thHcss.[objectObject] daemon still runs as a less privileged user. | ||||||||||||
Changed: | |||||||||||||
< < | Further complications arise if there is a need to access the Versant library, as this accesses native shared libraries, e.g. for DbPool or the TM/data frame server. Whilst the startup script uses the java.library.path argument to pass the location of these libraries to the daemon process, this does not entirely work since the first called library then calls other libraries, which does not work since the process does not inherit the value of the LD_LIBRARY_PATH environment variable (it defines its own). A workaround solution is to link to the required libraries from the Java installation, which is accessible, e.g. | ||||||||||||
> > | Further complications arisHcss.[objectObject] if therHcss.[objectObject] is a need tHcss.[objectObject] access thHcss.[objectObject] VersanHcss.[objectObject] library, as this accesses nativHcss.[objectObject] shared libraries, Hcss.[objectObject].g. for DbPool or thHcss.[objectObject] TM/data framHcss.[objectObject] server. WhilsHcss.[objectObject] thHcss.[objectObject] startup scripHcss.[objectObject] uses thHcss.[objectObject] java.library.path argumenHcss.[objectObject] tHcss.[objectObject] pass thHcss.[objectObject] location of thesHcss.[objectObject] libraries tHcss.[objectObject] thHcss.[objectObject] daemon process, this does noHcss.[objectObject] entirely work sincHcss.[objectObject] thHcss.[objectObject] firsHcss.[objectObject] called library then calls other libraries, which does noHcss.[objectObject] work sincHcss.[objectObject] thHcss.[objectObject] process does noHcss.[objectObject] inheriHcss.[objectObject] thHcss.[objectObject] valuHcss.[objectObject] of thHcss.[objectObject] LD_LIBRARY_PATH environmenHcss.[objectObject] variablHcss.[objectObject] (iHcss.[objectObject] defines its own). A workaround solution is tHcss.[objectObject] link tHcss.[objectObject] thHcss.[objectObject] required libraries from thHcss.[objectObject] Java installation, which is accessiblHcss.[objectObject], Hcss.[objectObject].g. | ||||||||||||
cd $JAVA_HOME/jre/lib/amd64 | |||||||||||||
Line: 196 to 195 | |||||||||||||
ln -s $VERSANT_ROOT/lib/libxa.so libxa.so | |||||||||||||
Changed: | |||||||||||||
< < | Note that this is only necessary since the server is running as a daemon process in order to access the privileged port 80. There may well be a better solution than this. | ||||||||||||
> > | NotHcss.[objectObject] thaHcss.[objectObject] this is only necessary sincHcss.[objectObject] thHcss.[objectObject] server is running as a daemon process in order tHcss.[objectObject] access thHcss.[objectObject] privileged porHcss.[objectObject] 80. TherHcss.[objectObject] may well bHcss.[objectObject] a better solution than this. | ||||||||||||
Changed: | |||||||||||||
< < | Using the telemetry and data frame server | ||||||||||||
> > | Using thHcss.[objectObject] telemetry and data framHcss.[objectObject] server | ||||||||||||
Changed: | |||||||||||||
< < | Put the classes for the access_server module in the hcss applications area, as for the PAL pool. | ||||||||||||
> > | PuHcss.[objectObject] thHcss.[objectObject] classes for thHcss.[objectObject] access_server modulHcss.[objectObject] in thHcss.[objectObject] hcss applications area, as for thHcss.[objectObject] PAL pool. | ||||||||||||
Changed: | |||||||||||||
< < | Then add this servlet definition to the web.xml file in WEB-APPS . | ||||||||||||
> > | Then add this servleHcss.[objectObject] definition tHcss.[objectObject] thHcss.[objectObject] weHcss.[objectObject].xml filHcss.[objectObject] in WEB-APPS . | ||||||||||||
<servlet> <servlet-name>tm</servlet-name> | |||||||||||||
Line: 214 to 213 | |||||||||||||
</servlet-mapping> | |||||||||||||
Changed: | |||||||||||||
< < | This corresponds to the url http://whatever:8080/hcss/tm , assuming default settings. | ||||||||||||
> > | This corresponds tHcss.[objectObject] thHcss.[objectObject] url http://whatever:8080/hcss/tm , assuming defaulHcss.[objectObject] settings. | ||||||||||||
Changed: | |||||||||||||
< < | This servlet has a feature to allow redirection of a database request to a specific server. This is done by means of HCSS properties. (It might be cleaner to redefine them as parameters specified in the web.xml file). The easiest way to set them is to put them in a HcssTmHttpServer.defaults file in the same directory as the corresponding class file. These are:
| ||||||||||||
> > | This servleHcss.[objectObject] has a featurHcss.[objectObject] tHcss.[objectObject] allow redirection of a databasHcss.[objectObject] requesHcss.[objectObject] tHcss.[objectObject] a specifiHcss.[objectObject] server. This is donHcss.[objectObject] by means of HCSS properties. (IHcss.[objectObject] mighHcss.[objectObject] bHcss.[objectObject] cleaner tHcss.[objectObject] redefinHcss.[objectObject] them as parameters specified in thHcss.[objectObject] weHcss.[objectObject].xml filHcss.[objectObject]). ThHcss.[objectObject] easiesHcss.[objectObject] way tHcss.[objectObject] seHcss.[objectObject] them is tHcss.[objectObject] puHcss.[objectObject] them in a HcssTmHttpServer.defaults filHcss.[objectObject] in thHcss.[objectObject] samHcss.[objectObject] directory as thHcss.[objectObject] corresponding class filHcss.[objectObject]. ThesHcss.[objectObject] arHcss.[objectObject]:
| ||||||||||||
Changed: | |||||||||||||
< < | This property should also be set on the server side. This will be made the default for this application in the next version of the module. Note that this value is specific to the server and inappropriate for interactive use. | ||||||||||||
> > | This property should alsHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject] on thHcss.[objectObject] server sidHcss.[objectObject]. This will bHcss.[objectObject] madHcss.[objectObject] thHcss.[objectObject] defaulHcss.[objectObject] for this application in thHcss.[objectObject] nexHcss.[objectObject] version of thHcss.[objectObject] modulHcss.[objectObject]. NotHcss.[objectObject] thaHcss.[objectObject] this valuHcss.[objectObject] is specifiHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] server and inappropriatHcss.[objectObject] for interactivHcss.[objectObject] use. | ||||||||||||
hcss.access.store = herschel.access.db.SimpleStoreHandler | |||||||||||||
Changed: | |||||||||||||
< < | This servlet is accessed by using the normal access API. These client-side properties need to be set: | ||||||||||||
> > | This servleHcss.[objectObject] is accessed by using thHcss.[objectObject] normal access API. ThesHcss.[objectObject] clienHcss.[objectObject]-sidHcss.[objectObject] properties need tHcss.[objectObject] bHcss.[objectObject] seHcss.[objectObject]: | ||||||||||||
hcss.access.connection=herschel.access.net.NetworkConnection | |||||||||||||
Line: 233 to 232 | |||||||||||||
hcss.access.url=http://whatever:8080/hcss/tm | |||||||||||||
Changed: | |||||||||||||
< < | Convenience methods to set these properties dynamically are provided in the herschel.access.Access class. | ||||||||||||
> > | ConveniencHcss.[objectObject] methods tHcss.[objectObject] seHcss.[objectObject] thesHcss.[objectObject] properties dynamically arHcss.[objectObject] provided in thHcss.[objectObject] herschel.access.Access class. | ||||||||||||
Changed: | |||||||||||||
< < | Using Tomcat's Manager applicationThis is a very useful tool for monitoring, stopping and restarting applications. To use it you have to give yourself privilege. Either:
| ||||||||||||
> > | Using TomcaHcss.[objectObject]'s Manager applicationThis is a very useful tool for monitoring, stopping and restarting applications. THcss.[objectObject] usHcss.[objectObject] iHcss.[objectObject] you havHcss.[objectObject] tHcss.[objectObject] givHcss.[objectObject] yourself privilegHcss.[objectObject]. Either:
| ||||||||||||
Changed: | |||||||||||||
< < | Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | ||||||||||||
> > | Then gHcss.[objectObject] tHcss.[objectObject] thHcss.[objectObject] "manager/html" weHcss.[objectObject] pagHcss.[objectObject] on your server. I found thaHcss.[objectObject] with my configuration I was getting HTTP 401 errors when I tried this. I goHcss.[objectObject] iHcss.[objectObject] tHcss.[objectObject] work by commenting ouHcss.[objectObject] thHcss.[objectObject] error-pagHcss.[objectObject] entry in thHcss.[objectObject] manager weHcss.[objectObject].xml filHcss.[objectObject]. | ||||||||||||
Changed: | |||||||||||||
< < | -- SteveGuest - 29 Mar 2011 | ||||||||||||
> > | -- SteveGuest - 03 Aug 2012 | ||||||||||||
Changed: | |||||||||||||
< < |
| ||||||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 163 to 163 | ||||||||
Then restart the server. | ||||||||
Added: | ||||||||
> > | If you get an error because sun.grid/8.0.1/drmaa_8.0.1 is the wrong number of bytes then edit <hcss-dir>/installed.userlibraries, search for drmaa and delete that line. | |||||||
TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Line: 244 to 246 | ||||||||
-- SteveGuest - 29 Mar 2011
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 83 to 83 | ||||||||
Application configuration | ||||||||
Changed: | ||||||||
< < | ![]() web.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this: basic authentication or digest authentication. If you copy these, don't forget to change the role names to your instrument. | |||||||
> > | ![]() web.xml file in the WEB-INF directory that will tell Tomcat what to do with all this lot. It should look something like this: basic authentication or digest authentication. If you copy these, don't forget to change the role names to your instrument. | |||||||
This example does two things in addition to defining the servlet:
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 83 to 83 | ||||||||
Application configuration | ||||||||
Changed: | ||||||||
< < | Now create the web.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this (you can paste this directly, but don't forget to change the role names to your instrument):
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> <display-name>HCSS applications</display-name> <description> Servlets that use the HCSS. </description> <filter> <filter-name>GzipFilter</filter-name> <filter-class>herschel.ia.server.util.GzipFilter</filter-class> </filter> <filter-mapping> <filter-name>GzipFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>pal</servlet-name> <servlet-class>herschel.ia.pal.pool.http.server.HttpPoolServlet</servlet-class> <init-param> <param-name>allowLoadAccess</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>allowSaveAccess</param-name> <param-value>false</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>pal</servlet-name> <url-pattern>/pal</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> </web-resource-collection> <auth-constraint> <!-- Anyone with one of the listed roles may access this area --> <role-name>spire_user</role-name> <role-name>spire_admin</role-name> </auth-constraint> </security-constraint> <!-- Default login configuration --> <login-config> <auth-method>BASIC</auth-method> </login-config> <!-- Security roles referenced by this web application --> <security-role> <role-name>spire_user</role-name> <role-name>spire_admin</role-name> </security-role> </web-app> | |||||||
> > | ![]() web.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this: basic authentication or digest authentication. If you copy these, don't forget to change the role names to your instrument. | |||||||
This example does two things in addition to defining the servlet:
| ||||||||
Line: 215 to 150 | ||||||||
r = st.select (Query (ObservationContext, "1")) | ||||||||
Added: | ||||||||
> > |
This is all that is necessary to update to a new HCSS version:
| |||||||
TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Line: 295 to 243 | ||||||||
-- SteveGuest - 29 Mar 2011 | ||||||||
Deleted: | ||||||||
< < | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | ||||||||
Changed: | ||||||||
< < | These instructions have been updated for HCSS 4.0. | |||||||
> > | These instructions have been updated for HCSS 7.0. | |||||||
Installation | ||||||||
Line: 48 to 48 | ||||||||
| ||||||||
Added: | ||||||||
> > | ![]() | |||||||
Adding a servletServlets live inside thewebapps directory. Applications have their own area in this directory and run in a sandbox isolated from the others. Note that a single application area can contain any number of servlets. | ||||||||
Line: 291 to 293 | ||||||||
Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | ||||||||
Changed: | ||||||||
< < | -- SteveGuest - 26 Apr 2010 | |||||||
> > | -- SteveGuest - 29 Mar 2011 | |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | ||||||||
Changed: | ||||||||
< < | These instructions have been updated for HCSS 3.0. | |||||||
> > | These instructions have been updated for HCSS 4.0. | |||||||
Installation | ||||||||
Line: 15 to 15 | ||||||||
There is no need to install Tomcat in a privileged account, and probably good security reasons for not doing so. Set the environment variable CATALINA_HOME to point to the directory where it is installed. You can also use the CATALINA_OPTS variable to set JVM options and HCSS configuration as explained later. This should be used to increase the available memory. My settings look like this:
CATALINA_HOME=/home/spire/hcssbld/tomcat | ||||||||
Changed: | ||||||||
< < | CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false -Dvar.hcss.dir=$CATALINA_HOME/webapps/hcss/WEB-INF/lib" | |||||||
> > | CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false -Dvar.hcss.dir=$CATALINA_HOME/webapps/hcss/WEB-INF" | |||||||
Changed: | ||||||||
< < | Note: Because startup script of tomcat will call another script to launch tomcat jvm, you must export the environment variable with export command. | |||||||
> > | Note: Because the startup script of tomcat will call another script to launch the tomcat jvm, you must export the environment variable with the export command (or other shell equivalent). | |||||||
The global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below. | ||||||||
Line: 77 to 77 | ||||||||
The servlet itself is in the ia_pal_pool_http_server jar file. | ||||||||
Changed: | ||||||||
< < | Now copy the project.xml file from the build directory into the same lib directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (It doesn't work in v3.0, see HcssSpr:10188![]() | |||||||
> > | Now copy the project.xml file from the build directory into the WEB-INF directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (It doesn't work in v3.0, see HcssSpr:10188![]() | |||||||
Application configuration | ||||||||
Line: 193 to 193 | ||||||||
HCSS properties configuration | ||||||||
Changed: | ||||||||
< < | Follow the steps below to set HCSS properties:
| |||||||
> > | Here are guidelines for ensuring that HCSS properties are set as you expect. | |||||||
Added: | ||||||||
> > |
user.props of the user owning the Tomcat process will also be read if it exists and with higher precedence. You might not want this. This is one reason for running the server from a dedicated account rather than a standard user account. | |||||||
Trying it out |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 70 to 70 | ||||||||
While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose in the bin directory of your installed build. This program comes with the hcss.services project, which is included in the hcss project. The program is called copyBuildJars . It is used as follows: | ||||||||
Changed: | ||||||||
< < | rm $CATALINA_HOME/webapps/hcss/lib/*.jar copyBuildJars $CATALINA_HOME/webapps/hcss/lib | |||||||
> > | rm $CATALINA_HOME/webapps/hcss/WEB-INF/lib/*.jar copyBuildJars $CATALINA_HOME/webapps/hcss/WEB-INF/lib | |||||||
The servlet itself is in the ia_pal_pool_http_server jar file. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 75 to 75 | ||||||||
The servlet itself is in the ia_pal_pool_http_server jar file. | ||||||||
Changed: | ||||||||
< < | Now copy the project.xml file from the build directory into the same lib directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (Except it doesn't currently work, see HcssSpr:10188![]() | |||||||
> > | Now copy the project.xml file from the build directory into the same lib directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (It doesn't work in v3.0, see HcssSpr:10188![]() | |||||||
Application configuration |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 67 to 67 | ||||||||
| ||||||||
Changed: | ||||||||
< < | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose. | |||||||
> > | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose in the bin directory of your installed build. This program comes with the hcss.services project, which is included in the hcss project. The program is called copyBuildJars . It is used as follows: | |||||||
rm $CATALINA_HOME/webapps/hcss/lib/*.jar copyBuildJars $CATALINA_HOME/webapps/hcss/lib |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 12 to 12 | ||||||||
Note that only one HTTP pool server is needed, regardless of the number of pools it accesses. | ||||||||
Changed: | ||||||||
< < | There is no need to install Tomcat in a privileged account, and probably good security reasons for not doing so. Set the environment variable CATALINA_HOME to point to the directory where it is installed. You can also use the CATALINA_OPTS variable to set JVM options. This should be used to increase the available memory. My settings look like this: | |||||||
> > | There is no need to install Tomcat in a privileged account, and probably good security reasons for not doing so. Set the environment variable CATALINA_HOME to point to the directory where it is installed. You can also use the CATALINA_OPTS variable to set JVM options and HCSS configuration as explained later. This should be used to increase the available memory. My settings look like this: | |||||||
CATALINA_HOME=/home/spire/hcssbld/tomcat | ||||||||
Changed: | ||||||||
< < | CATALINA_OPTS="-server -Xmx4096m" | |||||||
> > | CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false -Dvar.hcss.dir=$CATALINA_HOME/webapps/hcss/WEB-INF/lib" | |||||||
The global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below. | ||||||||
Line: 74 to 74 | ||||||||
The servlet itself is in the ia_pal_pool_http_server jar file. | ||||||||
Added: | ||||||||
> > | Now copy the project.xml file from the build directory into the same lib directory. The property var.hcss.dir needs to be set to the same directory. It can be set in CATALINA_OPTS , see example above. This is needed for the correct project info to be passed from server to client. (Except it doesn't currently work, see HcssSpr:10188![]() | |||||||
Application configurationNow create theweb.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this (you can paste this directly, but don't forget to change the role names to your instrument): | ||||||||
Line: 171 to 173 | ||||||||
![]() ![]() Configuration.class file. How to do this is explained in the Trouble Shooting section below. | ||||||||
Changed: | ||||||||
< < | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPTS , which now looks something like this:
CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false" | |||||||
> > | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPTS , as in the example setting of this variable above. | |||||||
The hcss application area should now log to a file called hcss.date.log . |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 69 to 69 | ||||||||
While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose. | ||||||||
Added: | ||||||||
> > | rm $CATALINA_HOME/webapps/hcss/lib/*.jar | |||||||
copyBuildJars $CATALINA_HOME/webapps/hcss/lib
The servlet itself is in the ia_pal_pool_http_server jar file. | ||||||||
Line: 170 to 171 | ||||||||
![]() ![]() Configuration.class file. How to do this is explained in the Trouble Shooting section below. | ||||||||
Changed: | ||||||||
< < | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPS , which now looks something like this: | |||||||
> > | The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPTS , which now looks something like this: | |||||||
CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false" |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http PoolThis page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | ||||||||
Added: | ||||||||
> > | These instructions have been updated for HCSS 3.0. | |||||||
Installation | ||||||||
Changed: | ||||||||
< < | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | |||||||
> > | The server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() | |||||||
Note that only one HTTP pool server is needed, regardless of the number of pools it accesses.
There is no need to install Tomcat in a privileged account, and probably good security reasons for not doing so. Set the environment variable CATALINA_HOME to point to the directory where it is installed. You can also use the CATALINA_OPTS variable to set JVM options. This should be used to increase the available memory. My settings look like this:
CATALINA_HOME=/home/spire/hcssbld/tomcat | ||||||||
Changed: | ||||||||
< < | CATALINA_OPTS=-server -Xmx4096m | |||||||
> > | CATALINA_OPTS="-server -Xmx4096m" | |||||||
The global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below. | ||||||||
Line: 59 to 61 | ||||||||
It is also necessary to create the application configuration file web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat. | ||||||||
Changed: | ||||||||
< < | "Old/new" style configurationCopy these libraries into thelib directory:
hcssExtLibs library, it is necessary to work around HcssSpr:5410![]()
CIB ConfigurationWhile the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. This script can be used to copy the jar files from the CIB repository. It copies more libraries than is necessary, but it is difficult to know what can safely be left out. This method can still be plagued by the dreadedNoClassDefFoundError . The class reported to be missing is not necessarily the one that is. If you know it's there, follow the dependency trail from the reported class to look for something missing. Pay particular attention to what is used in static initialisation statements.
Adding the Http pool servletThe servlet classes are contained in thehcss.services project of the CIB. It contains these modules: | |||||||
> > | The HTTP pool servletMake sure that thehcss.services project of the CIB. is installed. This project contains these modules: | |||||||
| ||||||||
Changed: | ||||||||
< < | These can be installed by either checking them out from CVS and compiling them, or using the CIB installer and extracting the jar files (see above).
CVS methodThis is not necesssary with the CIB setup as the jar files are already installed. However, this can be useful for debugging. This method is a little messy, but does have the advantage that it leaves you with an already set up developer environment, which is useful for troubleshooting. From theclasses directory, get the source code and put it in the right place, e.g.
cvs export -r D_IA_SERVER_UTIL_0_2 develop/main/herschel/ia/server/util cp -r develop/main/herschel/ia/server herschel/iaNow do the same for the ia_pal_pool_http_server module, e.g. | |||||||
> > | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. It is therefore necessary to copy most of the jar files into the servlet directory. Fortunately a program is provided for this purpose. | |||||||
Changed: | ||||||||
< < | cvs export -r D_IA_PAL_POOL_HTTP_SERVER_0_2 develop/main/herschel/ia/pal/pool/http/server mv develop/main/herschel/ia/pal herschel/ia | |||||||
> > | copyBuildJars $CATALINA_HOME/webapps/hcss/lib | |||||||
Changed: | ||||||||
< < |
Then compile the source code (javac will do). The source files can be left there and as an aid to debugging, although Tomcat won't look at them. | |||||||
> > | The servlet itself is in the ia_pal_pool_http_server jar file. | |||||||
Application configuration | ||||||||
Line: 185 to 146 | ||||||||
| ||||||||
Deleted: | ||||||||
< < | HCSS configurationThe steps in this section are no longer necessary. This section should be removed if no longer useful. The complication was due to the Jython intrepreter (used by the Http pool) being loaded from the classpath. Now Tomcat uses custom class loaders and clears the class path, so that didn't work. The servlet now specifically inserts the libraries (from the Tomcat location) into the class path before initialising the interpreter. Thehcss.ia.io.fits.handle_missing_classes property is now set automatically on servlet startup.
These properties should be set for the PAL server to work correctly. You can put them in ~.hcss/user.props . The ${var.hcss.dir} must / should be specified in the user.props . I (Kevin) have found that the python property is not picked up by the tomcat server as one might expect from the "normal" sourcing of the build.
hcss.interpreter.python.path = {${var.hcss.dir}/lib, ${var.hcss.dir}/lib/ext/jython/Lib} hcss.ia.io.fits.handle_missing_classes = trueI have also found that I have needed to unpack the jar files in the HCSS installation (not in the Tomcat directory), in order to avoid an error like this from the server:
SEVERE: Failed to create pool Traceback (innermost last): File "<string>", line 1, in ? ImportError: no module named herschelIf the python property is not found you may see errors of the following type as well: Traceback (innermost last): File "<string>", line 1, in ? File "/Users/hcssbld/hcss_builds/dp-hifi_current/lib/herschel/__init__.py", line 128, in ? File "/Users/hcssbld/hcss_builds/dp-hifi_current/lib/herschel/__init__.py", line 48, in recursive_module_lookup ImportError: no module named javaos at org.python.core.Py.ImportError(Py.java:184) at org.python.core.imp.import_first(imp.java) at org.python.core.imp.import_name(imp.java) at org.python.core.imp.importName(imp.java)This means that the above settings cause Jython to initialise from a different location to the Java classes. There may be a better way of doing this... Additionally you may wish to configure pool locations etc, for example: hcss.ia.pal.pool.lstore.dir=/misc/winchester1/data/products | |||||||
Logging configurationTomcat will normally by default write log messages tocatalina.out , but it is generally better for applications to write to their own logs. However the reinitialisation of Java logging performed by the Configuration class can interfere with Tomcat's logging and prevent it from working properly, see HcssScr:6672![]() | ||||||||
Line: 246 to 168 | ||||||||
java.util.logging.ConsoleHandler.formatter = herschel.share.log.api.StandardFormatter | ||||||||
Changed: | ||||||||
< < | Now make a patch to Configuration to stop it interfering: | |||||||
> > | ![]() ![]() Configuration.class file. How to do this is explained in the Trouble Shooting section below.
The system property hcss.init.logging should be set to false . It will not work to add it user.props or any other HCSS property file! You can add it to CATALINA_OPS , which now looks something like this: | |||||||
Changed: | ||||||||
< < | cvs co develop/main/herschel/share/util/Configuration.java cp develop/main/herschel/share/util/Configuration.java herschel/share/util cd herschel/share/util Edit Configuration.java and comment out the line LogInitialiser.init(); javac Configuration.java | |||||||
> > | CATALINA_OPTS="-server -Xmx4096m -Dhcss.init.logging=false" | |||||||
The hcss application area should now log to a file called hcss.date.log . | ||||||||
Line: 284 to 204 | ||||||||
It is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Changed: | ||||||||
< < | The first rule of troubleshooting is to check the log file. The principle Tomcat log file is $CATALINA_HOME/logs/catalina.out . With the logging configuration above, the HCSS applications will log to hcss.date.log . | |||||||
> > | The first rule of troubleshooting is to check the log file. The principle Tomcat log file is $CATALINA_HOME/logs/catalina.out . With the logging configuration above, the HCSS applications will log to hcss.date.log . Don't forget that what is written to the log can be configured as desired.
Sometimes there is no substitute for putting debugging statements in the code. You can do this by making modifications in a developer environment as normal, and then copying the class file(s) into the classes directory of the servlet. For example:
cvs co ia_pal_pool_http_server edit HttpPoolServlet.java jakeThen copy the output HttpPoolServlet.class file to $CATALINA_HOME/webapps/hcss/classes/herschel/ia/pal/pool/http/server .
![]() NoClassDefFoundError . The class reported to be missing is not necessarily the one that is. If you know it's there, follow the dependency trail from the reported class to look for something missing. Pay particular attention to what is used in static initialisation statements. | |||||||
Running on a privileged port | ||||||||
Line: 348 to 278 | ||||||||
Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | ||||||||
Changed: | ||||||||
< < | -- SteveGuest - 12 Aug 2009 | |||||||
> > | -- SteveGuest - 26 Apr 2010 | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 351 to 351 | ||||||||
-- SteveGuest - 12 Aug 2009
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 81 to 81 | ||||||||
This script can be used to copy the jar files from the CIB repository. It copies more libraries than is necessary, but it is difficult to know what can safely be left out. | ||||||||
Added: | ||||||||
> > | This method can still be plagued by the dreaded NoClassDefFoundError . The class reported to be missing is not necessarily the one that is. If you know it's there, follow the dependency trail from the reported class to look for something missing. Pay particular attention to what is used in static initialisation statements. | |||||||
Adding the Http pool servletThe servlet classes are contained in thehcss.services project of the CIB. It contains these modules: |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 77 to 77 | ||||||||
CIB Configuration | ||||||||
Changed: | ||||||||
< < | These libraries are needed by all servlets:
| |||||||
> > | While the static dependencies for the servlets can be identified - and this will work for the TM server - the runtime dependencies for the PAL HTTP pool cannot. | |||||||
Changed: | ||||||||
< < | This script can be used to copy the jar files from the CIB repository. | |||||||
> > | This script can be used to copy the jar files from the CIB repository. It copies more libraries than is necessary, but it is difficult to know what can safely be left out. | |||||||
Adding the Http pool servlet |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 315 to 315 | ||||||||
Running on a privileged port | ||||||||
Changed: | ||||||||
< < | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. I was not able to get the default Tomcat startup script to work when installed on this port. Here is my script: | |||||||
> > | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. I was not able to get the default Tomcat startup script to work when installed on this port. Here is my script. | |||||||
Deleted: | ||||||||
< < | #!/bin/sh # Adapt the following lines to your configuration JAVA_HOME=/home/spire/hcssbld/java/jdk1.6.0_10/ CATALINA_HOME=/home/spire/hcssbld/tomcat TOMCAT_USER=hcssbld TMP_DIR=/var/tmp CATALINA_OPTS=-Xmx4096m CLASSPATH=\ $JAVA_HOME/lib/tools.jar:\ $CATALINA_HOME/bin/commons-daemon.jar:\ $CATALINA_HOME/bin/bootstrap.jar case "$1" in start) # # Start Tomcat # $CATALINA_HOME/bin/jsvc \ -user $TOMCAT_USER \ -home $JAVA_HOME \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$TMP_DIR \ -Djava.library.path=$VERSANT_ROOT/lib:$VERSANT_ROOT/lib/jvi/1p \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ -Djava.util.logging.config.file=$CATALINA_HOME/conf/logging.properties \ -outfile $CATALINA_HOME/logs/catalina.out \ -errfile '&1' \ $CATALINA_OPTS \ -cp $CLASSPATH \ org.apache.catalina.startup.Bootstrap # # To get a verbose JVM #-verbose \ # To get a debug of jsvc. #-debug \ ;; stop) # # Stop Tomcat # PID=`cat /var/run/jsvc.pid` kill $PID ;; *) echo "Usage tomcat.sh start/stop" exit 1;; esac | |||||||
This script must be started with root privilege. Note that the daemon still runs as a less privileged user. | ||||||||
Line: 426 to 375 | ||||||||
Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | ||||||||
Changed: | ||||||||
< < | -- SteveGuest - 05 Aug 2009 | |||||||
> > | -- SteveGuest - 12 Aug 2009 | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 81 to 81 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Line: 103 to 104 | ||||||||
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
This script can be used to copy the jar files from the CIB repository. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 119 to 119 | ||||||||
CVS method | ||||||||
Added: | ||||||||
> > | This is not necesssary with the CIB setup as the jar files are already installed. However, this can be useful for debugging. | |||||||
This method is a little messy, but does have the advantage that it leaves you with an already set up developer environment, which is useful for troubleshooting.
From the classes directory, get the source code and put it in the right place, e.g. | ||||||||
Line: 135 to 137 | ||||||||
Then compile the source code (javac will do). The source files can be left there and as an aid to debugging, although Tomcat won't look at them. | ||||||||
Deleted: | ||||||||
< < | CIB methodTBW | |||||||
Application configurationNow create theweb.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this (you can paste this directly, but don't forget to change the role names to your instrument): | ||||||||
Line: 213 to 212 | ||||||||
HCSS configuration | ||||||||
Changed: | ||||||||
< < | The steps in this section should now no longer be necessary. They can be removed when this is confirmed. The complication was due to the Jython intrepreter (used by the Http pool) being loaded from the classpath. Now Tomcat uses custom class loaders and clears the class path, so that didn't work. The servlet now specifically inserts the libraries (from the Tomcat location) into the class path before initialising the interpreter. The hcss.ia.io.fits.handle_missing_classes property is now set automatically on servlet startup. | |||||||
> > | The steps in this section are no longer necessary. This section should be removed if no longer useful. The complication was due to the Jython intrepreter (used by the Http pool) being loaded from the classpath. Now Tomcat uses custom class loaders and clears the class path, so that didn't work. The servlet now specifically inserts the libraries (from the Tomcat location) into the class path before initialising the interpreter. The hcss.ia.io.fits.handle_missing_classes property is now set automatically on servlet startup. | |||||||
These properties should be set for the PAL server to work correctly. You can put them in ~.hcss/user.props . The ${var.hcss.dir} must / should be specified in the user.props . I (Kevin) have found that the python property is not picked up by the tomcat server as one might expect from the "normal" sourcing of the build. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 95 to 95 | ||||||||
| ||||||||
Changed: | ||||||||
< < | These libraries are needed to run telemetry and data frames servlet: | |||||||
> > | These libraries are needed to run the telemetry and data frames servlet: | |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > | This script can be used to copy the jar files from the CIB repository. | |||||||
Adding the Http pool servletThe servlet classes are contained in thehcss.services project of the CIB. It contains these modules: | ||||||||
Line: 421 to 425 | ||||||||
Then go to the "manager/html" web page on your server. I found that with my configuration I was getting HTTP 401 errors when I tried this. I got it to work by commenting out the error-page entry in the manager web.xml file. | ||||||||
Changed: | ||||||||
< < | -- SteveGuest - 01 May 2009 | |||||||
> > | -- SteveGuest - 05 Aug 2009
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 55 to 55 | ||||||||
The general idea is to put jar files in the lib directory and class files in classes. Everything you need should be in there. Don't assume that it will pick up your CLASSPATH environment variable - it won't. | ||||||||
Changed: | ||||||||
< < | Things are currently a little confused due to the transition period between the "new style" and the "continuous integration builds", and I am unsure about the best way to do some things right now. The following section mostly refers to the "new-style" builds. | |||||||
> > | These libraries should be updated whenever a new version of the HCSS is deployed, although in practice it usually continues working anyway (except for schema evolutions which kill database accessing servlets).
It is also necessary to create the application configuration file web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat.
"Old/new" style configuration | |||||||
Copy these libraries into the lib directory:
| ||||||||
Line: 64 to 68 | ||||||||
| ||||||||
Deleted: | ||||||||
< < | These libraries should be updated whenever a new version of the HCSS is deployed, although in practice it usually continues working anyway (except for schema evolutions which kill database accessing servlets). | |||||||
For the hcssExtLibs library, it is necessary to work around HcssSpr:5410![]()
| ||||||||
Line: 73 to 75 | ||||||||
| ||||||||
Changed: | ||||||||
< < | It is also necessary to create the application configuration file web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat. | |||||||
> > | CIB ConfigurationThese libraries are needed by all servlets:
| |||||||
Adding the Http pool servlet | ||||||||
Line: 82 to 111 | ||||||||
| ||||||||
Changed: | ||||||||
< < | These can be installed by either checking them out from CVS and compiling them, or using the CIB installer and extracting the jar files (see reference to current uncertainty above). | |||||||
> > | These can be installed by either checking them out from CVS and compiling them, or using the CIB installer and extracting the jar files (see above). | |||||||
CVS method | ||||||||
Line: 384 to 413 | ||||||||
Convenience methods to set these properties dynamically are provided in the herschel.access.Access class. | ||||||||
Added: | ||||||||
> > | Using Tomcat's Manager applicationThis is a very useful tool for monitoring, stopping and restarting applications. To use it you have to give yourself privilege. Either:
error-page entry in the manager web.xml file. | |||||||
-- SteveGuest - 01 May 2009 \ No newline at end of file |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 180 to 180 | ||||||||
HCSS configuration | ||||||||
Added: | ||||||||
> > | The steps in this section should now no longer be necessary. They can be removed when this is confirmed. The complication was due to the Jython intrepreter (used by the Http pool) being loaded from the classpath. Now Tomcat uses custom class loaders and clears the class path, so that didn't work. The servlet now specifically inserts the libraries (from the Tomcat location) into the class path before initialising the interpreter. The hcss.ia.io.fits.handle_missing_classes property is now set automatically on servlet startup. | |||||||
These properties should be set for the PAL server to work correctly. You can put them in ~.hcss/user.props . The ${var.hcss.dir} must / should be specified in the user.props . I (Kevin) have found that the python property is not picked up by the tomcat server as one might expect from the "normal" sourcing of the build.
hcss.interpreter.python.path = {${var.hcss.dir}/lib, ${var.hcss.dir}/lib/ext/jython/Lib} | ||||||||
Line: 382 to 384 | ||||||||
Convenience methods to set these properties dynamically are provided in the herschel.access.Access class. | ||||||||
Deleted: | ||||||||
< < | -- SteveGuest - 28 Apr 2009 | |||||||
\ No newline at end of file | ||||||||
Added: | ||||||||
> > | -- SteveGuest - 01 May 2009 | |||||||
\ No newline at end of file |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 180 to 180 | ||||||||
HCSS configuration | ||||||||
Changed: | ||||||||
< < | These properties should be set for the PAL server to work correctly. You can put them in user.props . | |||||||
> > | These properties should be set for the PAL server to work correctly. You can put them in ~.hcss/user.props . The ${var.hcss.dir} must / should be specified in the user.props . I (Kevin) have found that the python property is not picked up by the tomcat server as one might expect from the "normal" sourcing of the build. | |||||||
Changed: | ||||||||
< < | hcss.interpreter.python.path = {${var.hcss.dir}/lib} | |||||||
> > | hcss.interpreter.python.path = {${var.hcss.dir}/lib, ${var.hcss.dir}/lib/ext/jython/Lib} | |||||||
hcss.ia.io.fits.handle_missing_classes = true | ||||||||
Line: 192 to 192 | ||||||||
File " | ||||||||
Added: | ||||||||
> > |
If the python property is not found you may see errors of the following type as well:
Traceback (innermost last): File "<string>", line 1, in ? File "/Users/hcssbld/hcss_builds/dp-hifi_current/lib/herschel/__init__.py", line 128, in ? File "/Users/hcssbld/hcss_builds/dp-hifi_current/lib/herschel/__init__.py", line 48, in recursive_module_lookup ImportError: no module named javaos at org.python.core.Py.ImportError(Py.java:184) at org.python.core.imp.import_first(imp.java) at org.python.core.imp.import_name(imp.java) at org.python.core.imp.importName(imp.java) | |||||||
This means that the above settings cause Jython to initialise from a different location to the Java classes. There may be a better way of doing this... Additionally you may wish to configure pool locations etc, for example: |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 199 to 199 | ||||||||
hcss.ia.pal.pool.lstore.dir=/misc/winchester1/data/products | ||||||||
Added: | ||||||||
> > | Logging configurationTomcat will normally by default write log messages tocatalina.out , but it is generally better for applications to write to their own logs. However the reinitialisation of Java logging performed by the Configuration class can interfere with Tomcat's logging and prevent it from working properly, see HcssScr:6672![]() classes directory under hcss create a file called logging.properties like this:
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ org.apache.juli.FileHandler.level = FINE org.apache.juli.FileHandler.directory = ${catalina.base}/logs org.apache.juli.FileHandler.prefix = hcss. org.apache.juli.FileHandler.formatter = herschel.share.log.api.StandardFormatter java.util.logging.ConsoleHandler.level = FINE java.util.logging.ConsoleHandler.formatter = herschel.share.log.api.StandardFormatterNow make a patch to Configuration to stop it interfering:
cvs co develop/main/herschel/share/util/Configuration.java cp develop/main/herschel/share/util/Configuration.java herschel/share/util cd herschel/share/util Edit Configuration.java and comment out the line LogInitialiser.init(); javac Configuration.javaThe hcss application area should now log to a file called hcss.date.log . | |||||||
Starting and stoppingThe scripts can be found in Tomcat'sbin directory. Use startup to start it, and shutdown to stop it. You may wish to check the catalina.out log to see if it started correctly. | ||||||||
Line: 226 to 259 | ||||||||
It is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Changed: | ||||||||
< < | The first rule of troubleshooting is to check the log file. The principle log file is $CATALINA_HOME/logs/catalina.out . | |||||||
> > | The first rule of troubleshooting is to check the log file. The principle Tomcat log file is $CATALINA_HOME/logs/catalina.out . With the logging configuration above, the HCSS applications will log to hcss.date.log . | |||||||
Running on a privileged port | ||||||||
Line: 256 to 289 | ||||||||
-Dcatalina.home=$CATALINA_HOME -Djava.io.tmpdir=$TMP_DIR -Djava.library.path=$VERSANT_ROOT/lib:$VERSANT_ROOT/lib/jvi/1p | ||||||||
Added: | ||||||||
> > | -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=$CATALINA_HOME/conf/logging.properties | |||||||
-outfile $CATALINA_HOME/logs/catalina.out -errfile '&1' $CATALINA_OPTS |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 316 to 316 | ||||||||
| ||||||||
Added: | ||||||||
> > | This property should also be set on the server side. This will be made the default for this application in the next version of the module. Note that this value is specific to the server and inappropriate for interactive use.
hcss.access.store = herschel.access.db.SimpleStoreHandler | |||||||
This servlet is accessed by using the normal access API. These client-side properties need to be set: |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 312 to 312 | ||||||||
This corresponds to the url http://whatever:8080/hcss/tm , assuming default settings. | ||||||||
Deleted: | ||||||||
< < | -- SteveGuest - 23 Apr 2009 | |||||||
\ No newline at end of file | ||||||||
Added: | ||||||||
> > | This servlet has a feature to allow redirection of a database request to a specific server. This is done by means of HCSS properties. (It might be cleaner to redefine them as parameters specified in the web.xml file). The easiest way to set them is to put them in a HcssTmHttpServer.defaults file in the same directory as the corresponding class file. These are:
access API. These client-side properties need to be set:
hcss.access.connection=herschel.access.net.NetworkConnection hcss.access.authentication=true hcss.access.url=http://whatever:8080/hcss/tmConvenience methods to set these properties dynamically are provided in the herschel.access.Access class.
-- SteveGuest - 28 Apr 2009 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 186 to 186 | ||||||||
hcss.ia.io.fits.handle_missing_classes = true | ||||||||
Added: | ||||||||
> > | I have also found that I have needed to unpack the jar files in the HCSS installation (not in the Tomcat directory), in order to avoid an error like this from the server:
SEVERE: Failed to create pool Traceback (innermost last): File "<string>", line 1, in ? ImportError: no module named herschelThis means that the above settings cause Jython to initialise from a different location to the Java classes. There may be a better way of doing this... | |||||||
Additionally you may wish to configure pool locations etc, for example:
hcss.ia.pal.pool.lstore.dir=/misc/winchester1/data/products |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Changed: | ||||||||
< < | Under construction... This page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | |||||||
> > | This page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here other than in brief. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | |||||||
Installation | ||||||||
Line: 204 to 202 | ||||||||
In this case you need to kill the process (look for catalina ) before restarting it. | ||||||||
Added: | ||||||||
> > | Trying it outFollowing the instructions above and starting Tomcat, we should now have a running PAL server with urlhttp://whatever:8080/hcss/pal . Check the log for any initialisation errors. Here is an example Jython script for trying it out on the client side:
from herschel.ia.pal.pool.http import HttpClientPool pool = HttpClientPool ("http://wakefield.bnsc.rl.ac.uk/hcss/pal", "sims3") st = ProductStorage (pool) st.authenticate() r = st.select (Query (ObservationContext, "1")) | |||||||
TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Line: 292 to 302 | ||||||||
</servlet-mapping> | ||||||||
Added: | ||||||||
> > | This corresponds to the url http://whatever:8080/hcss/tm , assuming default settings. | |||||||
-- SteveGuest - 23 Apr 2009 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 49 to 49 | ||||||||
Adding a servletServlets live inside thewebapps directory. Applications have their own area in this directory and run in a sandbox isolated from the others. Note that a single application area can contain any number of servlets. | ||||||||
Added: | ||||||||
> > | Now we go through how to set up an application called hcss . In the webapps directory, create a directory structure like this:
hcss - WEB-INF - lib - classesThe general idea is to put jar files in the lib directory and class files in classes. Everything you need should be in there. Don't assume that it will pick up your CLASSPATH environment variable - it won't.
Things are currently a little confused due to the transition period between the "new style" and the "continuous integration builds", and I am unsure about the best way to do some things right now. The following section mostly refers to the "new-style" builds.
Copy these libraries into the lib directory:
hcssExtLibs library, it is necessary to work around HcssSpr:5410![]()
web.xml in WEB-INF . A version with a servlet defined is in the next section. You can also look at the versions of this file in the other applications that come preinstalled with Tomcat. | |||||||
Adding the Http pool servlet | ||||||||
Added: | ||||||||
> > | The servlet classes are contained in the hcss.services project of the CIB. It contains these modules:
jar files (see reference to current uncertainty above).
CVS methodThis method is a little messy, but does have the advantage that it leaves you with an already set up developer environment, which is useful for troubleshooting. From theclasses directory, get the source code and put it in the right place, e.g.
cvs export -r D_IA_SERVER_UTIL_0_2 develop/main/herschel/ia/server/util cp -r develop/main/herschel/ia/server herschel/iaNow do the same for the ia_pal_pool_http_server module, e.g.
cvs export -r D_IA_PAL_POOL_HTTP_SERVER_0_2 develop/main/herschel/ia/pal/pool/http/server mv develop/main/herschel/ia/pal herschel/iaThen compile the source code ( javac will do). The source files can be left there and as an aid to debugging, although Tomcat won't look at them.
CIB methodTBWApplication configurationNow create theweb.xml file in the WEB-APPS directory that will tell Tomcat what to do with all this lot. It should look something like this (you can paste this directly, but don't forget to change the role names to your instrument):
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd"> <web-app> <display-name>HCSS applications</display-name> <description> Servlets that use the HCSS. </description> <filter> <filter-name>GzipFilter</filter-name> <filter-class>herschel.ia.server.util.GzipFilter</filter-class> </filter> <filter-mapping> <filter-name>GzipFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <servlet> <servlet-name>pal</servlet-name> <servlet-class>herschel.ia.pal.pool.http.server.HttpPoolServlet</servlet-class> <init-param> <param-name>allowLoadAccess</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>allowSaveAccess</param-name> <param-value>false</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>pal</servlet-name> <url-pattern>/pal</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/</url-pattern> </web-resource-collection> <auth-constraint> <!-- Anyone with one of the listed roles may access this area --> <role-name>spire_user</role-name> <role-name>spire_admin</role-name> </auth-constraint> </security-constraint> <!-- Default login configuration --> <login-config> <auth-method>BASIC</auth-method> </login-config> <!-- Security roles referenced by this web application --> <security-role> <role-name>spire_user</role-name> <role-name>spire_admin</role-name> </security-role> </web-app>This example does two things in addition to defining the servlet:
HCSS configurationThese properties should be set for the PAL server to work correctly. You can put them inuser.props .
hcss.interpreter.python.path = {${var.hcss.dir}/lib} hcss.ia.io.fits.handle_missing_classes = trueAdditionally you may wish to configure pool locations etc, for example: hcss.ia.pal.pool.lstore.dir=/misc/winchester1/data/products | |||||||
Starting and stoppingThe scripts can be found in Tomcat'sbin directory. Use startup to start it, and shutdown to stop it. You may wish to check the catalina.out log to see if it started correctly. | ||||||||
Line: 136 to 278 | ||||||||
Using the telemetry and data frame server | ||||||||
Added: | ||||||||
> > | Put the classes for the access_server module in the hcss applications area, as for the PAL pool.
Then add this servlet definition to the web.xml file in WEB-APPS .
<servlet> <servlet-name>tm</servlet-name> <servlet-class>herschel.access.server.HcssTmHttpServer</servlet-class> </servlet> <servlet-mapping> <servlet-name>tm</servlet-name> <url-pattern>/tm</url-pattern> </servlet-mapping> | |||||||
-- SteveGuest - 23 Apr 2009 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http Pool | ||||||||
Line: 18 to 18 | ||||||||
CATALINA_OPTS=-server -Xmx4096m | ||||||||
Changed: | ||||||||
< < | The global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml and web.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below. | |||||||
> > | The global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below. | |||||||
User Access Control | ||||||||
Line: 46 to 46 | ||||||||
| ||||||||
Added: | ||||||||
> > | Adding a servletServlets live inside thewebapps directory. Applications have their own area in this directory and run in a sandbox isolated from the others. Note that a single application area can contain any number of servlets.
Adding the Http pool servletStarting and stoppingThe scripts can be found in Tomcat'sbin directory. Use startup to start it, and shutdown to stop it. You may wish to check the catalina.out log to see if it started correctly.
Tomcat should automatically notice if a new servlet is defined and load it. You can force a servlet to reload by starting and stopping Tomcat. Wait a few seconds between stopping and starting or it might get confused (see next section). There is also a Tomcat "Manager" application that can do this from a web interface without stopping Tomcat - see the Tomcat documentation for details.
Occasionally it can get in a mess, which can be caused by things such as running out of memory, and refuse to restart. In this case you should see a message in the log along the lines of:
LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use:8080In this case you need to kill the process (look for catalina ) before restarting it. | |||||||
TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Http PoolUnder construction... | ||||||||
Changed: | ||||||||
< < | This page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here. | |||||||
> > | This page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here. Most of this page is about configuring Tomcat to run servlets using the HCSS in general, rather than specifically HttpPool. | |||||||
Installation | ||||||||
Line: 12 to 12 | ||||||||
Note that only one HTTP pool server is needed, regardless of the number of pools it accesses. | ||||||||
Added: | ||||||||
> > | There is no need to install Tomcat in a privileged account, and probably good security reasons for not doing so. Set the environment variable CATALINA_HOME to point to the directory where it is installed. You can also use the CATALINA_OPTS variable to set JVM options. This should be used to increase the available memory. My settings look like this:
CATALINA_HOME=/home/spire/hcssbld/tomcat CATALINA_OPTS=-server -Xmx4096mThe global configuration files are in Tomcat's conf directory. You should only need to make minor changes to server.xml and web.xml . The default port is 8080 and defined in the server.xml file. You can change this if you like, but running on a privileged port makes things a bit more complicated, see below.
User Access ControlI recommend enabling this for two reasons:
server.xml file in the conf directory. Look for the Realm entry and specify digest as SHA . It should now look like this:
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase" digest="SHA"/>Edit the tomcat-users.xml file in the conf directory. Add some roles, like this:
<role rolename="spire_admin"/> <role rolename="spire_user"/>You might want to leave the tomcat role as a placeholder for future general Tomcat admin.
This is how to add a user.
| |||||||
TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation. | ||||||||
Added: | ||||||||
> > | The first rule of troubleshooting is to check the log file. The principle log file is $CATALINA_HOME/logs/catalina.out . | |||||||
Running on a privileged port | ||||||||
Changed: | ||||||||
< < | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. The default Tomcat startup script does not work when installed on this port. Here is my script: | |||||||
> > | This is normally the standard HTTP port 80. The port is set by editing the server.xml file in the conf directory. I was not able to get the default Tomcat startup script to work when installed on this port. Here is my script: | |||||||
Added: | ||||||||
> > | #!/bin/sh | |||||||
# Adapt the following lines to your configuration JAVA_HOME=/home/spire/hcssbld/java/jdk1.6.0_10/ CATALINA_HOME=/home/spire/hcssbld/tomcat |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
Http PoolUnder construction... This page serves as the main documentation for running an HTTP server pool. The corresponding client pool is contained in the build and not covered here.InstallationThe server pool requires a web server that supports Java servlets. This page assumes that Tomcat![]() TroubleshootingIt is important to understand that the Tomcat scripts do not use the Java CLASSPATH environment variable. All required resources must be present in the classes or lib directories. For full details read the section on "Classloading" in the Tomcat documentation.Running on a privileged portThis is normally the standard HTTP port 80. The port is set by editing theserver.xml file in the conf directory. The default Tomcat startup script does not work when installed on this port. Here is my script:
# Adapt the following lines to your configuration JAVA_HOME=/home/spire/hcssbld/java/jdk1.6.0_10/ CATALINA_HOME=/home/spire/hcssbld/tomcat TOMCAT_USER=hcssbld TMP_DIR=/var/tmp CATALINA_OPTS=-Xmx4096m CLASSPATH=\ $JAVA_HOME/lib/tools.jar:\ $CATALINA_HOME/bin/commons-daemon.jar:\ $CATALINA_HOME/bin/bootstrap.jar case "$1" in start) # # Start Tomcat # $CATALINA_HOME/bin/jsvc \ -user $TOMCAT_USER \ -home $JAVA_HOME \ -Dcatalina.home=$CATALINA_HOME \ -Djava.io.tmpdir=$TMP_DIR \ -Djava.library.path=$VERSANT_ROOT/lib:$VERSANT_ROOT/lib/jvi/1p \ -outfile $CATALINA_HOME/logs/catalina.out \ -errfile '&1' \ $CATALINA_OPTS \ -cp $CLASSPATH \ org.apache.catalina.startup.Bootstrap # # To get a verbose JVM #-verbose \ # To get a debug of jsvc. #-debug \ ;; stop) # # Stop Tomcat # PID=`cat /var/run/jsvc.pid` kill $PID ;; *) echo "Usage tomcat.sh start/stop" exit 1;; esacThis script must be started with root privilege. Note that the daemon still runs as a less privileged user.
Further complications arise if there is a need to access the Versant library, as this accesses native shared libraries, e.g. for DbPool or the TM/data frame server. Whilst the startup script uses the java.library.path argument to pass the location of these libraries to the daemon process, this does not entirely work since the first called library then calls other libraries, which does not work since the process does not inherit the value of the LD_LIBRARY_PATH environment variable (it defines its own). A workaround solution is to link to the required libraries from the Java installation, which is accessible, e.g.
cd $JAVA_HOME/jre/lib/amd64 ln -s $VERSANT_ROOT/lib/liboscfe.so liboscfe.so ln -s $VERSANT_ROOT/lib/libxa.so libxa.soNote that this is only necessary since the server is running as a daemon process in order to access the privileged port 80. There may well be a better solution than this. Using the telemetry and data frame server-- SteveGuest - 23 Apr 2009 |