FRM-92101

by Gilberto C. Andrade on 18 abril 2008

Tagged as: Application-Server, Oracle-Forms,

Você já se deparou com essa categoria (genérica) de erro Oracle? Pois é, esse que me deparei é uma delícia. Vou me acostumar a chamá-lo de delícia, pois dessa forma, no próximo encontro eu não venha a ter um infarto. Perdi praticamente dois dias, rastreando, refazendo, desfazendo a configuração de uma instalação do Servidor IAS 10g no Linux. Veja o sintoma: (Atenção! Esse comportamento pode variar de ambiente para ambiente.)

Sessão do Forms não inicia no cliente, mesmo o forms de teste que usamos para testar a configuração de instalação não funciona. O erro descrito pelo cliente é bem genérico (frm-92101). O cliente envia um print screen da tela com problemas:

Agora com mais detalhes:

No servidor, o log não é de muita ajuda:

oracle@oasibm:/opt/oracle/oas/10.1.2.0.2/server/forms> tail -n 100 -f /opt/oracle/oas/10.1.2.0.2/server/opmn/logs/OC4J~OC4J_BI_Forms~default_island~1
08/02/18 09:27:06 Start process
--------
08/02/18 09:27:12 FormsServlet init():
    configFileName:     /opt/oracle/oas/10.1.2.0.2/server/forms/server/formsweb.cfg
    testMode:           false
08/02/18 09:27:12 Oracle Application Server Containers for J2EE 10g (10.1.2.2.0) initialized
08/02/18 09:40:31 ListenerServlet init()
08/02/18 09:44:07 RunformProcess.connect(): falhou !
08/02/18 09:44:07 Sessão de forms <1> abortada: não é possível a comunicação com o processo de runtime.
08/02/18 09:56:06 RunformProcess.connect(): falhou !
08/02/18 09:56:06 Sessão de forms <2> abortada: não é possível a comunicação com o processo de runtime.

Outro log:

oracle@oasibm:/opt/oracle/oas/10.1.2.0.2/server/forms/server> tail -n 100 -f /opt/oracle/oas/10.1.2.0.2/server/j2ee/OC4J_BI_Forms/application-deployments/formsapp/OC4J_BI_Forms_default_island_1/application.log
08/02/18 10:18:35 Started
08/02/18 10:18:36 formsweb: jsp: init
08/02/18 10:18:36 formsweb: frmservlet: init
08/02/18 10:18:36 formsweb: FormsServlet init():
    configFileName:     /opt/oracle/oas/10.1.2.0.2/server/forms/server/formsweb.cfg
    testMode:           false
08/02/18 10:18:36 formsweb: Started
08/02/18 10:18:51 formsweb: lservlet: init
08/02/18 10:18:51 formsweb: ListenerServlet init()
08/02/18 10:22:27 formsweb: RunformProcess.connect(): falhou !
08/02/18 10:22:27 formsweb: Sessão de forms <1> abortada: não é possível a comunicação com o processo de runtime.
08/02/18 10:22:27 formsweb: Forms session <1> exception stack trace:
java.net.ConnectException: Connection refused
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
        at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
        at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
        at java.net.Socket.connect(Socket.java:452)
        at java.net.Socket.connect(Socket.java:402)
        at java.net.Socket.<init>(Socket.java:309)
        at java.net.Socket.<init>(Socket.java:153)
        at oracle.forms.servlet.RunformProcess.connect(Unknown Source)
        at oracle.forms.servlet.RunformProcess.dataToRunform(Unknown Source)
        at oracle.forms.servlet.RunformSession.dataToRunform(Unknown Source)
        at oracle.forms.servlet.ListenerServlet.doPost(Unknown Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:834)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:340)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:830)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:228)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].server.http.AJPRequestHandler.run(AJPRequestHandler.java:133)
        at com.evermind[Oracle Application Server Containers for J2EE 10g (10.1.2.2.0)].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:186)
        at java.lang.Thread.run(Thread.java:534)

</init></init>

Uma opção para entender melhor o problema é debugar (Opa! Será que existe esse verbo? Será que rastrear ficaria melhor?) a sessão do cliente, ativado da seguinte forma: http://oasibm.secad.to.gov.br:7778/forms/frmservlet?form=test.fmx&config=debug

E ao mesmo tempo monitorar a saída do log:

tail -n 100 -f /opt/oracle/oas/10.1.2.0.2/server/j2ee/OC4J\_BI\_Forms/application-deployments/formsapp/OC4J\_BI\_Forms\_default\_island_1/application.log

Mas por incrível que pareça, no meu caso, o log com a opção de debug ativado não mostrou nada que pudesse ajudar na solução do problema. Mas algo me chamou a atenção:

08/02/19 15:29:42 FormsServlet init():
    configFileName:     /opt/oracle/oas/10.1.2.0.2/server/forms/server/formsweb.cfg
    testMode:           false
08/02/19 15:29:42 Oracle Application Server Containers for J2EE 10g (10.1.2.2.0) initialized
08/02/19 15:29:46 ListenerServlet init()
08/02/19 15:33:22 RunformProcess.connect(): falhou !
08/02/19 15:33:22 Sessão de forms <1> abortada: não é possível a comunicação com o processo de runtime.

Essa falha na inicialização do Forms runtime. Mas, como mencionei no início, desfiz e refiz a configuração do forms nesse servidor. Então o que me restava? Verifiquei também com o pessoal de redes e nada. Me avisaram que não houve mudança alguma no servidor. Bom, a única opção, após fazer uma pesquisa pelo google e principalmente pelo site de suporte da oracle foi, fazer o checklist dos requerimentos da instalação do servidor de aplicações oracle. Para encurtar a história, quando cheguei no tópico 3.9 The /etc/hosts File, olhei o arquivo e a primeira vista não notei nada de anormal:

oracle@oasibm:~> cat /etc/hosts
# special IPv6 addresses
#::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts

ip segunda placa      oasibm.secad
ip primeira placa     oasibm.secad oasibm

Olhando assim, ninguém fala nada a respeito. Mas rodando o programa ping, constatei o problema. Qual ip respondia? Para minha alegria, o segundo ip. Por que alegria, você pode perguntar, é que a ordem estava errada. O certo deveria ser assim:

ip primeira placa     oasibm.secad oasibm
ip segunda placa      oasibm.secad

Aí, foi só parar todos os serviços do servidor, alterar essa configuração e tudo voltou ao normal, aleluia!

Vivendo e Aprendendo

Experiência prática na administração de Banco de Dados

FRM-92101