TIBCO domain needs a repository where all service data are stored. This repository can be in xml files near TIBCO Administrator or it can be in a database. When you run both master and secondary servers of TIBCO Administrator, it is better to store repository in a database, because if it stored in files, both Administrator instances have to maintain its own copy of the repository. So, it could be a problem with syncing in some cases. When the copy of repository on the secondary server is out of sync, we can experience a problem with deploying and starting applications.
The errors seen in the admin log file:
2010 Feb 15 13:24:21:267 GMT +4 Error [ApplicationConfiguration] AESDKJ-0000 [http-8090-Processor11] COM.TIBCO.hawk.talon.MicroAgentException: Request timed out
2010 Feb 15 13:24:23:720 GMT +4 Error [Administrator] AESDKJ-0000 [http-8090-Processor11] ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error
And in the tsm log files errors are similar to:
2010 Feb 15 13:23:10:335 GMT 4 tsm Debug  [TRA-000000] tsm.syncBindings: probably admin server is not available. exception message: com.tibco.pof.entity.EntityStoreException: error creating client Server not responding
Caused by: com.tibco.infra.repository.OperationFailedException: error creating client Server not responding at com.tibco.infra.repository.RepoFactory.newClient(RepoFactory.java:3046)
Workaround is to stop secondary Administrator and deploy then. Solution is to stop secondary Administrator, remove all repository files on the secondary server, then copy repository files from the master. Usually all repository files in the
<tibco_home>\administrator\domain\<domain_name>\data folder. Strategic decision – migration to a database storage.
By the way, when you plan a backup/restore solution, it makes sense to backup repository only on the master TIBCO Administrator, but in the case of recovery, restore it on both at the same time.
You may experience this problem, when can’t run TIBCO Administrator, Hawk, BW process or any other TIBCO component. In log files you can find messages related to OpenSSL libraries libeay32.dll and ssleay32.dll. The reason is that TIBCO messaging components use OpenSSL, but other applications may also use OpenSSL and have already installed these dlls in
C:\WINDOWS\SysWOW64 depending on the platform.
When you start the application, it unsuccessful attempts to find dll files near the binary, then tries to find in the System32 folder. But dlls from other version of OpenSSL are there. Your application will use it, instead correct version from TIBCO Rendezvous bin folder for example, even you have this folder in the PATH. TIBCO product can’t call the necessary functions, gives an error and stops working.
Solution is take libeay32.dll and ssleay32.dll from TIBCO Rendezvous bin folder to the bin folders of every installed TIBCO component. Or just copy and replace to
Update: these libraries are needed for SSL communication using secured daemons (RVSD or RVSRD) only, if you are not using RVSD or RVSRD then just remove the tibrvjsd.jar file from the classpath.
If you need to change password for admin user in TIBCO Administrator please keep in mind that it is not enough just to change the admin password from Administrator GUI. But whole procedure is not so complex.
- Always have full backup of Administrator configuration files and repository files or database!
- Change admin password in the Administrator GUI.
- Start DomainUtility on each machine in the TIBCO Domain, select Server Settings => Update Domain Credentials and change password there or use domainutilitycmd and ChangeDomainCredentials.xml as a template.
- Make sure that password has been changed in tibcoadmin_<domain>.tra file. Or you can put new password manually there like this
repo.securePassword=#!tibco and use obfuscate utility to encrypt it.
- Restart Administrator daemon and Hawk Agents everywhere in TIBCO domain.
That’s all. But, if you change password in the Administrator GUI only, and Administrator service (on the Windows) or daemon (on the Unix) has been restarted as nothing is working as before, then you can find picture like this on your screen when you try to login into Administrator. If your daemon has been started using nohup utility as mine, then you have a chance to find little more in the nohup.out file:
com.tibco.infra.repository.RepoSecurityException: Can not read policy domain for repository server HM : Failed in authentication.
If you start DomainUtility at this time and try to change password there, following error will appear.
To solve this problem you need to disable security option in the tibcoadmin_<domain>.tra file
then restart Administrator.
Now it is possible to continue the procedure from step 3: DomainUtility will work. When password will be changed, you can enable security back in tra file. Do not forget to restart Administrator daemon and Hawk Agents everywhere in the domain!
After all, redeployment of all applications may be necessary.