Cluster Liferay

Você conhece algum tutorial passo a passo sobre a instalação do cluster Liferay no Glassfish?

Google encontrou-me este writeup chamado how-to-install-e-configure-a-liferay-cluster

Apreciar!

Eu estou trabalhando no mesmo problema, ou muito semelhante – a implantação do arquivo Liferay WAR para um cluster glassfish com dois nós. Eu não tenho configurado completamente corretamente ainda, mas eu tenho implantado com sucesso. Talvez isso também ajude você e possamos comparar as notas.

Aqui está o que eu tive que fazer.

Primeiro, o trabalho de base. O GlassFish é um pouco estranho para mim na maneira como implementa o WAR. Pelo que entendi, os arquivos WAR são explodidos em algum lugar pelo agente do nó, mas você não obtém access para cutucar os arquivos depois que eles são implementados. Isso significa que você ajusta os arquivos de configuração (portal-ext.properties) que precisará reimplantar a cada vez – e o Liferay é muito grande, com ~ 73MB. Isso causará exceções de falta de espaço no PermGen periodicamente e exigirá a reboot do cluster. Portanto, seria sensato definir a opção JVM para aumentar o tamanho do espaço PermGen no glassfish. Há uma boa explicação do problema aqui:

http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space

Essa opção da JVM não resolverá o problema, mas aumentará o atraso entre as reinicializações do cluster (o console glassfish não funcionou para reinicializar, btw; tivemos que fazer isso por meio da linha de comando).

A próxima pergunta foi: onde vão os arquivos JAR de dependência? Estamos operando em um cluster compartilhado executando outros serviços, portanto, colocá-lo na pasta domains / domain1 / lib não funcionará. Colocamos os arquivos JAR de dependência no arquivo war do liferay, no WEB-INF / lib, e parece estar feliz com isso.

Próximo: onde o arquivo de substituição do portal-ext.properties vai? A resposta está novamente no arquivo war do liferay, em WEB-INF / classs. Esse também é um motivo que contribui para a necessidade de reimplantar toda vez que modificamos uma propriedade, conforme discutido acima.

Próximo: contexto. Por padrão, o liferay tenta implantar no contexto raiz “/”. Estamos em um ambiente compartilhado, então implantamos o WAR no contexto / lr1. Em portal-ext.properties, tivemos que definir a propriedade

portal.ctx = / lr1

Próximo: Não faz muito sentido usar o HSQL incorporado em um ambiente em cluster; nós configuramos um nome de JNDI para nosso pool de conexões de database usando o GlassFish. Existem instruções sobre como fazer isso nos guias de documentação do Liferay. No arquivo portal-ext.properties, fomos capazes de colocar

jdbc.default.jndi.name = jdbc / LiferayPool

Nós também não queremos armazenar índices do Lucene no sistema de arquivos. Nós sobrescrevemos essas propriedades no arquivo portal-ext.properties para corrigir isso:

lucene.store.type = jdbc

lucene.store.jdbc.auto.clean.up = true

lucene.store.jdbc.dialect.oracle = org.apache.lucene.store.jdbc.dialect.OracleDialect

Lógica semelhante se aplica ao repository JackRabbit; Atualmente, tenho a seguinte configuração de propriedade (não sei se isso está correto, mas a biblioteca de documentos está funcionando):

jcr.jackrabbit.repository.root = WEB-INF / classs /

Eu tive que colocar o arquivo repository.xml do jackrabbit em WEB-INF / classs também. Esse arquivo xml diz ao jackrabbit que parâmetros de conexão de database devem ser usados ​​(veja a página de configuração do Apache Jackrabbit para mais detalhes). Novamente, não tenho certeza se colocar isso em WEB-INF / classs foi a idéia correta, mas provavelmente tem que ir em algum lugar no arquivo WAR ou estar em algum sistema de arquivos compartilhado para todos os nós em seu cluster compartilharem os mesmos dados .

Eu não mexi com o EHcache ainda, mas eu coloquei na propriedade hibernate:

hibernate.dialect = org.hibernate.dialect.Oracle10gDialect

para o nosso oráculo db. Eu acredito que ele usa a propriedade JDBC padrão acima para referenciar nossa conexão de database JNDI.

O conceito de “Liferay Home Directory” variável sendo “uma pasta acima do servidor home” é algo que eu ainda estou lutando, e isso está me causando erros toda vez que uma solicitação HTTP é enviada relacionada a / opt / ee / license .

O usuário que o liferay está executando como não tem permissão para modificar / opt e, em qualquer caso, é uma má idéia em um ambiente em cluster. Eu não tenho certeza de onde é o cenário, porque quando eu olho tudo o que vejo é

liferay.home = $ {resource.repositories.root}

e

resource.repositories.root = $ {default.liferay.home}

Eu não sei onde default.liferay.home é definido ainda; ainda está trabalhando nisso.

Implantar o liferay em um ambiente de cluster infelizmente não está tão bem documentado, mas espero que isso o ajude de alguma forma.

Boa sorte!

Sendo o Liferay um aplicativo Spring / Hibernate destinado a ser independente do servidor, a maioria de sua configuração de cluster deve ser as seções de cluster de seu arquivo portal (-ext) .properties: Configuração do Hibernate, EHCache e JGroup. A única configuração específica do servidor de aplicativos deve ser o failover de session, como em qualquer aplicativo da Web implantado.