From users-return-3423-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Thu Nov 04 13:25:24 2010 Return-Path: Delivered-To: apmail-qpid-users-archive@www.apache.org Received: (qmail 21998 invoked from network); 4 Nov 2010 13:25:24 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 Nov 2010 13:25:24 -0000 Received: (qmail 55870 invoked by uid 500); 4 Nov 2010 13:25:55 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 55802 invoked by uid 500); 4 Nov 2010 13:25:53 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 55793 invoked by uid 99); 4 Nov 2010 13:25:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Nov 2010 13:25:52 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=10.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Nov 2010 13:25:44 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oA4DPM2H005405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Nov 2010 09:25:22 -0400 Received: from [10.3.228.129] (vpn-228-129.phx2.redhat.com [10.3.228.129]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oA4DPKrA014498 for ; Thu, 4 Nov 2010 09:25:21 -0400 Message-ID: <4CD2B3D5.2090208@redhat.com> Date: Thu, 04 Nov 2010 13:23:33 +0000 From: Gordon Sim Organization: Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.,Registered in England and Wales under Company Registration No. 3798903,Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Why use the C++ broker versus the Java broker? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Virus-Checked: Checked by ClamAV on apache.org On 11/03/2010 04:09 PM, Drew Vogel wrote: > Hi. I'm new to Qpid (and AMQP in general). I'm having a bit of trouble > determining which broker to use. The compatibility page[1] says: > > There are two brokers: > > C++ with support for AMQP 0-10 > Java with support for AMQP 0-8, 0-9, and 0-10. > > The C++ broker supports only a subset of what the Java broker does, so > is there any reason (other than the never-ending performance > comparisons between Java and native languages) to use the C++ broker? > Is the Java broker being replaced by the C++ broker? No > Is the C++ broker > intended mainly for platforms without a reliable Java run-time? Not really > The > permissions structure seems to differ between the two brokers, with > the C++ broker relying on a newer ACL system, but I haven't used it > yet, so I'm relying on the (somewhat sparse) documentation. I've tried > to search the list archives for answers to these questions but the > only info I found referred to version 0.6, so I'm not sure that the > info is still current. > > Will someone explain this to me? Is this something that should be in > the FAQ or am I just missing something obvious? I think its really a question of personal preference at this point in time (some people feel more comfortable with one broker, others with another). The java broker can run pretty much anywhere there is a jvm, the c++ broker is more restricted (at least at present). The c++ broker has support for some 'native' features (e.g. RDMA). As you point out the java broker also speaks all versions of AMQP to date (the only broker known to do so!). Ultimately I would hope the choice would not be too significant and switching between the two as needed would not cause much disruption to an application, at least at the semantic level. We are moving towards a more uniform feature set and a more uniform management schema, but are still some way of that. Thats just my 2cents... --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org