You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2007/03/06 00:03:13 UTC
C++ 0-9 merge heads up
I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
know of any outstanding issues. The plan is to merge python first for
the tests (branch python speaks both old & new protocols) then the C++
codebase.
I'm currently working on getting python verified against all brokers
(trunk/branch, c++/java).
Cheers,
Alan.
Re: C++ 0-9 merge heads up
Posted by Rupert Smith <ru...@googlemail.com>.
Yes, I mean as few active branches as possible. I would prefer to
avoid the chore of merging whenever possible.
On 3/7/07, Andrew Stitcher <as...@redhat.com> wrote:
> On Wed, 2007-03-07 at 16:36 +0000, Rupert Smith wrote:
> > Once again, can I request as few branches as possible. Each is a
> > headache (unless of course I just pretend I don't know its there!).
> > Please, just the one for M2.
>
> I heard you say this before and I don't understand it - I think you mean
> as few *active* branches as possible, but an unused branch can just be
> deleted from the repo with no real repercussions at all.
>
> So I don't see why Alan can't just create a branch or even just create a
> tag called "AlansWhateverBranch" and then move it to a branch if/when it
> is what we need; else just delete it and then it's not there offending
> you at all ;-) (it might offend the repo admins but that's another thing
> entirely!).
>
> Andrew
>
>
>
Re: C++ 0-9 merge heads up
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2007-03-07 at 16:36 +0000, Rupert Smith wrote:
> Once again, can I request as few branches as possible. Each is a
> headache (unless of course I just pretend I don't know its there!).
> Please, just the one for M2.
I heard you say this before and I don't understand it - I think you mean
as few *active* branches as possible, but an unused branch can just be
deleted from the repo with no real repercussions at all.
So I don't see why Alan can't just create a branch or even just create a
tag called "AlansWhateverBranch" and then move it to a branch if/when it
is what we need; else just delete it and then it's not there offending
you at all ;-) (it might offend the repo admins but that's another thing
entirely!).
Andrew
Re: C++ 0-9 merge heads up
Posted by Rupert Smith <ru...@googlemail.com>.
Once again, can I request as few branches as possible. Each is a
headache (unless of course I just pretend I don't know its there!).
Please, just the one for M2.
Rupert
On 3/7/07, Alan Conway <ac...@redhat.com> wrote:
> Robert Godfrey wrote:
> > I'm just not sure whether (procedurally) we can make an M2 branch before
> > we've given people enough time to vote for an M2 release...
> Making a branch doesn't commit us to a release, it doesn't even force
> anybody to use the branch. It just means the current state of C++ is
> stored away safely so I can move on trunk while the Java issues are
> resolved. As long as the Java 0-9 isn't merged it'll be trivial to
> merge any Java trunk work done in the next 5-7 days to the M2 branch as
> there'll be no changes on it.
>
> > Suggestion of
> > early next week was as much to allow the normal voting window as anything
> > else...
> >
> > having said that, your ordering looks sensible.
> If it helps peoples voting sensibilities I can make a branch called
> "AlansPre09Branch" and we can rename it M2 when all the voting is done.
>
> Cheers,
> Alan.
>
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
Martin Ritchie wrote:
> On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
>> Robert Godfrey wrote:
>> > I'm just not sure whether (procedurally) we can make an M2 branch
>> before
>> > we've given people enough time to vote for an M2 release...
>
>> Making a branch doesn't commit us to a release, it doesn't even force
>> anybody to use the branch. It just means the current state of C++ is
>> stored away safely so I can move on trunk while the Java issues are
>> resolved. As long as the Java 0-9 isn't merged it'll be trivial to
>> merge any Java trunk work done in the next 5-7 days to the M2 branch as
>> there'll be no changes on it.
>
> This statement concerns me. The project is in Apache to make releases
> and build a community. If we are simply tagging our repository which
> contains a lot of hard effort by a lot of people and moving on with
> the next version which also contains a lot of effort by even more
> people then we are running a real risk of fracturing the community. If
> we, as a community feel it worth while to do a release then we need to
> push that goal through or we will not be allowed to graduate from the
> incubator.
Agree with everything you said, don't understand why the statement
concerns you or what the risk is. I intend to work hard on both the M2
release and the future 0.9, 0.10 versions. To do that I need a place to
save the state of C++ now as the basis of the M2 release so I can do
reorganization and 0.9 work on trunk. I understand that the timing is
different for Java, I don't see any reason why we have to tie the two
together. My aim in making a branch early is to protect the M2 release
while allowing forward motion of C++ on trunk.
Cheers,
Alan.
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
> Robert Godfrey wrote:
> > I'm just not sure whether (procedurally) we can make an M2 branch before
> > we've given people enough time to vote for an M2 release...
> Making a branch doesn't commit us to a release, it doesn't even force
> anybody to use the branch. It just means the current state of C++ is
> stored away safely so I can move on trunk while the Java issues are
> resolved. As long as the Java 0-9 isn't merged it'll be trivial to
> merge any Java trunk work done in the next 5-7 days to the M2 branch as
> there'll be no changes on it.
This statement concerns me. The project is in Apache to make releases
and build a community. If we are simply tagging our repository which
contains a lot of hard effort by a lot of people and moving on with
the next version which also contains a lot of effort by even more
people then we are running a real risk of fracturing the community. If
we, as a community feel it worth while to do a release then we need to
push that goal through or we will not be allowed to graduate from the
incubator.
> > Suggestion of
> > early next week was as much to allow the normal voting window as anything
> > else...
> >
> > having said that, your ordering looks sensible.
> If it helps peoples voting sensibilities I can make a branch called
> "AlansPre09Branch" and we can rename it M2 when all the voting is done.
>
> Cheers,
> Alan.
>
--
Martin Ritchie
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
Robert Godfrey wrote:
> I'm just not sure whether (procedurally) we can make an M2 branch before
> we've given people enough time to vote for an M2 release...
Making a branch doesn't commit us to a release, it doesn't even force
anybody to use the branch. It just means the current state of C++ is
stored away safely so I can move on trunk while the Java issues are
resolved. As long as the Java 0-9 isn't merged it'll be trivial to
merge any Java trunk work done in the next 5-7 days to the M2 branch as
there'll be no changes on it.
> Suggestion of
> early next week was as much to allow the normal voting window as anything
> else...
>
> having said that, your ordering looks sensible.
If it helps peoples voting sensibilities I can make a branch called
"AlansPre09Branch" and we can rename it M2 when all the voting is done.
Cheers,
Alan.
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
As far as I can see we are not actually voting for a release only
voting that we should do a release. As my understanding of a release
vote when passed means we branch and the code is packaged. We are far
from ready to package the code. Usually there are RC sent round before
so we know what we are voting to release.
I have no problem voting on branching so a release can be started just
so long as we actually put the effort behind doing the Apache release.
On 07/03/07, Robert Godfrey <ro...@gmail.com> wrote:
> I'm just not sure whether (procedurally) we can make an M2 branch before
> we've given people enough time to vote for an M2 release... Suggestion of
> early next week was as much to allow the normal voting window as anything
> else...
>
> having said that, your ordering looks sensible.
>
> -- Rob
>
> I'd suggest this order:
> > 1. Merge python 0-9 to trunk - compatible with 0-8 and has other
> > improvements beyond 0-9.
> > 2. Create M2 branch.
> > 3. Merge other 0-9 stuff - C++ for me, java when it's ready etc.
> > > Probably want to co-ordinate so that if people have a lot of pending
> > work
> > > for M2 that gets checked in before the 0-9 stuff gets merged in.
> > C++ has some other issues that urgently require us to get back to a
> > single branch. I'd suggest we make the M2 branch and then co-ordinate
> > Java work destined for trunk and M2 with the merging of java 0-9 branch
> > rather than holding everything up till Java is sorted out. Until the 0-9
> > Java stuff merges merging between trunk and M2 is trivial so the
> > existence of the branch won't hinder that work.
> >
> > Cheers,
> > Alan.
> >
> >
>
--
Martin Ritchie
Re: C++ 0-9 merge heads up
Posted by Robert Godfrey <ro...@gmail.com>.
I'm just not sure whether (procedurally) we can make an M2 branch before
we've given people enough time to vote for an M2 release... Suggestion of
early next week was as much to allow the normal voting window as anything
else...
having said that, your ordering looks sensible.
-- Rob
I'd suggest this order:
> 1. Merge python 0-9 to trunk - compatible with 0-8 and has other
> improvements beyond 0-9.
> 2. Create M2 branch.
> 3. Merge other 0-9 stuff - C++ for me, java when it's ready etc.
> > Probably want to co-ordinate so that if people have a lot of pending
> work
> > for M2 that gets checked in before the 0-9 stuff gets merged in.
> C++ has some other issues that urgently require us to get back to a
> single branch. I'd suggest we make the M2 branch and then co-ordinate
> Java work destined for trunk and M2 with the merging of java 0-9 branch
> rather than holding everything up till Java is sorted out. Until the 0-9
> Java stuff merges merging between trunk and M2 is trivial so the
> existence of the branch won't hinder that work.
>
> Cheers,
> Alan.
>
>
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
Robert Godfrey wrote:
> With the parallel thread on cutting an M2 release, do we want to cut
> that at
> a point before or after you merge 0-9 down to trunk (I would think
> before,
> but if you think the 0-9 branch does 0-8 as well or better than
> trunk...).
>
I'd suggest this order:
1. Merge python 0-9 to trunk - compatible with 0-8 and has other
improvements beyond 0-9.
2. Create M2 branch.
3. Merge other 0-9 stuff - C++ for me, java when it's ready etc.
> Probably want to co-ordinate so that if people have a lot of pending work
> for M2 that gets checked in before the 0-9 stuff gets merged in.
C++ has some other issues that urgently require us to get back to a
single branch. I'd suggest we make the M2 branch and then co-ordinate
Java work destined for trunk and M2 with the merging of java 0-9 branch
rather than holding everything up till Java is sorted out. Until the 0-9
Java stuff merges merging between trunk and M2 is trivial so the
existence of the branch won't hinder that work.
Cheers,
Alan.
Re: C++ 0-9 merge heads up
Posted by Robert Godfrey <ro...@gmail.com>.
With the parallel thread on cutting an M2 release, do we want to cut that at
a point before or after you merge 0-9 down to trunk (I would think before,
but if you think the 0-9 branch does 0-8 as well or better than trunk...).
Probably want to co-ordinate so that if people have a lot of pending work
for M2 that gets checked in before the 0-9 stuff gets merged in.
-- Rob
On 07/03/07, Alan Conway <ac...@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > On 06/03/07, Alan Conway <ac...@redhat.com> wrote:
> >> FAILED (failures=5, errors=14)
> >
> > Alan your java code needs an SVN update. These were the errors I was
> > seeing before I did my recent commit. I shall do an update and ensure
> > that the trunk passes all the python tests.
> >
> > The two topic tests will still fail but they are listed in the
> > java_failing.txt file. I hope to have those to sorted soon.
> Thanks and sorry for the noise. Am rebuilding a completely clean working
> copy now, if all goes well I'll go ahead with they python merge: first
> I'll backmerge trunk to branch then merge branch to trunk.
>
> I've updated python on the 0-9 branch to use the correct framing based
> on the version of the spec file so it works with all versions given the
> correct spec, I've verified with cpp & java trunk & branch. Post merge
> trunk will have 2 sets of python (tests.0-8 and tests.0-9) defaulting
> to run the 0-8 tests until everything on trunk is updated and are happy
> to delete the 0-8 stuff.
>
> Until we converge back to one test set we need to be careful that tests
> added to the 0-8 set have an equivalent test in the 0-9 set. If anyone
> has better ideas about how to manage the two let me know.
>
> Cheers,
> Alan.
>
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
Martin Ritchie wrote:
> On 06/03/07, Alan Conway <ac...@redhat.com> wrote:
>> FAILED (failures=5, errors=14)
>
> Alan your java code needs an SVN update. These were the errors I was
> seeing before I did my recent commit. I shall do an update and ensure
> that the trunk passes all the python tests.
>
> The two topic tests will still fail but they are listed in the
> java_failing.txt file. I hope to have those to sorted soon.
Thanks and sorry for the noise. Am rebuilding a completely clean working
copy now, if all goes well I'll go ahead with they python merge: first
I'll backmerge trunk to branch then merge branch to trunk.
I've updated python on the 0-9 branch to use the correct framing based
on the version of the spec file so it works with all versions given the
correct spec, I've verified with cpp & java trunk & branch. Post merge
trunk will have 2 sets of python (tests.0-8 and tests.0-9) defaulting
to run the 0-8 tests until everything on trunk is updated and are happy
to delete the 0-8 stuff.
Until we converge back to one test set we need to be careful that tests
added to the 0-8 set have an equivalent test in the 0-9 set. If anyone
has better ideas about how to manage the two let me know.
Cheers,
Alan.
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
On 07/03/07, Martin Ritchie <ri...@apache.org> wrote:
> On 06/03/07, Alan Conway <ac...@redhat.com> wrote:
> > On Tue, 2007-03-06 at 11:38 +0000, Martin Ritchie wrote:
> > > On 05/03/07, Alan Conway <ac...@redhat.com> wrote:
> > > > I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> > > > know of any outstanding issues. The plan is to merge python first for
> > > > the tests (branch python speaks both old & new protocols) then the C++
> > > > codebase.
> > > >
> > > > I'm currently working on getting python verified against all brokers
> > > > (trunk/branch, c++/java).
> > >
> > > Alan, I have some updates to the Java broker if you are working on the
> > > C++ - python I shall look at that java - python. Ensuring my recent
> > > updates haven't broken a python test.
> > >
> >
> > I'm still seeing many python test failures against the java broker on
> > trunk.
> >
> > Here's the failure output:
> >
> > .E.E.FFF.........F.......F....E...E.EEEEEEEEEE
> > ======================================================================
> > ERROR: test_ack (tests.basic.BasicTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/basic.py", line 178, in
> > test_ack
> > msg3b = queue.get(timeout=1)
> > File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> > result = BaseQueue.get(self, block, timeout)
> > File "/usr/lib/python2.4/Queue.py", line 127, in get
> > raise Empty
> > Empty
> >
> > ======================================================================
> > ERROR: test_consume_exclusive (tests.basic.BasicTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/basic.py", line 72, in
> > test_consume_exclusive
> > channel.channel_open()
> > File "<string>", line 3, in channel_open
> > File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> > raise Closed(self.reason)
> > Closed
> >
> > ======================================================================
> > ERROR: testTopic (tests.exchange.RecommendedTypesRuleTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/exchange.py", line 101, in
> > testTopic
> > self.verifyTopicExchange("t")
> > File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
> > verifyTopicExchange
> > self.assertPublishGet(q, ex, "a.b.x")
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
> > assertPublishGet
> > msg = queue.get(timeout=1)
> > File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> > result = BaseQueue.get(self, block, timeout)
> > File "/usr/lib/python2.4/Queue.py", line 127, in get
> > raise Empty
> > Empty
> >
> > ======================================================================
> > ERROR: testAmqTopic (tests.exchange.RequiredInstancesRuleTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/exchange.py", line 123, in
> > testAmqTopic
> > def testAmqTopic(self): self.verifyTopicExchange("amq.topic")
> > File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
> > verifyTopicExchange
> > self.assertPublishGet(q, ex, "a.b.x")
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
> > assertPublishGet
> > msg = queue.get(timeout=1)
> > File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> > result = BaseQueue.get(self, block, timeout)
> > File "/usr/lib/python2.4/Queue.py", line 127, in get
> > raise Empty
> > Empty
> >
> > ======================================================================
> > ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/broker.py", line 58, in
> > test_basic_delivery_immediate
> > self.queue_declare(channel, queue="test-queue")
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
> > queue_declare
> > reply = channel.queue_declare(*args, **keys)
> > File "<string>", line 3, in queue_declare
> > File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> > raise Closed(self.reason)
> > Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> > exclusive queue with same name declared on another connection [error
> > code 405: Already exists]', 50, 10) content = None
> >
> > ======================================================================
> > ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
> > tearDown
> > ch.exchange_delete(exchange=ex)
> > File "<string>", line 3, in exchange_delete
> > File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
> > raise Closed(self.reason)
> > Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> > exclusive queue with same name declared on another connection [error
> > code 405: Already exists]', 50, 10) content = None
> >
> > ======================================================================
> > ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/broker.py", line 78, in
> > test_basic_delivery_queued
> > self.queue_declare(channel, queue="test-queue")
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
> > queue_declare
> > reply = channel.queue_declare(*args, **keys)
> > File "<string>", line 3, in queue_declare
> > File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> > raise Closed(self.reason)
> > Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> > exclusive queue with same name declared on another connection [error
> > code 405: Already exists]', 50, 10) content = None
> >
> > ======================================================================
> > ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
> > tearDown
> > ch.exchange_delete(exchange=ex)
> > File "<string>", line 3, in exchange_delete
> > File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
> > raise Closed(self.reason)
> > Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> > exclusive queue with same name declared on another connection [error
> > code 405: Already exists]', 50, 10) content = None
> >
> > ======================================================================
> > ERROR: test_closed_channel (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/broker.py", line 103, in
> > test_closed_channel
> > self.assertConnectionException(504, e.args[0])
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 234, in
> > assertConnectionException
> > self.assertEqual("connection", message.method.klass.name)
> > AttributeError: Closed instance has no attribute 'method'
> >
> > ======================================================================
> > ERROR: test_invalid_channel (tests.broker.BrokerTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> > setUp
> > self.client = self.connect()
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> > connect
> > return testrunner.connect(*args, **keys)
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> > connect
> > client.start({"LOGIN": user, "PASSWORD": password})
> > File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> > self.conn.connect()
> > File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> > connect
> > sock.connect((self.host, self.port))
> > File "<string>", line 1, in connect
> > error: (111, 'Connection refused')
> >
> > ======================================================================
> > ERROR: test_auto_rollback (tests.tx.TxTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> > setUp
> > self.client = self.connect()
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> > connect
> > return testrunner.connect(*args, **keys)
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> > connect
> > client.start({"LOGIN": user, "PASSWORD": password})
> > File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> > self.conn.connect()
> > File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> > connect
> > sock.connect((self.host, self.port))
> > File "<string>", line 1, in connect
> > error: (111, 'Connection refused')
> >
> > ======================================================================
> > ERROR: test_commit (tests.tx.TxTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> > setUp
> > self.client = self.connect()
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> > connect
> > return testrunner.connect(*args, **keys)
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> > connect
> > client.start({"LOGIN": user, "PASSWORD": password})
> > File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> > self.conn.connect()
> > File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> > connect
> > sock.connect((self.host, self.port))
> > File "<string>", line 1, in connect
> > error: (111, 'Connection refused')
> >
> > ======================================================================
> > ERROR: test_commit_overlapping_acks (tests.tx.TxTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> > setUp
> > self.client = self.connect()
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> > connect
> > return testrunner.connect(*args, **keys)
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> > connect
> > client.start({"LOGIN": user, "PASSWORD": password})
> > File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> > self.conn.connect()
> > File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> > connect
> > sock.connect((self.host, self.port))
> > File "<string>", line 1, in connect
> > error: (111, 'Connection refused')
> >
> > ======================================================================
> > ERROR: test_rollback (tests.tx.TxTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> > setUp
> > self.client = self.connect()
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> > connect
> > return testrunner.connect(*args, **keys)
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> > connect
> > client.start({"LOGIN": user, "PASSWORD": password})
> > File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> > self.conn.connect()
> > File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> > connect
> > sock.connect((self.host, self.port))
> > File "<string>", line 1, in connect
> > error: (111, 'Connection refused')
> >
> > ======================================================================
> > FAIL: test_consume_queue_errors (tests.basic.BasicTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/basic.py", line 101, in
> > test_consume_queue_errors
> > self.assertConnectionException(530, e.args[0])
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> > assertConnectionException
> > self.assertEqual(expectedCode, message.reply_code)
> > AssertionError: 530 != 507
> >
> > ======================================================================
> > FAIL: test_consume_unique_consumers (tests.basic.BasicTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/basic.py", line 117, in
> > test_consume_unique_consumers
> > self.assertConnectionException(530, e.args[0])
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> > assertConnectionException
> > self.assertEqual(expectedCode, message.reply_code)
> > AssertionError: 530 != 507
> >
> > ======================================================================
> > FAIL: test_get (tests.basic.BasicTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/basic.py", line 350, in
> > test_get
> > self.assertEqual(reply.method.name, "get-ok")
> > AssertionError: u'get-empty' != 'get-ok'
> >
> > ======================================================================
> > FAIL: test_purge (tests.queue.QueueTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/queue.py", line 46, in
> > test_purge
> > self.assertEqual(3, reply.message_count)
> > AssertionError: 3 != 0L
> >
> > ======================================================================
> > FAIL: testDifferentDeclaredType
> > (tests.exchange.MiscellaneousErrorsTests)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/aconway/svn/qpid/python/tests/exchange.py", line 321, in
> > testDifferentDeclaredType
> > self.assertConnectionException(530, e.args[0])
> > File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> > assertConnectionException
> > self.assertEqual(expectedCode, message.reply_code)
> > AssertionError: 530 != 507
> >
> > ----------------------------------------------------------------------
> > Ran 44 tests in 536.599s
> >
> > FAILED (failures=5, errors=14)
>
> Alan your java code needs an SVN update. These were the errors I was
> seeing before I did my recent commit. I shall do an update and ensure
> that the trunk passes all the python tests.
>
> The two topic tests will still fail but they are listed in the
> java_failing.txt file. I hope to have those to sorted soon.
> --
> Martin Ritchie
That took longer than expected. Did a update on trunk and a clean
build of the java then ran the python and all passed. This was the
output:
$ ./run-tests -v -I java_failing.txt
test_ack (tests.basic.BasicTests) ... ok
test_cancel (tests.basic.BasicTests) ... ok
test_consume_exclusive (tests.basic.BasicTests) ... ok
test_consume_no_local (tests.basic.BasicTests) ... ok
test_consume_queue_errors (tests.basic.BasicTests) ... ok
test_consume_unique_consumers (tests.basic.BasicTests) ... ok
test_get (tests.basic.BasicTests) ... ok
test_qos_prefetch_count (tests.basic.BasicTests) ... ok
test_qos_prefetch_size (tests.basic.BasicTests) ... ok
test_recover_requeue (tests.basic.BasicTests) ... ok
test_amqp_basic_13 (tests.broker.BrokerTests) ... ok
test_basic_delivery_immediate (tests.broker.BrokerTests) ... ok
test_basic_delivery_queued (tests.broker.BrokerTests) ... ok
test_closed_channel (tests.broker.BrokerTests) ... ok
test_invalid_channel (tests.broker.BrokerTests) ... ok
test_example (tests.example.ExampleTest) ... ok
test (tests.exchange.DeclareMethodPassiveFieldNotFoundRuleTests) ... ok
testDefaultExchange (tests.exchange.DefaultExchangeRuleTests) ... ok
testMatchAll (tests.exchange.HeadersExchangeTests) ... ok
testMatchAny (tests.exchange.HeadersExchangeTests) ... ok
testDifferentDeclaredType (tests.exchange.MiscellaneousErrorsTests) ... ok
testTypeNotKnown (tests.exchange.MiscellaneousErrorsTests) ... ok
testDirect (tests.exchange.RecommendedTypesRuleTests) ... ok
testFanout (tests.exchange.RecommendedTypesRuleTests) ... ok
testHeaders (tests.exchange.RecommendedTypesRuleTests) ... ok
testAmqDirect (tests.exchange.RequiredInstancesRuleTests) ... ok
testAmqFanOut (tests.exchange.RequiredInstancesRuleTests) ... ok
testAmqMatch (tests.exchange.RequiredInstancesRuleTests) ... ok
test_bind (tests.queue.QueueTests) ... ok
test_declare_exclusive (tests.queue.QueueTests) ... ok
test_declare_passive (tests.queue.QueueTests) ... ok
test_delete_ifempty (tests.queue.QueueTests) ... ok
test_delete_ifunused (tests.queue.QueueTests) ... ok
test_delete_simple (tests.queue.QueueTests) ... ok
test_purge (tests.queue.QueueTests) ... ok
testAssertEmptyFail (tests.testlib.TestBaseTest) ... ok
testAssertEmptyPass (tests.testlib.TestBaseTest) ... ok
testMessageProperties (tests.testlib.TestBaseTest) ... ok
test_auto_rollback (tests.tx.TxTests) ... ok
test_commit (tests.tx.TxTests) ... ok
test_commit_overlapping_acks (tests.tx.TxTests) ... ok
test_rollback (tests.tx.TxTests) ... ok
----------------------------------------------------------------------
Ran 42 tests in 56.311s
OK
=======================================
NOTE: the following tests were ignored:
tests.exchange.RecommendedTypesRuleTests.testTopic
tests.exchange.RequiredInstancesRuleTests.testAmqTopic
=======================================
--
Martin Ritchie
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
On 06/03/07, Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2007-03-06 at 11:38 +0000, Martin Ritchie wrote:
> > On 05/03/07, Alan Conway <ac...@redhat.com> wrote:
> > > I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> > > know of any outstanding issues. The plan is to merge python first for
> > > the tests (branch python speaks both old & new protocols) then the C++
> > > codebase.
> > >
> > > I'm currently working on getting python verified against all brokers
> > > (trunk/branch, c++/java).
> >
> > Alan, I have some updates to the Java broker if you are working on the
> > C++ - python I shall look at that java - python. Ensuring my recent
> > updates haven't broken a python test.
> >
>
> I'm still seeing many python test failures against the java broker on
> trunk.
>
> Here's the failure output:
>
> .E.E.FFF.........F.......F....E...E.EEEEEEEEEE
> ======================================================================
> ERROR: test_ack (tests.basic.BasicTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/basic.py", line 178, in
> test_ack
> msg3b = queue.get(timeout=1)
> File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.4/Queue.py", line 127, in get
> raise Empty
> Empty
>
> ======================================================================
> ERROR: test_consume_exclusive (tests.basic.BasicTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/basic.py", line 72, in
> test_consume_exclusive
> channel.channel_open()
> File "<string>", line 3, in channel_open
> File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> raise Closed(self.reason)
> Closed
>
> ======================================================================
> ERROR: testTopic (tests.exchange.RecommendedTypesRuleTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/exchange.py", line 101, in
> testTopic
> self.verifyTopicExchange("t")
> File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
> verifyTopicExchange
> self.assertPublishGet(q, ex, "a.b.x")
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
> assertPublishGet
> msg = queue.get(timeout=1)
> File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.4/Queue.py", line 127, in get
> raise Empty
> Empty
>
> ======================================================================
> ERROR: testAmqTopic (tests.exchange.RequiredInstancesRuleTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/exchange.py", line 123, in
> testAmqTopic
> def testAmqTopic(self): self.verifyTopicExchange("amq.topic")
> File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
> verifyTopicExchange
> self.assertPublishGet(q, ex, "a.b.x")
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
> assertPublishGet
> msg = queue.get(timeout=1)
> File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
> result = BaseQueue.get(self, block, timeout)
> File "/usr/lib/python2.4/Queue.py", line 127, in get
> raise Empty
> Empty
>
> ======================================================================
> ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/broker.py", line 58, in
> test_basic_delivery_immediate
> self.queue_declare(channel, queue="test-queue")
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
> queue_declare
> reply = channel.queue_declare(*args, **keys)
> File "<string>", line 3, in queue_declare
> File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> raise Closed(self.reason)
> Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> exclusive queue with same name declared on another connection [error
> code 405: Already exists]', 50, 10) content = None
>
> ======================================================================
> ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
> tearDown
> ch.exchange_delete(exchange=ex)
> File "<string>", line 3, in exchange_delete
> File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
> raise Closed(self.reason)
> Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> exclusive queue with same name declared on another connection [error
> code 405: Already exists]', 50, 10) content = None
>
> ======================================================================
> ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/broker.py", line 78, in
> test_basic_delivery_queued
> self.queue_declare(channel, queue="test-queue")
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
> queue_declare
> reply = channel.queue_declare(*args, **keys)
> File "<string>", line 3, in queue_declare
> File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
> raise Closed(self.reason)
> Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> exclusive queue with same name declared on another connection [error
> code 405: Already exists]', 50, 10) content = None
>
> ======================================================================
> ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
> tearDown
> ch.exchange_delete(exchange=ex)
> File "<string>", line 3, in exchange_delete
> File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
> raise Closed(self.reason)
> Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
> exclusive queue with same name declared on another connection [error
> code 405: Already exists]', 50, 10) content = None
>
> ======================================================================
> ERROR: test_closed_channel (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/broker.py", line 103, in
> test_closed_channel
> self.assertConnectionException(504, e.args[0])
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 234, in
> assertConnectionException
> self.assertEqual("connection", message.method.klass.name)
> AttributeError: Closed instance has no attribute 'method'
>
> ======================================================================
> ERROR: test_invalid_channel (tests.broker.BrokerTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> setUp
> self.client = self.connect()
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> connect
> return testrunner.connect(*args, **keys)
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> connect
> client.start({"LOGIN": user, "PASSWORD": password})
> File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> self.conn.connect()
> File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> connect
> sock.connect((self.host, self.port))
> File "<string>", line 1, in connect
> error: (111, 'Connection refused')
>
> ======================================================================
> ERROR: test_auto_rollback (tests.tx.TxTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> setUp
> self.client = self.connect()
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> connect
> return testrunner.connect(*args, **keys)
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> connect
> client.start({"LOGIN": user, "PASSWORD": password})
> File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> self.conn.connect()
> File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> connect
> sock.connect((self.host, self.port))
> File "<string>", line 1, in connect
> error: (111, 'Connection refused')
>
> ======================================================================
> ERROR: test_commit (tests.tx.TxTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> setUp
> self.client = self.connect()
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> connect
> return testrunner.connect(*args, **keys)
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> connect
> client.start({"LOGIN": user, "PASSWORD": password})
> File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> self.conn.connect()
> File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> connect
> sock.connect((self.host, self.port))
> File "<string>", line 1, in connect
> error: (111, 'Connection refused')
>
> ======================================================================
> ERROR: test_commit_overlapping_acks (tests.tx.TxTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> setUp
> self.client = self.connect()
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> connect
> return testrunner.connect(*args, **keys)
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> connect
> client.start({"LOGIN": user, "PASSWORD": password})
> File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> self.conn.connect()
> File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> connect
> sock.connect((self.host, self.port))
> File "<string>", line 1, in connect
> error: (111, 'Connection refused')
>
> ======================================================================
> ERROR: test_rollback (tests.tx.TxTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
> setUp
> self.client = self.connect()
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
> connect
> return testrunner.connect(*args, **keys)
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
> connect
> client.start({"LOGIN": user, "PASSWORD": password})
> File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
> self.conn.connect()
> File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
> connect
> sock.connect((self.host, self.port))
> File "<string>", line 1, in connect
> error: (111, 'Connection refused')
>
> ======================================================================
> FAIL: test_consume_queue_errors (tests.basic.BasicTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/basic.py", line 101, in
> test_consume_queue_errors
> self.assertConnectionException(530, e.args[0])
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> assertConnectionException
> self.assertEqual(expectedCode, message.reply_code)
> AssertionError: 530 != 507
>
> ======================================================================
> FAIL: test_consume_unique_consumers (tests.basic.BasicTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/basic.py", line 117, in
> test_consume_unique_consumers
> self.assertConnectionException(530, e.args[0])
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> assertConnectionException
> self.assertEqual(expectedCode, message.reply_code)
> AssertionError: 530 != 507
>
> ======================================================================
> FAIL: test_get (tests.basic.BasicTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/basic.py", line 350, in
> test_get
> self.assertEqual(reply.method.name, "get-ok")
> AssertionError: u'get-empty' != 'get-ok'
>
> ======================================================================
> FAIL: test_purge (tests.queue.QueueTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/queue.py", line 46, in
> test_purge
> self.assertEqual(3, reply.message_count)
> AssertionError: 3 != 0L
>
> ======================================================================
> FAIL: testDifferentDeclaredType
> (tests.exchange.MiscellaneousErrorsTests)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/aconway/svn/qpid/python/tests/exchange.py", line 321, in
> testDifferentDeclaredType
> self.assertConnectionException(530, e.args[0])
> File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
> assertConnectionException
> self.assertEqual(expectedCode, message.reply_code)
> AssertionError: 530 != 507
>
> ----------------------------------------------------------------------
> Ran 44 tests in 536.599s
>
> FAILED (failures=5, errors=14)
Alan your java code needs an SVN update. These were the errors I was
seeing before I did my recent commit. I shall do an update and ensure
that the trunk passes all the python tests.
The two topic tests will still fail but they are listed in the
java_failing.txt file. I hope to have those to sorted soon.
--
Martin Ritchie
[java] python test status (was Re: C++ 0-9 merge heads up)
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> I'm still seeing many python test failures against the java broker on
> trunk.
They work for me. A lot of the errors you are seeing seem to indicate
some odd problems.
There are some connection refused errors which would seem to indicate a
broker crash or something(?).
The use of the 507 code is also odd; I can't find that number being used
in the current codebase (based on a very simple greping of files). Are
you sure you are running a fresh build?
The 'exclusive queue already declared' are most likely due to earlier
failures - the python client doesn't close sockets reliably on failure,
I made changes for this on the 0-9 branch. We will get those when you
merge or I can move them across separately.
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2007-03-06 at 11:38 +0000, Martin Ritchie wrote:
> On 05/03/07, Alan Conway <ac...@redhat.com> wrote:
> > I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> > know of any outstanding issues. The plan is to merge python first for
> > the tests (branch python speaks both old & new protocols) then the C++
> > codebase.
> >
> > I'm currently working on getting python verified against all brokers
> > (trunk/branch, c++/java).
>
> Alan, I have some updates to the Java broker if you are working on the
> C++ - python I shall look at that java - python. Ensuring my recent
> updates haven't broken a python test.
>
I'm still seeing many python test failures against the java broker on
trunk.
Here's the failure output:
.E.E.FFF.........F.......F....E...E.EEEEEEEEEE
======================================================================
ERROR: test_ack (tests.basic.BasicTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/basic.py", line 178, in
test_ack
msg3b = queue.get(timeout=1)
File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
result = BaseQueue.get(self, block, timeout)
File "/usr/lib/python2.4/Queue.py", line 127, in get
raise Empty
Empty
======================================================================
ERROR: test_consume_exclusive (tests.basic.BasicTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/basic.py", line 72, in
test_consume_exclusive
channel.channel_open()
File "<string>", line 3, in channel_open
File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
raise Closed(self.reason)
Closed
======================================================================
ERROR: testTopic (tests.exchange.RecommendedTypesRuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/exchange.py", line 101, in
testTopic
self.verifyTopicExchange("t")
File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
verifyTopicExchange
self.assertPublishGet(q, ex, "a.b.x")
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
assertPublishGet
msg = queue.get(timeout=1)
File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
result = BaseQueue.get(self, block, timeout)
File "/usr/lib/python2.4/Queue.py", line 127, in get
raise Empty
Empty
======================================================================
ERROR: testAmqTopic (tests.exchange.RequiredInstancesRuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/exchange.py", line 123, in
testAmqTopic
def testAmqTopic(self): self.verifyTopicExchange("amq.topic")
File "/home/aconway/svn/qpid/python/tests/exchange.py", line 60, in
verifyTopicExchange
self.assertPublishGet(q, ex, "a.b.x")
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 216, in
assertPublishGet
msg = queue.get(timeout=1)
File "/home/aconway/svn/qpid/python/qpid/queue.py", line 38, in get
result = BaseQueue.get(self, block, timeout)
File "/usr/lib/python2.4/Queue.py", line 127, in get
raise Empty
Empty
======================================================================
ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/broker.py", line 58, in
test_basic_delivery_immediate
self.queue_declare(channel, queue="test-queue")
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
queue_declare
reply = channel.queue_declare(*args, **keys)
File "<string>", line 3, in queue_declare
File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
raise Closed(self.reason)
Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
exclusive queue with same name declared on another connection [error
code 405: Already exists]', 50, 10) content = None
======================================================================
ERROR: test_basic_delivery_immediate (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
tearDown
ch.exchange_delete(exchange=ex)
File "<string>", line 3, in exchange_delete
File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
raise Closed(self.reason)
Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
exclusive queue with same name declared on another connection [error
code 405: Already exists]', 50, 10) content = None
======================================================================
ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/broker.py", line 78, in
test_basic_delivery_queued
self.queue_declare(channel, queue="test-queue")
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 178, in
queue_declare
reply = channel.queue_declare(*args, **keys)
File "<string>", line 3, in queue_declare
File "/home/aconway/svn/qpid/python/qpid/peer.py", line 182, in invoke
raise Closed(self.reason)
Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
exclusive queue with same name declared on another connection [error
code 405: Already exists]', 50, 10) content = None
======================================================================
ERROR: test_basic_delivery_queued (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 170, in
tearDown
ch.exchange_delete(exchange=ex)
File "<string>", line 3, in exchange_delete
File "/home/aconway/svn/qpid/python/qpid/peer.py", line 153, in invoke
raise Closed(self.reason)
Closed: Method(name=close, id=40) (405, 'Cannot declare queue, as
exclusive queue with same name declared on another connection [error
code 405: Already exists]', 50, 10) content = None
======================================================================
ERROR: test_closed_channel (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/broker.py", line 103, in
test_closed_channel
self.assertConnectionException(504, e.args[0])
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 234, in
assertConnectionException
self.assertEqual("connection", message.method.klass.name)
AttributeError: Closed instance has no attribute 'method'
======================================================================
ERROR: test_invalid_channel (tests.broker.BrokerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
setUp
self.client = self.connect()
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
connect
return testrunner.connect(*args, **keys)
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
connect
client.start({"LOGIN": user, "PASSWORD": password})
File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
self.conn.connect()
File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
======================================================================
ERROR: test_auto_rollback (tests.tx.TxTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
setUp
self.client = self.connect()
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
connect
return testrunner.connect(*args, **keys)
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
connect
client.start({"LOGIN": user, "PASSWORD": password})
File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
self.conn.connect()
File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
======================================================================
ERROR: test_commit (tests.tx.TxTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
setUp
self.client = self.connect()
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
connect
return testrunner.connect(*args, **keys)
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
connect
client.start({"LOGIN": user, "PASSWORD": password})
File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
self.conn.connect()
File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
======================================================================
ERROR: test_commit_overlapping_acks (tests.tx.TxTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
setUp
self.client = self.connect()
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
connect
return testrunner.connect(*args, **keys)
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
connect
client.start({"LOGIN": user, "PASSWORD": password})
File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
self.conn.connect()
File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
======================================================================
ERROR: test_rollback (tests.tx.TxTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 162, in
setUp
self.client = self.connect()
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 174, in
connect
return testrunner.connect(*args, **keys)
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 139, in
connect
client.start({"LOGIN": user, "PASSWORD": password})
File "/home/aconway/svn/qpid/python/qpid/client.py", line 79, in start
self.conn.connect()
File "/home/aconway/svn/qpid/python/qpid/connection.py", line 66, in
connect
sock.connect((self.host, self.port))
File "<string>", line 1, in connect
error: (111, 'Connection refused')
======================================================================
FAIL: test_consume_queue_errors (tests.basic.BasicTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/basic.py", line 101, in
test_consume_queue_errors
self.assertConnectionException(530, e.args[0])
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
assertConnectionException
self.assertEqual(expectedCode, message.reply_code)
AssertionError: 530 != 507
======================================================================
FAIL: test_consume_unique_consumers (tests.basic.BasicTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/basic.py", line 117, in
test_consume_unique_consumers
self.assertConnectionException(530, e.args[0])
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
assertConnectionException
self.assertEqual(expectedCode, message.reply_code)
AssertionError: 530 != 507
======================================================================
FAIL: test_get (tests.basic.BasicTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/basic.py", line 350, in
test_get
self.assertEqual(reply.method.name, "get-ok")
AssertionError: u'get-empty' != 'get-ok'
======================================================================
FAIL: test_purge (tests.queue.QueueTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/queue.py", line 46, in
test_purge
self.assertEqual(3, reply.message_count)
AssertionError: 3 != 0L
======================================================================
FAIL: testDifferentDeclaredType
(tests.exchange.MiscellaneousErrorsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/aconway/svn/qpid/python/tests/exchange.py", line 321, in
testDifferentDeclaredType
self.assertConnectionException(530, e.args[0])
File "/home/aconway/svn/qpid/python/qpid/testlib.py", line 236, in
assertConnectionException
self.assertEqual(expectedCode, message.reply_code)
AssertionError: 530 != 507
----------------------------------------------------------------------
Ran 44 tests in 536.599s
FAILED (failures=5, errors=14)
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
On 05/03/07, Alan Conway <ac...@redhat.com> wrote:
> I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> know of any outstanding issues. The plan is to merge python first for
> the tests (branch python speaks both old & new protocols) then the C++
> codebase.
>
> I'm currently working on getting python verified against all brokers
> (trunk/branch, c++/java).
Alan, I have some updates to the Java broker if you are working on the
C++ - python I shall look at that java - python. Ensuring my recent
updates haven't broken a python test.
--
Martin Ritchie
Re: C++ 0-9 merge heads up
Posted by Alan Conway <ac...@redhat.com>.
+1 - Kim can answer the question on the code generator.
On Tue, 2007-03-06 at 15:58 +0000, Robert Godfrey wrote:
> Addressing these points in a random order:
>
> 1) Changing the spec file:
>
> I think we should ensure that all our changes are in a separate XML file
> from the official AMQP spec. We can then overlay these on top of the
> official spec at code generation time. There is some ability in the code
> generator to do this, but as to whether it would work for the case of
> replacing a method with a new version with an extra argument, I would have
> to find by experimentation :-)
>
> 2) Interoperability
>
> I think we should do our best to guarantee that any change that we make will
> not stop an AMQP compliant client working correctly with our broker. That
> is no new arguments (unless they are bits which default to false in methods
> which already have bitfields)... no new contracts (i.e. that a client must
> sent command Y whenever the broker sends command X).
>
> Our issue is that there are things in the AMQP spec which are unclear or
> cannot be implemented safely without the addition of extra methods. On
> alternative would be to implement a parallel method (lets say, rollback2 or
> recover2) which has the extra method. This would obviously require some
> duplication of handler code on our part, but would not be so fundamentally
> non-compliant with the spec.
>
> Our particular problem here is that we *know* that the spec in this area
> will be changing, so there is no point lobbying for a spec change.
>
> All my opinion only, of course :-)
>
> -- Rob
>
> On 06/03/07, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Martin Ritchie wrote:
> > > I didn't think that change 'extra' spec change would affect the C++ as
> > > it is only required if nowait is false.
> >
> > Almost all changes to a spec file will affect any implementation that
> > uses that spec file. Even adding an unused parameter to a method has an
> > effect - for c++, any client or broker built against that will require
> > that parameter to be specified or else a decoding error will occur.
> > Whether it breaks anything (beyond interoperability) is a separate
> > question.
> >
> > As nowait is false by default, any piece of code not explicitly updated
> > to set the new parameter to true will require a response. The python
> > client waits for responses if they are to be sent, resulting in the test
> > hanging if the broker doesn't respond as expected.
> >
> > I'm not jumping on this case only, and I know this has been discussed
> > before, but I think we must be very careful about modifications of the
> > spec file.
> >
> > For one thing I'm not sure how that works with the copyright on the top
> > of those files; are we allowed to make changes to this file? do we need
> > to make those changes clear in some way?
> >
> > Another issue is that when we come to creating releases our
> > implementation is non-compliant. This is different (and worse in my
> > opinion) than merely not implementing everything or adding extra
> > functionality. Again, I'm not sure what the legal position is w.r.t
> > releasing AMQP 'implementations' with altered methods.
> >
Code generator and changes to the XML (was C++ 0-9 merge heads up)
Posted by Kim van der Riet <ki...@redhat.com>.
On Tue, 2007-03-06 at 15:58 +0000, Robert Godfrey wrote:
> I think we should ensure that all our changes are in a separate XML
> file
> from the official AMQP spec. We can then overlay these on top of the
> official spec at code generation time.
Agreed. This minimized the possibility that changes required for one
implementation will adversely affect the others.
> There is some ability in the code
> generator to do this, but as to whether it would work for the case of
> replacing a method with a new version with an extra argument, I would
> have
> to find by experimentation :-)
The code generator can suppress and/or add additional elements to the
XML down to field level. The only thing it cannot do at present is
insert an additional field into the middle of an existing method's field
list, it will only append the extra field to the end of the field list.
This is something that needs to be added to the generator in the future.
The code generator works in an additive mode, so each additional XML
file read prior to generation will add to the internal model. This
includes the elements that will be suppressed during generation, which
are appended to the elements in question as a special flag in the
internal model. Thus the XML file containing the suppressed elements
should be processed last as the generator needs to find the element to
be suppressed already in the internal model.
The 0-9 trunk currently uses the generator in both additive and suppress
modes.
Kim
Re: C++ 0-9 merge heads up
Posted by Gordon Sim <gs...@redhat.com>.
Robert Godfrey wrote:
> Addressing these points in a random order:
>
> 1) Changing the spec file:
>
> I think we should ensure that all our changes are in a separate XML file
> from the official AMQP spec. We can then overlay these on top of the
> official spec at code generation time. There is some ability in the code
> generator to do this, but as to whether it would work for the case of
> replacing a method with a new version with an extra argument, I would have
> to find by experimentation :-)
The generator on the 0-9 branch was altered to allow exactly that and it
does allow the addition of arguments for methods. I agree thats a nice
way to go as changes become more visible and more manageable.
> 2) Interoperability
>
> I think we should do our best to guarantee that any change that we make
> will
> not stop an AMQP compliant client working correctly with our broker. That
> is no new arguments (unless they are bits which default to false in methods
> which already have bitfields)... no new contracts (i.e. that a client must
> sent command Y whenever the broker sends command X).
>
> Our issue is that there are things in the AMQP spec which are unclear or
> cannot be implemented safely without the addition of extra methods. On
> alternative would be to implement a parallel method (lets say, rollback2 or
> recover2) which has the extra method. This would obviously require some
> duplication of handler code on our part, but would not be so fundamentally
> non-compliant with the spec.
>
> Our particular problem here is that we *know* that the spec in this area
> will be changing, so there is no point lobbying for a spec change.
I agree and am not saying that we should never ever change the spec
file, just that we should do so cautiously, and aim to minimise
interoperability and compliance issues.
In the particular case of recover the method is so underspecified that
the chances of interoperability are arguably pretty low anyway. Again,
different interpretations of a vague aspect of the standard reflect less
badly than do changes resulting in crashing channels.
Re: C++ 0-9 merge heads up
Posted by Robert Godfrey <ro...@gmail.com>.
Addressing these points in a random order:
1) Changing the spec file:
I think we should ensure that all our changes are in a separate XML file
from the official AMQP spec. We can then overlay these on top of the
official spec at code generation time. There is some ability in the code
generator to do this, but as to whether it would work for the case of
replacing a method with a new version with an extra argument, I would have
to find by experimentation :-)
2) Interoperability
I think we should do our best to guarantee that any change that we make will
not stop an AMQP compliant client working correctly with our broker. That
is no new arguments (unless they are bits which default to false in methods
which already have bitfields)... no new contracts (i.e. that a client must
sent command Y whenever the broker sends command X).
Our issue is that there are things in the AMQP spec which are unclear or
cannot be implemented safely without the addition of extra methods. On
alternative would be to implement a parallel method (lets say, rollback2 or
recover2) which has the extra method. This would obviously require some
duplication of handler code on our part, but would not be so fundamentally
non-compliant with the spec.
Our particular problem here is that we *know* that the spec in this area
will be changing, so there is no point lobbying for a spec change.
All my opinion only, of course :-)
-- Rob
On 06/03/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Martin Ritchie wrote:
> > I didn't think that change 'extra' spec change would affect the C++ as
> > it is only required if nowait is false.
>
> Almost all changes to a spec file will affect any implementation that
> uses that spec file. Even adding an unused parameter to a method has an
> effect - for c++, any client or broker built against that will require
> that parameter to be specified or else a decoding error will occur.
> Whether it breaks anything (beyond interoperability) is a separate
> question.
>
> As nowait is false by default, any piece of code not explicitly updated
> to set the new parameter to true will require a response. The python
> client waits for responses if they are to be sent, resulting in the test
> hanging if the broker doesn't respond as expected.
>
> I'm not jumping on this case only, and I know this has been discussed
> before, but I think we must be very careful about modifications of the
> spec file.
>
> For one thing I'm not sure how that works with the copyright on the top
> of those files; are we allowed to make changes to this file? do we need
> to make those changes clear in some way?
>
> Another issue is that when we come to creating releases our
> implementation is non-compliant. This is different (and worse in my
> opinion) than merely not implementing everything or adding extra
> functionality. Again, I'm not sure what the legal position is w.r.t
> releasing AMQP 'implementations' with altered methods.
>
Re: C++ 0-9 merge heads up
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> I didn't think that change 'extra' spec change would affect the C++ as
> it is only required if nowait is false.
Almost all changes to a spec file will affect any implementation that
uses that spec file. Even adding an unused parameter to a method has an
effect - for c++, any client or broker built against that will require
that parameter to be specified or else a decoding error will occur.
Whether it breaks anything (beyond interoperability) is a separate
question.
As nowait is false by default, any piece of code not explicitly updated
to set the new parameter to true will require a response. The python
client waits for responses if they are to be sent, resulting in the test
hanging if the broker doesn't respond as expected.
I'm not jumping on this case only, and I know this has been discussed
before, but I think we must be very careful about modifications of the
spec file.
For one thing I'm not sure how that works with the copyright on the top
of those files; are we allowed to make changes to this file? do we need
to make those changes clear in some way?
Another issue is that when we come to creating releases our
implementation is non-compliant. This is different (and worse in my
opinion) than merely not implementing everything or adding extra
functionality. Again, I'm not sure what the legal position is w.r.t
releasing AMQP 'implementations' with altered methods.
Re: C++ 0-9 merge heads up
Posted by Martin Ritchie <ri...@apache.org>.
On 06/03/07, Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2007-03-06 at 12:32 +0000, Martin Ritchie wrote:
> > On 05/03/07, Alan Conway <ac...@redhat.com> wrote:
> > > I'll be merging the 0-9 C++ branch (Jira QPID-400) soon, speak up if you
> > > know of any outstanding issues. The plan is to merge python first for
> > > the tests (branch python speaks both old & new protocols) then the C++
> > > codebase.
> > >
> > > I'm currently working on getting python verified against all brokers
> > > (trunk/branch, c++/java).
> >
> > Alan,
> >
> > I have the Java broker passing the python tests. I'm in the process of
> > preparing my commit. There were a couple of cases of the code just
> > being wrong, the purge for example never actually purged the messages
> > properly.
> >
> > Once I have done this I shall get mvn running the python tests.
> >
>
> Excellent, thanks. I've fixed the one failure in the C++ broker (wasn't
> sending recoverOK responses) so we should be in good shape.
>
> Cheers,
> Alan.
I didn't think that change 'extra' spec change would affect the C++ as
it is only required if nowait is false.
The Java broker also now passes the Python tests. With the transaction
fixes now in perhaps i'll have time to sort finish off the topic
matching :D
--
Martin Ritchie