I don't know if this applies in your case but there is now one class loader per solr core instance (more exactly per config; it used to be a static before). If your connection pool is a static member of a core handler, each core will create the handler through different class loaders - thus different instances of the static member. Which raises the question of "how do I share objects between handlers created by different cores then?" - and I dont have an answer to that yet... Internally, it could be better (aka easier to use) to create one class loader per instance dir instead of per core. Hope this helps Henrib
Walter Ferrara-2 wrote: > > I'm currently using latest solr + SOLR350 in a multicore solr. > I've a ConnectionPool, which use a singleton design, it has been tested > and it really works as singleton. > Every cores have an handler, responsible for update that will eventually > use that connection pool. > > The problem is: every core re-instance the connectionpool (this seems to > happen with a test singleton too), like what would happen if every core > reside in a different JVMs. This happens when the handler is called (not > inited), at different time period; inside the same core, it work as > singleton, but others cores, when called, will simple make a new ones. > > Is there a way to bypass that, and to use singletons in a "singleton" > fashion between cores? > Btw: Cores do see MultiCore as a singleton, i.e. all handler see the > same object, so I could get around this problem using MultiCore to get > cores..., but I would like to understand why cores doesn't seems to > share singletons. I may be wrong, but this used to work with (old) > Henri's solr215 patch. > > Thanks, > Walter > > > -- View this message in context: http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html#a13680116 Sent from the Solr - Dev mailing list archive at Nabble.com.
