QUESTION

What is the difference between hot-hot deployment, hot-warm deployment and hot-cold deployment?

ANSWER
In hot-warm deployment TIBCO EMS fault tolerant servers must have access to a shared state, and they are deployed as a primary and secondary pair. When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl). The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried). If none of the attempts succeed, the connection fails. For example, to identify the first server as tcp://server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify: serverUrl = tcp://server0:7222, tcp://server1:7344 Hot-hot deployment would mean that both servers can accept client connections at the same time, which is not supported by EMS at the moment. Currently, we provide fault tolerance support for EMS both on Hot-Warm and Hot-Cold setup. By referring to Hot-Cold configuration, we mean High Availability. HA is a hot-cold setup, which typically requires more time to failover, though the failover time mainly depends on the clustering software. When using clustering software like Veritas, the secondary server is started by the clustering software after its remounted the shared store to the secondary host. The newly started EMS server then initializes its state from the backend store. To achieve EMS HA, hardware for connected storage (e.g. SAN) and clustering software (e.g. Veritas) are required. In the event of an EMS server failure, the cluster service will restart the service on the same node. If its the node hosting EMS service that fails, the cluster service will move the entire resource group to another node in the cluster. That is the EMS service will be started on the other node. So that, If you are using HOT-COLD setup (only one EMS server instance running at a time), you have to use the server URL in your client application as: tcp://<hostname>:<port>,tcp://<hostname>:port to ensure that the client reconnects to the new server instance if the old server instance goes down. If you are using JNDI lookup, you have to set the URL in the same way in the factories.conf as well. You have to define your client reconnection logic like reconnect attempt count and reconnect attempt delay in the factories.conf as well as per your existing setup.

QUESTION

How many connections will the EMS server be able to service if the tibemsd.conf parameter "max_connections" is set to zero?

ANSWER
How many connections will the EMS server be able to service if the tibemsd.conf parameter "max_connections" is set to zero? The documentation claims that by setting this value to zero would allow the EMS server to service an unlimited number of simultaneous connections. The max_connections parameter is purely artificial. EMS uses techniques such that only system resources will limit this number. If you specify the value as 0 then the EMS server will allow as many connections as it can realistically handle (realistically being a relative term). Every connection the EMS server accepts will require some memory usage which may be fairly sizeable at 50-100KB per connection. Assuming that the OS does not limit the number of opened files (sockets), which, by the way, is always possible to configure, the assumption would be that system memory will become the bottleneck for the number of simultaneous connections the server can service. For large number of connections customers may want to consider 64-bit versions of the product, available under Solaris and Linux.

QUESTION
If you have topic to queue bridge, what happens to the PERSISTENT messages published to that topic if the EMS server is stopped and/or crashes? Is the message lost?

ANSWER
If the publisher sends a PERSISTENT message to a topic that is bridged to 'failsafe' queue(s), then EMS Server will send a response to the publisher only after the message has been persisted on disk (for the failsafe queue(s)). In this case no message will be lost, because if the EMS server crashes before the message has been persisted on disk, the publisher will get an exception. If the bridged destination queue is not failsafe, EMS Server writes asynchronously on disk, and there is still a time window that could cause message loss in case of OS crash.

QUESTION
We sometimes get an error message like "'Failed to connect to the server at tcp://myhost1234:7222'.

ANSWER
If you are performing a JNDI lookup, the ConnectionFactory should then include the fully qualify name. For example, let's say that the QueueConnectionFactory is defined like this in the EMS Server: From the tibemsadmin tool:

show factory QueueConnectionFactory Factory: = QueueConnectionFactory JNDI names: "QueueConnectionFactory" URL = tcp://7222 ClientID = Then, when an application performs a JNDI lookup on the connection factory, EMS Server will return tcp://<EMS Server hostname>:7222. The hostname will be the value returned by the system call to gethostbyname(). The hostname will be the one that is printed in the EMS Server startup banner. When this ConnectionFactory is returned to a remote client and then the client creates a Connection based on that ConnectionFactory, it will use the URL from the ConnectionFactory. If, on this machine, the "short hostname" is not resolved, then that will fail. To solve this issue, modify the ConnectionFactory URL in the server to include the correct hostname. From the admin tool: setprop factory QueueConnectionFactory url=tcp://<hostname>:7222

QUESTION
EMS 4.4 has fix for temporary queue accumulation issue but issue persists even with EMS 4.4, why?

ANSWER
To take benefit of the fix of temporary queue accumulation in EMS server that was introduced in EMS 4.4, you have to use both EMS server 4.4 as well as the clients library from EMS 4.4. The protocol messages exchanged between the server and client were changed to achieve the temporary destination compliance. So, both server and clients need to be from 4.4 releases. Since the EMS 4.4 is the latest release, its client libraries are not included in any of the existing TRA version (till TRA 5.5.1). So, you should copy all jar files from the /clients/java directory of EMS 4.4 installation to the /TRA_HOME/hotfix/lib folder. After this restart the Adapter and other TIBCO applications, you should not experience the temp queue(s) accumulation in the EMS server any more.

QUESTION
Can I create an ACL on a Dynamic Queue?

ANSWER
Yes, you can create an ACL on a dynamic queue if there is a static queue, which is a "parent" of that dynamic queue in the configuration file (queues.conf). For example, if you have the following specified in queues.conf: queue.test.> secure In acl.conf, QUEUE=queue.test.1 USER=john PERM=receive,send Or use tibemsadmin tool: grant queue queue.test.1 user=john send,receive Then user "john" can create, send, and receive into queue queue.test.1, while other users won't be allowed to.

QUESTION
In the bin directory of the installation, there is a datastore directory with a async-msgs.db and a sync-msgs.db file. In tibemsd.conf, store=datastore. What does it mean? So, does sync and async prefix to storage and the two files hold sync and async persistent messages respectively?

ANSWER
TIBCO Enterprise Message Service uses the "store" value as the name of the directory used to store the messages. Inside this directory, TIBCO Enterprise Message Service uses three files meta.db, sync-msgs.db and async-msgs.db. These two last files hold synchronous and asynchronous persistent messages respectively.

QUESTION
How will EMS behave with high number of connections?

ANSWER
We cannot provide benchmarks, because performances can be impacted by too many variables, Throughput performance is affected by a number of factors including:

1. Message size 2. Number of clients 3. Bandwidth 4. Processor and NIC card performance 5. If message selectors are used. 6. If tracing and/or statistics is enabled 7. Message delivery mode 8. Acknowledgment mode 9. Implementation of OS 10. Expiration time 11. Authorization 12. Route/bridge 13. Transactions .... and many other factors. As the actual throughput is determined by many factors as mentioned above, the best benchmark is the one that you run tests in your own environment, with the hardware that you plan to use and the message flow and characteristics that you plan to use in production. We provide customers with two sample programs "tibjmsMsgProducerPerf.java and tibjmsMsgConsumerPerf.java (located in the <EMS_INSTALL>/samples/java directory) which can be used to generate messages with multiple threads and connections. You can use these samples to simulate topic, queue, messages size, threads, delivery mode .... Alternatively, customers may consult our PSG Architect for the EMS applications to improve their application performance, and analyse like the complexity/scale of your scenario.

QUESTION
How the message selector works on the server side?

ANSWER
It depends on the destination that is used. For topics: When the server receives a message, it goes through the list of all potential consumers (consumers that subscribe directly to the topic or to a child topic). For each consumer, the server checks if the message satisfies the consumer's selector (if any). If the message passes the test, then the server delivers the message to the consumer. Note that if all consumers for that topic use a selector and an incoming message is rejected by all consumers, the server will discard that message. For queues: When the server receives a message, if the queue is exclusive, the unique active receiver will receive the message if the receiver's selector (if any) does not reject that message. If the queue is non-exclusive, and there are multiple receivers, the message is delivered in a

round-robin fashion. If the candidate consumer has a selector, the server will evaluate the selector. If the message is not rejected, it is delivered to that consumer. Otherwise, the next consumer is evaluated, etc... Note that if all consumers for that queue use a selector and an incoming message is rejected by all consumers, the message will be pending in the queue until a consumer accepting that message (no selector or selector accepting the message) is started. In the case of an exclusive queue, this means that the message will be pending until the active consumer to the exclusive queue is stopped.

QUESTION
When I use setJMSExpiration() before sending the message, the message stays in the JMS Server and is never expired. I also found that the following methods do not work: setJMSDestination(), setJMSDeliveryMode(), setJMSPriority(), setJMSMessageID(), setJMSTimestamp(), setJMSRedelivered().

ANSWER
This is normal and expected per JMS Specifications. Here is a comprehensive table of what header fields set, when and why: JMSDestination JMSDeliveryMode JMSPriority JMSExpiration These fields are set in that order: - by send() or publish() method if application uses send() or publish() method form which takes those parameters (refer to the API reference for more information) (example: Sending a NON_PERSISTENT message to a queue, with a priority of 6, and no message expiration sender.send(myMsg, DeliveryMode.NON_PERSISTENT, 6, 0); ) - by MessageProducer, by default delivery=PERSISTENT, priority=4 and ttl=0. There are methods to set different defaults for a particular producer (refer to the API reference for more information) (example: Suppose that sender is a QueueSender sender.setDeliveryMode(DeliveryMode.NON_PERSISTENT); ) - destination *either* specified when producer is created or is a parameter to send() or publish() call. (example: create a sender with no destination QueueSender sender = myQueueSession.createQueueSender(null); Now, to send a message to a specific queue, you need to provide the queue sender.send(myQueue, myMessage);

) JMSMessageID JMSTimestamp - set by send() or publish() method unless disabled, in that case left empty (timestamp=0, messageID=null). JMSRedelivered - set by the provider in the received message, makes no sense in sent message ======================================================== Setting all fields above in the message by application, while possible, makes no effect whatsoever and does not really make sense. ======================================================== JMSReplyTo JMSCorrelationID JMSType - only set by the application. Provider does not ever change these fields and transfers them in the message as they were set by the application. (example: set the JMSReplyTo to a temporary queue TemporaryQueue myTempQueue = myQueueSession.createTemporaryQueue(); myMessage.setText("This is a test"); myMessage.setJMSReplyTo(myTempQueue); )

QUESTION
How are transactions managed in TIBCO Enterprise Message Service?

ANSWER
The JMS specification provides for two different transaction management mechanisms: (1) internal transaction management via transacted sessions (2) external transaction management via XA. The former is a required part of the JMS specification, and is implemented in TIBCO Enterprise Message Service since the first release; the latter is an optional part of the specification, and is implemented since release 3.0.0.

QUESTION
What does durable mean in the context of access control?

ANSWER
The ability to create a durable subscriber on the given destination.

QUESTION
What happens when EMS is writing to disk and runs out of disk space, how does it behave?

ANSWER
If you run out of disk space while writing persistent messages to disk you will get a SEVERE ERROR with an I/O exception on the EMS server log. The error could be differently worded for failsafe and non failsafe destinations. On the other hand the client application would throw javax.jms.JMSException: Failure storing message kind of error message. Messages should not be lost if you are using Persistent delivery mode on a failsafe destination with disk caching disabled.

QUESTION
On host A, I have a topic publisher that sends messages with a time-to-live of 30 seconds. It is connected to serverA, which has an active route to serverB on host B. There is a durable subscriber connected to serverB running on host B. ServerB crashed and as result messages backed-up in serverA. When I restarted serverB and the subscriber, messages began to flow again from the serverA to serverB. However, none of the messages were being delivered to the subscriber because they were all expired in serverB. What happened?

ANSWER
The expiration time is checked at both the server and the client. If you send messages while serverB and the subscriber are not running, you should clearly see that they expire in serverA after 30 seconds. However, if the system clocks between host A and B are not in sync, and you restart serverB and the subscriber, you could see the messages being expired by serverB. If you intend to set expiration on messages, we would suggest that you try your best to have the system clocks in sync as much as possible, and take into account any time differences when choosing a time-to-live value.

QUESTION
What happens if the maxbytes limit set to a topic is exceeded?

ANSWER
The maxbytes limit is for consumers of that topic; not for the destination itself. We do not cause the publisher to fail when a durable subscriber reaches its maxbytes. Another durable may not have reached its limit and needs to be able to continue receiving messages.

QUESTION
Does TIBCO Enterprise Message Service use file(s) to persist messages?

ANSWER
Yes.

QUESTION
In tibemsd.conf, what is logfile used for?

ANSWER
If logfile is specified, then the trace items specified in the log_trace parameter are directed to that file. Notice that log_trace and console_trace can have different trace items.

QUESTION
It seems that the inbound messages rate, as shown by the "show server" command of the tibemsadmin tool, is sometimes much higher than the actual producer message rate. Why?

ANSWER
TIBCO Enterprise Message Service (EMS) 4.3 and earlier versions account for both bridged and monitor messages generated in the server as part of the inbound message rate. It explains why the inbound rate is sometimes higher than the rate of actual incoming messages. From EMS 4.4 onward, this behavior is changed so that the inbound message rate only reports messages that originate from connections, not messages generated internally due to bridged destinations or monitor messages.

QUESTION
Choose between multiple connections and multiple sessions

ANSWER
Since cpu and memory usage vary according to application design for the connections, unless you have a very good reason for using mulitple connections, we would recommend typical applications to use a single connection with multiple sessions. The following explains the difference between connection and session, which will be helpful for you to decide which implementation you will choose. Connections support concurrent use. A connection serves several purposes: * It encapsulates an open connection with a JMS provider. It typically represents an open TCP/IP socket between a client and the service provider software. * Its creation is where client authentication takes place. * It can specify a unique client identifier. * It provides a ConnectionMetaData object. * It supports an optional ExceptionListener object. Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection. Other more advanced applications may use several connections. The JMS API does not architect a reason for using multiple connections; however, there may be operational reasons for doing so. On the other hand, a Session object is a single-threaded context for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine (JVM), it is considered a lightweight JMS object. A session serves several purposes: * It is a factory for its message producers and consumers. * It supplies provider-optimized message factories. * It is a factory for TemporaryTopics and TemporaryQueues. * It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names. * It supports a single series of transactions that combine work spanning its producers and consumers into atomic units. * It defines a serial order for the messages it consumes and the messages it produces. * It retains messages it consumes until they have been acknowledged. * It serializes execution of message listeners registered with its message consumers. * It is a factory for QueueBrowsers. A session can create and service multiple message producers and consumers. One typical use is to have a thread block on a synchronous MessageConsumer until a message arrives. The thread may then use one or more of the Session's MessageProducers. If a client desires to have one thread produce messages while others consume them, the client should use a separate session for its producing thread. Once a connection has been started, any session with one or more registered message listeners is dedicated to the thread of control that delivers messages to it. It is erroneous for client code to use this session or any of its constituent objects from another thread of control. The only exception to this rule is the use of the session or connection close method. As you can imagine, for a basic client application need, a Session can accommodate most

requirements and much cheapter to create and manage than a Connection. Thus, multiple sessions over a single connection is the recommended use for most applications.

QUESTION
In TIBCO Enterprise Message Service, how is connection managed, short-lived, on-demand, with a pool of connections? Or long-lived, for the duration of the client lifespan?

ANSWER
Currently it is client lifespan, i.e., as long as the connection instance within the client is not closed.

QUESTION
Can we attach the two different versions EMS server running on one box to administrator?

ANSWER
only one EMS version can be registered with administrator domain. When you install higher version of EMS, it does not put into different folder like TRA, but just upgrade it. Only one version of RV, EMS and Hawk can work with administrator. It is by design of TIBCO Products.

QUESTION
Is it okay to run two different versions of EMS servers as FT pair (For eg. 3.1 and 4.1 EMS servers) ?

ANSWER
This is NOT considered as a supported option. As we do make enhancements in the FT protocol in the newer versions for better performance and reliablity we assume that the EMS versions are the same when configuring a FT pair.

QUESTION
How does RV bridge message translation work?

ANSWER
The message translation is done in a way that if the RV/RVCM message contains a field named JMSBytes, JMSObject, JMSStream, JMSText, it will be translated as its JMS equivalent: BytesMessage, ObjectMessage, StreamMessage and TextMessage. For instance, to import a message as a TextMessage, the RV message should contain a single field called "JMSText" with a string value. To import a BytesMessage, the RV message should contain a single field called "JMSBytes" with a TibrvMsg.OPAQUE field value, etc... If none of these fields is present, the RV/RVCM message is translated to a MapMessage. However, there is an exception. In order to support old RV5 applications that may send a *unique* field called "DATA", EMS Server was importing and translating to a JMS type message based on the type of the "DATA" field. So, if an RV/RVCM message containing a *single* field called "DATA" with a string type, it would be imported as a TextMessage. If it is an opaque type, it will be translated as a BytesMessage. The important thing to notice is that it is a *single* field called "DATA". If you have and application which gets messages exported from JMS, and this application expects a "DATA=" tag, there should not be any issue. The JMS application creates a MapMessage and adds a field called "DATA", you can add also other fields, and the message will be exported correctly to Rendezvous. For instance, here is a MapMessage containing two fields "DATA" and "TIME" received with tibrvlisten: C:\tibrvlisten topic.sample.exported tibrvlisten: Listening to subject topic.sample.exported [2007-04-19 10:33:08]: subject=topic.sample.exported, message={JMSHeaders={JMSDeliveryMode=2 JMSPriority=4 JMSTimestamp=1101925988859 JMSMessageID="ID:EMS-SERVER.B5C24D4BC4:1"} JMSProperties={} DATA=[50 opaque bytes] TIME=[14 opaque bytes]} Please notice that in transports.conf, there are two properties called "export_headers" and "export_properties". By default, they are enabled, which means that the RV message resulting from a JMS export will contain additional nested fields such as JMSHeaders and JMSProperties. If you do not want the RV message to have these fields, you need to set export_headers and export_properties to false. With these parameters disabled, the RV message received will look like this: [2007-04-19 10:38:32]: subject=topic.sample.exported, message={DATA=[50 opaque bytes] TIME=[14 opaque bytes]}

QUESTION
Why QueueBrower could not be used to browse temporary queues?

ANSWER
QueueBrower could not be used on temporary queues, neither are there other ways to browse the content of temporary queues. This is because EMS 4.4.x is compliant with JMS spec. The temporary destination's scope is within the connection and only be accessed within the same connection.

QUESTION
How can I determine the connection information of a $TMP$ queue?

ANSWER
There is no way we can guaranty to get the creator of the temporary queue, because the creator may already be gone. In a request/reply scenario, the requestor usually is the creator. 1. run "show stat consumers queue=<name>" to get the connection ID and user name. 2. run "show connections type=q user=<user name>". to get host name and user name or ClientID to help you narrow down the problem. 3. after EMS 4.4, run show queue <TMP queueName>, you can get connectionID information.

QUESTION
How to use tibemsadmin commands if destination name has spaces in between them?

ANSWER
tibemsadmin commands can be used with destination names which have spaces by using quotes. For example, if we want to delete the queue name "x y z", use it as mentioned in the bracket ( delete queue "x y z" ). This is true for any commands dealing with names which have spaces in between them.

QUESTION
Why do I get "ERROR: unable to bind to LDAP server as: 'cn=svc_tibco_ldap,cn=Users,dc=global,dc=thenational,dc=com', Can't contact LDAP server"?

ANSWER
This error could be caused by mismatch between ldap_url and CN of LDAP server's certiicate. First, find out CN of LDAP server's certificate; then use this CN as ldap_url in tibemsd.conf. For example, subject DN of LDAP server's certificate ========================

CN=ldap-dt,OU=TIBCO,O=suppprt,... This error could be caused by mismatch between ldap_url and CN of LDAP server's certificate. First, find out CN of LDAP server's certificate; then use this CN as ldap_url in tibemsd.conf. For example, subject DN of LDAP server's certificate ======================== CN=ldap-dt,OU=TIBCO,O=suppprt,... Then, set up ldapurl as, ======================== ldap_url = ldaps://ldap_dt:10639 If ldap-dt is not resolvable to EMS server, you could add it to hosts file.

QUESTION

Creating a Message Listener for Asynchronous Message Consumption

EMS allows a Message Consumer to consume messages either synchronously or asynchronously. For synchronous consumption, the Message Consumer explicitly calls a receive method on the topic or queue. For asynchronous consumption, you can implement a Message Listener that serves as an asynchronous event handler for messages. A Message Listener implementation has one method, onMessage, that is called by the EMS server when a message arrives on a destination. You implement the onMessage method to perform the desired actions when a message arrives. Your implementation should handle all exceptions, and it should not throw any exceptions. Once you create a Message Listener, you must register it with a specific Message Consumer before calling the connections start method to begin receiving messages. A Message Listener is not specific to the type of the destination. The same listener can obtain messages from a queue or a topic, depending upon the destination set for the Message Consumer with which the listener is registered. The J2EE 1.3 platform introduced message-driven beans (MDBs) that are a special kind of Message Listener. See the J2EE documentation for more information about MDBs. Java Create an implementation of the MessageListener interface, create a MessageConsumer, and use the MessageConsumer objects setMessageListener() method to register the Message Listener with the Message Consumer:
public class tibjmsAsyncMsgConsumer implements MessageListener { /* Create a connection, session and consumer */

...

MessageConsumer QueueReceiver = session.createConsumer(queue); QueueReceiver.setMessageListener(this); connection.start();

1) Create Message Listener 2) Register With Specific Message Consumer 3) Connection Start.

Do not use the Session.setMessageListener() method, which is used by application servers, rather than by applications