lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Webster Homer <>
Subject Strange Alias behavior
Date Fri, 19 Jan 2018 22:14:40 GMT
I just discovered some odd behavior with aliases.

We are in the process of converting over to use aliases in solrcloud. We
have a number of collections that applications have referenced the
collections from when we used standalone solr. So we created alias names to
match the name that the java applications already used.

We still have collections that have the name of the alias.

We also decided to create new aliases for use in our ETL process.
I have 3 collections that have the same configset which is named
collection 1: b2b-catalog-material
collection 2: b2b-catalog-material-180117
collection 3: b2b-catalog-material-180117T

When the alias, b2b-catalog-material-etl is pointed at b2b-catalog-material
and the alias b2b-catalog-material is pointed to b2b-catalog-material-180117

and we do a data load to b2b-catalog-material-etl

We see data being added to both b2b-catalog-material and

when I delete the alias b2b-catalog-material then the data stopped loading
into the collection b2b-catalog-material-180117

So it seems that alias resolution is somewhat recursive. I'm surprised that
both collections were being updated.

Is this the intended behavior for aliases? I don't remember seeing this
This was on a solrcloud running solr 7.2

I haven't checked this in Solr 7.2 but when I created a new collection and
then pointed the alias to it and did a search no data was returned because
there was none to return. So this indicates to me that aliases behave
differently if we're writing to them or reading from them.


This message and any attachment are confidential and may be privileged or 
otherwise protected from disclosure. If you are not the intended recipient, 
you must not copy this message or attachment or disclose the contents to 
any other person. If you have received this transmission in error, please 
notify the sender immediately and delete the message and any attachment 
from your system. Merck KGaA, Darmstadt, Germany and any of its 
subsidiaries do not accept liability for any omissions or errors in this 
message which may arise as a result of E-Mail-transmission or for damages 
resulting from any unauthorized changes of the content of this message and 
any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its 
subsidiaries do not guarantee that this message is free of viruses and does 
not accept liability for any damages caused by any virus transmitted 

Click to access the German, French, 
Spanish and Portuguese versions of this disclaimer.

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