Re: Store tests
2009/11/11 Ján Sáreník : > Hello! > > On Wed, Nov 11, 2009 at 02:45:25AM +, 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." >> > > 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-subscr...@qpid.apache.org > > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Store tests
Hello! On Wed, Nov 11, 2009 at 02:45:25AM +, 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." > 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-subscr...@qpid.apache.org
RE: Store tests
On Tuesday, November 10, 2009 5:42 AM, Aidan Skinner
[mailto:aidan.skin...@gmail.com] wrote:
>On Tue, Nov 10, 2009 at 3:33 AM, James Birdsall 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-subscr...@qpid.apache.org
Re: Store tests
On Tue, Nov 10, 2009 at 3:33 AM, James Birdsall 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-subscr...@qpid.apache.org
Re: Store tests
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
On Tue, 2009-11-10 at 04:41 +0100, Robert Godfrey wrote: > 2009/11/10 James Birdsall > > > > 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-subscr...@qpid.apache.org
Re: Store tests
2009/11/10 James Birdsall > 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-subscr...@qpid.apache.org > >
RE: Store tests
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-subscr...@qpid.apache.org
Re: Store tests
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 mess
