Re: Replicación de permisos en cluster

rafabono_9703 · ‎15 Mar 2011

Buenas tardes, tenemos el siguiente problema, en una configuración en cluster de alfresco 3.2r (2 nodos) no se replican los cambios en la gestión de permisos.
Es decir, si por ejemplo agrego un usuario a un espacio desde un nodo, en el otro nodo no se aprecia dicho cambio hasta que reinicio la aplicación. Buscando un poco por intenet he encontrado esto:

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

y tiene toda la pinta de ser lo que está ocurriendo en nuestra instalación.

¿Alguien conoce alguna otra posible solución que no sea subir la versión de alfresco?

Gracias.

pjcaracuel_2349 · ‎15 Mar 2011

Hola Rafa,

No sabria yo decirte si el bug reportado es el mismo. Se hace referencia a que no refresca bien la seguridad cuando se añaden/eliminan usuarios de un grupo. LA seguridad en si no cambia puesto que esta a nivel de grupo y por tanto no añaden usuarios concretos al documento.

Una cosa, el cluster esta montado en NFS o en GFS? Ya en su dia sobre NFS tuvimos una incidencia parecida.

Saludos

rafabono_9703 · ‎15 Mar 2011

Hola Pedro, qué de tiempo…..

Esta instalación está en GFS. Es realmente raro, ya que por lo demás funciona sin problemas, los metadatos los replican inmediatamente, pero el tema de los usuarios es un verdadero misterio, es como si no actualizase el índice ante los cambios del otro nodo.

rafabono_9703 · ‎15 Mar 2011

He activado los siguientes niveles de log:

log4j.logger.net.sf.ehcache.distribution=DEBUG
log4j.logger.org.alfresco.repo.node.index.IndexTransactionTracker=DEBUG
log4j.logger.org.alfresco.repo.node.index.AVMRemoteSnapshotTracker=DEBUG

Y se ve perfectamente como a la hora de realizar un cambio de permisos, no actualiza la cache. Cuando se agrega un espacio, por ejemplo, sí se actualiza en ambos nodos:

nodo1:

16:25:55,019  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:25:55,031  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:00,019  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:26:00,032  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:05,021  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:26:05,073  DEBUG [node.index.IndexTransactionTracker] Reindexing batch of 1 transactions from Tue Mar 15 16:19:17 CET 2011 (txnId=4258337)
16:26:05,084  DEBUG [node.index.IndexTransactionTracker] Reindex skipping transaction: Transaction[id=4258337, txnTimeMs=2011-03-15T16:26:00.970+01:00, changeTxnId=95edb009-21ac-4035-988d-775082408a2e]
16:26:05,085  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:10,018  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:26:10,030  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:15,014  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:26:15,029  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:20,014  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7ef53270
16:26:20,025  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

nodo2:

16:25:55,019  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:25:55,036  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:00,022  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:26:00,034  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:05,011  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:26:05,015  DEBUG [node.index.IndexTransactionTracker] Reindexing batch of 1 transactions from Tue Mar 15 16:19:17 CET 2011 (txnId=4258337)
16:26:05,023  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:05,052  DEBUG [node.index.IndexTransactionTracker] Reindexing transaction: Transaction[id=4258337, txnTimeMs=2011-03-15T16:26:00.970+01:00, changeTxnId=95edb009-21ac-4035-988d-775082408a2e]
16:26:10,011  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:26:10,024  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:15,013  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:26:15,023  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores
16:26:20,016  INFO  [node.index.IndexTransactionTracker] reindexImpl started: org.alfresco.repo.node.index.IndexTransactionTracker@7a2513d0
16:26:20,027  DEBUG [node.index.AVMRemoteSnapshotTracker] Reindex check complete for AVM stores‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Las opciones que tenemos configuradas actualmente para la ehcache son las siguientes:

# Hibernate cache
hibernate.cache.use_second_level_cache=false

index.tracking.cronExpression=0/5 * * * * ?
index.tracking.adm.cronExpression=${index.tracking.cronExpression}
index.tracking.avm.cronExpression=${index.tracking.cronExpression}

index.tracking.maxTxnDurationMinutes=60
index.tracking.reindexLagMs=1000
index.tracking.maxRecordSetSize=1000

index.recovery.maximumPoolSize=5
index.tracking.maxTransactionsPerLuceneCommit=100

lucene.indexer.maxFieldLength=1000000
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

¿Alguna sugerencia?

pjcaracuel_2349 · ‎15 Mar 2011

Ya ves tio, yo ahora ando por los "madriles". Y la verdad es que me preocupa la incidencia que has abierto. ME estoy cansando de recomendar GFS para cluster y …. me ha dejado un poco desconcertado la incidencia que reportas.

Yo optaria por abrir una incidencia en JIRA

Saludos

rafabono_9703 · ‎16 Mar 2011

Solucionado.

Se ha realizado una modificación en la configuración del cluster (jgroups) y ahora replica correctamente.

Concretamente se trataba de la ip de los nodos que se utiliza a la hora de configurar el cluster:

alfresco.cluster.name=alfceiccluster

# Jgroups
alfresco.jgroups.defaultProtocol=TCP
#alfresco.tcp.initial_hosts=alfceic01[7800],alfceic02[7810]
alfresco.tcp.initial_hosts=precordoc01[7800],precordoc02[7810]

La ip que resuelve precordoc01 y 02 son de la red 192.168.103, configurada en multicast, mientras que la red de alfceic01 y 02 era la 10.240.208. Es necesario que las ip de los nodos que se configuren en el cluster sean las que resuelva el nombre de la máquina, si no, se produce el efecto que hemos visto (no mandaba el refresco de la ehcache de un nodo a otro ante un cambio de permisos).

Replicación de permisos en cluster

Replicación de permisos en cluster