One problem with Rob's method of initialization is you have to
re-initialize the broker for each unit test which I'd rather not do
for performance reasons.
The problem with the recommended approach James mentioned in the docs
(turning persistence off), is what about when you specifically want to
test the persistence functionality and how your application uses it?
I'm trying to use the local jmx server to do the purge, but it gets an
InstanceNotFoundException for the MX bean. (code below):
MBeanServer jmxServer = ManagementFactory.getPlatformMBeanServer();
Queue queue = createQueue(queueName); // open a connection, session,
create the queue
ObjectName objName = new
ObjectName("org.apache.activemq:BrokerName=localhost,Type=Queue,Destination="
+ queueName);
jmxServer.invoke(objName, "purge", null, null);
The order of getting the MBeanServer vs. createQueue doesn't seem to
matter. I get the same exception in both cases.
On 3/2/07, Rob Davies <[EMAIL PROTECTED]> wrote:
for unit tests - we often set the deleteAllMessagesOnStartup flag on
the broker
For your case where you are using the vm://transport, create the
broker separetly in your setUp() - and set the
deleteAllMessageOnStartup property on the broker before calling start
() or setting a transport connector (for vm:// you won't need to
explicitly do this).
cheers,
Rob Davies
http://rajdavies.blogspot.com/
On 1 Mar 2007, at 22:13, Kelly Campbell wrote:
> I'm trying to figure out how to do this same thing in the current
> codebase (4.1/4.2). Basically I just want to purge all queues at the
> beginning of a unit test to ensure a clean start. I have a local vm://
> broker and would prefer not to go through JMX to do this.
>
> Thanks,
> Kelly
>
> On 5/17/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>> Correct.
>>
>> On 5/17/06, Adrian Tarau <[EMAIL PROTECTED]> wrote:
>> > Thanks. I presume this purge will remove all the messages from the
>> > persistance, right? not only memory...
>> >
>> > Hiram Chirino wrote:
>> > > Yes. That should be a map of ActiveMQDestination to
>> > > o.a.a.b.r.Destination objects.
>> > > You should be able to do something like ((o.a.a.b.r.Queue)
>> > > destination).purge();
>> > >
>> > > On 5/17/06, Adrian Tarau <[EMAIL PROTECTED]> wrote:
>> > >>
>> > >> BrokerServer.getBroker().getDestinationMap() ?
>> > >>
>> > >> Hiram Chirino wrote:
>> > >> > Hi Adrian,
>> > >> >
>> > >> > If you get a hold of the BrokerServer it should be possible
>> navigate
>> > >> > the object tree and be able to get a Queue object and ask
>> it to delete
>> > >> > it's messages.
>> > >> >
>> > >> >
>> > >> > On 5/17/06, Adrian Tarau <[EMAIL PROTECTED]> wrote:
>> > >> >> James? Anybody? Help? :)
>> > >> >>
>> > >> >> Adrian Tarau wrote:
>> > >> >> > James? Any suggestions how to clear a queue with
>> activemq API
>> > >> without
>> > >> >> > JMX? Thanks.
>> > >> >> >
>> > >> >> > Adrian Tarau wrote:
>> > >> >> >> I know the utility of JMX, I use it :) But right now I
>> don't
>> > >> want to
>> > >> >> >> activate JMX. I saw that ActiveMQ use MX4J 2.1.1(why
>> don't use
>> > >> >> >> 3.0.1?) and I have already in my application MX4J 3.0.1
>> > >> libraries and
>> > >> >> >> I remember I used 3.0.1 with a project that need 2.1.x
>> and was not
>> > >> >> >> working.
>> > >> >> >>
>> > >> >> >> And of course I cannot have two version of MX4J in my
>> application.
>> > >> >> >>
>> > >> >> >> James Strachan wrote:
>> > >> >> >>> On 5/15/06, Adrian Tarau <[EMAIL PROTECTED]> wrote:
>> > >> >> >>>> Since I use embedded JMS is not necessary to activate
>> also JMX,
>> > >> >> >>>
>> > >> >> >>> JMX is extremely useful. e.g. in JConsole you can
>> watch all of
>> > >> the
>> > >> >> >>> mbeans in an application (the garbage collector,
>> number of
>> > >> threads,
>> > >> >> >>> amount of memory free together wtih the ActiveMQ
>> mbeans such
>> > >> as all
>> > >> >> >>> the destinations & consumers and queue depths etc
>> > >> >> >>>
>> > >> >> >>>
>> > >> >> >>>> and JMX
>> > >> >> >>>> MBeans already use those parts to interrogate for
>> values outside
>> > >> >> >>>> the JMS
>> > >> >> >>>> standard. Why not to be accessible with Java code and
>> only JMX?
>> > >> >> >>>
>> > >> >> >>> Everything is accessible via Java code and JMX; the
>> reason I
>> > >> suggest
>> > >> >> >>> JMX is that
>> > >> >> >>>
>> > >> >> >>> (i) it can work with remote brokers too
>> > >> >> >>> (ii) it works great in JConsole - so its really easy
>> to look
>> > >> at the
>> > >> >> >>> mbeans whenever you like (rather than having to write
>> Java code)
>> > >> >> >>>
>> > >> >> >>
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >> >
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>>
>>
>> --
>> Regards,
>> Hiram
>>
