Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of aconway@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4ECFC0F4.40807@redhat.com>
Date: Fri, 25 Nov 2011 11:23:16 -0500
From: Alan Conway <aconway@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:7.0) Gecko/20110927 Thunderbird/7.0
MIME-Version: 1.0
To: users@qpid.apache.org
CC: Fraser Adams <fraser.adams@blueyonder.co.uk>
Subject: Re: Connections from JMS take noticeably longer than from C++
References: <4ECF52D5.10609@blueyonder.co.uk>
In-Reply-To: <4ECF52D5.10609@blueyonder.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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