You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Kim van der Riet <ki...@redhat.com> on 2009/11/09 17:45:32 UTC
Store tests
It would be a good idea to standardize store tests if we can. If we can
agree that no matter what store is used, the end-result from a client
perspective would be the same, then tests would be fairly universal and
can be run against any store module.
All tests outlined below (which are based on some of the current async
store tests) assume a clean broker start with the store module loaded
(with no store content on disk) and stopping broker on conclusion for
each test (which may or may not leave messages in the store) - so there
needs to be some mechanism to clean up store artifacts between tests.
However, if tests are carefully constructed, it may be possible to avoid
a disk cleanup between tests by ensuring exchange and queue names do not
overlap between tests. No test should leave the store in an
unrecoverable state.
Tests marked (SERVER-SIDE) may need to be run from the broker itself or
on the same machine as the broker in order to gain access to store
artifacts.
Suggestions welcome.
Kim
----------------------------------
SimpleTest.CreateDelete: (SERVER-SIDE) Create a persistent queue and
delete it again, making sure that the disk artifacts (db tables, files)
are created and destroyed as appropriate to the implementation.
SimpleTest.EmptyRecover: Start stop and restart broker without creating
any queues.
SimpleTest.QueueCreate: Create a persistent queue. Stop broker and
restart it. Make sure queue exists after recovery, and that its
persistence ID is unchanged.
SimpleTest.QueueCreateWithSettings: Create a persistent queue with a
content policy. Stop and restart broker. Make sure queue exists after
recovery, and that its policy is still set with the correct limits.
SimpleTest.QueueDestroy: Create a persistent queue, then destroy it.
Stop broker, then restart. Make sure the queue does not exist.
SimpleTest.Enqueue: Create a persistent queue. Send three messages to
the queue. Stop and restart the broker. Deqeueue the messages, checking
the content. Make sure no extra messages exist in the queue.
SimpleTest.Dequeue: Create a persistent queue. Send three messages to
the queue, then consume them. Stop the broker. Restart the broker. Make
sure no messages exist in the queue.
SimpleTest.Staging: Set the frame size to a small value - this will
ensure that the message will arrive in parts over the wire. Create a
persistent queue with a size policy. Send both a transient and a
persistent message which is larger than the size policy and the frame
size. This will force the broker to release the content of the message
to disk in parts. Now browse the messages, making sure that they are
correctly read from the store. Check that the messages are still on the
queue. Now stop the broker, then restart. First browse, then consume the
messages, making sure the content is as expected. Make sure no other
messages remain.
SimpleTest.DestroyStagedMessage: Create a persistent queue with a size
policy. Send both a transient and a persistent message which is larger
than the size policy. This will force the broker to release the content
of the message to disk. Now consume the messages, making sure that it is
correctly read from the store. Now stop the broker, then restart. Make
sure no messages are present.
SimpleTest.ExchangeCreateAndDestroy: Create a persistent exchange. Stop
and restart broker. Check exchange still exists. Destroy exchange. Stop
and restart broker. Make sure exchange does not exist.
SimpleTest.ExchangeBindAndUnbind: Create a persistent exchange, a
persistent queue and bind them. Stop and restart the broker. Unbind the
exchange and the queue. Stop and restart the broker. Check that the
exchange and queue are unbound.
SimpleTest.ExchangeBindAndUnbindWithArgs: Create a persistent exchange
with args, a persistent queue and bind them. Stop and restart the
broker. Check that the args are still set on the exchange. Unbind the
exchange and the queue. Stop and restart the broker. Check that the args
are still set on the exchange. Check that the exchange and queue are
unbound.
SimpleTest.ExchangeImplicitUnbind: Create persistent exchange and two
persistent queues. Bind both queues to exchange. Destroy one of the
queues. Stop and restart broker. Ensure that only one queue remains, and
is still bound to the exchange. Delete the exchange. Stop and restart
broker. Make sure remaining queue still exists, but is not bound. Delete
remaining queue.
OrderingTest.Basic: Create a persistent queue. Produce 10 messages to
the queue. Stop and restart the broker. Consume the 10 messages, making
sure that the order is correct.
OrderingTest.Cycle: Create a persistent queue. Send 10 messages to the
queue. Consume 5 messages from the queue, then send another 5 messages
to the queue. Stop and restart the broker. Consume the 10 messages,
making sure that the order is correct.
TransactionalTest.Commit: Create two queues. Send a message to queue 1.
Opening a transaction, consume the message from queue 1, then send it to
queue 2. Commit the transaction, then stop and restart the broker. Check
both queues exist. Check queue 1 is empty and queue 2 contains the
message.
TransactionalTest.Abort: Create two queues. Send a message to queue 1.
Open a transaction, consume the message from queue 1, then send it to
queue 2. Abort the transaction, then stop and restart the broker. Check
both queues exist. Check queue 1 contains the message and queue 2 is
empty.
TransactionalTest.MultiQueueCommit: Create a fanout exchange. Create two
queues, binding them to the exchange. Transactionally send two messages
to the exchange (each queue should contain a copy of each message).
Commit the transaction. Stop and restart the exchange. Ensure that both
messages exist on both queues. Consume both messages from both queues.
Make sure both queues are now empty.
TransactionalTest.MultiQueueAbort: Create a fanout exchange. Create two
queues, binding them to the exchange. Transactionally send two messages
to the exchange (each queue should contain a copy of each message).
Abort the transaction. Stop and restart the exchange. Make sure both
queues are empty.
TwoPhaseCommitTest.CommitEnqueue: Create two queues. Using a 2PC
transaction, send three messages to the first queue. Prepare and commit
the transaction. Stop and restart the broker. Consume the three messages
from the first queue, checking their content. Check that the second
queue is empty.
TwoPhaseCommitTest.CommitDequeue: Create two queues. Send three messages
to the first queue. Using a 2PC transaction, consume the three messages
from the first queue, checking their content. Prepare and commit the
transaction. Stop and restart the broker. Check that all queues are
empty.
TwoPhaseCommitTest.CommitSwap: Create two queues. Send a message to the
first queue. Using a 2PC transaction, consume the message from the first
queue and then send that message to the second queue. Prepare and commit
the transaction. Stop and restart the broker. Check that the first queue
is empty. Consume the message from the second queue, checking its
content.
TwoPhaseCommitTest.PrepareAndAbortEnqueue: Create two queues. Using a
2PC transaction, send three messages to the first queue. Prepare then
abort the transaction. Stop and restart the broker. Check that all
queues are empty.
TwoPhaseCommitTest.PrepareAndAbortDequeue: Create two queues. Send three
messages to the first queue. Using a 2PC transaction, consume the three
messages from the first queue, checking their content. Prepare then
abort the transaction. Stop and restart the broker. Consume the three
messages from the first queue, checking their content. Check that the
second queue is empty.
TwoPhaseCommitTest.PrepareAndAbortSwap: Create two queues. Send a
message to the first queue. Using a 2PC transaction, consume the message
from the first queue and then send that message to the second queue.
Prepare then abort the transaction. Stop and restart the broker. Consume
the message from the first queue, checking its content. Check that the
second queue is empty.
TwoPhaseCommitTest.AbortNoPrepareEnqueue: Create two queues. Using a 2PC
transaction, send three messages to the first queue. Abort the
transaction without a prepare. Stop and restart the broker. Check that
all queues are empty.
TwoPhaseCommitTest.AbortNoPrepareDequeue: Create two queues. Send three
messages to the first queue. Using a 2PC transaction, consume the three
messages from the first queue, checking their content. Abort the
transaction without a prepare. Stop and restart the broker. Consume the
three messages from the first queue, checking their content. Check that
the second queue is empty.
TwoPhaseCommitTest.AbortNoPrepareSwap: Create two queues. Send a message
to the first queue. Using a 2PC transaction, consume the message from
the first queue and then send that message to the second queue. Abort
the transaction without a prepare. Stop and restart the broker. Consume
the message from the first queue, checking its content. Check that the
second queue is empty.
TwoPhaseCommitTest.Prepared: Create two queues. Send a message to the
first queue. Using a 2PC transaction, consume the message from the first
queue and then send that message to the second queue. Prepare the
transaction, but do not commit or abort. Stop and restart the broker. We
assume that prepared transactions roll forward on recovery. Check that
the first queue is empty. Consume the message from the second queue,
checking its content.
TwoPhaseCommitTest.MultiQueueCommit: Create two queues, and bind them to
a fanout exchange. Using a 2PC transaction, send two messages. Both
messages should be on both queues. Prepare, then commit the transaction.
Stop and restart the broker. Consume both messages from each of the two
queues, checking their content.
TwoPhaseCommitTest.MultiQueueAbort: Create two queues, and bind them to
a fanout exchange. Using a 2PC transaction, send two messages. Both
messages should be on both queues. Prepare, then abort the transaction.
Stop and restart the broker. Check that both queues are empty.
TwoPhaseCommitTest.MultiQueuePrepare: Create two queues, and bind them
to a fanout exchange. Using a 2PC transaction, send two messages. Both
messages should be on both queues. Prepare the transaction, but neither
commit nor abort it. Stop and restart the broker. We assume that
prepared transactions roll forward on recovery. Consume both messages
from each of the two queues, checking their content.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Martin Ritchie <ri...@apache.org>.
2009/11/11 Ján Sáreník <js...@redhat.com>:
> Hello!
>
> On Wed, Nov 11, 2009 at 02:45:25AM +0000, James Birdsall wrote:
>> + clicking on the "Qpid Testing" link gets me a login page, then after
>> I log in I get "You cannot view this page", "Page level restrictions
>> have been applied that limit access to this page."
>> <snip>
>
> I am experiencing all the same.
> Thank you, James, for pointing this out!
>
> Best regards, Jasan
Should be fixed now. The IBM JMS Testing page is still restricted to
qpid-comitters. IIRC this is because we have results from the IBM JMS
Toolkit there and the license says not to publish results.
> --
> Red Hat Czech, MRG Quality Assurance Associate
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Ján Sáreník <js...@redhat.com>.
Hello!
On Wed, Nov 11, 2009 at 02:45:25AM +0000, James Birdsall wrote:
> + clicking on the "Qpid Testing" link gets me a login page, then after
> I log in I get "You cannot view this page", "Page level restrictions
> have been applied that limit access to this page."
> <snip>
I am experiencing all the same.
Thank you, James, for pointing this out!
Best regards, Jasan
--
Red Hat Czech, MRG Quality Assurance Associate
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Store tests
Posted by James Birdsall <jb...@microsoft.com>.
On Tuesday, November 10, 2009 5:42 AM, Aidan Skinner [mailto:aidan.skinner@gmail.com] wrote:
>On Tue, Nov 10, 2009 at 3:33 AM, James Birdsall <jb...@microsoft.com> wrote:
>> The mailing list strips attachments and I don't have permissions to add a page to the wiki (I can't even LOOK at most of the testing pages!), so I will send the PDF to Kim directly. If anyone else would like to see it, please let me know!
>
>Which pages are you getting permission denied on? There shouldn't be
>anything on the wiki that isn't publically readable... (both as a
>bland statement of fact and, y'know, general policy)
Well, if I go to "Developer Pages":
+ clicking on the "Qpid Testing" link gets me a login page, then after I log in I get "You cannot view this page", "Page level restrictions have been applied that limit access to this page."
+ clicking on any of the three links beneath that ("Qpid JMX Management Console Testing Guide", "Interop Testing Specification", and "Performance Reliability and Scaling") gets a login and then a different message: "You cannot view this page due to inherited restrictions", "Page level restrictions have been applied to a parent of the current page. These restrictions limit access to only certain certain user(s) or group(s) and apply to all pages in the hierarchy underneath the parent."
+ by way of variety, the "Distributed Testing" link higher up the page actually works
--James Birdsall
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Nov 10, 2009 at 3:33 AM, James Birdsall <jb...@microsoft.com> wrote:
> The mailing list strips attachments and I don't have permissions to add a page to the wiki (I can't even LOOK at most of the testing pages!), so I will send the PDF to Kim directly. If anyone else would like to see it, please let me know!
Which pages are you getting permission denied on? There shouldn't be
anything on the wiki that isn't publically readable... (both as a
bland statement of fact and, y'know, general policy)
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Carl Trieloff <cc...@redhat.com>.
James Birdsall wrote:
> On Monday, November 09, 2009 12:41 PM, Alan Conway wrote:
>
>
>> On 11/09/2009 11:45 AM, Kim van der Riet wrote:
>>
>>> It would be a good idea to standardize store tests if we can. If we can
>>> agree that no matter what store is used, the end-result from a client
>>> perspective would be the same, then tests would be fairly universal and
>>> can be run against any store module.
>>>
>>> All tests outlined below (which are based on some of the current async
>>> store tests) assume a clean broker start with the store module loaded
>>> (with no store content on disk) and stopping broker on conclusion for
>>> each test (which may or may not leave messages in the store) - so there
>>> needs to be some mechanism to clean up store artifacts between tests.
>>> However, if tests are carefully constructed, it may be possible to avoid
>>> a disk cleanup between tests by ensuring exchange and queue names do not
>>> overlap between tests. No test should leave the store in an
>>> unrecoverable state.
>>>
>> The python broker tests framework I've been working on creates a separate
>> working directory for each test, all under a common directory so its easy to
>> clean up between test runs so there's no need to worry about conflicts between
>> tests.
>>
>>
>>> Tests marked (SERVER-SIDE) may need to be run from the broker itself or
>>> on the same machine as the broker in order to gain access to store
>>> artifacts.
>>>
>> And they'd be easy enough to write in python.
>>
>>
>>> Suggestions welcome.
>>>
>> The set below looks good. In particular I think the idea of having the tests be
>> based on user-observable outcomes is the right way to go.
>>
>
> Tests for persistence providers came up a while back; I'm in the middle of writing some for the SQL-based provider that Steve Huston is working on. My test plan is more basic, since I'm new to AMQP and Qpid and don't have the detailed understanding of it yet, but even so my tests have shaken out a number of bugs. The test plan is 99% not specific to the provider; at some point I would like to try it against other providers, just to see what happens.
>
> The mailing list strips attachments and I don't have permissions to add a page to the wiki (I can't even LOOK at most of the testing pages!), so I will send the PDF to Kim directly. If anyone else would like to see it, please let me know!
>
> --James B.
James,
You can create a Jira, and attach it. This is a good way as then it can
be used as the project. It also serves as a way to interact with the
project and is weighed into decision to nominate and vote people onto
the project as committers. i.e. if you want to work to committership it
helps to provide details of what you are doing on the list as a form of
updates so people can comment and understand the work stream.
regards
Carl.
Re: Store tests
Posted by Kim van der Riet <ki...@redhat.com>.
On Tue, 2009-11-10 at 04:41 +0100, Robert Godfrey wrote:
> 2009/11/10 James Birdsall <jb...@microsoft.com>
> >
> > Tests for persistence providers came up a while back; I'm in the middle of
> > writing some for the SQL-based provider that Steve Huston is working on. My
> > test plan is more basic, since I'm new to AMQP and Qpid and don't have the
> > detailed understanding of it yet, but even so my tests have shaken out a
> > number of bugs. The test plan is 99% not specific to the provider; at some
> > point I would like to try it against other providers, just to see what
> > happens.
> >
> > The mailing list strips attachments and I don't have permissions to add a
> > page to the wiki (I can't even LOOK at most of the testing pages!), so I
> > will send the PDF to Kim directly. If anyone else would like to see it,
> > please let me know!
> >
> >
> Can you create a JIRA and attach the PDF to that?
>
I have created a JIRA: https://issues.apache.org/jira/browse/QPID-2194
in which the original proposal has been pasted. I suggest that we
transfer the conversation there. It should be possible to add
attachments and files here, please feel free to do so.
Kim
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Robert Godfrey <ro...@gmail.com>.
2009/11/10 James Birdsall <jb...@microsoft.com>
> On Monday, November 09, 2009 12:41 PM, Alan Conway wrote:
>
> >On 11/09/2009 11:45 AM, Kim van der Riet wrote:
> >> It would be a good idea to standardize store tests if we can. If we can
> >> agree that no matter what store is used, the end-result from a client
> >> perspective would be the same, then tests would be fairly universal and
> >> can be run against any store module.
> >>
> >> All tests outlined below (which are based on some of the current async
> >> store tests) assume a clean broker start with the store module loaded
> >> (with no store content on disk) and stopping broker on conclusion for
> >> each test (which may or may not leave messages in the store) - so there
> >> needs to be some mechanism to clean up store artifacts between tests.
> >> However, if tests are carefully constructed, it may be possible to avoid
> >> a disk cleanup between tests by ensuring exchange and queue names do not
> >> overlap between tests. No test should leave the store in an
> >> unrecoverable state.
> >
> >The python broker tests framework I've been working on creates a separate
> >working directory for each test, all under a common directory so its easy
> to
> >clean up between test runs so there's no need to worry about conflicts
> between
> >tests.
> >
> >> Tests marked (SERVER-SIDE) may need to be run from the broker itself or
> >> on the same machine as the broker in order to gain access to store
> >> artifacts.
> >And they'd be easy enough to write in python.
> >
> >> Suggestions welcome.
> >The set below looks good. In particular I think the idea of having the
> tests be
> >based on user-observable outcomes is the right way to go.
>
> Tests for persistence providers came up a while back; I'm in the middle of
> writing some for the SQL-based provider that Steve Huston is working on. My
> test plan is more basic, since I'm new to AMQP and Qpid and don't have the
> detailed understanding of it yet, but even so my tests have shaken out a
> number of bugs. The test plan is 99% not specific to the provider; at some
> point I would like to try it against other providers, just to see what
> happens.
>
> The mailing list strips attachments and I don't have permissions to add a
> page to the wiki (I can't even LOOK at most of the testing pages!), so I
> will send the PDF to Kim directly. If anyone else would like to see it,
> please let me know!
>
>
Can you create a JIRA and attach the PDF to that?
Cheers,
Rob
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Store tests
Posted by James Birdsall <jb...@microsoft.com>.
On Monday, November 09, 2009 12:41 PM, Alan Conway wrote:
>On 11/09/2009 11:45 AM, Kim van der Riet wrote:
>> It would be a good idea to standardize store tests if we can. If we can
>> agree that no matter what store is used, the end-result from a client
>> perspective would be the same, then tests would be fairly universal and
>> can be run against any store module.
>>
>> All tests outlined below (which are based on some of the current async
>> store tests) assume a clean broker start with the store module loaded
>> (with no store content on disk) and stopping broker on conclusion for
>> each test (which may or may not leave messages in the store) - so there
>> needs to be some mechanism to clean up store artifacts between tests.
>> However, if tests are carefully constructed, it may be possible to avoid
>> a disk cleanup between tests by ensuring exchange and queue names do not
>> overlap between tests. No test should leave the store in an
>> unrecoverable state.
>
>The python broker tests framework I've been working on creates a separate
>working directory for each test, all under a common directory so its easy to
>clean up between test runs so there's no need to worry about conflicts between
>tests.
>
>> Tests marked (SERVER-SIDE) may need to be run from the broker itself or
>> on the same machine as the broker in order to gain access to store
>> artifacts.
>And they'd be easy enough to write in python.
>
>> Suggestions welcome.
>The set below looks good. In particular I think the idea of having the tests be
>based on user-observable outcomes is the right way to go.
Tests for persistence providers came up a while back; I'm in the middle of writing some for the SQL-based provider that Steve Huston is working on. My test plan is more basic, since I'm new to AMQP and Qpid and don't have the detailed understanding of it yet, but even so my tests have shaken out a number of bugs. The test plan is 99% not specific to the provider; at some point I would like to try it against other providers, just to see what happens.
The mailing list strips attachments and I don't have permissions to add a page to the wiki (I can't even LOOK at most of the testing pages!), so I will send the PDF to Kim directly. If anyone else would like to see it, please let me know!
--James B.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Store tests
Posted by Alan Conway <ac...@redhat.com>.
On 11/09/2009 11:45 AM, Kim van der Riet wrote:
> It would be a good idea to standardize store tests if we can. If we can
> agree that no matter what store is used, the end-result from a client
> perspective would be the same, then tests would be fairly universal and
> can be run against any store module.
>
> All tests outlined below (which are based on some of the current async
> store tests) assume a clean broker start with the store module loaded
> (with no store content on disk) and stopping broker on conclusion for
> each test (which may or may not leave messages in the store) - so there
> needs to be some mechanism to clean up store artifacts between tests.
> However, if tests are carefully constructed, it may be possible to avoid
> a disk cleanup between tests by ensuring exchange and queue names do not
> overlap between tests. No test should leave the store in an
> unrecoverable state.
The python broker tests framework I've been working on creates a separate
working directory for each test, all under a common directory so its easy to
clean up between test runs so there's no need to worry about conflicts between
tests.
> Tests marked (SERVER-SIDE) may need to be run from the broker itself or
> on the same machine as the broker in order to gain access to store
> artifacts.
And they'd be easy enough to write in python.
> Suggestions welcome.
The set below looks good. In particular I think the idea of having the tests be
based on user-observable outcomes is the right way to go.
> SimpleTest.CreateDelete: (SERVER-SIDE) Create a persistent queue and
> delete it again, making sure that the disk artifacts (db tables, files)
> are created and destroyed as appropriate to the implementation.
>
> SimpleTest.EmptyRecover: Start stop and restart broker without creating
> any queues.
>
> SimpleTest.QueueCreate: Create a persistent queue. Stop broker and
> restart it. Make sure queue exists after recovery, and that its
> persistence ID is unchanged.
>
> SimpleTest.QueueCreateWithSettings: Create a persistent queue with a
> content policy. Stop and restart broker. Make sure queue exists after
> recovery, and that its policy is still set with the correct limits.
>
> SimpleTest.QueueDestroy: Create a persistent queue, then destroy it.
> Stop broker, then restart. Make sure the queue does not exist.
>
> SimpleTest.Enqueue: Create a persistent queue. Send three messages to
> the queue. Stop and restart the broker. Deqeueue the messages, checking
> the content. Make sure no extra messages exist in the queue.
>
> SimpleTest.Dequeue: Create a persistent queue. Send three messages to
> the queue, then consume them. Stop the broker. Restart the broker. Make
> sure no messages exist in the queue.
>
> SimpleTest.Staging: Set the frame size to a small value - this will
> ensure that the message will arrive in parts over the wire. Create a
> persistent queue with a size policy. Send both a transient and a
> persistent message which is larger than the size policy and the frame
> size. This will force the broker to release the content of the message
> to disk in parts. Now browse the messages, making sure that they are
> correctly read from the store. Check that the messages are still on the
> queue. Now stop the broker, then restart. First browse, then consume the
> messages, making sure the content is as expected. Make sure no other
> messages remain.
>
> SimpleTest.DestroyStagedMessage: Create a persistent queue with a size
> policy. Send both a transient and a persistent message which is larger
> than the size policy. This will force the broker to release the content
> of the message to disk. Now consume the messages, making sure that it is
> correctly read from the store. Now stop the broker, then restart. Make
> sure no messages are present.
>
> SimpleTest.ExchangeCreateAndDestroy: Create a persistent exchange. Stop
> and restart broker. Check exchange still exists. Destroy exchange. Stop
> and restart broker. Make sure exchange does not exist.
>
> SimpleTest.ExchangeBindAndUnbind: Create a persistent exchange, a
> persistent queue and bind them. Stop and restart the broker. Unbind the
> exchange and the queue. Stop and restart the broker. Check that the
> exchange and queue are unbound.
>
> SimpleTest.ExchangeBindAndUnbindWithArgs: Create a persistent exchange
> with args, a persistent queue and bind them. Stop and restart the
> broker. Check that the args are still set on the exchange. Unbind the
> exchange and the queue. Stop and restart the broker. Check that the args
> are still set on the exchange. Check that the exchange and queue are
> unbound.
>
> SimpleTest.ExchangeImplicitUnbind: Create persistent exchange and two
> persistent queues. Bind both queues to exchange. Destroy one of the
> queues. Stop and restart broker. Ensure that only one queue remains, and
> is still bound to the exchange. Delete the exchange. Stop and restart
> broker. Make sure remaining queue still exists, but is not bound. Delete
> remaining queue.
>
> OrderingTest.Basic: Create a persistent queue. Produce 10 messages to
> the queue. Stop and restart the broker. Consume the 10 messages, making
> sure that the order is correct.
>
> OrderingTest.Cycle: Create a persistent queue. Send 10 messages to the
> queue. Consume 5 messages from the queue, then send another 5 messages
> to the queue. Stop and restart the broker. Consume the 10 messages,
> making sure that the order is correct.
>
> TransactionalTest.Commit: Create two queues. Send a message to queue 1.
> Opening a transaction, consume the message from queue 1, then send it to
> queue 2. Commit the transaction, then stop and restart the broker. Check
> both queues exist. Check queue 1 is empty and queue 2 contains the
> message.
>
> TransactionalTest.Abort: Create two queues. Send a message to queue 1.
> Open a transaction, consume the message from queue 1, then send it to
> queue 2. Abort the transaction, then stop and restart the broker. Check
> both queues exist. Check queue 1 contains the message and queue 2 is
> empty.
>
> TransactionalTest.MultiQueueCommit: Create a fanout exchange. Create two
> queues, binding them to the exchange. Transactionally send two messages
> to the exchange (each queue should contain a copy of each message).
> Commit the transaction. Stop and restart the exchange. Ensure that both
> messages exist on both queues. Consume both messages from both queues.
> Make sure both queues are now empty.
>
> TransactionalTest.MultiQueueAbort: Create a fanout exchange. Create two
> queues, binding them to the exchange. Transactionally send two messages
> to the exchange (each queue should contain a copy of each message).
> Abort the transaction. Stop and restart the exchange. Make sure both
> queues are empty.
>
> TwoPhaseCommitTest.CommitEnqueue: Create two queues. Using a 2PC
> transaction, send three messages to the first queue. Prepare and commit
> the transaction. Stop and restart the broker. Consume the three messages
> from the first queue, checking their content. Check that the second
> queue is empty.
>
> TwoPhaseCommitTest.CommitDequeue: Create two queues. Send three messages
> to the first queue. Using a 2PC transaction, consume the three messages
> from the first queue, checking their content. Prepare and commit the
> transaction. Stop and restart the broker. Check that all queues are
> empty.
>
> TwoPhaseCommitTest.CommitSwap: Create two queues. Send a message to the
> first queue. Using a 2PC transaction, consume the message from the first
> queue and then send that message to the second queue. Prepare and commit
> the transaction. Stop and restart the broker. Check that the first queue
> is empty. Consume the message from the second queue, checking its
> content.
>
> TwoPhaseCommitTest.PrepareAndAbortEnqueue: Create two queues. Using a
> 2PC transaction, send three messages to the first queue. Prepare then
> abort the transaction. Stop and restart the broker. Check that all
> queues are empty.
>
> TwoPhaseCommitTest.PrepareAndAbortDequeue: Create two queues. Send three
> messages to the first queue. Using a 2PC transaction, consume the three
> messages from the first queue, checking their content. Prepare then
> abort the transaction. Stop and restart the broker. Consume the three
> messages from the first queue, checking their content. Check that the
> second queue is empty.
>
> TwoPhaseCommitTest.PrepareAndAbortSwap: Create two queues. Send a
> message to the first queue. Using a 2PC transaction, consume the message
> from the first queue and then send that message to the second queue.
> Prepare then abort the transaction. Stop and restart the broker. Consume
> the message from the first queue, checking its content. Check that the
> second queue is empty.
>
> TwoPhaseCommitTest.AbortNoPrepareEnqueue: Create two queues. Using a 2PC
> transaction, send three messages to the first queue. Abort the
> transaction without a prepare. Stop and restart the broker. Check that
> all queues are empty.
>
> TwoPhaseCommitTest.AbortNoPrepareDequeue: Create two queues. Send three
> messages to the first queue. Using a 2PC transaction, consume the three
> messages from the first queue, checking their content. Abort the
> transaction without a prepare. Stop and restart the broker. Consume the
> three messages from the first queue, checking their content. Check that
> the second queue is empty.
>
> TwoPhaseCommitTest.AbortNoPrepareSwap: Create two queues. Send a message
> to the first queue. Using a 2PC transaction, consume the message from
> the first queue and then send that message to the second queue. Abort
> the transaction without a prepare. Stop and restart the broker. Consume
> the message from the first queue, checking its content. Check that the
> second queue is empty.
>
> TwoPhaseCommitTest.Prepared: Create two queues. Send a message to the
> first queue. Using a 2PC transaction, consume the message from the first
> queue and then send that message to the second queue. Prepare the
> transaction, but do not commit or abort. Stop and restart the broker. We
> assume that prepared transactions roll forward on recovery. Check that
> the first queue is empty. Consume the message from the second queue,
> checking its content.
>
> TwoPhaseCommitTest.MultiQueueCommit: Create two queues, and bind them to
> a fanout exchange. Using a 2PC transaction, send two messages. Both
> messages should be on both queues. Prepare, then commit the transaction.
> Stop and restart the broker. Consume both messages from each of the two
> queues, checking their content.
>
> TwoPhaseCommitTest.MultiQueueAbort: Create two queues, and bind them to
> a fanout exchange. Using a 2PC transaction, send two messages. Both
> messages should be on both queues. Prepare, then abort the transaction.
> Stop and restart the broker. Check that both queues are empty.
>
> TwoPhaseCommitTest.MultiQueuePrepare: Create two queues, and bind them
> to a fanout exchange. Using a 2PC transaction, send two messages. Both
> messages should be on both queues. Prepare the transaction, but neither
> commit nor abort it. Stop and restart the broker. We assume that
> prepared transactions roll forward on recovery. Consume both messages
> from each of the two queues, checking their content.
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org