Hi Robbie,
I've just got round to trying this using the 0.12 C++ broker and Java
client.
a connection URL of:
amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?retries='2147483647'&connectdelay='5000''
took 967ms
a connection URL of:
amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?retries='2147483647'&connectdelay='5000'&tcp_nodelay='True''
took 892ms
a connection URL of:
amqp://guest:guest@QpidJMS/vhost?brokerlist='tcp://localhost?tcp_nodelay='True''
took 870ms
So I'm not seeing the sort of differences that you seem to be getting
with TCP_NODELAY. In any case I'm not convinced that the C++ clients
default to tcp-nodelay = true and they connect in next to no time.
Your other theory about class loading might be be what the real issue
is, but if that's the case why should Java suck so much? From what I can
gather python connection times are similar to the C++ ones and python is
a bytecode based language too is it not.
It could definitely do with some investigation, taking the best part of
a second to connect isn't great :-(
Should I raise a Jira or is there already one covering this?
Frase
Robbie Gemmell wrote:
I know you are using the C++ broker from your previous posts. I just
used the Java broker as I had one running and it seemed clear it wasnt
broker related, both from my hunches and the previous tests.
I expect a lot of the additional difference you are seeing is going to
be TCP_NODELAY related. 420ms was craptacular if every connection took
that long, but the next test showed it doesnt and short of forcing the
JVM to load classes at points it doesnt actaually need them im not
sure we can improve that. (I was however surprised it apparently makes
that much difference)
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
