TIBCO Applications
The following error comes when EMS details are not present in the tra file.
Could not create connection with JMS server.[ Queue Connection Factory = QueueConnectionFactory User Name = admin Provider URL = isUFO = false]
Resolution:-
Add the EMS client libraries by running the traUpgradeManager utility with the –ems option.
Example:
TIBCO BW / Adapter services take long time to start.We gotta add the following property to the base bwengine.tra file then restart the slow-starting services and see if the startup speeds up:
java.property.java.security.egd=file:/dev/./urandom
If you prefer, you can test the same property on one slow application service first by adding it to the application’s .tra file. If it works, apply it to the base bwengine.tra.
If the solution above helps, consider the following option below for a global fix:
Open the <jre_home>/lib/security/java.security configurations file, and edit/modify the property “securerandom.source” as follows:
Change the property
securerandom.source=file:/dev/urandom
to
securerandom.source=file:/dev/./urandom
and save the change.
Probably You Might get rid of indefinite starting up issue, provided all the resources in the Admin server are enough for management.
If you encounter the following error in your adapter logs :-
| Error | AER3-910005 | Exception: “JMS error: “Not allowed to create destination tracking=#B0fo–uT5-V4zkYM9A/UbWgUzas# |
The following are the possibilities and pointers to be checked :-
Cause
While testing for failover we found that the adapter is not failing over properly to the secondary ems server in case if the primary is down. The adapter logs show the below error. The adapter does not pick up any messages when this error occurs.
Advisory: _SDK.ERROR.JMS.RECEIVE_FAILED : { {ADV_MSG, M_STRING, “Consumer receive failed. JMS Error: Illegal state, SessionName: TIBCOCOMJmsTerminatorSession, Destination: Rep.adcom.Rep-COMAdapter_Rep_v1.exit” } {^description^, M_STRING, “” } }.
The only way to resolve this is to restart the adapter so that it reconnects to the ems server. Then it picks up the messages.
“JMS Error: Illegal state” usually happens when a JMS call or request occurs in an inappropriate context. For example, a consumer is trying to receive message while the JMS server is down. In your case you are saying that this is happening during EMS failover from machine1 to machine2.
One thing to keep in mind is that depending on the number of oustanding messages, connections, and other resources managed by EMS there may be a brief period before the secondary server is ready to accept connections.
Clients that disconnect will typically attempt to reconnect, however there is a limit to the number of reconnection attempts (as well as the interval between attempts). These are specified at the connection factory level in factories.conf. Here are some of the applicable settings:
reconnect_attempt_count – After losing its server connection, a client program configured with more than one server URL attempts to reconnect, iterating through its URL list until it re-establishes a connection with an EMS server. This property determines the maximum number of iterations. When absent, the default is 4.
reconnect_attempt_delay – When attempting to reconnect, the client sleeps for this interval (in milliseconds) between iterations through its URL list. When absent, the default is 500 milliseconds.
reconnect_attempt_timeout – When attempting to reconnect to the EMS server, you can set this connection timeout period to abort the connection attempt after a specified period of time (in milliseconds).
It may also be helpful to specify heartbeats between the adapter and the EMS server. This way if the EMS server is brought down either gracefully or ungracefully the connection will be reset when the configured number of heartbeats is missed. This should then trigger the reconnection attempts described above. The heartbeat settings are defined in the tibemsd.conf. Here are some relevant settings:
client_heartbeat_server – Specifies the interval clients are to send heartbeats to the server.
server_timeout_client_connection – Specifies the period of time server will wait for a client heartbeat before terminating the client connection.
server_heartbeat_client – Specifies the interval this server is to send heartbeats to all of its clients.
client_timeout_server_connection – Specifies the period of time a client will wait for a heartbeat from the server before terminating the connection.
Working in IT, you’re likely doing the same tasks over and over. What if you could solve problems once and then automate your solutions going forward? Ansible is here to help.
Every business is a digital business. Technology is your innovation engine, and delivering your applications faster helps you win. Historically, that required a lot of manual effort and complicated coordination. But today, there is Ansible – the simple, yet powerful IT automation engine that thousands of companies are using to drive complexity out of their environments and accelerate DevOps initiatives.
No one likes repetitive tasks. With Ansible, IT admins can begin automating away the drudgery from their daily tasks. Automation frees admins up to focus on efforts that help deliver more value to the business by speeding time to application delivery, and building on a culture of success. Ultimately, Ansible gives teams the one thing they can never get enough of: time. Allowing smart people to focus on smart things.
Ansible is a simple automation language that can perfectly describe an IT application infrastructure. It’s easy-to-learn, self-documenting, and doesn’t require a grad-level computer science degree to read. Automation shouldn’t be more complex than the tasks it’s replacing.
Unless automation is designed for teams, it’s just another tool. For it to serve people, automation needs to be smarter and simpler.
Simplicity grows more important the more people it impacts. That’s why Ansible is automation designed with everyone in mind.
Imagine you have a TIBCO Suite in Linux and you have a monthly maintenance, wherein you are supposed to stop the entire TIBCO Suite to give your servers some momentary rest and start them all again, just like a power nap.
You have to take multiple ssh sessions to kill all services manually and when the server comes up we need to manually start the TIBCO Suite each component wise, Ansible meanwhile resolves this discrepancy .
I have created a playbook to stop & Start the entire TIBCO Suite
You all can customize the playbook as required
Please Find my GITHUB URL for the playbook and instruction
https://github.com/chriszones2000/Ansible-Playbooks
Hari's Technical Space 
You must be logged in to post a comment.