For some reason, we’ve got a test system that is hooked up to a db2 database that is using DHCP. This would be ok if Portal was configured to talk to the hostname of the database server, but it’s using the IP. So the inevitable happened and the IP of the database changed and the Portal server went down.
So the obvious fix is to change the datasource so it’s using the hostname of the database server, rather than the ip (or set a static IP for the database server, but that wouldn’t really require a whole blog post now would it!).
To do this, fire up the WAS admin console and navigate to datasources.
Your list of datasources might be different to mine, depending on your database, but the principles are the same.
Go into each datasource and at the bottom you will see a properties dialog. Change the old IP to a hostname.
change the IP
All of them need to be changed, so go back into each one and change it. Now run the test, by selecting each one and clicking the test connection button.
You should get a message like this:
successful test connection message
Now start Portal. Hmm, I get this when I try to go to the site….
” Error 404: Initialization of one or more services failed. ”
Check the SystemOut.log :
Caused by: com.ibm.websphere.ce.cm.StaleConnectionException: [ibm][db2][jcc][t4][2043][11550] Exception java.net.SocketException: Error opening socket to server /9.185.226.121 on port 50,000 with message: Operation timed out: connect:could be due to invalid address.DSRA0010E: SQL State = null, Error Code = -4,499
at sun.reflect.GeneratedConstructorAccessor64.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:522)
at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:523)
at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:578)
at com.ibm.ws.rsadapter.AdapterUtil.mapException(AdapterUtil.java:2159)
... 11 more
Hang on, the datasource test worked? Why won’t the server start? It looks like it’s using the old database server IP still!
The answer lies in the transaction logs that WAS uses. These binary log files contain XA transactions that might not have been executed yet. You should take care when messing about with these files – they are there for a reason. But on the other hand, the server won’t start now, so we can hardly make things worse, can we :o) . Stop the server1 and WebSphere_Portal application servers and go to your wp_profile directory. Delete the contents of the tranlog and recoverylogs directories and try to start the server again.
This message should appear in SystemOut :
[4/08/09 15:23:16:825 EST] 00000012 LogHandle I CWRLS0007I: No existing recovery log files found in C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog. Cold starting the recovery log.
[4/08/09 15:23:16:825 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog\log1.
[4/08/09 15:23:16:841 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\tranlog\log2.
[4/08/09 15:23:16:856 EST] 00000012 LogHandle I CWRLS0007I: No existing recovery log files found in C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog. Cold starting the recovery log.
[4/08/09 15:23:16:856 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog\log1.
[4/08/09 15:23:16:856 EST] 00000012 LogFileHandle I CWRLS0006I: Creating new recovery log file C:/WebSphere/wp_profile\tranlog\win61\win61\WebSphere_Portal\transaction\partnerlog\log2.
[4/08/09 15:23:16:903 EST] 00000012 RecoveryManag A WTRN0028I: Transaction service recovering 0 transactions.
Success, now the server will start up!