Hi Peter,
My solution for JMS queuing is ready. It is tested on WebSphere Application Server 5 and MQ Series 5.3.
The screen consists of the following groups:
JMS Resources
* JNDI name of the Queue Connection Factory
* JNDI name of the Send queue
* JNDI name of the Receive queue
(If the receive queue is empty, temporary queues will be used if the communication style is request/response)
Message
* Communication Style
Value are "Request Response" and "Request Only".
* Timeout
If a fixed response queue is defined, this is the timeout to use for the response messages.
* Content of the message
* JMS Properties
These properties are transferred to the JMS Properties of the JMS Message
JNDI Properties * Initial Context Factory * Provider URL
With the WebSphere Application client you do not have provide the initial context factory and the provider url. Therefore I do not see a problem if no initial context factory and provider url are provided: the InitialContext is constructed with the default constructor.
I want to provide a default configuration screen for the JNDI properties, so that multiple JMS samplers can share the same JNDI configuration. The default properties are however not being used if the initial context and provider url are empty on the configuration screen of the Message Sampler. I have been looking at the HTTP Default configuration but i can not figure out how the configuration mechanism works so that the sampler 'auto-magically' takes the default configuration if the entries on the sampler screen are not filled. Any clues?????
Can someone commit them to head or how does this work?
Greetings,
Martijn
Peter Lin wrote:
it's funny you mention that. that last couple of days, I've been struggling to get Orion to to work remotely for JMS. Here is a link to my blog entry today.
http://woolfel.blogspot.com/2004/10/jms-jndi-and-orion-well-i-spent-last.html
I'll go into greater detail about my plan of attack. One of the things James Strachan and will pugh would like is to be able to create a specific number of connections. Here is a link to blueGrass http://docs.codehaus.org/display/BG/Home .
In order to make a QueueConnection and TopicConnection, there's two jndi lookups a client is suppose to make. Atleast according to the recommendations of the official jms spec.
1. lookup InitialContextFactory with the Context.PROVIDER_URL and Context.INITIAL_CONTEXT_FACTORY
2. lookup the connection factory, which should be either QueueConnectionFactory or TopicConnectionFactory
3. create the appropriate Session, which is either TopicSession or QueueSession
4. from the session create either publisher/subscriber or reciever/requestor
My plan was to first write 2 samplers for pub/sub messaging, than write 2 for reciever/requestor. Right now I'm writing a generic pub/sub messaging client to encapsulate the JNDI lookup. The tricky part is when someone wants to have say 10 publishers for every connection.
to support that, I plan to write some kind of simple connection pool, and make it a manager component. I haven't worked out the exact details, but the basic idea right now is the manager randomly picks a connection and gives it to the sampler to create the publisher/subscriber. After that, the sampler only interacts with the publisher/subscriber, so it doesn't need a full blown connection pool API like jdbc.
In terms of the configuration, I don't think it should default. My reasoning is JMS API purposely tries to hide the implementation details of the connection factory, so if no jndi properties are provided, it should fail and log an error in jmeter's log.
Does that help clarify things? that's my long winded response :)
peter
Hi Peter,
Thanks for your email. I have read the plan
I have been working on a JMS Sampler which supports 'fire and forget' and 'request/reply' semantics for regulare queues, not for publish and subscribe. I think this can be complementary to your plans.
I have a problem with the default configuration mechanism. I have a configuration screen with an initial context factory and a provider url. In the jms screen i have an entry for these two fields also. What i do not understand is what I have to do to let the sampler 'magically' use the entries of the default configuration screen if the fields are not filled in on the jms screen. I have been staring at the HTTP solution but i can not determine how they have done it there.
thanks
Martijn
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
