: However, my take on it is that this seems like a pretty broad brush to : paint with to move *all* our classes up and out of the normal core loading : process. I assume there are good reasons for segregating this stuff into : separate class loaders to begin with. It would also be fairly burdensom to
There are, but those reasons don't really apply if the whole point is you want to share resources between cores. : I really just want a way to stash the map in a place where other cores can : see it (and thus I can appropriately synchronize things so that the loading : only happens once). I'm asking because it seems like surely this must be a : solved problem... if not, it might be easiest to just solve it by adding : some sort of shared resources facility to CoreContainer? There has been some discussion about it in the past (ie: multiple instances of StopwordFilterFactory configured to point at the same stopwords.txt file on disk can/should share the same Map in RAM (in most cases) even if those instances exist in completely diff cores) There's been a few jiras where this concept of "sharing" heavy objects have come up, but i don't think anyone has made any attempts at a general solution... https://issues.apache.org/jira/browse/SOLR-7282 https://issues.apache.org/jira/browse/SOLR-4872?focusedCommentId=13682471&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13682471 https://issues.apache.org/jira/browse/SOLR-3443 -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
