Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 59E8A6523 for ; Wed, 6 Jul 2011 22:34:05 +0000 (UTC) Received: (qmail 72951 invoked by uid 500); 6 Jul 2011 22:34:05 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 72897 invoked by uid 500); 6 Jul 2011 22:34:04 -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 72889 invoked by uid 99); 6 Jul 2011 22:34:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 22:34:04 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [65.55.88.12] (HELO TX2EHSOBE003.bigfish.com) (65.55.88.12) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 22:33:56 +0000 Received: from mail175-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Jul 2011 22:33:33 +0000 Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2-R.bigfish.com (Postfix) with ESMTP id A98D71098107 for ; Wed, 6 Jul 2011 22:33:33 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zzbb2dK617R9371Mc85fh1432N98dKzz1202hzz8275bh8275dhz2dh668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:173.12.30.67;KIP:(null);UIP:(null);IPVD:NLI;H:notes.princeton.com;RD:173-12-30-67-panjde.hfc.comcastbusiness.net;EFVD:NLI Received: from mail175-tx2 (localhost.localdomain [127.0.0.1]) by mail175-tx2 (MessageSwitch) id 1309991613329215_27189; Wed, 6 Jul 2011 22:33:33 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.241]) by mail175-tx2.bigfish.com (Postfix) with ESMTP id 413131AD004B for ; Wed, 6 Jul 2011 22:33:33 +0000 (UTC) Received: from notes.princeton.com (173.12.30.67) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id 14.1.225.22; Wed, 6 Jul 2011 22:33:31 +0000 In-Reply-To: <4E132BCE.6090107@redhat.com> References: <4E132BCE.6090107@redhat.com> To: MIME-Version: 1.0 Subject: Re: Federation - trouble-shooting X-KeepSent: F6F0DF3A:D87E39F9-852578C5:00758B52; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP2 March 23, 2011 Message-ID: From: Date: Wed, 6 Jul 2011 18:33:30 -0400 X-MIMETrack: Serialize by Router on Notes/Princeton Consultants(Release 8.5.2FP2|March 22, 2011) at 07/06/2011 06:33:31 PM, Serialize complete at 07/06/2011 06:33:31 PM Content-Type: multipart/alternative; boundary="=_alternative 007BEAB4852578C5_=" X-OriginatorOrg: princeton.com X-Virus-Checked: Checked by ClamAV on apache.org --=_alternative 007BEAB4852578C5_= Content-Type: text/plain; charset="US-ASCII" > I believe the 'interaction disallowed' error is a result of having the > link use PLAIN by default even though a password is not specified > (should be fixed now on trunk). I've started explicitly specifying the username/password as "guest/guest" and the "interaction disallowed" messages have since stopped appearing in the logs, so authorization was likely part of the issue. I plan to do some more testing with authorization in the near future. After lots of experimentation, federation has finally started working for me, but I still have some kinks to work out. Most issues appear to be problems with the order of commands for adding/removing entities. dyanmic routes: These seem to only work if the queues do not yet exist. When you bind a queue to the exchange on the destination broker, the bridge queue is automatically created on the source broker. However, if you add the dynamic route after the queues have already all been created, then the bridge queue never gets created, and messages will not federate. exchange routes: Exchange routes may or may not work depending on whether the exchange on the source broker already exists when the route is added (at least that is my current theory). Like dynamic routes, when it doesn't work, the route will be "added" and visible via "route map" but the bridge queue will be missing and messages will not federate. queue routes: These require that the queue already exists on the source broker prior to adding the route (this is in the documentation, but I missed it). If the queue does not exist yet on the source broker, the route can be added but will not actually work (and there is no error/exception at the time the route is added to indicate that something is wrong). ----- I'm trying to build a kind of "click-once" tool for setting up or tearing down a broker (via calls to qpid-config and qpid-route) based on a configuration file. A couple of things would help: 1. Has a tool like this already been developed? 2. Are there some rules/documentation for how to add/remove entities in the correct order to avoid mishaps? 3. Using queue routing, my messages federate to the exchange on the destination broker where it will be visible to applications there, but it will also pass to the queue that is a source for federating back to the source broker...so I end up with a message that "bounces" back and forth forever. This problem can be avoided by using dynamic routing, but is there a way to avoid this with queue routing (or exchange routing, if it has the same problem)? David Johnson Princeton Consultants 2 Research Way Princeton, NJ 08540 609.987.8787 x266 From: Gordon Sim To: Date: 07/05/2011 11:22 AM Subject: Re: Federation - trouble-shooting On 07/05/2011 03:26 PM, DJohnson@princeton.com wrote: >> Are the any errors in the qpid log? > > from the logs on broker A: > > trying to establish the connection: > > [timestamp] A qpidd[30909]: [timestamp] error Connection B:port closed > by error: closed by management(320) > > afterwards, about once every 2 seconds: > > [timestamp] A qpidd[30909]: [timestamp] warning Client closed > connection with 541: internal-error: interaction disallowed > > from the logs on broker B: > > about once every 2 seconds: > > [timestamp] B qpidd[4592]: [timestamp] warning Inter-broker link > disconnected from A:port Do you have authentication turned on? I believe the 'interaction disallowed' error is a result of having the link use PLAIN by default even though a password is not specified (should be fixed now on trunk). --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org --=_alternative 007BEAB4852578C5_=--