Mailing-List: contact jmeter-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JMeter Developers List" <jmeter-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of woolfel@gmail.com designates
 64.233.170.198 as permitted sender)
Message-ID: <27e674a904100807513b592cc@mail.gmail.com>
Date: Fri, 8 Oct 2004 10:51:12 -0400
From: Peter Lin <woolfel@gmail.com>
Reply-To: Peter Lin <woolfel@gmail.com>
To: JMeter Developers List <jmeter-dev@jakarta.apache.org>
Subject: Re: JMS sampler plan
In-Reply-To: <41669945.3020501@hccnet.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <27e674a9041005200760cd42f@mail.gmail.com>
	 <41669945.3020501@hccnet.nl>

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