qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <DJohn...@princeton.com>
Subject Re: Federation - trouble-shooting
Date Wed, 06 Jul 2011 22:33:30 GMT
> 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 <gsim@redhat.com>
To:     <users@qpid.apache.org>
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




Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message