Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chubrilo@gmail.com designates
 209.85.217.171 as permitted sender)
MIME-Version: 1.0
Sender: chubrilo@gmail.com
In-Reply-To: <20120622154642.GA27399@iniquitous.heresiarch.ca>
References: <20120621165623.GA22838@iniquitous.heresiarch.ca>
	<CAGeh-pGzUBZiykJ05fA=6k4kiSqJBLX3LYznUu8a4JJPPaAv1w@mail.gmail.com>
	<20120622154642.GA27399@iniquitous.heresiarch.ca>
Date: Mon, 25 Jun 2012 15:34:39 +0200
Message-ID: 
 <CAGeh-pHic+XpZkdzy+5pBZ_HO1wLapaZwNi6i3kpwBgq31vEsA@mail.gmail.com>
Subject: Re: periodic 5.6.0 ldap permission issues, solved by restart?
From: Dejan Bosanac <dejan@nighttale.net>
To: users@activemq.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, it will try to keep the current cache until ldap server comes back.


Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Fri, Jun 22, 2012 at 5:46 PM, Christopher Wood
<christopher_wood@pobox.com> wrote:
> It certainly makes sense to reconnect if there's a problem.
>
> Will 5.7.0 also keep the current authorization cache if there's an ldap i=
ssue? In a production scenario it's probably okay to keep functioning if th=
e ldap server goes away for a while.
>
> Thank you for the pointer, very much appreciated.
>
> On Fri, Jun 22, 2012 at 10:12:29AM +0200, Dejan Bosanac wrote:
>> Hi,
>>
>> there are some improvements in that area on the trunk (and will be
>> available in the next fuse release). Please take a look at
>>
>> https://issues.apache.org/jira/browse/AMQ-3845
>>
>>
>> Regards
>> --
>> Dejan Bosanac
>> Senior Software Engineer | FuseSource Corp.
>> dejanb@fusesource.com | fusesource.com
>> skype: dejan.bosanac | twitter: @dejanb
>> blog: http://www.nighttale.net
>> ActiveMQ in Action: http://www.manning.com/snyder/
>>
>>
>> On Thu, Jun 21, 2012 at 6:56 PM, Christopher Wood
>> <christopher_wood@pobox.com> wrote:
>> > I upgraded our lab ActiveMQ to 5.6.0 and am using the cached ldap auth=
 module. I appear to be having a problem where at times ActiveMQ loses its =
authorization data cache and does not refresh this from ldap. Is there any =
way of forcing a retry if it has a connection issue, or otherwise further d=
iagnosing what is happening?
>> >
>> > Details:
>> >
>> > Three times now (solved by an ActiveMQ restart) I have started seeing =
these errors in the log (but for all queues that they are trying to access)=
:
>> >
>> > 2012-06-21 11:57:31,538 | DEBUG | Error occured while processing sync =
command: ConsumerInfo {commandId =3D 28936, responseRequired =3D true, cons=
umerId =3D ID:myhost-53793-1340295272790-0:6:-1:1, destination =3D ActiveMQ=
.Advisory.TempQueue,ActiveMQ.Advisory.TempTopic, prefetchSize =3D 0, maximu=
mPendingMessageLimit =3D 0, browser =3D false, dispatchAsync =3D false, sel=
ector =3D null, subscriptionName =3D null, noLocal =3D true, exclusive =3D =
false, retroactive =3D false, priority =3D 0, brokerPath =3D null, optimize=
dAcknowledge =3D false, noRangeAcks =3D false, additionalPredicate =3D null=
}, exception: java.lang.SecurityException: User vm5a is not authorized to r=
ead from: ActiveMQ.Advisory.TempQueue,ActiveMQ.Advisory.TempTopic | org.apa=
che.activemq.broker.TransportConnection.Service | ActiveMQ Transport: tcp:/=
//10.201.147.250:51236
>> > java.lang.SecurityException: User vm5a is not authorized to read from:=
 ActiveMQ.Advisory.TempQueue,ActiveMQ.Advisory.TempTopic
>> >
>> > Per our developers, they are seeing:
>> >
>> > 12:16:53,926 =A0WARN DefaultMessageListenerContainer:822 - Setup of JM=
S message listener invoker failed for destination 'queue://vm5.queuename' -=
 trying to recover. Cause: User vm5a is not authorized to read from: Active=
MQ.Advisory.TempQueue,ActiveMQ.Advisory.TempTopic
>> >
>> > I ran some tcpdumps. While this is in the logs, I do not see any ldap =
searches attempting to update the authorization info. Just after a restart,=
 I do see intermittent searches for the entries under ou=3Ddestination,ou=
=3Dactivemq,ou=3Dsystems,o=3Dme.
>> >
>> > My plugin info:
>> >
>> > <authorizationPlugin>
>> > =A0<map>
>> > =A0 =A0<cachedLDAPAuthorizationMap
>> > =A0 =A0 =A0 =A0 connectionURL=3D"ldap://ldap-lab.me:389"
>> > =A0 =A0 =A0 =A0 connectionUsername=3D"cn=3Dmqbroker,ou=3Dservices,o=3D=
me"
>> > =A0 =A0 =A0 =A0 connectionPassword=3D"password"
>> > =A0 =A0 =A0 =A0 baseDn=3D"ou=3Dsystems,o=3Dme"
>> > =A0 =A0 =A0 =A0 refreshInterval=3D"5000"
>> > =A0 =A0 />
>> > =A0</map>
>> > </authorizationPlugin>
>>