qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Connections from JMS take noticeably longer than from C++
Date Fri, 25 Nov 2011 16:23:16 GMT
On 11/25/2011 03:33 AM, Fraser Adams wrote:
> Hi all,
> I've been wondering about this for some time, but from my observations it looks
> like connections (to the C++ broker) take much longer (noticeably!!) from JMS
> than from C++ clients (qpid::messaging).
>
> I was idly playing with qpid-printevents and firing up Java and C++ consumers
> and the subscription event was pretty much instantaneous with the C++ consumer
> but ~seconds with the JMS consumer. I don't think it's accounted for by JVM
> startup time as my JMS client prints a message on startup before creating a
> Connection and the subscription event is noticeably after that.
>
> I've not systematically checked the elapsed time of the various bits of:
>
> Context jndi = new InitialContext(props);
> ConnectionFactory connectionFactory =
> (ConnectionFactory)jndi.lookup("ConnectionFactory");
> connection = connectionFactory.createConnection();
>
> yet, but as the qpid::messaging C++ client is so fast I can't imagine that
> there's something fundamental that should cause creating JMS connections to be
> so much slower.
>
> Judging by the standard Qpid tools I suspect that the python connection startup
> suffers similar issues.

The python management clients (e.g. qpid-config) are slow starting because of a 
slow interaction with the management bits, not due to the connection setup. A 
normal client written in python should connect fairly instantaneously. I have no 
idea why JMS would be so much slower

> Any thoughts as to what this is due to? Should I raise a Jira?
>
> I guess mostly connections are created infrequently, but I was musing over the
> idea of creating a "Qpid crawler" to crawl over and map out various brokers in a
> large federated topology - clearly connection delays will slow that sort of
> application down.

There's no reason at the AMQP layer why it should be this slow. I don't know if 
JMS imposes something that takes a long time - do other JMS clients have the 
same problem? If not then it should be fixed. The "created infrequently" excuse 
doesn't hold up. e.g. if someone is writing a command line tool it will connect 
every time it's run. If they write a script that uses the tool 100 times they 
will not be pleased to wait more than a minute. The slow startup of the 
management clients infuriates me for this very reason - its creating a lot of 
drag in our own test suite. Apparently this will be better with qmf2, but i digress.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message