...
By having a publish and subscribe sampler, it means a single test plan can have two thread groups running concurrently. One thread group can have X threads publishing, while the thread group for the subscribers can have a different number of threads. this should allow for a wide variety of test scenarios. Using the same connection for N producers/consumers will measure the effect of connection on performance.
Here's some details about what parameters the sampler GUI will have.
- radio buttuns: JNDI, manual
Parameters for JNDI
...
- InitialContextFactory 2. provider url 3. connection factory 4. topic 5. user 6. password
Parameters for manual connections
...
- concrete connection factory class 2. topic 3. user 4. password
Common parameters
...
- message type: text or object 2. textarea 3. directory of files to choose randomly 4. specific file 5. use as monitor
After some discussion with James, it seems to make sense to treat the Session as the client. This way, a single connection may have multiple Sessions. I still need to work out the details of how measure the time for subscribers, since they will get notified of when new messages come in. For the first implementation, I'm going to by pass a connection factory. Once it the details of how subscribers will work, I'll move on to the connection factory.
For the connection factory, the plan right now is to make a real JMS connection pool. Most likely I'll borrow heavily from JDBC pool connection API and modify it to meet the needs of the JMS Sampler. This way, I can have it implement TestListener to setup and tear down the connection pool propertly. It would be bad to create a pool of connections to JMS at the start of a test, but not close those connections when the test ends.
Here are screen captures of the GUI so far.
...
http://www.apache.org/~woolfel/subscriber.png
http://www.apache.org/~woolfel/publisher.png