Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com
 designates 209.85.220.177 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Solrj 4.2 - CloudSolrServer aliases are not loaded
From: Mark Miller <markrmiller@gmail.com>
In-Reply-To: <C3596118-B63B-4FF4-BBCD-439B7F835CF7@gmail.com>
Date: Tue, 2 Apr 2013 14:32:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <78220192-BC41-42B6-A6C9-4FB0FA3F54B4@gmail.com>
References: <515AFD28.1000509@kelkoo.fr>
 <CE06BD94-DBAD-4942-BD10-D40C270590F5@gmail.com>
 <C3596118-B63B-4FF4-BBCD-439B7F835CF7@gmail.com>
To: solr-user@lucene.apache.org

I've created https://issues.apache.org/jira/browse/SOLR-4664

- Mark

On Apr 2, 2013, at 2:07 PM, Mark Miller <markrmiller@gmail.com> wrote:

> I think the current tests probably build the cloudsolrserver before =
creating the aliases - sounds like we need to do some creating the =
cloudsolrserver after.
>=20
> - Mark
>=20
> On Apr 2, 2013, at 1:31 PM, Mark Miller <markrmiller@gmail.com> wrote:
>=20
>> Answers inline:
>>=20
>> On Apr 2, 2013, at 11:45 AM, Elodie Sannier =
<elodie.sannier@kelkoo.fr> wrote:
>>=20
>>> Hello,
>>>=20
>>> I am using the new collection alias feature, and it seems
>>> CloudSolrServer class (solrj 4.2.0) does not allow to use it, either =
for
>>> update or select.
>>>=20
>>> When I'm requesting the CloudSolrServer with a collection alias =
name, I
>>> have the error:
>>> org.apache.solr.common.SolrException: Collection not found:
>>> aliasedCollection
>>>=20
>>> The collection alias cannot be found because, in
>>> CloudSolrServer#getCollectionList (line 319) method, the alias =
variable
>>> is always empty.
>>>=20
>>> When I'm requesting the CloudSolrServer, the connect method is =
called
>>> and it calls the ZkStateReader#createClusterStateWatchersAndUpdate =
method.
>>> In the ZkStateReader#createClusterStateWatchersAndUpdate method, the
>>> aliases are not loaded.
>>>=20
>>> line 295, the data from /clusterstate.json are loaded :
>>> ClusterState clusterState =3D ClusterState.load(zkClient, =
liveNodeSet);
>>> this.clusterState =3D clusterState;
>>>=20
>>> Should we have the same data loading from /aliases.json, in order to
>>> fill the aliases field ?
>>> line 299, a Watcher for aliases is created but does not seem used.
>>=20
>> The Watcher is used. It updates the Aliases if they changed - there =
is some lag time though. There is some work that tries to avoid the lag =
in the update being a problem, but I'm guessing somehow it's not =
covering your case.=20
>>=20
>> It wouldn't hurt to add the updateAliases call automatically on =
ZkStateReader init. If the watcher was indeed not being used, that would =
not solve things though - the client still needs to be able to detect =
alias additions and changes.
>>=20
>> Your best bet is to file a JIRA issue so we can work on a test that =
mimics what you are seeing.
>>=20
>> - Mark
>>=20
>>>=20
>>>=20
>>> As a workaround to avoid the error, I have to force the aliases =
loading
>>> at my application start and when the aliases are updated:
>>> CloudSolrServer solrServer =3D new =
CloudSolrServer("localhost:2181");
>>> solrServer.setDefaultCollection("aliasedCollection");
>>> solrServer.connect();
>>> solrServer.getZkStateReader().updateAliases();
>>>=20
>>> Is there a better way to use collection aliases with solrj ?
>>>=20
>>> Elodie Sannier
>>>=20
>>> Kelkoo SAS
>>> Soci=E9t=E9 par Actions Simplifi=E9e
>>> Au capital de =80 4.168.964,30
>>> Si=E8ge social : 8, rue du Sentier 75002 Paris
>>> 425 093 069 RCS Paris
>>>=20
>>> Ce message et les pi=E8ces jointes sont confidentiels et =E9tablis =E0=
 l'attention exclusive de leurs destinataires. Si vous n'=EAtes pas le =
destinataire de ce message, merci de le d=E9truire et d'en avertir =
l'exp=E9diteur.
>>=20
>=20