Front end for mobile devices

phonegap

Adobe IOS



player for iphone(JWplayer)

Contents supported for onlineEdit

application/msword	"Word.Document"
	application/vnd.ms-excel	"Excel.Sheet"
	application/vnd.ms-powerpoint	"PowerPoint.Slide"
	application/vnd.openxmlformats-officedocument.presentationml.presentation	"PowerPoint.Slide"
	application/vnd.openxmlformats-officedocument.spreadsheetml.sheet	"Excel.Sheet"
	application/vnd.openxmlformats-officedocument.wordprocessingml.document We can get this value from the code /** * Configure the Online Edit URL if enabled for this mimetype */ if (scope.doclistMetadata.onlineEditing && (record.mimetype in scope.onlineEditMimetypes)) { from the file documentlist.js in Alfresco3.4.5

Thumbnail

http://ecmarchitect.com/archives/2009/03/03/913

The above link talks about the Thumbanil generation from the image

Problem in Thumbnail generation and JVM settings

JAVA_OPTS configuration can be seen in /opt/alfresco/tomcat/scripts
Inside this we will have the file name by name ctl.sh.
To make the thumbnails to work we should add -Djava.awt.headless=true in ctl.sh file

#!/bin/sh

CATALINA_HOME=/opt/alfresco/tomcat
TOMCAT_BINDIR=/opt/alfresco/tomcat/bin
JRE_HOME=/opt/alfresco/java
CATALINA_PID=/opt/alfresco/tomcat/temp/catalina.pid
export CATALINA_PID
TOMCAT_STATUS=""
ERROR=0
PID=""

start_tomcat() {
is_tomcat_running
RUNNING=$?
if [ $RUNNING -eq 1 ]; then
echo "$0 $ARG: tomcat (pid $PID) already running"
else
rm -f $CATALINA_PID
export JAVA_OPTS="-Xms512m -Xmx1024m -Xss1024k -XX:MaxPermSize=256m -XX:NewSize=256m -XX:+UseConcMarkSweepGC -Dalfresco.home=/opt/alfresco -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Djava.awt.headless=true"
export JAVA_HOME=$JRE_HOME
$TOMCAT_BINDIR/startup.sh
if [ $? -eq 0 ]; then
echo "$0 $ARG: tomcat started"
else
echo "$0 $ARG: tomcat could not be started"
ERROR=1
fi
fi
}

daemon_tomcat() {
export JAVA_OPTS="-Xms512m -Xmx1024m -Xss1024k -XX:MaxPermSize=256m -XX:NewSize=256m -XX:+UseConcMarkSweepGC -Dalfresco.home=/opt/alfresco -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Djava.awt.headless=true"
export JAVA_HOME=$JRE_HOME
$TOMCAT_BINDIR/catalina.sh run
}

stop_tomcat() {
$TOMCAT_BINDIR/shutdown.sh 300 -force
if [ $? -eq 0 ]; then
echo "$0 $ARG: tomcat stopped"
if [ -f $CATALINA_PID ] ; then
rm $CATALINA_PID
fi
sleep 3
else
echo "$0 $ARG: tomcat could not be stopped"
ERROR=2
fi
}

get_pid() {
PID=""
PIDFILE=$1
# check for pidfile
if [ -f $PIDFILE ] ; then
PID=`cat $PIDFILE`
fi
}

get_tomcat_pid() {
get_pid $CATALINA_PID
if [ ! $PID ]; then
return
fi
}

is_service_running() {
PID=$1
if [ "x$PID" != "x" ] && kill -0 $PID 2>/dev/null ; then
RUNNING=1
else
RUNNING=0
fi
return $RUNNING
}

is_tomcat_running() {
get_tomcat_pid
is_service_running $PID
RUNNING=$?
if [ $RUNNING -eq 0 ]; then
TOMCAT_STATUS="tomcat not running"
else
TOMCAT_STATUS="tomcat already running"
fi
return $RUNNING
}

if [ "x$1" = "xstart" ]; then
start_tomcat
sleep 2
elif [ "x$1" = "xdaemon" ]; then
daemon_tomcat
elif [ "x$1" = "xstop" ]; then
stop_tomcat
sleep 2
elif [ "x$1" = "xstatus" ]; then
is_tomcat_running
echo $TOMCAT_STATUS
fi

exit $ERROR

JVM Details

http://www.unidata.ucar.edu/projects/THREDDS/tech/tds4.2/reference/JavaOptsSummary.html

TDS Reference: Summary of JAVA_OPTS

---

Note: This page focuses on Tomcat running on a Unix/Linux OS but much of it is appropriate for other servlet containers and other OSs. How and where the various options are configured will depend on the servlet container and OS you are using.

---

You can set JAVA_OPTS in the ${TOMCAT_HOME}/bin/setenv.sh file. The options discussed below are the ones we set on our production server.

Memory Available to the Java JVM

Increasing the memory available to the Java JVM can help TDS performance (see more on TDS performance here). Try to give your server as much memory as you can. The following are reasonable numbers to start with but if you have more memory increase these numbers. [Note: 32-bit JVMs max out around 1500m.)

JAVA_OPTS="-Xmx1024m -Xms256m" export JAVA_OPT 

What the options mean:

• -Xmx sets the maximum amount of memory that can be allocated to the JVM heap; here it is being set to 1024 megabytes.
• -Xms sets the initial amount of memory allocated to the JVM heap; here it is being set to 256 megabytes.

Run Java JVM in Server Mode

The Java JVM can optimize a number of things for server environments. [Since Java 5, the launcher tries to detect whether it is running on a "server-class" machine and set this for you (more on this here). But ...] You can explicitly select the Java HotSpot Server VM with the -server option.

JAVA_OPTS="-Xmx1024m -Xms256m -server" export JAVA_OPT 

What the option means:

• -server instructs the launcher to use the Java HotSpot Server VM.

PermGen Memory

If you start getting java.lang.OutOfMemoryError: PermGen space error messages. You may want to include a "-XX:MaxPermSize" option in your JAVA_OPTS. See the PermGen FAQ entry for more information on this problem.

JAVA_OPTS="-Xmx1024m -Xms256m -server -XX:MaxPermSize=128m" export JAVA_OPT 

What the option means:

• -XX:MaxPermSize set the maximum amount of memory that can be used for PermGen.

If Using WMS, Tell Graphics Engine There is No Console

An obscure bug concerning X servers and graphics rendering code can cause WMS requests to fail or, in certain situations, cause Tomcat to crash. You may see error messages like the following:

"java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment" 

To avoid this situation, the graphics code needs to be told that there is no graphics console available. This can be done by setting the java.awt.headless system property to true which can be done using JAVA_OPTS:

JAVA_OPTS="-Xmx1024m -Xms256m -server -Djava.awt.headless=true" export JAVA_OPT 

What the option means:

• -Djava.awt.headless=true sets the value of the java.awt.headless system property to true. Setting this system property to true prevent graphics rendering code from assuming that a graphics console exists.

More on using the headless mode in Java SE here.

If Using WMS, Setup Writable Directory for System java.util.prefs.

Some libraries that WMS depends on use the java.util.prefs package and there are some known issues that can crop up with storing system preferences. This problem can be avoided by setting the java.util.prefs.systemRoot system property to point to a directory in which the TDS can write. The given directory must exist and must contain a directory named ".systemPrefs" which must be writable by the user under which Tomcat is run.

JAVA_OPTS="-Xmx1024m -Xms256m -server -Djava.util.prefs.systemRoot=$CATALINA_HOME/content/thredds/javaUtilPrefs" export JAVA_OPT 

What the option means:

• -Djava.util.prefs.systemRoot= sets the value of the java.util.prefs.systemRoot system property to the given directory. The java.util.prefs code will use the given directory to persist the system (as opposed to user) preferences.

More information on the issue can be found on the TDS FAQ page.

---

Our production setenv.sh file looks like:

#!/bin/sh # ulimit -n 2048  CATALINA_HOME="/opt/tomcat" export CATALINA_HOME  JAVA_HOME="/opt/jdk" export JAVA_HOME  # Some commonly used JAVA_OPTS settings: # NORMAL="-d64 -Xmx4090m -Xms512m -server" MAX_PERM_GEN="-XX:MaxPermSize=256m" HEADLESS="-Djava.awt.headless=true" JAVA_PREFS_SYSTEM_ROOT="-Djava.util.prefs.systemRoot=$CATALINA_HOME/content/thredds/javaUtilPrefs"  # Standard setup. # JAVA_OPTS="$NORMAL $MAX_PERM_GEN $HEADLESS $JAVA_PREFS_SYSTEM_ROOT" export JAVA_OPTS 

Server Performance

---

Hardware

Throw more $$ at this problem, hardware is cheap, compared to people.

It would be highly unusual for the TDS not to be I/O bound, so buying a high-performance disk subsystem is much better than buying fast CPUs. Slower, more energy efficient multicore processors are optimized for web server loads.

Typically disk access is faster on a local drive than on an NFS mounted drive. High performance disk subsystems like RAID or SANs can also significantly improve TDS throughput.

Operating System Configuration

Use a 64-bit OS

• 'nuff said

Use a high-performance file system

If you have system admin resources, examine the possible file systems available for your OS, eg on Linux or Solaris. We are using the ZFS file system on Solaris-X86 and it is very fast. We use ZFS software RAID, which replaces hardware RAID.

Resources:

• http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide
• http://blogs.sun.com/realneel/entry/zfs_and_databases
• http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
• http://www.redhat.com/gfs/
  

Setting the number of file handles

The OS typically limits the number of open file handles per process. To check this value on Unix, use:

 ulimit -n 

If you are using the default TDS configuration values, this value should be 1024 or greater. Otherwise you can tune this number based on your own settings. For example, to set this value to 2048 in the tomcat startup.sh script:

 ulimit -n 2048

This affects the number of files to keep in the NetcdfFile Object Cache.

Java Virtual Machine

Use a 64-bit JVM with -server

• You may have to examine the docs for your JVM on how to do this. Below are the options we use for Sun Solaris 1.6 JVM, which requires -d64 to run the 64 bit version
• You should run with the Java HotSpot Server VM, by using the -server option.
• You should give the JVM as much memory as possible. Here we give it 4 Gbytes. The maximum you can use for 32-bit JVMs seems to be around 1500 Mbytes

-d64 -Xmx4081m -Xms512m -server -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Djava.awt.headless=true

• -XX:+HeapDumpOnOutOfMemoryError triggers a heap dump when you run out of memory. We recommend the Memory Analyser from Eclipse to explore heap dumps.
• -Djava.awt.headless=true tells the system that there is not a graphics console being used, which avaois some arcane errors from third party libraries.

We recommend the latest version of JDK 1.6, which has typically a 20% performance improvement or more over 1.5, especially with the -server option. We have not yet had a chance to compare performance of 32-bit vs 64-bit JVMs. However, 64-bit JVMs allow the use of much larger memory heaps, which will help for highly loaded systems.

Resources

• Java Performance Tuning website with tuning tips
• Java Tuning White Paper whitepaper from Sun (2005)
• Java performance tuning, Jack Shirazi (O'Reilly, 2003), classic book, a bit dated.

Tomcat

Version

We recommend the latest stable version of Tomcat 6, which has better stability and performance than Tomcat 5.x. This requires JDK 1.5 or above.

Compression

Tomcat can be configured to automatically compress the responses, whenever the client allows that. Compression is usually a big win, especially for bandwidth-limited sites. Deciding when and what to compress depends on a lot of factors, however. We use the following settings in server.xml:

    
  compression="1000"
             compressableMimeType="text/html,text/xml,text/plain,application/octet-stream" />

This says to compress (gzip or deflate) when the number of bytes is >= 1000, for the named mime-types. See Tomcat HTTP Connector reference page for more details.

Automatic Startup

In a production environment, Tomcat should be automatically restarted when the machine starts. How to do this depends on what OS you are running. This FAQ has a bit of info.

Miscellaneous

Once thredds.war is expanded, manually copy everything in ${tomcat_home}/webapps/thredds/initialContent/root/ to ${tomcat_home}/webapps/ROOT/ .

1. This sets up a robots.txt file to keep crawlers from wasting bandwidth.
2. The favicon.ico file is mostly a convenience to keep browsers from constantly asking for it (substitute your own icon if you like!).

Resources

• Tomcat Performance FAQ
• Tomcat Performance paper by Peter Lin
• Tomcat Performance Tuning paper at Apache Con 2003
• Servlet Container Benchmarking (2004)
• Tomcat Tuning free online chapter in Tomcat: The Definitive Guide (2007). Check out the timings between Tomcat and Apache.

Thredds Data Server

File Handles and Caching

The TDS caches file handles to minimize OS overhead. Currently this defaults to allow 200 - 400 open files for OPeNDAP and WCS, and 25 - 40 for HTTP file serving. This means that your OS must allow at least that many file handles per process, otherwise you can get a "out of file handles" message, and the server can freeze up.

These numbers limit performance, but not functionality. For example, the number of files in an aggregation is not limited by these file handle limits.

You can change these settings in the threddsConfig.xml file.

Each NetcdfFile object encapsolates a file. NcML aggregations are careful not to keep component files open. When number of cache files > maxElementsInMemory, a cleanup thread starts after 100 msecs. So the number of cached files can get larger than maxElementsInMemory in the interim, but unless you are really hammering the OS by opening many files per scond, it shouldnt get too much bigger. But leave some cushion, depending on your expected rate of opening files.

Consolidate cache / temporary directories

The TDS writes temporary files and caches files. By default these are stored under ${tomcat_home}/content/thredds/cache. These directories can get large. You might want to relocate them to another place, for example if ${tomcat_home} has limited space. Also, theres no need to backup the cache directories, so they can be placed on a disk that is not backed up. The easiest thing to do is to create a symbolic link from ${tomcat_home}/content/thredds/cache to wherever you want thes files to live.

OPeNDAP Memory Use

The OPeNDAP-Java layer of the server currently has to read the entire data request into memory before sending it to the client (we hope to get a streaming I/O solution working eventually). Generally clients only request subsets of large files, but if you need to support large data requests, make sure that the -Xmx parameter above is set accordingly.

Pre-indexing GRIB files

If you are serving GRIB files through any of the subsetting services (OPENDAP, WCS, etc), the CDM must write an index the first time it tries to read it. This can take several minutes for very large GRIB files. By indexing GRIB files before they are accessed, users get much faster response time.

JVM settings recommendation from Sun
http://java.sun.com/performance/reference/whitepapers/tuning.html

Kaleo workflow

More details you can find here

http://l154k.blogspot.com/2011/11/10-things-programmer-should-know-about.html

Debugging with eclipse in server

if [ -z "$LOGGING_MANAGER" ]; then
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xdebug -Xrunjdwp:transport=dt_socket,address=7777,server=y,suspend=n"
else
JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER -Xdebug -Xrunjdwp:transport=dt_socket,address=7777,server=y,suspend=n"
fi



Add above line in catalina.sh present in /opt /alfresco/tomcat/bin