The JMeter documentation does an excellent job of describing how to set up a test plan for a JMS provider. However there are still a few provider specific details you need to know:
Make sure you’ve copied all the jars from TIBCO_HOME\ems\6.0\lib to jmeter\lib!
The InitialContextFactory for TIBCO EMS 6.0 is:
com.tibco.tibjms.naming.TibjmsInitialContextFactory
A fault tolerant Provider Url looks like:
tibjmsnaming://machine1:7222,tibjmsnaming://machine2:7222
It’s also worth setting the reconnect_attempt_delay (or count) reasonably high in your connection factory, as it can take a while for failover to succeed.
[LoadTesting] type = topic url = tcp://machine1:7222,tcp://machine2:7222 reconnect_attempt_delay = 10000
If you’re using durable subscribers, you can only have one thread (user) per subscriber as the client id must be unique. And the permissions are different (durable & use_durable).
You can’t use MapMessage, stick with TextMessage.
There’s a bug in JMeter 2.5.1 (fixed in the trunk) that may cause you to see NPEs when getting the connection (InitialContextFactory.lookupContext doesn’t use the map/cache properly).
Look on my works, ye Mighty, and despair! 
Hi Graham,
I’m interested in what you were testing. Did you have a know good performance level you wanted to assert the SUT delivered, or was this an experiment to see where your TIBCO instance failed?
Could you post a follow up, with the driver for testing TIBCO this way, and what your findings are? Even if its to say, testing TIBCO with jmeter sucks because…
Many thanks,
Stu.
Good question :)
At the time, we were mainly interested in the effects failover of an FT pair had. Either loss of a Tibco instance, or the RAC/TAF db cluster underlying. Up till now we’ve purely been testing the infrastructure (Tibco included), rather than what we’re delivering. Although that’s soon to change!
I’ll try and find time to write something up, in more detail.