JMS sampler update

[Peter Lin <wo...@gmail.com>]

I dug around a bit more with OptimizeIt and verified that Orion's
implementation does indeed create 2 threads for the RMI
initialcontextfactory.

tomorrow I hope to finish implementing the two remaining features and
then commit the code to CVS.  I've decided to go with the
Consumer.recieve() approach, since I can reliably clean up the
subscriber and make sure the threads are destroyed. Although onMessage
approach works, it means the stability of JMeter and the JMS sampler
would be more vulnerable to bugs in JMS implementations.

Whether the sampler uses onMessage(message) or recieve() results in
the same number of threads created during runtime, so I'm going with
the more reliable approach, even if onMessage(message) is recommended
for async messages.

peter

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

Re: JMS sampler update

[Peter Lin <wo...@gmail.com>]

On Tue, 26 Oct 2004 06:56:50 +0100, jastrachan@mac.com
<ja...@mac.com> wrote:
> 
> On 25 Oct 2004, at 21:53, Peter Lin wrote:
> > I dug around a bit more with OptimizeIt and verified that Orion's
> > implementation does indeed create 2 threads for the RMI
> > initialcontextfactory.
> 
> I wouldn't worry too much about glitches in one containers JNDI
> provider.
> 

the threads created for JNDI by orion is constant, so it's not an
issue. I just can't kill them, since they're created by orion's
classes.

> 
> Most decent JMS providers should work for both receive() and
> setMessageListener() approaches. Again I wouldn't worry yourself too
> much with dodgy JMS providers :)

I don't consider Orion dodgy, even if there's a bug in their client :)
 in their defense, a normal application wouldn't need to create a
bunch of consumers, run, stop and create a whole new set of consumers
with sessions and repeat. I'll submit a bug entry to orion once I get
the first release of jmeter out, so they can fix the bug.

> 
> Why not just leave this as a configuration flag so users can choose
> which one they want. (This will also allow folks to double check that
> both options result in about the same performance).
> 

that is definitely an option. I'll clean up the code a bit and make
both available. today I have to run some errands, so I won't get to
check in the code. hopefully tomorrow afternoon.

peter

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org