Shawn, thanks for taking the time to reply.
Turned out it was something entirely different. We missed to deploy newly added core.properties file. Adding them immediately fixed everything. The zookeeper debug messages apparently are there even if SASL is turned off. We just got sidetracked because there are no error messages related to the missing file in the logs. Cheers, Sven On Wed, Nov 13, 2013 at 3:06 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 11/11/2013 11:37 PM, Sven Stark wrote: > > We are testing to upgrade Solr from 4.3 to 4.5.1 . We're using SolrCloud > > and our problem is that the core does not appear to be loaded anymore. > > > > We've set logging to DEBUG and we've found lots of those > > > > 2013-11-12 06:30:43,339 [pool-2-thread-1-SendThread( > our.zookeeper.com:2181)] > > DEBUG org.apache.zookeeper.client.ZooKeeperSaslClient ā<U+0080><U+0093> > > Could not retrieve login configuration: java.lang.SecurityException: > Unable > > to locate a login configuration > > > > Zookeeper is up and running. > > > > Is there any doco on how to disable SASL ? Or what changes were made to > > SolrCould exactly? > > Something outside Solr probably has turned SASL on. The Zookeeper > client library in Solr supports SASL, so it is picking up on that and > complaining because it can't find credentials. > > It might be a container configuration, so perhaps the config for Tomcat, > Jetty, Glassfish, JBoss, WebSphere, or whatever container you are using > has it turned on. It might also be something system-wide with Java itself. > > If some other software that you are running in your servlet container > requires SASL, then you will either need to move the SASL config to that > specific application, or you will need to put Solr into a separate > container that doesn't have SASL turned on. The Solr download comes > with a production-quality jetty install (in the example) that's tuned > for a 'typical' small to medium Solr setup. > > Thanks, > Shawn > >
