can you send it to me. I'm working the sampler this week, this way I can compare what you did with the plan I had. In terms of automatic default config properties, looking at the various vendors, the properties are different enough that I was thinking it would be nice to have a default set of configs for the major vendors.
peter On Tue, 12 Oct 2004 13:48:38 +0200, Martijn Blankestijn <[EMAIL PROTECTED]> wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
