You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Elliotte Harold <er...@gmail.com> on 2007/07/03 18:09:32 UTC
Unit testing, stup and tearDown
I have a bunch of ActiveMQ tests that are exhibiting weird behavior. That
is, sometimes they pass and sometimes they fail. I can run a suite and see
seven failures. Then run those tests individually and watch them all pass.
This suggests to me that I'm not properly initializing the queue in setUp or
clearing it out in tearDown. The relevant chunks of code look like this:
public class FooSchedulerTest extends TestCase {
private ConnectionFactory factory;
private FooScheduler scheduler;
private MessageConsumer consumer;
private MessageProducer producer;
private Connection connection;
private FooConfig config;
private int fooID = 10;
private Session session;
protected void setUp() throws Exception {
factory = new
ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
config = new FooConfig();
config.setFooID(fooID);
Foo foo = new Foo(config, null);
scheduler = new FooScheduler(factory, foo, new
LinkedBlockingQueue());
connection = factory.createConnection();
Destination dispatcher = new ActiveMQQueue(
FooScheduler.DISPATCHER_QUEUE_NAME );
Destination callback = new ActiveMQQueue(
FooScheduler.COMPLETED_JOBS_QUEUE_NAME );
connection.start();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
consumer = session.createConsumer(dispatcher);
producer = session.createProducer(callback);
super.setUp();
}
protected void tearDown() throws Exception {
connection.close();
super.tearDown();
}
Can anyone see anything I might be doing wrong or forgetting to do?
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by Elliotte Harold <er...@gmail.com>.
On 7/6/07, James Strachan <ja...@gmail.com> wrote:
>
>
> FWIW lots of the test cases in ActiveMQ derive from
> EmbeddedBrokerTestSupport which explicitly creates/stops a broker
> which might help work around this glitch.
>
> e.g. in your test try creating, before the connection (and stopping
> after the connection close) a BrokerService...
Thanks. I'll try that.
http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html
>
> (Another smelly hack is to just fork the jvm for each test case and
> only put one test method per class :)
The Ant builds that fork the VM do seem to pass the tests more reliably than
when I run them from inside Eclipse.
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by James Strachan <ja...@gmail.com>.
On 7/11/07, Elliotte Harold <er...@gmail.com> wrote:
> On 7/6/07, James Strachan <ja...@gmail.com> wrote:
> >
> > I don't see anything wrong I'm afraid. Maybe there's some timing issue
> > where the close of the connection is a tad asynchronous in some aspect
> > of closing the broker down properly.
> >
> > FWIW lots of the test cases in ActiveMQ derive from
> > EmbeddedBrokerTestSupport which explicitly creates/stops a broker
> > which might help work around this glitch.
>
>
>
>
> Is this available only in Subversion or is it bundled in any of the JARs? I
> didn;t find it in any obvious location aside from SVN.
Its in the activemq-core-tests.jar. Or you could cut-n-paste the code
from activemq-core/src/test/java/*
--
James
-------
http://macstrac.blogspot.com/
Re: Unit testing, stup and tearDown
Posted by Elliotte Harold <er...@gmail.com>.
On 7/6/07, James Strachan <ja...@gmail.com> wrote:
>
> I don't see anything wrong I'm afraid. Maybe there's some timing issue
> where the close of the connection is a tad asynchronous in some aspect
> of closing the broker down properly.
>
> FWIW lots of the test cases in ActiveMQ derive from
> EmbeddedBrokerTestSupport which explicitly creates/stops a broker
> which might help work around this glitch.
Is this available only in Subversion or is it bundled in any of the JARs? I
didn;t find it in any obvious location aside from SVN.
If it's only in SVN, will it work with 4.1?
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by James Strachan <ja...@gmail.com>.
I don't see anything wrong I'm afraid. Maybe there's some timing issue
where the close of the connection is a tad asynchronous in some aspect
of closing the broker down properly.
FWIW lots of the test cases in ActiveMQ derive from
EmbeddedBrokerTestSupport which explicitly creates/stops a broker
which might help work around this glitch.
e.g. in your test try creating, before the connection (and stopping
after the connection close) a BrokerService...
http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html
(Another smelly hack is to just fork the jvm for each test case and
only put one test method per class :)
On 7/3/07, Elliotte Harold <er...@gmail.com> wrote:
> I have a bunch of ActiveMQ tests that are exhibiting weird behavior. That
> is, sometimes they pass and sometimes they fail. I can run a suite and see
> seven failures. Then run those tests individually and watch them all pass.
>
> This suggests to me that I'm not properly initializing the queue in setUp or
> clearing it out in tearDown. The relevant chunks of code look like this:
>
> public class FooSchedulerTest extends TestCase {
>
> private ConnectionFactory factory;
> private FooScheduler scheduler;
> private MessageConsumer consumer;
> private MessageProducer producer;
> private Connection connection;
> private FooConfig config;
> private int fooID = 10;
> private Session session;
>
> protected void setUp() throws Exception {
> factory = new
> ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
>
> config = new FooConfig();
> config.setFooID(fooID);
> Foo foo = new Foo(config, null);
> scheduler = new FooScheduler(factory, foo, new
> LinkedBlockingQueue());
> connection = factory.createConnection();
> Destination dispatcher = new ActiveMQQueue(
> FooScheduler.DISPATCHER_QUEUE_NAME );
> Destination callback = new ActiveMQQueue(
> FooScheduler.COMPLETED_JOBS_QUEUE_NAME );
> connection.start();
> session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
> consumer = session.createConsumer(dispatcher);
> producer = session.createProducer(callback);
> super.setUp();
> }
>
> protected void tearDown() throws Exception {
> connection.close();
> super.tearDown();
> }
>
> Can anyone see anything I might be doing wrong or forgetting to do?
>
> --
> Elliotte Rusty Harold
> erharold@gmail.com
>
--
James
-------
http://macstrac.blogspot.com/
Re: Unit testing, stup and tearDown
Posted by Elliotte Harold <er...@gmail.com>.
I've fixed/kludged the latest instance of this problem by manually draining
the queue before sending in my test messages; e.g.
while (true) {
TextMessage m1 = (TextMessage) consumer.receive(3000);
if (m1 == null) break;
}
The problem seems to be that under some circumstances previous test methods
leave messages somewhere that the new test can find them. They are not
cleaned up in tearDown() and the queue is not reinitialized fresh in
setUp(). At least that's my current hypothesis.
Why the the queue is not reinitialized fresh in setUp() I don't understand.
It certainly looks like it is. Probably I'm not doing something right. I
know I'm leaving active threads around after some of my tests complete, and
I need to be more careful about shutting those down, but that alone did not
seem to fix this problem.
I may need to understand more about just what a queue of the type
vm://localhost?broker.persistent=false is really doing.
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by Elliotte Harold <er...@gmail.com>.
After adding Derby to the classpath and async=true to the broker string, the
tests now fail both when run individually and when run in a group. I still
don't understand why the tests are fialing at all, and some other tests are
failing sporadicall. Sometimes I can run two test suites in a row and the
first one fails and the second one passes or vice versa.
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by Elliotte Harold <er...@gmail.com>.
On 7/9/07, Rob Davies <ra...@gmail.com> wrote:
>
> It would be interesting to see if setting the async flag = false
> makes a difference on the vm:// transport:
> e.g. factory = new ActiveMQConnectionFactory("vm://localhost?
> broker.persistent=false,async=false");
The immediate result of that is breaking all my unit tests with
NoClassDefErrors because Derby is not found.
I'll try adding Derby to the classpath and seeing what happens then.
--
Elliotte Rusty Harold
erharold@gmail.com
Re: Unit testing, stup and tearDown
Posted by Rob Davies <ra...@gmail.com>.
It would be interesting to see if setting the async flag = false
makes a difference on the vm:// transport:
e.g. factory = new ActiveMQConnectionFactory("vm://localhost?
broker.persistent=false,async=false");
cheers,
Rob
On Jul 3, 2007, at 5:09 PM, Elliotte Harold wrote:
> I have a bunch of ActiveMQ tests that are exhibiting weird
> behavior. That
> is, sometimes they pass and sometimes they fail. I can run a suite
> and see
> seven failures. Then run those tests individually and watch them
> all pass.
>
> This suggests to me that I'm not properly initializing the queue in
> setUp or
> clearing it out in tearDown. The relevant chunks of code look like
> this:
>
> public class FooSchedulerTest extends TestCase {
>
> private ConnectionFactory factory;
> private FooScheduler scheduler;
> private MessageConsumer consumer;
> private MessageProducer producer;
> private Connection connection;
> private FooConfig config;
> private int fooID = 10;
> private Session session;
>
> protected void setUp() throws Exception {
> factory = new
> ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
>
> config = new FooConfig();
> config.setFooID(fooID);
> Foo foo = new Foo(config, null);
> scheduler = new FooScheduler(factory, foo, new
> LinkedBlockingQueue());
> connection = factory.createConnection();
> Destination dispatcher = new ActiveMQQueue(
> FooScheduler.DISPATCHER_QUEUE_NAME );
> Destination callback = new ActiveMQQueue(
> FooScheduler.COMPLETED_JOBS_QUEUE_NAME );
> connection.start();
> session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> consumer = session.createConsumer(dispatcher);
> producer = session.createProducer(callback);
> super.setUp();
> }
>
> protected void tearDown() throws Exception {
> connection.close();
> super.tearDown();
> }
>
> Can anyone see anything I might be doing wrong or forgetting to do?
>
> --
> Elliotte Rusty Harold
> erharold@gmail.com
Rob Davies
'Go further faster with Apache Camel!'
http://rajdavies.blogspot.com/