Tag Archives: cluster

Change glassfish password – part 2

Posted on by
Reply

Recently I already posted a bog about this subject, only it wasn’t sufficient enough. So below the exact steps you have to follow to change your admin password in an glasfish cluster environment.

Log in on the admin console, click on domain > Administrator Password, and put in a new password. Click on save. The password is immediatly changes. This does the same as “asadmin update-file-user –authrealmname admin-realm admin” commando, except the update-file-user expects that there is an other user. Default there is only the admin user. Both actions change the keyfile in $GLASSFISH_HOME/domains/domain1/config. I perfer the change password through the console, since I don’t have a second admin user.

next we have to change the .asadminpassword file in the user home. Start asadmin and enter the following commands:

[glassfish@YSGF01 ~]$ asadmin
Use "exit" to exit and "help" for online help.
asadmin> change-admin-password
Please enter the old admin password> [new password]
Please enter the new admin password> [new password]
Please enter the new admin password again> [new password]
Updated .asadminpass file with new password.
Command change-admin-password executed successfully.

Next we have to make sure the the node-agent are aware of the changed password.

asadmin> stop-node-agent nadev01-yenlo
Command stop-node-agent executed successfully.
asadmin> start-node-agent --startinstances=false nadev01-yenlo
Please enter the admin user name>admin
Please enter the admin password>
Redirecting output to /u00/oracle/product/2.2/glassfishesb/glassfish/nodeagents/nadev01-yenlo/agent/logs/server.log
Redirecting application output to /u00/oracle/product/2.2/glassfishesb/glassfish/nodeagents/nadev01-yenlo/agent/logs/server.log
Command start-node-agent executed successfully.
asadmin> list-instances
indev01-yenlo not running
indev02-yenlo running
Command list-instances executed successfully.
asadmin> start-instance indev01-yenlo
Command start-instance executed successfully.

Log in on every node of the cluster, stop the node agent, then start it again without starting the instance on it (–startinstances=false). Then start the instances on it. On this way you can change your password without any down time.

Failed to get ESB_HOME

Posted on by
2

Last week I had to deploy an application on a Oracle SOA Suite cluster. This is something I’ve done frequently the last few weeks and was never a problem until yesterday. Normaly when you deploy an application on IAS you deploy it to an OC4J container, when deploying to a clsuter you deploy it to the group where the containers are memeber of.

So when I deployed this application everything seemd fine, but when I look closer I saw that not all the BPEL processes and ESBs where deployed. When I looked in the opmn log of the esb container I saw the following error: 

log4j:WARN No appenders could be found for logger (wsif).
log4j:WARN Please initialize the log4j system properly.
Warning: Unable to set up connection factory for a resource adapter in esb-dt: java.lang.RuntimeException: failed to get ESB_HOME: java.lang.NullPointerException
Oracle Containers for J2EE 10g (10.1.3.4.0)  initialized
oc4jadmin********************request.isUserInRole(oc4j-administrators))=true
oc4jadmin********************request.isUserInRole(oc4j-administrators))=true

Also when I deleted the BPEL Domain it didn’t removed from the ESB. I got the following error in the log.xml of th ESB: 

<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2009-05-12T09:32:22.993+02:00</TSTZ_ORIGINATING>
<COMPONENT_ID>tip</COMPONENT_ID>
<MSG_TYPE TYPE="ERROR"></MSG_TYPE>
<MSG_LEVEL>1</MSG_LEVEL>
<HOST_ID>(HOSTNAME)</HOST_ID>
<HOST_NWADDR>(IP)</HOST_NWADDR>
<MODULE_ID>esb.server.dispatch</MODULE_ID>
<THREAD_ID>16</THREAD_ID>
<USER_ID>oracle</USER_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID><UNIQUE_ID>10.9.8.38:17610:1242113515884:3</UNIQUE_ID><SEQ>0</SEQ></EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>Destroying JMSDequeuer failed</MSG_TEXT>
<SUPPL_DETAIL><![CDATA[javax.jms.InvalidDestinationException: JMS-235: Can not link the durable subscriber name with a topic in unsubscribe method.
at oracle.jms.AQjmsSession.unsubscribe(AQjmsSession.java:3994)
at oracle.j2ee.ra.jms.generic.SessionWrapper.unsubscribe(SessionWrapper.java:455)
at oracle.tip.esb.server.dispatch.JMSDequeuer.unsubscribeDeferredSubscriber(JMSDequeuer.java:513)
at oracle.tip.esb.server.dispatch.JMSDequeuer.destroy(JMSDequeuer.java:453)
at oracle.tip.esb.server.dispatch.JMSDequeuer.destroy(JMSDequeuer.java:442)
at oracle.tip.esb.server.dispatch.agent.ESBWork.stop(ESBWork.java:185)
at oracle.tip.esb.server.bootstrap.DesignTimeResourceAdapter.stop(DesignTimeResourceAdapter.java:161)
at oracle.j2ee.connector.ResourceAdapterWrapper.stop(ResourceAdapterWrapper.java:266)
at com.evermind.server.connector.deployment.ConnectorArchive.stopResourceAdapter(ConnectorArchive.java:2192)
at com.evermind.server.connector.deployment.ConnectorArchive.stop(ConnectorArchive.java:2156)
at com.evermind.server.connector.deployment.ConnectorArchive.destroy(ConnectorArchive.java:2108)
at com.evermind.server.ApplicationStateRunning.stopOrDestroyActiveRunningStateObjects(ApplicationStateRunning.java:1102)
at com.evermind.server.ApplicationStateRunning.destroyActiveRunningStateObjects(ApplicationStateRunning.java:1051)
at com.evermind.server.Application.stateCleanUp(Application.java:3633)
at com.evermind.server.Application.destroy(Application.java:792)
at com.evermind.server.ApplicationServer.destroyApplications(ApplicationServer.java:2289)
at com.evermind.server.ApplicationServer.destroy(ApplicationServer.java:2086)
at com.evermind.server.ApplicationServerShutdownHandler.run(ApplicationServerShutdownHandler.java:93)
at java.lang.Thread.run(Thread.java:595)
]]></SUPPL_DETAIL>
</PAYLOAD>
</MESSAGE>

Solution to this problem was to set the opmn ports of both tiers of the cluster the same, some how the cluster does work when this is not the case, except from some part..

Stop the AS tier, check for a free port with netstat and change the opmn.xml. Set the local, request and remote ports of both tiers to the same value. In other words, set request to 6010, local to 6110 en remote to 6210 on both tiers.