I was looking into a similar issue when I saw this thread. I wrote a simple
test which uploads a configuration to ZK, creates a collection and indexes
a document. Then I delete the configuration and I see these in the logs,
which is expected:
6299 [Thread-13] INFO org.apache.solr.cloud.ZkController – Check for
collection zkNode:mycollection
6299 [Thread-13] INFO org.apache.solr.cloud.ZkController – Collection
zkNode exists
6299 [Thread-13] INFO org.apache.solr.common.cloud.ZkStateReader – Load
collection config from:/collections/mycollection
6322 [Thread-13] ERROR org.apache.solr.common.cloud.ZkStateReader –
Specified config does not exist in ZooKeeper:ConfigurationManagementTest
6323 [Thread-13] WARN org.apache.solr.cloud.ZkController – listener
throws error
org.apache.solr.common.SolrException: Unable to reload core
[mycollection_shard1_replica1]
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:615)
Caused by: org.apache.solr.common.cloud.ZooKeeperException: Specified
config does not exist in ZooKeeper:ConfigurationManagementTest
at
org.apache.solr.common.cloud.ZkStateReader.readConfigName(ZkStateReader.java:171)
at
org.apache.solr.cloud.CloudConfigSetService.createCoreResourceLoader(CloudConfigSetService.java:37)
at
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:58)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:608)
But, the exception comes from CoreContainer.reload(), which seems to get
invoked when there was a configuration change in ZK?
Then my test indexes another document and verifies it exists by searching
for it, and it works, without me explicitly reloading the core. Is that
expected behavior?
Then I tested what happens if I re-create the configuration after deleting
it (to simulate a full configuration update), so I re-uploaded the
configuration after deleting it (and indexed the second document still).
Everything works as above, without me explicitly reloading the core.
Though, I do see this being logged after my test completes, and is in the
process of shutting down:
6184 [Thread-14] INFO org.apache.solr.core.CoreContainer – Reloading
SolrCore 'mycollection_shard1_replica1' using configuration from collection
mycollection
6188
[OverseerStateUpdate-93599389182590978-127.0.0.1:63070_solr-n_0000000000]
INFO org.apache.solr.cloud.overseer.ZkStateWriter – going to
update_collection /collections/mycollection/state.json version: 3
6227 [zkCallback-5-thread-1] INFO
org.apache.solr.common.cloud.ZkStateReader – A cluster state change:
WatchedEvent state:SyncConnected type:NodeDataChanged
path:/collections/mycollection/state.json, has occurred - updating...
6392 [main] INFO org.apache.solr.core.SolrCore –
SolrDeletionPolicy.onCommit: commits: num=2
commit{dir=NRTCachingDirectory(MMapDirectory@C:\Users\shaie\AppData\Local\Temp\1428213335695-0\solr\node1\mycollection_shard1_replica1\data\index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@46b0f5e9;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_1,generation=1}
commit{dir=NRTCachingDirectory(MMapDirectory@C:\Users\shaie\AppData\Local\Temp\1428213335695-0\solr\node1\mycollection_shard1_replica1\data\index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@46b0f5e9;
maxCacheMB=48.0 maxMergeSizeMB=4.0),segFN=segments_2,generation=2}
6392 [main] INFO org.apache.solr.core.SolrCore – newest commit generation
= 2
6395 [Thread-14] WARN org.apache.solr.cloud.ZkController – listener
throws error
org.apache.solr.common.SolrException: Unable to reload core
[mycollection_shard1_replica1]
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:615)
Caused by: java.lang.IllegalStateException: IndexWriter has been closed
at
org.apache.solr.update.SolrCoreState.increfSolrCoreState(SolrCoreState.java:53)
at org.apache.solr.core.SolrCore.reload(SolrCore.java:442)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:610)
In other times I run the test I get this:
7199 [Thread-14] INFO org.apache.solr.core.CoreContainer – replacing
core: mycollection_shard1_replica1
7200 [searcherExecutor-11-thread-1] WARN
org.apache.solr.core.JmxMonitoredMap – Failed to register info bean:
searcher
javax.management.InstanceAlreadyExistsException:
solr/mycollection_shard1_replica1:type=searcher,id=org.apache.solr.search.SolrIndexSearcher
at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:153)
at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:52)
at
org.apache.solr.search.SolrIndexSearcher.register(SolrIndexSearcher.java:420)
at org.apache.solr.core.SolrCore.registerSearcher(SolrCore.java:1957)
I tried both SOFT_COMMIT and COMMIT in my update requests, the exceptions
alternate and seems to be a timing issue.
So, the questions that I have are:
1. It does look like Solr re-loads cores on configuration changes, is
that true?
2. If (1) is YES, do I still need to manually invoke a collection RELOAD
explicitly after updating the configuration?
3. Can someone explain the errors I see in the log, even though the test
passes and as I indicated, I'm able to index more documents and search them?
Shai
On Fri, Apr 3, 2015 at 7:22 PM, shamik <sham...@gmail.com> wrote:
> Thanks Shawn for the pointer, really appreciate it.
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Unable-to-update-config-file-using-zkcli-or-RELOAD-tp4197376p4197494.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
