Actualizando Alfresco

Muchas instalaciones de Alfresco de las que he visto son bastante estáticas, y quizás uno de los motivos principales es que si las cosas funcionan no se tocan. Otro de los motivos suele ser que hay desarrollos involucrados en la instalación que se deberian validar contra la nueva versión (aunque la experiencia me demuestra que desarrollos hechos para 2.0c han seguido funcionando en versiones 3.4d no está de más asegurarse).

Antes de nada nos deberemos plantear nuestros motivos para hacer actualizar Alfresco. ¿ Hay bugs en nuestra versión que queremos resolver ? (changelog de versiones 3.4.3 en adelante)  ¿ Queremos alguna funcionalidad nueva ? (release notes para community)

Una vez decidida la actualización es la hora de ver sobre que versiones deberemos pasar para llegar a la que queremos. Alfresco suele diferenciar entre versiones menores y mayores y siempre es recomendable pasar a la última versión menor antes de hacer un salto a una mayor aunque el diagrama para la versión 4.0 muestra actualizaciones directas desde 3.1 en adelante:

Una vez tenemos claro nuestro escenario conviene hacerse varias preguntas:

• ¿ Mis logs estan libres de errores "desconocidos" ? Deberiamos ver que la instalación en funcionamiento no esta dando errores de forma continuada ya que la actualización puede agravar el problema si no lo tenemos controlado.
• ¿ Tengo algún tipo de personalización que deberia probar? se incluyen modificaciones en apariencia, modelo de datos, desarrollos, ficheros AMP.
• ¿ Deberia actualizar algún componente ? JDK, Servidor de aplicaciones, conector de base de datos... Intentaremos ir conforme el stack oficial para enterprise ya que son versiones testeadas. Tener muy en cuenta que desde las versiones Community 3.2 se dejó de soportar oficialmente Oracle y SQL Server aunque existen proyectos de la comunidad para darles el soporte.
• ¿ Voy a disponer de una copia de mi instancia de Alfresco para realizar las copias ? El disponer de una copia con datos, aunque no estén actualizados nos puede ahorrar muchos dolores de cabeza y vueltas atrás en producción.
• ¿ Mi usuario de base de datos tiene permisos para borrar y crear tablas ?
• ¿ He tocado algo dentro del directorio de deploy ? Deberia mover toda mi configuración al directorio extension
• ¿ Estoy en una versión 3.1 o anterior ? Deberé unificar toda mi configuración del fichero custom-repository.properties en el fichero alfresco-global.properties

Alfresco provee de un mecanismo sencillo de actualización que basicamente se centra un leer el nuevo war y parchear la base de datos a la nueva versión. Por este mismo mecanismo no se debe tocar nunca el contenido desplegado de Alfresco y se debe usar el directorio de extension que nos ayuda a tener toda la configuración centralizada en un directorio.

Lo ideal si tenemos tiempo y espacio sería tener una copia con datos y trabajar primero sobre esa ya que será el entorno más parecido al escenario final. Manos a la obra:

1. Pararemos Alfresco y realizaremos una copia en frio (ver la entrada de Backup)
2. Instalaremos la nueva versión de Alfresco en una nueva ubicación, con una base de datos límpia y con un nuevo repositorio (directorio alf_data). Yo suelo nombrar a las instalaciones segun la versión, por ejemplo teniendo la versión 3.3g en /opt/alfresco33g y la 4.0 en /opt/alfresco40, lo mismo aplica para las bases de datos
3. Verificaremos que la instalación limpia funciona correctamente y la pararemos
4. Revisaremos los ficheros de configuración anteriores y llevaremos la configuración a los de la nueva versión. No se deben reutilizar los ficheros porque pueden aparecer nuevos parámetros que quedarán sin configurar. Además también deberemos incluir en este punto todos los desarrollos y personalizaciones. Esta tarea se puede hacer de manera previa al proceso de actualización y así minizaremos el downtime. Si configuramos en este punto la base de datos db.url  y hibernate.default_schema (Oracle) y el repositorio de la versión anterior dir.root en el próximo reinicio se ejecutará la actualización. Si queremos hacer alguna prueba más dejar estos dos puntos para el final.
5. Reiniciar alfresco y monitorizar el fichero log

Empezaremos a ver como Alfresco detecta la nueva versión y empieza a aplicar parches. Este proceso es bastante rápido, en mi portátil ha tardado menos de 3 minutos en arrancar (no he reindexado contenido). Tras la actualización el log muestra el siguiente mensaje indicando la versión original y la nueva.

2012-02-15 13:07:45,445 INFO [service.descriptor.DescriptorService] [main] Alfresco started (Community). Current version: 4.0.0 (4003) schema 5.025. Originally installed version: 3.3.0 (g 2860) schema 4.100.

Durante este proceso de actualización puede ser recomendable hacer una reindexación del repositorio estableciendo en alfresco-global.properties el parámetro

index.recovery.mode=FULL

NOTA: en este proceso se ha mantenido la indexación con lucene. Si queremos empezar a usar SOLR primero deberemos actualizar con lucene para que se ejecuten algunos scripts y una vez se haya actualizado se puede migrar a SOLR.

Información obtenida de:
http://wiki.alfresco.com/wiki/General_Upgrade_Process
http://docs.alfresco.com/4.0/index.jsp

Alfresco 4 ya está aquí

Aunque  la versión  Community 4.0c ya lleva un tiempo entre nosotros ayer se liberaron las versiones 4.0 EE y 4.0d.

Aunque podeis información en la página oficial de Alfresco y la comunidad de blogs sobre las nuevas funcionalidades de Alfresco me ha alegrado encontrar en un PDF referencias a como se compara con la versión 3.4 y que puede ser determinante para los usuarios de Alfresco que lo están usando ya que según Alfresco, en sus tests, gracias sobre todo al sistema de indexado con SOLR que permite separar el contenido de los indices han comprobado:

• 10x consultas más rapidas al  Dashboard  de Alfresco Share
• 3x más rapido en la subida de documentos (hasta 4x más rapido en cargas masivas)
• 25% más rapido cargando la Document Library
• 50% mas rápido cargando los detalles de un Documento
• Búsquedas e indexados significativamente mejorados.

Información obtenida de
http://alfresco.com/products/editions/enterprise/4-0/

Tomcat en modo demonio: jsvc

Es posible ejecutar Tomcat, y por ende Alfresco, en modo demonio. La principal ventaja de este sistema es que nos permite ejecutar Tomcat como usuario no-root y usar puertos privilegiados. Es importante aclarar que según la documentación vamos a poder usar los puertos <1024  pero única y exclusivamente a nivel de tomcat, no de Alfresco. Esto nos va a permitir por ejemplo ejecutar Tomcat en el puerto 80. Sin embargo para poder usar FTP y CIFS desde un usuario no privilegiados deberemos usar puertos alternativos y seguir la guía de la wiki y redireccionar los puertos a nivel de firewall. Esto es debido a que solo se demoniza el proceso de tomcat y no las aplicaciones que ejecuta.

jsvc viene con los binarios de Tomcat con lo que solo necesitaremos compilarlos:

    cd $CATALINA_HOME/bin
    tar xvfz commons-daemon-native.tar.gz
    cd commons-daemon-1.0.x-native-src/unix
    ./configure
    make
    cp jsvc ../..
    cd ../..

Si no tenemos definida la variable de entorno JAVA_HOME tendremos que pasar la ruta en el configure:

./configure --with-java=/usr/java/jdk1.6.0_19/

A continuacion pongo el init script que uso para arrancar/parar Alfresco con jsvc

#!/bin/sh
#
# tomcat           Utilizing the jsvc start and stop the servlet engine.
#
# chkconfig: 345 99 10
# description: Starts and stops the tomcat servlet engine.
# Source function library.
. /etc/rc.d/init.d/functions
JAVA_HOME=/usr/java/jdk1.6.0_15/
CATALINA_HOME=/opt/alfresco/tomcat
DAEMON_HOME=/opt/alfresco/tomcat/bin/
TOMCAT_USER=tomcat
TOMCAT_GROUP=tomcat
TOMCAT_PID=/var/run/jsvc_alfresco.pid
TMP_DIR=/opt/alfresco/tomcat/temp
CATALINA_OPTS=
CLASSPATH=$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/commons-daemon.jar:$CATALINA_HOME/bin/bootstrap.jar
CATALINA_WORK_DIR=$CATALINA_HOME/work
# To get a verbose JVM
#-verbose \
# To get a debug of jsvc.
#-debug \
WAIT_MAX=2
case "$1" in
start)
  #
  # Start Tomcat
  #
echo -n "Starting Tomcat: "
$DAEMON_HOME/jsvc -user $TOMCAT_USER -pidfile $TOMCAT_PID -home $JAVA_HOME -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=196M -Xms512m -Xmx2048m -Dcatalina.home=$CATALINA_HOME -Djava.io.tmpdir=$TMP_DIR -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile '&1' $CATALINA_OPTS -cp $CLASSPATH org.apache.catalina.startup.Bootstrap

sleep 2s
if [ -f $TOMCAT_PID ]; then
             echo_success
else
             echo_failure
fi
echo
;;
stop)
#
# Stop Tomcat
#
echo -n "Stopping Tomcat: "
PID=`cat $TOMCAT_PID`
kill $PID 2>/dev/null 1>/dev/null
if [ `ps -p ${PID} > /dev/null 2>&1` ]; then
             echo_failure
else
             echo_success
             rm -f $TOMCAT_PID > /dev/null 2>&1
fi
echo
;;
flush)
#
# Stop Tomcat
#
   echo -n "Stopping Tomcat: "
   PID=`cat $TOMCAT_PID`
   kill $PID 2>/dev/null 1>/dev/null
   if [ `ps -p ${PID} > /dev/null 2>&1` ]; then
                echo_failure
   else
                echo_success
                rm -f $TOMCAT_PID > /dev/null 2>&1
   fi
   echo
   echo -n "Flushing Tomcat CACHE ($CATALINA_WORK_DIR) : "
   rm -rf $CATALINA_WORK_DIR
   if [ -e $CATALINA_WORK_DIR ]; then
                echo_failure
                echo
                exit 1;
   fi
   mkdir $CATALINA_WORK_DIR
   chown $TOMCAT_USER.$TOMCAT_GROUP $CATALINA_WORK_DIR
   if [ ! -e $CATALINA_WORK_DIR ]; then
                echo_failure
                echo
                exit 1;
   fi
   echo_success
   echo
   ;;
*)
   echo "Usage: $0 {start|stop|flush}"
   exit 1;;
esac
exit 0

Este script además tiene el parámetro flush que nos va a permitir eliminar de una forma fácil el contenido del directorio work.

Hay que tener en cuenta que cuando usamos jsvc ya no estamos invocando a los scripts startup.sh ni shutdown.sh con lo cual no se parará el proceso usando estos ficheros. Todas las variables que tuvieramos definidas en este fichero como en el catalina.sh deberán ser movidas al nuevo script.

Cuando miremos los procesos en ejecución veremos 2 procesos. El primero levanta los puertos y el segundo es el que atiende las peticiones.

root     16126     1  0 12:32 ?        00:00:00 jsvc.exec -user tomcat -pidfile /var/run/jsvc_alfresco.pid -home /usr/java/jdk1.6.0_19/ -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=160M -Xms512m -Xmx1024m -Dcatalina.home=/opt/alfresco/tomcat -Djava.io.tmpdir=/opt/alfresco/tomcat/temp -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile &1 -cp /usr/java/jdk1.6.0_19//lib/tools.jar:/opt/alfresco/tomcat/bin/commons-daemon.jar:/opt/alfresco/tomcat/bin/bootstrap.jar org.apache.catalina.startup.Bootstrap
tomcat   16127 16126 52 12:32 ?        00:01:15 jsvc.exec -user tomcat -pidfile /var/run/jsvc_alfresco.pid -home /usr/java/jdk1.6.0_19/ -jvm server -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=160M -Xms512m -Xmx2048m -Dcatalina.home=/opt/alfresco/tomcat -Djava.io.tmpdir=/opt/alfresco/tomcat/temp -outfile /opt/alfresco/tomcat/logs/catalina.out -errfile &1 -cp /usr/java/jdk1.6.0_19//lib/tools.jar:/opt/alfresco/tomcat/bin/commons-daemon.jar:/opt/alfrescod/tomcat/bin/bootstrap.jar org.apache.catalina.startup.Bootstrap

Parando Tomcat

Arrancando Tomcat via jsvc,  entra en mono deomnio, lo que significa que no va a escuchar en el puerto 8005 y por tanto no se va a poder detener via catalina.sh (o shutdown.sh).
Lo que se hace es enviar un SIGTERM o SIGINT al proceso que pertenece a root. En nuestro caso se encuentra el pid en $CATALINA_PID.

Receta para Alfresco en Cluster con replicación de sesión

Con la salida de la versión 3.4.3 de Alfresco Enterprise se ha solucionado un bug que arrastraba la configuración en cluster desde 2009. Finalmente se ha solucionado y voy a explicar paso a paso como se debe configurar utilizando el paquete en formato zip.

Alfresco de por si no replica las sesiones del usuario de un nodo a otro y de esto se debe encargar el servidor de alpicaciones. Por tanto debemos establecer el cluster no solo en Alresco si no también a nivel de Tomcat. En mis pruebas he seguido este esquema:

         Balanceador
        192.168.1.122
             |    
          Cluster      
        /         \        
    Tomcat1       Tomcat2  
192.168.1.122   192.168.1.12

Balanceador: Apache 2.2 + proxy_balancer + proxy_ajp
Cluster: Tomcat configurado mediante BackupManager
Tomcat1: Centos 5 con Tomcat 6.0.32
Tomcat2: Ubuntu con Tomcat 6.0.32 
En este esquema un nodo hace de servidor NFS y de balanceador. En un entorno en producción estos 2 elementos deberian ser independientes para garantizar que la caida de un nodo no afecte al otro. 

Creamos la estructura de directorios para la instalación
#mkdir -p /opt/alfresco/tomcat
#mkdir -p /opt/alfresco/indices
Tomcat:

#cd /opt/alfresco
#tar zxvf  /tmp/apache-tomcat-6.0.32.tar.gz
#ln -s apache-tomcat-6.0.32 tomcat
Copiamos el contenido del paquete de Alfresco
#unzip alfresco-enterprise-3.4.3.zip -d alfresco
#cp -rp /tmp/alfresco/web-server/* /opt/alfresco/tomcat
En esta copia a parte de los ficheros de Alfresco también se sobreescriben ficheros de configuración de Tomcat. Es necesario editar el fichero context.xml en destino puesto que el valor que tiene impide el funcionamiento del cluster. En el fichero context.xml debemos dejar comentada la línea:

 <!-- Uncomment this to disable session persistence across Tomcat restarts -->
 <!--Manager pathname="" /-->
Activamos el puerto AJP en ambos nodos descomentando en el fichero server.xml la linea

 <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
Configuramos el nombre de la ruta en la directiva Engine del fichero server.xml de los 2 nodos. 
tomcat1:

 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
tomcat2:
 <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat2">
En este punto también vamos a configurar el Cluster de Tomcat tal como se indica en el manual de Apache Tomcat:
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html

Editamos el fichero server.xml dentro de la directiva <Engine>

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                 channelSendOptions="6">

          <Manager className="org.apache.catalina.ha.session.BackupManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"
                   mapSendOptions="6"/>
          <!--
          <Manager className="org.apache.catalina.ha.session.DeltaManager"
                   expireSessionsOnShutdown="false"
                   notifyListenersOnReplication="true"/>
          -->        
          <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                        address="228.0.0.4"
                        port="45564"
                        frequency="500"
                        dropTime="3000"/>
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                      address="auto"
                      port="5000"
                      selectorTimeout="100"
                      maxThreads="6"/>

            <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
              <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
            </Sender>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
          </Channel>

          <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
                 filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>

          <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
                    tempDir="/tmp/war-temp/"
                    deployDir="/tmp/war-deploy/"
                    watchDir="/tmp/war-listen/"
                    watchEnabled="false"/>

          <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
Añadimos el tag distributable que permitirá la replicación de sesiones en el fichero web.xml de alfresco.war y share.war en ambos nodos al final del fichero:

.

.
<distributable/>
</web-app>
MySQL
tomcat1:
mysql> create database alfresco343;
mysql> grant all privileges on alfresco343.* to 'alfresco'@'%' identified by 'alfresco';
NFS
tomcat1:
/etc/exports
/opt/alfresco/alf_data 192.168.1.0/24(rw,no_root_squash,no_subtree_check,async) 
tomcat2:
#mount 192.168.1.122:/opt/alfresco/alf_data /opt/alfresco/alf_data
Apache
tomcat1:
#a2enmod proxy_ajp proxy_balancer proxy

Configuramos el balanceo con los 2 nodos, incluyendo además el balancer-manager que nos permitirá monitorizar, activar y desactivar cada uno de los nodos para realizar las pruebas. Para ello he configurado 2 grupos diferentes de balanceo, uno para Alfresco y otro para Share, cada uno de manera distinta para ver las 2 posibles configuraciones en el fichero /etc/apache2/conf.d/proxyajp.conf
<Location /balancer-manager>
   SetHandler balancer-manager
</Location>

<Proxy balancer://balancer1>
   BalancerMember ajp://192.168.1.122:8009 route=tomcat1
   BalancerMember ajp://192.168.1.12:8009 route=tomcat2
   ProxySet stickysession=JSESSIONID
</Proxy>
ProxyPass /alfresco balancer://balancer1/alfresco
<Proxy balancer://balancer2>
   BalancerMember ajp://192.168.1.122:8009 route=tomcat1
   BalancerMember ajp://192.168.1.12:8009 route=tomcat2
</Proxy>
<Location /share>
ProxyPass balancer://balancer2/share stickysession=JSESSIONID
</Location>
alfresco-global.properties en tomcat2:
#alf_data compartido por nfs
dir.root=/opt/alfresco343/alf_data
#indices en local
dir.indexes=/opt/alfresco343/indices/lucene-indexes
dir.indexes.backup=/opt/alfresco343/indices/backup-lucene-indexes
dir.indexes.lock=/opt/alfresco343/indices/locks
.
.
alfresco.cluster.name=ALFCLUSTER
alfresco.jgroups.defaultProtocol=TCP
alfresco.tcp.initial_hosts=192.168.1.122[7800],192.168.1.12[7800]
alfresco.jgroups.bind_address=192.168.1.12
En el arranque veremos primero como se forma el cluster de tomcat
22-jul-2011 19:38:47 org.apache.catalina.core.StandardService start
INFO: Arrancando servicio Catalina
22-jul-2011 19:38:47 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.32
22-jul-2011 19:38:47 org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
22-jul-2011 19:38:47 org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/192.168.1.12:5000
22-jul-2011 19:38:47 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
22-jul-2011 19:38:47 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:4
22-jul-2011 19:38:48 org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{192, 168, 1, 122}:5000,{192, 168, 1, 122},5000, alive=10519,id={80 9
4 82 -34 95 106 76 118 -85 119 -121 -44 -79 -105 -125 74 }, payload={}, command={}, domain={}, ]
y una vez arrancado Alfresco, el cluster de este:
19:39:29,778  INFO  [cache.jgroups.JGroupsKeepAliveHeartbeatReceiver]
New cluster view with additional members:
   Last View: null
   New View:  [tomcat1-59540|1] [tomcat1-59540, tomcat2-44982]

Una vez arrancados los 2 nodos y comprobando que Alfresco funciona vamos a abrir una pestaña nueva en el navegador con el balancer manager para poder ver en que nodo estamos y poder deshabilitarlo sin tener que parar ningún nodo:



Accediendo a http://192.168.1.122/share vemos que se ha generado tráfico en el worker del primer nodo, por tanto procedo a deshabilitarlo forzando el paso al segundo nodo.

Durate mis pruebas con Share la sesión se ha mantenido sin mostrarse ningún error. En el caso de Alfresco Explorer ha mostrado una pantalla de error de sesión expirada pero al volver a la aplicación ha recuperado la sesión.

Espero que esto os sirva!

Configuracion con Oracle RAC 10g y 11g

Recientemente he tenido la oportunidad de configurar Alfresco contra un Oracle RAC. Además la suerte ha sido doble porque inicialmente se configuró contra un RAC de 10g y posteriormente se ha migrado a un 11g, con lo cual hemos podido comprobar el funcionamiento en ambas versiones.

De cara a Alfresco el tema del RAC es transparente ya que los cambios de configuración se realizan a nivel del driver de conexión. Vamos a ver la configuración utilizada:

db.name=alfresco
db.username=alfresco
db.password=alfresco
db.driver=oracle.jdbc.OracleDriver
db.url=jdbc:oracle:thin:@(DESCRIPTION=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=nodo1-vip.red.dominio.es)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=nodo2-vip.red.dominio.es)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=LAN_APLICACIONES.red.dominio.es)))
db.pool.validate.query=SELECT 1 FROM DUAL
hibernate.default_schema=ALFRESCO

El cambio para Oracle RAC está en la cadena de conexión. Vamos a ver uno a uno los parámetros de esta cadena de conexión:

DESCRIPTION 
contiene el descriptor de conexión, es decir todos los parámetros que se van a usar para conectar. En este caso teniamos el RAC con 2 nodos con lo cual solo teniamos un único descriptor. Sería posible para instalaciones mas complejas tener una lista de descriptores y cada descriptor a su vez con varios servidores. Por ejemplo:

(DESCRIPTION_LIST=
  (DESCRIPTION= 
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (CONNECT_DATA= 
     (SERVICE_NAME=service_name)))
  (DESCRIPTION= 
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (ADDRESS=(protocol_address_information))
   (CONNECT_DATA= 
     (SERVICE_NAME=service_name))))

LOAD_BALANCE

Indica si se van a usar las direcciones de forma aleatoria (activo) o de forma secuencial (desactivado). Se puede especificar cualquiera de estos valores que podemos encontrar en diferentes ejemplos:

on | off | yes | no | true | false

ADDRESS contiene el PROTOCOL, ADDRESS, PORT

que se explican por si mismas

CONNECT_DATA contiene la identificación del servicio .

SERVICE_NAME
En este caso no estamos usando un SID, el cual apuntaría solo a uno de los nodos, si no que se define un servicio a nivel de Oracle y se apunta contra este.

Es posible que nos encontremos ejemplos en los que en la cadena de conexión aparece también el parámetro FAILOVER. Este parámetro esta por defecto activado para los descriptores así que no será necesario incluirlo a no ser que queramos desactivarlo.

Desde el servidor podemos ver como las conexiones se empiezan a balancear entre los nodos:

[tomcat]# lsof -nPi |grep 1521
tnslsnr   22544   oracle   11u  IPv6  996133       TCP *:1521 (LISTEN)
jsvc      28316 alfresco  231u  IPv6 1026752       TCP 172.17.1.154:55223->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  232u  IPv6 1026753       TCP 172.17.1.154:55224->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  233u  IPv6 1026754       TCP 172.17.1.154:55667->172.17.31.21:1521 (ESTABLISHED)
jsvc      28316 alfresco  234u  IPv6 1026755       TCP 172.17.1.154:55226->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  235u  IPv6 1026756       TCP 172.17.1.154:55227->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  236u  IPv6 1026757       TCP 172.17.1.154:55228->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  237u  IPv6 1026758       TCP 172.17.1.154:55671->172.17.31.21:1521 (ESTABLISHED)
jsvc      28316 alfresco  238u  IPv6 1026759       TCP 172.17.1.154:55230->172.17.31.23:1521 (ESTABLISHED)
jsvc      28316 alfresco  239u  IPv6 1026760       TCP 172.17.1.154:55231->172.17.31.23:1521 (ESTABLISHED)

Es importante recordar que el esquema para el parámetro hibernate.default_schema se debe incluir siempre en mayúsculas, ya que de otro modo el primer arranque funcionará correctamente pero en el segundo recibiriamos un error de Schema upgrade failed


http://download.oracle.com/docs/cd/B28359_01/network.111/b28317/tnsnames.htm
http://wiki.alfresco.com/wiki/Database_Configuration#Oracle_example

Bug: Read only y renombrar licencia

Como reza en el JIRA de Alfresco

http://issues.alfresco.com/jira/browse/ALF-7487

Era muy común en las versiones enterprise que de vez en cuando se perdiera la licencia y el repositorio se pusiera en modo lectura. La solución siempre habia sido renombrar la licencia de *.installed a *.lic

Como se puede ver en JIRA, el bug se ha "solucionado" en la 3.4.2, lo pongo entre comillas porque el problema aparece pero con otra cara. Esta vez el repositorio no se queda en read-only pero aparece un warning en el log:

 16:10:38,215 WARN [service.descriptor.DescriptorService] unexpected exception caught and ignored  
 de.schlichtherle.xml.GenericCertificateIntegrityException  
 at de.schlichtherle.xml.GenericCertificate.verify(Unknown Source)  
 at de.schlichtherle.license.LicenseNotary.verify(Unknown Source)  
 at de.schlichtherle.license.LicenseManager.verify(Unknown Source)  
 at de.schlichtherle.license.ftp.LicenseManager.verify(Unknown Source)  
 at org.alfresco.enterprise.license.AlfrescoLicenseManager.verify(AlfrescoLicenseManager.java:148)  
 at de.schlichtherle.license.LicenseManager.verify(Unknown Source)  
 at org.alfresco.enterprise.license.LicenseComponent$1.execute(LicenseComponent.java:147)  
 at org.alfresco.enterprise.license.LicenseComponent$1.execute(LicenseComponent.java:141)  
 at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:381)  
 at org.alfresco.enterprise.license.LicenseComponent$2.doWork(LicenseComponent.java:201)  
 at org.alfresco.enterprise.license.LicenseComponent$2.doWork(LicenseComponent.java:198)  
 at org.alfresco.repo.security.authentication.AuthenticationUtil.runAs(AuthenticationUtil.java:508)  
 at org.alfresco.enterprise.license.LicenseComponent.verify(LicenseComponent.java:197)  
 at org.alfresco.enterprise.license.LicenseComponent.verifyLicense(LicenseComponent.java:101)  
 at org.alfresco.repo.descriptor.DescriptorServiceImpl$1$2.execute(DescriptorServiceImpl.java:206)  
 at org.alfresco.repo.descriptor.DescriptorServiceImpl$1$2.execute(DescriptorServiceImpl.java:199)  
 at org.alfresco.repo.transaction.RetryingTransactionHelper.doInTransaction(RetryingTransactionHelper.java:381)  
 at org.alfresco.repo.descriptor.DescriptorServiceImpl$1.doWork(DescriptorServiceImpl.java:197)  
 at org.alfresco.repo.security.authentication.AuthenticationUtil.runAs(AuthenticationUtil.java:508)  
 at org.alfresco.repo.descriptor.DescriptorServiceImpl.onBootstrap(DescriptorServiceImpl.java:162)  
 at org.springframework.extensions.surf.util.AbstractLifecycleBean.onApplicationEvent(AbstractLifecycleBean.java:56)  
 at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaste  
 r.java:97)  
 at org.alfresco.repo.management.SafeApplicationEventMulticaster.multicastEvent(SafeApplicationEventMulticaster.java:78  
 )  
 at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:294)  
 at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:858)  
 at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:419)  
 at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:261)  
 at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:192)  
 at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)  
 at org.alfresco.web.app.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:63)  
 at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)  
 at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)  
 at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)  
 at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)  
 at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)  
 at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:627)  
 at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)  
 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)  
 at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)  
 at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)  
 at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)  
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)  
 at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)  
 at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)  
 at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)  
 at org.apache.catalina.core.StandardService.start(StandardService.java:516)  
 at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)  
 at org.apache.catalina.startup.Catalina.start(Catalina.java:578)  
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
 at java.lang.reflect.Method.invoke(Method.java:597)  
 at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)  
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)  
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)  
 at java.lang.reflect.Method.invoke(Method.java:597)  
 at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)  

La solución como en el caso anterior es la misma, renombrar el fichero .lic a .installed

Importación masiva con Alfresco Bulk Filesystem import

La entrada de hoy es para explicar como funciona el módulo Alfresco Bulk Filesystem import desarrollado por Peter Monks. Este módulo nos va a permitir importar un conjunto de ficheros permitiendonos incorporar metadatos en el proceso.

Alfresco trae varios mecanismos para importar contenidos:

• Servidor Alfresco JLAN  – permite acceder al repositorio como si fuera una unidad de red de Windows , un servidor FTP, WebDAV o NFS.
• CMIS API
• REST API
• SOAP API
• Ficheros ACP

En todos los casos anteriores necesitamos crear reglas o los mecanismos necesarios usando la API para asignar los metadatos.

Mediante el módulo simplemente creando un fichero con el mismo nombre que el original pero con la extension metadata.properties hará que se lea su contenido y se incorporen los metadatos de forma dinámica.

Por ejemplo, tengo un documento que llamado Documentación.odf y otro Documentación.metadata.properties ubicado en el mismo directorio

Dentro del fichero properties se pondrá el tipo de contenido y cada uno de los metadatos:

  # tipo de contenido
  type=cm:content
  # Aspectos
  aspects=cm:versionable, custom:myAspect
  # Propiedades
  cm\:title=This is the value of the cm:title field.
  cm\:description=This is the value of the cm:description field.
  # Enlace a un tag (es necesario apuntar a la referencia)
  cm\:taggable=workspace://SpacesStore/3da6c395-3a4b-4a57-836d-8e5
  # Propiedad personalizada de nuestro modelo de datos:
  custom\:myProperty=This is the value of the custom:myProperty field.
  # Propiedad con multiples valores
  custom\:mvProperty=first value,second value,third value.
  # Fechas (sólo formato ISO8601)
  cm\:created=2011-06-15T10:00:01.234+01:00
  cm\:modified=2011-06-15T10:00:01.234+01:00

Otra de las ventajas de las que se habla es que la importación mediante este metodo es mucho más rápida, ya que nos ahorramos el overhead de los protocolos y estamos cargando los datos desde un disco local, así que me he decidido a comprobarlo por mi mismo

He subido a alfresco mediante FTP y utilizando Filezilla configurado para subir los ficheros de 1 en 1, (haciéndolo de 2 en dos tuve fallos en varios ficheros y fue más lento).

El tiempo para subir 1,4Gb de datos distribuidos en 679 ficheros fue de 4:24 segundos. Esto sin haber asignado ningún metadato.

A continuación y para poder realizar la prueba con metadatos de forma rápida me situé en la carpeta donde se habían subido los documentos (/opt/alfresco34/alf_data/contentstore/2011/6/14/12) y con un pequeño script cree los ficheros de metadatos introduciendo únicamente el tipo de contenido:

# for i in `find . -type f` ;do echo "type=cm:content" > $i.metadata.properties;done

De esta manera he podido crear  de una forma muy rápida todos los ficheros. He usado el contenido del contentstore porque sabemos que los nombres en el contenstore no tienen espacios, y el miniscript me dio algún problema con los ficheros que tenían espacios en los nombres. El módulo es muy sensible a fallos, si no existe algún fichero de metadatos no se ejecutará.

He comprobado además que en la carpeta del contentstore únicamente están los archivos cargados por FTP y que los nuevos se van a copiar en la hora siguiente.

Ya tenemos los ficheros a subir con sus metadatos. Con la importación del módulo se añade un web-script que nos ofrece una página desde donde podemos iniciar la importación masiva en Alfresco y monitorizar todo el proceso. En mi caso localhost (ojo de no poner barra al final!!):

http://localhost:8080/alfresco/service/bulk/import/filesystem

En esta pantalla pondremos donde se encuentran los ficheros que queremos importar. Esto ha de ser una ruta en el sistema de ficheros y puede ser local o estar montada de forma remota.

El siguiente campo es donde queremos que se ubiquen los ficheros. La página usa Ajax y nos ayudará a auto completar este campo, lo que resulta muy útil.

Una vez lanzada la importación veremos como va el progreso

El resultado fue que se subieron los ficheros en 2 minutos 39 segundos, casi la mitad de tiempo. No está nada mal.

Como nota final,  mencionar que es posible incorporar metadatos a ficheros que ya existen en Alfresco simplemente poniendo los ficheros de metadatos.

ACTUALIZACIÓN:

El formato del fichero de metadatos ya no es un fichero de texto plano, si no que se ha pasado al formato xml para dar un mejor soporte a carácteres unicode. El formato que sigue es:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
  <properties>
    <entry key="key1">value1</entry>
    <entry key="key2">value2</entry>
    ...
  </properties>

Más información

http://blogs.alfresco.com/wp/pmonks/2009/10/22/bulk-import-from-a-filesystem/
http://code.google.com/p/alfresco-bulk-filesystem-import/