You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Peter Lin <wo...@gmail.com> on 2004/10/06 05:07:10 UTC
JMS sampler plan
http://wiki.apache.org/jakarta-jmeter/JMS_20Sampler
I wrote up the plan I had in mind.
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JMS sampler plan
Posted by Peter Lin <wo...@gmail.com>.
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
<m....@hccnet.nl> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: JMS sampler plan
Posted by Peter Lin <wo...@gmail.com>.
you can also create a bugzilla entry and attach the files.
peter
On Tue, 12 Oct 2004 13:48:38 +0200, Martijn Blankestijn
<m....@hccnet.nl> wrote:
>
> Can someone commit them to head or how does this work?
>
> Greetings,
>
> Martijn
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: JMS sampler plan
Posted by Martijn Blankestijn <m....@hccnet.nl>.
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: jmeter-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: JMS sampler plan
Posted by Peter Lin <wo...@gmail.com>.
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: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: JMS sampler plan
Posted by Martijn Blankestijn <m....@hccnet.nl>.
Peter Lin wrote:
>http://wiki.apache.org/jakarta-jmeter/JMS_20Sampler
>
>I wrote up the plan I had in mind.
>
>
>peter
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
>
>
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org