You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2009/10/01 17:58:14 UTC
Java Client failes to close 0-10 connection after protocol
negotiation
Hi,
I'm just trying to understand the java client protocol negotication code.
As I understand it we attempt to connect 0-10 first and the java
broker replies saying 0-9 which we then use to connect using Mina.
However, does the 0-10 IoReceiver/IoSender Connection/socket actually
get closed?
I'm seeing the BrokerStartupTest fail because the previous test is
logging DEBUG IoReceive Connection closed logs in to the log run of
the next test.
See below for log.
Now perhaps it is the fault of the Java Broker, should it close the
socket after replying with the supported protocol versions?
Should the client ensure that it has closed the socket?
Thoughts?
Regards
Martin
main 2009-10-01 14:08:47,436 INFO [qpid.test.utils.QpidTestCase]
========== start BrokerStartupTest.testInvalidLog4jConfigurationFile
==========
main 2009-10-01 14:08:47,445 INFO [qpid.test.utils.QpidTestCase]
starting broker:
/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/bin/qpid-server
-p 15672 -m 18999 -c
/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/etc/config-systests.xml
-l invalid
System Properties set to -Damqj.logging.level=debug
-DQPID_HOME=/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build
-DQPID_WORK=/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/work
QPID_OPTS set to -Dlog4j.debug -Damqj.protocol.logging.level=debug
-Damqj.logging.level=info
-Dtest.config=/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/results/systests/BrokerStartupTest-testInvalidLog4jConfigurationFile.xml
-Damqj.server.logging.level=info -Droot.logging.level=warn
-Damqj.read_write_pool_size=32 -DQPID_LOG_APPEND=true
Using QPID_CLASSPATH
/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/lib/qpid-all.jar:/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/lib/bdbstore-launch.jar
Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC
-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError
Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m
IoReceiver - /127.0.0.1:56126 2009-10-01 14:08:47,546 DEBUG
[apache.qpid.transport.Connection] connection closed: conn:190690e
IoReceiver - /127.0.0.1:56127 2009-10-01 14:08:47,706 DEBUG
[apache.qpid.transport.Connection] connection closed: conn:1854d1f
MESSAGE [Broker] BRK-1006 : Using configuration :
/usr/local/cruise/work/projects/qpid_trunk/qpid/java/build/etc/config-systests.xml
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java Client failes to close 0-10 connection after protocol
negotiation
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Oct 5, 2009 at 1:16 PM, Robert Godfrey <ro...@gmail.com> wrote:
> Agreed... the issue for the Java Broker (IIRC) was that MINA wasn't being
> cooperative would close the socket before all the commands that were
> buffered had been sent... thus the broker deliberately relies on the client
> to do the closing... Obviously not ideal, and would be nice to fix as part
> of the upcoming IO work...
I had a shot at that at the time, the 0-10 client *hates* that the
socket is closed after version negotiation fails. Really hates it. A
lot. Once I've landed the IO stuff from the branch onto trunk we
should look into a) porting the o.a.q.t.io stuff to be a NetworkDriver
and b) port the 0-10 session to be a ProtocolEngine and then try to
fix this. It's pretty unportable if we want to interop with other <
0-10 implementations.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Java Client failes to close 0-10 connection after protocol
negotiation
Posted by Robert Godfrey <ro...@gmail.com>.
2009/10/5 Rafael Schloming <ra...@redhat.com>
> Martin Ritchie wrote:
>
>> Hi,
>>
>> I'm just trying to understand the java client protocol negotication code.
>>
>> As I understand it we attempt to connect 0-10 first and the java
>> broker replies saying 0-9 which we then use to connect using Mina.
>>
>> However, does the 0-10 IoReceiver/IoSender Connection/socket actually
>> get closed?
>>
>> I'm seeing the BrokerStartupTest fail because the previous test is
>> logging DEBUG IoReceive Connection closed logs in to the log run of
>> the next test.
>>
>> See below for log.
>>
>> Now perhaps it is the fault of the Java Broker, should it close the
>> socket after replying with the supported protocol versions?
>> Should the client ensure that it has closed the socket?
>>
>> Thoughts?
>>
>
> Strictly speaking I'd say both are responsible for closing it, i.e. neither
> side should depend on the other side closing the socket first in order to
> accomplish it's cleanup.
Agreed... the issue for the Java Broker (IIRC) was that MINA wasn't being
cooperative would close the socket before all the commands that were
buffered had been sent... thus the broker deliberately relies on the client
to do the closing... Obviously not ideal, and would be nice to fix as part
of the upcoming IO work...
-- Rob
Re: Java Client failes to close 0-10 connection after protocol negotiation
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> Hi,
>
> I'm just trying to understand the java client protocol negotication code.
>
> As I understand it we attempt to connect 0-10 first and the java
> broker replies saying 0-9 which we then use to connect using Mina.
>
> However, does the 0-10 IoReceiver/IoSender Connection/socket actually
> get closed?
>
> I'm seeing the BrokerStartupTest fail because the previous test is
> logging DEBUG IoReceive Connection closed logs in to the log run of
> the next test.
>
> See below for log.
>
> Now perhaps it is the fault of the Java Broker, should it close the
> socket after replying with the supported protocol versions?
> Should the client ensure that it has closed the socket?
>
> Thoughts?
Strictly speaking I'd say both are responsible for closing it, i.e.
neither side should depend on the other side closing the socket first in
order to accomplish it's cleanup.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org