Solucionado (ver solução)
Solucionado
(ver solução)
14
respostas

WildFly 10.1.0 erro na inicialização do servidor

Prezados,

Na inicialização do WildFly 10.1.0 está ocorrendo um erro que não estou conseguindo determinar a causa. Segue o trecho do arquivo server.log, onde é apontado o erro:

2017-11-14 11:03:35,399 INFO  [org.hibernate.tool.hbm2ddl.SchemaValidator] (ServerService Thread Pool -- 63) HHH000229: Running schema validator
2017-11-14 11:03:35,404 INFO  [org.hibernate.tool.hbm2ddl.SchemaValidator] (ServerService Thread Pool -- 62) HHH000229: Running schema validator
2017-11-14 11:03:35,594 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 67) WFLYCLINF0002: Started UBIMensagens-1.0-1.3.3.ear.UBIMensagens-war-1.0-1.3.3.war cache from web container
2017-11-14 11:03:35,642 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) WFLYCLINF0002: Started routing cache from web container
2017-11-14 11:03:35,653 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 66) WFLYCLINF0002: Started UBIPobox.ear.UBIPobox-war-1.0.war cache from web container
2017-11-14 11:03:35,665 INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0002: Started client-mappings cache from ejb container
2017-11-14 11:03:35,693 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.ejb.remoting.connector.client-mappings.installer: org.jboss.msc.service.StartException in service jboss.ejb.remoting.connector.client-mappings.installer: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Duplicate key [org.jboss.as.network.ClientMapping@147c79f3]
    at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133)
    at java.util.HashMap.merge(HashMap.java:1254)
    at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
    at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
    at java.util.Iterator.forEachRemaining(Iterator.java:116)
    at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
    at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
    at org.wildfly.clustering.server.registry.CacheRegistry.getEntries(CacheRegistry.java:123)
    at org.jboss.as.ejb3.remote.LocalEjbReceiver.registryAdded(LocalEjbReceiver.java:454)
    at org.jboss.as.ejb3.remote.RegistryCollectorService.add(RegistryCollectorService.java:54)
    at org.jboss.as.ejb3.remote.RegistryInstallerService.start(RegistryInstallerService.java:65)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
    ... 3 more

2017-11-14 11:03:36,016 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "UBIMensagens-1.0-1.3.3.ear")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
2017-11-14 11:03:36,020 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "UBIPobox.ear")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
2017-11-14 11:03:36,023 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {
    "WFLYCTL0080: Failed services" => {"jboss.ejb.remoting.connector.client-mappings.installer" => "org.jboss.msc.service.StartException in service jboss.ejb.remoting.connector.client-mappings.installer: Failed to start service
    Caused by: java.lang.IllegalStateException: Duplicate key [org.jboss.as.network.ClientMapping@147c79f3]"},
    "WFLYCTL0412: Required services that are not installed:" => ["jboss.ejb.remoting.connector.client-mappings.installer"],
    "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined

Qualquer informação sobre como resolver o erro é bem vinda. Obrigado, Anderson Bestteti

14 respostas

Olá, Anderson!

O erro é de Duplicate Key quando tenta mapear os client members do ejb container.

Você está tentando executar mais de um servidor ao mesmo tempo na mesma máquina? Se estiver, elas precisam ter nomes únicos.

Olá Arthur,

Obrigado pelo retorno, em primeiro lugar.

Embora a configuração do WildFly esteja preparada para trabalhar em cluster, esse problema ocorre em uma instalação onde eu só tenho uma instância do servidor de aplicação rodando. Eu achei no fórum do JBoss um posto com o mesmo erro, mas a resposta não ficou clara para mim, devido a minha pouca experiência. Também a resposta dada não foi marcada como solução para o problema. Segue o link para você conferir: https://developer.jboss.org/thread/272990

O ambiente onde roda o WildFly 10.1.0 é um CentOS 7 64Bits e Java 1.8 update 151.

Eu já fiz várias instalações do ambiente anteriormente e nunca tive esse erro. Não seu o que fazer para corrigir o deploy da aplicação no WildFly. Arthur, você teria alguma orientação. Atenciosamente, Anderson

Anderson,

Como que você está usando o cluster? Está usando o WildFly em modo Domain? Por mais que tenha somente uma instância, dependendo de como estiver configurado pode ser que ele esteja identificando mais de um servidor ou similar.

Se estiver usando o modo Domain, um teste a ser feito para saber se é a configuração do domain é executar o seu servidor em modo Standalone.

O ideal é revisarmos o seu arquivo XML de configuração. Pode colocar ele no PasteBin e colar a URL aqui para nós revisarmos o XML?

Colocar no pastebin conseguimos visualizar melhor e até salvar o seu arquivo aqui para revisar melhor.

-- Arthur Ferreira

Oá Arthur,

Obrigado pelo retorno! O Wildfly está rodando sozinho numa VM com CentOS 7, embora a configuração feita no projeto está feita para ele trabalhar em cluster. Eu não comentei isso antes, mas esse deploy vinha funcionando bem no WF 10.1.0.

Originalmente, o projeto que ajudei a desenvolver usava o WF 9.0.1. Por um problema no Apache CXF, que vinha no WF 9.0.1, tivemos que fazer o upgrade para WF 10.1.0, onde o bug do Apache CXF está corrigido.

Dito isso, volto ao arquivo de configuração. Arthur, por favor, você pode me dizer qual o arquivo XML de configurção do WF você quer eu faça upload para o PasteBin? Desculpe-me pela pergunta, mas é que sou beginner no WildFly e estou correndo para aprender e entender como configura-lo.

Obrigado, mais uma vez. Anderson Bestteti

Olá, Anderson!

Então, depende de como você está executando o seu WildFly.

Como que você está executando ele? Qual comando?

-- Arthur

Olá Arthur,

Eu não mandei para o PasteBin os arquivos de configuração do WildFly 10.1.0, mas eles estão disponíveis em https://developer.jboss.org/message/977990#977990. A instalação, como eu disse anteriormente, está com a configuração preparada para rodar em cluster. Entretanto, a instalação que eu fiz, foi só de uma instância do WF numa VM CentOS 7.

Obrigado, Anderson

Olá, Anderson.

Eu vou responder aqui e no JBoss Developer para manter um histórico do que fizermos, blz?

Por favor, faça um teste. Pare o servidor, remova o deploy UBIMensagens-1.0-1.3.3.ear e reinicie o servidor novamente.

Vamos ver se o problema é da sua configuração do JBoss ou se é um problema da aplicação.

Eu tenho a forte impressão que pode ser a aplicação, mas precisamos isolar o problema de configuração primeiro.

Outra coisa, antes de reiniciar seu servidor, verifique se não tem nenhuma instância Java do JBoss presa rodando. Use o comando:

ps -ef | grep java

-- Arthur

Combinado, Arthur. Assim que eu tiver o resultado, farei um no post. Obrigado, Anderson

Olá Arthur,

O arquivo server.log do WilFly 10.1.0 não apresenta o erro após eu ter removido os arquivo EARs da aplicação.

Sendo assim, a suspeita é de que seja algum problema na aplicação?

Obrigado, Anderson

solução!

Olá, Anderson.

Parcialmente. Aparentemente só acontece quando você faz o deploy da aplicação.

Você tem alguma outra máquina, VM, ou qualquer instância do JBoss rodando na rede? Mesmo que não esteja configurada para cluster?

Nos logs indicam que há duas máuqinas no cluster e, usando a configuração padrão, terão o mesmo nome (por isso o erro).

Se não tiver outra máquina rodando, pode ser o caso que eu descrevi de ter um processo perdido na máquina, por isso pedi para verificar com o comando que citei na minha última mensagem.

-- Arthur

Olá Arthur,

Aparentemente você matou a charada. Eu tenho sim essa mesma instalação do WidFly 10.1.0 rodando em outras VMs na mesma rede.

Você poderia me informa em que arquivo XML e qual propriedade eu mudo o nome do cluster, por favor?

Enquanto você não responde, eu vou procurar essas informações na documentação do WildFly 10.1.0. Eu até estou cogitando em mudar essa configuração para rodar standalone.

Nós temos um projeto do Eclipse que usa o Gradle para instalar o ambiente de produção. O Gradle foi configurado para baixar o WildFly 10.1.0, instala-lo e configura-lo com os arquivos de config pré-definidos no projeto. Além disso, o Gradle cria o datasource no WildFly e faz o deploy dos dois EARs da aplicação. Por fim, o Gradle configura o CentOS 7 para iniciar o WildFly no startup do sistema operacional, deixando o ambiente completamente de produção operacional.

O detalhe é que essa pré-configuração do WildFly foi toda montada para suportar um ambiente em Cluster. Eu no fim não me dei conta que as outras VMs, que têm essa mesma instalação, usam a mesma configuração de cluster. Logo, essa nova VM que criei deve estar tentando fazer join no cluster e, por erro de configuração, o deploy da aplicação está apresentando aquele erro que está no arquivo server.log.

Atualizo esse post assim que eu tiver o resultado da troca do nome do cluster ou uso de uma configuração standalone.

Obrigado, Anderson Bestteti

Olá, Anderson!

Respondendo suas perguntas:

Você poderia me informa em que arquivo XML e qual propriedade eu mudo o nome do cluster, por favor?

O arquivo é o standalone.xml. Para mudar o nome do cluster você tem que definir o parâmetro instance-id na sua configuração do undertow (linha 409 do seu arquivo standalone.xml):

<subsystem xmlns="urn:jboss:domain:undertow:3.1" instance-id="nomeDoServidor">

O detalhe é que essa pré-configuração do WildFly foi toda montada para suportar um ambiente em Cluster. Eu no fim não me dei conta que as outras VMs, que têm essa mesma instalação, usam a mesma configuração de cluster. Logo, essa nova VM que criei deve estar tentando fazer join no cluster e, por erro de configuração, o deploy da aplicação está apresentando aquele erro que está no arquivo server.log.

Eu recomendo que você entenda como que funciona o cluster do WildFly antes de enviar para produção. Não é exatamente simples, mas também não é algo extremamente difícil. Só merece uma atenção maior.

O WildFly utiliza o mod_cluster para clusterização. O problema que está acontecendo com o seu servidor é que a configuração de cluster padrão do Wildfly utiliza UDP como protocolo de comunicação e faz broadcasting na sua rede. Esse broadcast é uma mensagem enviada na rede em busca de outras máquinas JBoss para serem adicionadas automaticamente ao cluster.

Isso significa que somente uma instância JBoss deve possuir a configuração de cluster. Ela é quem irá gerenciar seu cluster e suas máquinas.

Para isso, nesse cenário, a Red Hat criou o domain mode. No domain mode você consegue gerenciar várias máquinas em vários perfis diferentes, inclusive consegue configurar um cluster de forma mais fácil do que gerenciar máquinas standalone.

A documentação do WildFly é bastante extensa e com detalhes com relação a isso. Tem vários blogs de desenvolvedores e do pessoal de middleware explicando também.

Qualquer coisa é só falar.

-- Arthur

Olá Arthur,

Obrigado pela informação. Farei a alteração no arquivo standalone.xml para testar.

Atualizo o tópico assim que eu tiver o resultado da alteração.

Obrigado pela ajuda! Anderson

Olá Arthur,

Se confirmou a hipótese!

Na sexta passada eu fiz a instalação do WildFly manualmente e consegui fazer o deploy dos EARs da aplicação com sucesso.

O problema está nos arquivos do WF pré-configurados no projeto do Eclipse, que é responsável pela instalação do ambiente. Esses arquivos foram criados a partir do WF 9.0.1, prevendo a configuração em cluster.

Entretanto, é bem provável que o XML de configuração (standalone.xml) do WF 10.1.0 seja um pouco diferente do 9.0.1 e, por esse motivo, a instalação na versão mais nova o WF esteja apresentando problemas.

Arthur, obrigado pelo retorno e atenção. Tenha uma ótima semana!

Atenciosamente, Anderson