Message and File Transports

A **JMS Publisher** aimed at an order queue looks deceptively simple in the GUI: a destination name, a message body, press play. In practice the first three failures a team hits are all about the lookup chain in front of the broker, not about the message. ## The lookup chain The sampler does not open a socket to a broker. It builds a JNDI `InitialContext`, looks up a connection factory in it by name, looks up the destination, and only then publishes. Every field on the JMS Publisher panel feeds one of those three steps: - **Initial Context Factory** — the class name of the JNDI provider, e.g. `org.apache.activemq.jndi.ActiveMQInitialContextFactory`. - **Provider URL** — where that factory should connect, e.g. `tcp://localhost:61616` or `vm://localhost`. - **Connection Factory** — the JNDI *name* under which the factory is registered, commonly `ConnectionFactory`. - **Destination** — the JNDI name of the queue or topic. ActiveMQ lets you create one on the fly with the `dynamicQueues/NAME` or `dynamicTopics/NAME` prefixes. - **Use Authorization**, **User**, **Password** — credentials for the JMS provider. The password is stored unencrypted in the `.jmx`. ## The two ways to supply the context The **Use jndi.properties file** checkbox switches off only the context-building fields. Ticked, JMeter calls `new InitialContext()` with no properties of its own, so the JNDI environment comes entirely from a `jndi.properties` resource on the classpath, and the GUI greys out **Initial Context Factory**, **Provider URL** and **Use Authorization** with its **User**/**Password**. The catch is the phrase *on the classpath* — dropping the file next to the `.jmx` is not enough; the usual fix is to add its directory to the `user.classpath` property. Unticked, those fields build the context instead. **Connection Factory** and **Destination** stay live in both modes: they name what is looked up in the context, not how the context is made. Teams that run one plan against several brokers usually keep the fields and drive them from properties rather than shipping a `jndi.properties` per environment. ## What the download does not ship JMeter's JMS samplers compile against the Jakarta Messaging API only. The component reference says it plainly for all three JMS elements: *"JMeter does not include any JMS implementation jar; this must be downloaded from the JMS provider and put in the lib directory."* So the checklist for a new machine is: 1. Download the broker's client JAR (and its own dependencies). 2. Copy them into JMeter's `lib` directory. 3. Restart JMeter — the classpath is built at startup. 4. Repeat on **every** injector, because a distributed run does not ship JARs to the remote engines. At 6.0.0 the API on the classpath is `jakarta.jms-api` 3.1.0 and every sampler class imports `jakarta.jms.*`. A client JAR written against the older `javax.jms` package therefore cannot satisfy the lookup at all — the `instanceof jakarta.jms.ConnectionFactory` check in `Utils.getConnection` simply never matches, and the lookup dies with `Expected jakarta.jms.ConnectionFactory, found <your class>`. (The JMS Point-to-Point sampler is the one that demands a `jakarta.jms.QueueConnectionFactory`.) When you pick a client build, pick the Jakarta one. ## Static or per-sample destinations The **Setup** radio decides when the destination name is resolved: | Setup | Meaning | |---|---| | `At startup` | the destination is looked up once per thread, on that thread's first sample, and reused for every later sample in that thread | | `Each sample` | the name is evaluated per sample, so it may contain a variable | Publishing to a per-order queue name needs `Each sample`; a single `ORDERS` queue is cheaper on `At startup`. ## The rest of the panel, briefly **Number of samples to aggregate** controls how many messages one sample publishes in a loop — the default is `1`. **Expiration** defaults to `0`, meaning the message never expires; **Priority** defaults to `4` on the JMS scale of `0` to `9`. **Message source** chooses between a file, a random file from a folder, and the text area; **Message type** chooses Text, Map, Object or Bytes. **Reconnect on error codes (regex)** is empty by default, which means an error never triggers a reconnect. ## Where it goes wrong - The client JAR was put in `lib/ext` (which is for JMeter plugins) instead of `lib`. - `jndi.properties` exists but is not on the classpath, so the lookup silently uses defaults and fails. - The connection factory *name* was confused with the factory *class name* — the Connection Factory field wants the JNDI name. - A `javax.jms`-era client JAR was downloaded for a JMeter 6 install. - The JAR was added on the controller only, and the remote engines fail at the first sample.