[ 
https://issues.apache.org/jira/browse/SOLR-7282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344197#comment-15344197
 ] 

Noble Paul commented on SOLR-7282:
----------------------------------

Looked at the patch. It's broken. 

The way you cache things assume that schema is immutable. it is not. 
{{IndexSchema}} can change all the time. So, the cache must be aware of the 
znode version from where the schema is loaded. 

There are two ways we can cache.
# Cache the schema file content and avoid reloading from ZK. This is low impact 
and cheaper to implement but less beneficial. The cost of parsing the XML is 
high. If we can pre-parse the XML and store them as Java objects and share this 
java object it is faster.
# Cache the {{IndexSchema}} object. This would mean, we need to carefully look  
at the lifecycle of components in {{IndexSchema}}

 

> Cache config or index schema objects by configset and share them across cores
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-7282
>                 URL: https://issues.apache.org/jira/browse/SOLR-7282
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrCloud
>            Reporter: Shalin Shekhar Mangar
>            Assignee: Shalin Shekhar Mangar
>             Fix For: 5.2, 6.0
>
>         Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to