You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Steve Vinoski <vi...@iona.com> on 2006/11/08 06:12:37 UTC
[java] client tests hanging
After the flurry of commits yesterday, I'm seeing the client tests
hang with an error about being unable to connect to the broker (see
below). Anyone else seeing the same?
--steve
[junit] 2006-11-08 00:08:45,746 INFO [pool-9-thread-3]
handler.ConnectionCloseMethodHandler
(ConnectionCloseMethodHandler.java:52) - ConnectionClose received
with reply code/reply text 200/JMS client is closing the connection.
for AMQProtocolSession(anonymous(15375609))
[junit] 2006-11-08 00:08:45,752 INFO [AnonymousIoService-7]
protocol.AMQProtocolHandler (AMQProtocolHandler.java:167) - Session
closed called by client
[junit] 2006-11-08 00:08:45,753 INFO [AnonymousIoService-7]
protocol.AMQProtocolHandler (AMQProtocolHandler.java:212) - Protocol
Session [org.apache.qpid.client.protocol.AMQProtocolHandler@82f3da]
closed
[junit] 2006-11-08 00:08:45,779 INFO [main]
protocol.AMQPFastProtocolHandler (AMQPFastProtocolHandler.java:132) -
Protocol Session closed
[junit] 2006-11-08 00:08:45,784 INFO [main] pool.PoolingFilter
(PoolingFilter.java:179) - Destroy called on PoolingFilter
AsynchronousWriteFilter
[junit] 2006-11-08 00:08:45,791 INFO [main] pool.PoolingFilter
(PoolingFilter.java:179) - Destroy called on PoolingFilter
AsynchronousReadFilter
[junit] 2006-11-08 00:08:45,799 INFO [main]
transport.TransportConnection (TransportConnection.java:311) -
Killing VM Broker:1
[junit] 2006-11-08 00:08:45,805 INFO [main]
client.AMQConnection (AMQConnection.java:174) - Connection:amqp://
guest:guest@Client1162962525805/test_path?brokerlist='vm://:1'
[junit] 2006-11-08 00:08:45,812 INFO [main]
client.AMQConnection (AMQConnection.java:210) - Unable to connect to
broker at vm://:1
Re: [java] client tests hanging
Posted by Marnie McCormack <ma...@googlemail.com>.
We *really* didn't mean to cause you any problems. Sorry.
We didn't know what the test restructuring you were doing was so the damage
was inadvertant :-( We're done on the release changes front now - so
shouldn't hold you up.
BTW we don't usually send notes about what we're planning to work on. Maybe
we need to have a project policy on using the 'Start Progress' JIRA option
to help with this ?
Marnie
On Nov 10, 2006, at 10:10 AM, Martin Ritchie wrote:
> On 10/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> On Nov 10, 2006, at 3:28 AM, Marnie McCormack wrote:
>> > As you all know we're currently getting organised for M1.
>>
>> Yep, and I've been working to make maven ready for it. Brian asked
>> the question about moving to maven for M1 in another thread last
>> night, and I'm surprised to see no answers to it this morning.
>>
>> > At things stand
>> > there are several open JIRAs for this work. Most of the changes you
>> > are
>> > seeing are directly related to the legal/license requirements for
>> > releasing,
>> > with some others being derived from these changes.
>>
>> This isn't accurate. I don't think the reorganization of tests that
>> occurred earlier this week was necessary for legal/license
>> requirements.
>>
>> All I'm saying in my email below is that 1) it would have been nice
>> to have gotten advance notice that the tests were going to be
>> reorganized, so that I wouldn't have wasted time moving the old stuff
>> around on my branch, and 2) the only thing keeping maven from being
>> ready for M1 is the need for further improvement to the test
>> structure.
>
> I'm sorry you feel like you wasted time moving the old stuff arround.
> We were having increased problems with the tests failing and not
> seeing exactly why so started the re-org as per QPID-37 created back
> Oct 17th.
IMO a JIRA is a definitely good thing to have for cases like this,
but it's not enough -- it's no substitute for a simple note to qpid-
dev announcing that you're planning to reorganize stuff to resolve it.
--steve
Re: [java] client tests hanging
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 10, 2006, at 10:10 AM, Martin Ritchie wrote:
> On 10/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> On Nov 10, 2006, at 3:28 AM, Marnie McCormack wrote:
>> > As you all know we're currently getting organised for M1.
>>
>> Yep, and I've been working to make maven ready for it. Brian asked
>> the question about moving to maven for M1 in another thread last
>> night, and I'm surprised to see no answers to it this morning.
>>
>> > At things stand
>> > there are several open JIRAs for this work. Most of the changes you
>> > are
>> > seeing are directly related to the legal/license requirements for
>> > releasing,
>> > with some others being derived from these changes.
>>
>> This isn't accurate. I don't think the reorganization of tests that
>> occurred earlier this week was necessary for legal/license
>> requirements.
>>
>> All I'm saying in my email below is that 1) it would have been nice
>> to have gotten advance notice that the tests were going to be
>> reorganized, so that I wouldn't have wasted time moving the old stuff
>> around on my branch, and 2) the only thing keeping maven from being
>> ready for M1 is the need for further improvement to the test
>> structure.
>
> I'm sorry you feel like you wasted time moving the old stuff arround.
> We were having increased problems with the tests failing and not
> seeing exactly why so started the re-org as per QPID-37 created back
> Oct 17th.
IMO a JIRA is a definitely good thing to have for cases like this,
but it's not enough -- it's no substitute for a simple note to qpid-
dev announcing that you're planning to reorganize stuff to resolve it.
--steve
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
On 10/11/06, Steve Vinoski <vi...@iona.com> wrote:
> On Nov 10, 2006, at 3:28 AM, Marnie McCormack wrote:
> > As you all know we're currently getting organised for M1.
>
> Yep, and I've been working to make maven ready for it. Brian asked
> the question about moving to maven for M1 in another thread last
> night, and I'm surprised to see no answers to it this morning.
>
> > At things stand
> > there are several open JIRAs for this work. Most of the changes you
> > are
> > seeing are directly related to the legal/license requirements for
> > releasing,
> > with some others being derived from these changes.
>
> This isn't accurate. I don't think the reorganization of tests that
> occurred earlier this week was necessary for legal/license requirements.
>
> All I'm saying in my email below is that 1) it would have been nice
> to have gotten advance notice that the tests were going to be
> reorganized, so that I wouldn't have wasted time moving the old stuff
> around on my branch, and 2) the only thing keeping maven from being
> ready for M1 is the need for further improvement to the test structure.
I'm sorry you feel like you wasted time moving the old stuff arround.
We were having increased problems with the tests failing and not
seeing exactly why so started the re-org as per QPID-37 created back
Oct 17th.
> > Martin, Rajith & I have been doing the work for the release, but
> > everyone is
> > most welcome (indeed encouraged) to contribute to the leg work on
> > this front
> > - via the JIRAs (and any new ones you think we need). We're hoping to
> > complete the restructuring required for release later today. It's not
> > exciting, but we're getting there.
>
> And as I've noted several times, if anyone wants to pitch in and help
> on the maven front, that would be great as well.
>
> > For unrelated changes to the tests that you think a good idea -
> > probably
> > best to raise JIRAs with details and progress them after M1 is
> > complete to
> > minimise flux.
>
> These aren't unrelated test changes -- they're required for maven to
> work.
>
> > Plenty to be done :-)
>
> Indeed, but let's not make a flurry of immediate changes in the name
> of M1 based on assumptions that may or may not be accurate. You seem
> to be assuming that maven is not in the M1 picture, while a number of
> the rest of us are not making that assumption, as indicated by
> Brian's other email thread.
>
> --steve
>
> >
> > Marnie
> >
> >
> > On 11/10/06, Steve Vinoski <vi...@iona.com> wrote:
> >>
> >> On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
> >> > - Reorganised unit tests to test.unit
> >> > + This allows ant build system to show what is being built and
> >> > allow easier detection of failure
> >>
> >> BTW, despite the reorganization of the unit tests earlier this week,
> >> the client tests still suffer a fundamental flaw: they depend on test
> >> classes under the broker directory. In general, unit tests, for
> >> purposes of isolation, should have as few dependencies as possible,
> >> so this arrangement is less than ideal. It's also specifically bad
> >> from a maven POV because by default maven builds each subproject's
> >> unit tests separately. Such isolation enforcement via standardized
> >> project directory structure is another nice feature of maven.
> >>
> >> The client org.apache.qpid.test.unit.ack.DisconnectAndRedeliverTest
> >> class appears to be a big offender in this regard, for example. This
> >> is one of the issues that's been giving me fits on the maven branch.
> >> Over there, I've been trying to move tests that aren't really unit
> >> tests out of the subproject test subdirectories and into a new top-
> >> level subproject under qpid/java called systests. The unannounced
> >> test reorganizations this week have not helped the maven work,
> >> because it means I have to pick up the new structure from the trunk
> >> and get it over on the branch, determine yet again which tests are
> >> actual unit tests and which aren't, and try again to move everything
> >> to where it needs to be. Please don't do any more moves in the trunk
> >> like that for now. Rather, if you'd like to help move things around,
> >> let's do so on the maven branch, as this issue is really the only
> >> blocker remaining to having maven working.
> >>
> >> thanks,
> >> --steve
> >>
>
>
--
Martin Ritchie
Re: [java] client tests hanging
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 10, 2006, at 3:28 AM, Marnie McCormack wrote:
> As you all know we're currently getting organised for M1.
Yep, and I've been working to make maven ready for it. Brian asked
the question about moving to maven for M1 in another thread last
night, and I'm surprised to see no answers to it this morning.
> At things stand
> there are several open JIRAs for this work. Most of the changes you
> are
> seeing are directly related to the legal/license requirements for
> releasing,
> with some others being derived from these changes.
This isn't accurate. I don't think the reorganization of tests that
occurred earlier this week was necessary for legal/license requirements.
All I'm saying in my email below is that 1) it would have been nice
to have gotten advance notice that the tests were going to be
reorganized, so that I wouldn't have wasted time moving the old stuff
around on my branch, and 2) the only thing keeping maven from being
ready for M1 is the need for further improvement to the test structure.
> Martin, Rajith & I have been doing the work for the release, but
> everyone is
> most welcome (indeed encouraged) to contribute to the leg work on
> this front
> - via the JIRAs (and any new ones you think we need). We're hoping to
> complete the restructuring required for release later today. It's not
> exciting, but we're getting there.
And as I've noted several times, if anyone wants to pitch in and help
on the maven front, that would be great as well.
> For unrelated changes to the tests that you think a good idea -
> probably
> best to raise JIRAs with details and progress them after M1 is
> complete to
> minimise flux.
These aren't unrelated test changes -- they're required for maven to
work.
> Plenty to be done :-)
Indeed, but let's not make a flurry of immediate changes in the name
of M1 based on assumptions that may or may not be accurate. You seem
to be assuming that maven is not in the M1 picture, while a number of
the rest of us are not making that assumption, as indicated by
Brian's other email thread.
--steve
>
> Marnie
>
>
> On 11/10/06, Steve Vinoski <vi...@iona.com> wrote:
>>
>> On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
>> > - Reorganised unit tests to test.unit
>> > + This allows ant build system to show what is being built and
>> > allow easier detection of failure
>>
>> BTW, despite the reorganization of the unit tests earlier this week,
>> the client tests still suffer a fundamental flaw: they depend on test
>> classes under the broker directory. In general, unit tests, for
>> purposes of isolation, should have as few dependencies as possible,
>> so this arrangement is less than ideal. It's also specifically bad
>> from a maven POV because by default maven builds each subproject's
>> unit tests separately. Such isolation enforcement via standardized
>> project directory structure is another nice feature of maven.
>>
>> The client org.apache.qpid.test.unit.ack.DisconnectAndRedeliverTest
>> class appears to be a big offender in this regard, for example. This
>> is one of the issues that's been giving me fits on the maven branch.
>> Over there, I've been trying to move tests that aren't really unit
>> tests out of the subproject test subdirectories and into a new top-
>> level subproject under qpid/java called systests. The unannounced
>> test reorganizations this week have not helped the maven work,
>> because it means I have to pick up the new structure from the trunk
>> and get it over on the branch, determine yet again which tests are
>> actual unit tests and which aren't, and try again to move everything
>> to where it needs to be. Please don't do any more moves in the trunk
>> like that for now. Rather, if you'd like to help move things around,
>> let's do so on the maven branch, as this issue is really the only
>> blocker remaining to having maven working.
>>
>> thanks,
>> --steve
>>
Re: [java] client tests hanging
Posted by Marnie McCormack <ma...@googlemail.com>.
As you all know we're currently getting organised for M1. At things stand
there are several open JIRAs for this work. Most of the changes you are
seeing are directly related to the legal/license requirements for releasing,
with some others being derived from these changes.
Martin, Rajith & I have been doing the work for the release, but everyone is
most welcome (indeed encouraged) to contribute to the leg work on this front
- via the JIRAs (and any new ones you think we need). We're hoping to
complete the restructuring required for release later today. It's not
exciting, but we're getting there.
For unrelated changes to the tests that you think a good idea - probably
best to raise JIRAs with details and progress them after M1 is complete to
minimise flux.
Plenty to be done :-)
Marnie
On 11/10/06, Steve Vinoski <vi...@iona.com> wrote:
>
> On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
> > - Reorganised unit tests to test.unit
> > + This allows ant build system to show what is being built and
> > allow easier detection of failure
>
> BTW, despite the reorganization of the unit tests earlier this week,
> the client tests still suffer a fundamental flaw: they depend on test
> classes under the broker directory. In general, unit tests, for
> purposes of isolation, should have as few dependencies as possible,
> so this arrangement is less than ideal. It's also specifically bad
> from a maven POV because by default maven builds each subproject's
> unit tests separately. Such isolation enforcement via standardized
> project directory structure is another nice feature of maven.
>
> The client org.apache.qpid.test.unit.ack.DisconnectAndRedeliverTest
> class appears to be a big offender in this regard, for example. This
> is one of the issues that's been giving me fits on the maven branch.
> Over there, I've been trying to move tests that aren't really unit
> tests out of the subproject test subdirectories and into a new top-
> level subproject under qpid/java called systests. The unannounced
> test reorganizations this week have not helped the maven work,
> because it means I have to pick up the new structure from the trunk
> and get it over on the branch, determine yet again which tests are
> actual unit tests and which aren't, and try again to move everything
> to where it needs to be. Please don't do any more moves in the trunk
> like that for now. Rather, if you'd like to help move things around,
> let's do so on the maven branch, as this issue is really the only
> blocker remaining to having maven working.
>
> thanks,
> --steve
>
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
Sorry Gordon, got called away before I hit commit.. Strange I thought
I had done that before I left. Ah well thanks for doing that.
On 10/11/06, Gordon Sim <gs...@redhat.com> wrote:
> Martin Ritchie wrote:
> > Sorry about that I hadn't noticed it there were two @Afters.
>
> I checked in a fix that removes the @After from the stopVmBroker() and
> calls that explicitly from the shutdown method. All tests pass for me.
>
--
Martin Ritchie
Re: [java] client tests hanging
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 10, 2006, at 4:22 AM, Gordon Sim wrote:
> Martin Ritchie wrote:
>> Sorry about that I hadn't noticed it there were two @Afters.
>
> I checked in a fix that removes the @After from the stopVmBroker()
> and calls that explicitly from the shutdown method. All tests pass
> for me.
All tests now pass for me as well.
--steve
Re: [java] client tests hanging
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> Sorry about that I hadn't noticed it there were two @Afters.
I checked in a fix that removes the @After from the stopVmBroker() and
calls that explicitly from the shutdown method. All tests pass for me.
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
Sorry about that I hadn't noticed it there were two @Afters.
On 10/11/06, Gordon Sim <gs...@redhat.com> wrote:
> Martin Ritchie wrote:
> > It is good that the test that depend on both client and broker test be
> > moved to a more central location. However, I am still concerned that
> > both test and testreport are failing for you.
> >
> > Is your qpid-head uptodate? What version of ant are you using. The
> > test target should stop on failures can you send me a thread dump when
> > it is hanging. I haven't seen TransactedTest timeout since the changes
> > I made.
>
> Fails for me also (though when run individually it seems to pass). The
> issue seems to be that the shutdown method blocks on closing the first
> connection while waiting for a basic.cancel-ok that never comes.
>
> I notice there are two methods labeled @After. Is there any guarantee on
> ordering of these? Perhaps the invm broker is being killed before the close?
>
--
Martin Ritchie
Re: [java] client tests hanging
Posted by Gordon Sim <gs...@redhat.com>.
Martin Ritchie wrote:
> It is good that the test that depend on both client and broker test be
> moved to a more central location. However, I am still concerned that
> both test and testreport are failing for you.
>
> Is your qpid-head uptodate? What version of ant are you using. The
> test target should stop on failures can you send me a thread dump when
> it is hanging. I haven't seen TransactedTest timeout since the changes
> I made.
Fails for me also (though when run individually it seems to pass). The
issue seems to be that the shutdown method blocks on closing the first
connection while waiting for a basic.cancel-ok that never comes.
I notice there are two methods labeled @After. Is there any guarantee on
ordering of these? Perhaps the invm broker is being killed before the close?
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
It is good that the test that depend on both client and broker test be
moved to a more central location. However, I am still concerned that
both test and testreport are failing for you.
Is your qpid-head uptodate? What version of ant are you using. The
test target should stop on failures can you send me a thread dump when
it is hanging. I haven't seen TransactedTest timeout since the changes
I made.
On 10/11/06, Steve Vinoski <vi...@iona.com> wrote:
> On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
> > - Reorganised unit tests to test.unit
> > + This allows ant build system to show what is being built and
> > allow easier detection of failure
>
> BTW, despite the reorganization of the unit tests earlier this week,
> the client tests still suffer a fundamental flaw: they depend on test
> classes under the broker directory. In general, unit tests, for
> purposes of isolation, should have as few dependencies as possible,
> so this arrangement is less than ideal. It's also specifically bad
> from a maven POV because by default maven builds each subproject's
> unit tests separately. Such isolation enforcement via standardized
> project directory structure is another nice feature of maven.
>
> The client org.apache.qpid.test.unit.ack.DisconnectAndRedeliverTest
> class appears to be a big offender in this regard, for example. This
> is one of the issues that's been giving me fits on the maven branch.
> Over there, I've been trying to move tests that aren't really unit
> tests out of the subproject test subdirectories and into a new top-
> level subproject under qpid/java called systests. The unannounced
> test reorganizations this week have not helped the maven work,
> because it means I have to pick up the new structure from the trunk
> and get it over on the branch, determine yet again which tests are
> actual unit tests and which aren't, and try again to move everything
> to where it needs to be. Please don't do any more moves in the trunk
> like that for now. Rather, if you'd like to help move things around,
> let's do so on the maven branch, as this issue is really the only
> blocker remaining to having maven working.
>
> thanks,
> --steve
>
--
Martin Ritchie
Re: [java] client tests hanging
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
> - Reorganised unit tests to test.unit
> + This allows ant build system to show what is being built and
> allow easier detection of failure
BTW, despite the reorganization of the unit tests earlier this week,
the client tests still suffer a fundamental flaw: they depend on test
classes under the broker directory. In general, unit tests, for
purposes of isolation, should have as few dependencies as possible,
so this arrangement is less than ideal. It's also specifically bad
from a maven POV because by default maven builds each subproject's
unit tests separately. Such isolation enforcement via standardized
project directory structure is another nice feature of maven.
The client org.apache.qpid.test.unit.ack.DisconnectAndRedeliverTest
class appears to be a big offender in this regard, for example. This
is one of the issues that's been giving me fits on the maven branch.
Over there, I've been trying to move tests that aren't really unit
tests out of the subproject test subdirectories and into a new top-
level subproject under qpid/java called systests. The unannounced
test reorganizations this week have not helped the maven work,
because it means I have to pick up the new structure from the trunk
and get it over on the branch, determine yet again which tests are
actual unit tests and which aren't, and try again to move everything
to where it needs to be. Please don't do any more moves in the trunk
like that for now. Rather, if you'd like to help move things around,
let's do so on the maven branch, as this issue is really the only
blocker remaining to having maven working.
thanks,
--steve
Re: [java] client tests hanging
Posted by Steve Vinoski <vi...@iona.com>.
On Nov 9, 2006, at 10:04 AM, Martin Ritchie wrote:
> Steve the tests were failing because the InVM broker hadn't been
> created. I have:
> - Check all unit tests create and destroy InVM Brokers
> - Reorganised unit tests to test.unit
> + This allows ant build system to show what is being built and
> allow easier detection of failure
> - The tests are now timedout after 90seconds so this should prevent
> the tests hanging forever.
>
> Let me know if the tests are still failling for you. I'd recommend the
> 'testreport' target this will show a summary on screen but create html
> reports in build/<module>/test/junit/index.html
If I run "ant test" it still hangs, in the
org.apache.qpid.test.unit.transacted.TransactedTest. I left it there
for many minutes to see if it would timeout and finish, but it didn't.
If I run "ant testreport" the same test fails due to
"junit.framework.AssertionFailedError: Timeout occurred", but at
least it doesn't hang.
--steve
>
> Cheers
>
> Martin
>
> On 08/11/06, Robert Greig <ro...@gmail.com> wrote:
>> On 08/11/06, Steve Vinoski <vi...@iona.com> wrote:
>> > After the flurry of commits yesterday, I'm seeing the client tests
>> > hang with an error about being unable to connect to the broker (see
>> > below). Anyone else seeing the same?
>>
>> I've just looked at our continuous build system which is still
>> running
>> the tests after 906 minutes so it looks like it is bust.
>>
>> We'll investigate further.
>>
>> RG
>>
>
>
> --
> Martin Ritchie
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
Steve the tests were failing because the InVM broker hadn't been
created. I have:
- Check all unit tests create and destroy InVM Brokers
- Reorganised unit tests to test.unit
+ This allows ant build system to show what is being built and
allow easier detection of failure
- The tests are now timedout after 90seconds so this should prevent
the tests hanging forever.
Let me know if the tests are still failling for you. I'd recommend the
'testreport' target this will show a summary on screen but create html
reports in build/<module>/test/junit/index.html
Cheers
Martin
On 08/11/06, Robert Greig <ro...@gmail.com> wrote:
> On 08/11/06, Steve Vinoski <vi...@iona.com> wrote:
> > After the flurry of commits yesterday, I'm seeing the client tests
> > hang with an error about being unable to connect to the broker (see
> > below). Anyone else seeing the same?
>
> I've just looked at our continuous build system which is still running
> the tests after 906 minutes so it looks like it is bust.
>
> We'll investigate further.
>
> RG
>
--
Martin Ritchie
Re: [java] client tests hanging
Posted by Robert Greig <ro...@gmail.com>.
On 08/11/06, Steve Vinoski <vi...@iona.com> wrote:
> After the flurry of commits yesterday, I'm seeing the client tests
> hang with an error about being unable to connect to the broker (see
> below). Anyone else seeing the same?
I've just looked at our continuous build system which is still running
the tests after 906 minutes so it looks like it is bust.
We'll investigate further.
RG
Re: [java] client tests hanging
Posted by Martin Ritchie <ri...@apache.org>.
On 08/11/06, Steve Vinoski <vi...@iona.com> wrote:
> After the flurry of commits yesterday, I'm seeing the client tests
> hang with an error about being unable to connect to the broker (see
> below). Anyone else seeing the same?
>
> --steve
>
> [junit] 2006-11-08 00:08:45,746 INFO [pool-9-thread-3]
> handler.ConnectionCloseMethodHandler
> (ConnectionCloseMethodHandler.java:52) - ConnectionClose received
> with reply code/reply text 200/JMS client is closing the connection.
> for AMQProtocolSession(anonymous(15375609))
> [junit] 2006-11-08 00:08:45,752 INFO [AnonymousIoService-7]
> protocol.AMQProtocolHandler (AMQProtocolHandler.java:167) - Session
> closed called by client
> [junit] 2006-11-08 00:08:45,753 INFO [AnonymousIoService-7]
> protocol.AMQProtocolHandler (AMQProtocolHandler.java:212) - Protocol
> Session [org.apache.qpid.client.protocol.AMQProtocolHandler@82f3da]
> closed
> [junit] 2006-11-08 00:08:45,779 INFO [main]
> protocol.AMQPFastProtocolHandler (AMQPFastProtocolHandler.java:132) -
> Protocol Session closed
> [junit] 2006-11-08 00:08:45,784 INFO [main] pool.PoolingFilter
> (PoolingFilter.java:179) - Destroy called on PoolingFilter
> AsynchronousWriteFilter
> [junit] 2006-11-08 00:08:45,791 INFO [main] pool.PoolingFilter
> (PoolingFilter.java:179) - Destroy called on PoolingFilter
> AsynchronousReadFilter
> [junit] 2006-11-08 00:08:45,799 INFO [main]
> transport.TransportConnection (TransportConnection.java:311) -
> Killing VM Broker:1
> [junit] 2006-11-08 00:08:45,805 INFO [main]
> client.AMQConnection (AMQConnection.java:174) - Connection:amqp://
> guest:guest@Client1162962525805/test_path?brokerlist='vm://:1'
> [junit] 2006-11-08 00:08:45,812 INFO [main]
> client.AMQConnection (AMQConnection.java:210) - Unable to connect to
> broker at vm://:1
>
>
If you can tell me what test is being run I'll look in to it. There
are several messages that appear in the test output that look
erroneous however, that might be a test to ensure that the client code
responds well when trying to connect to a broker that doesn't exist.
--
Martin Ritchie