: My apologies for generating confusion.
oh please don't ... some confusion is bound to be a by-product of active
experimentation and forward thinking change ... we just need to make sure
that we periodicly take stock, and double check that we know where we are
going.
: Hopes this makes the m
not to mention
my interest in solr-281). There is even more work after to tackle
replication...
Hopes this makes the mess more understandable.
Any other advice besides the kind suggestions you already made?
--
View this message in context:
http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-
: Created solr-409 as a sub-task of solr-215 to track and post patch.
: I took the shareable library directory path (ie you can specify the library
: directory used by a given core and whether it is shared or not); if 2 cores
: specify the same directory and they are shared, there will be only one
instance of the class loader.
Comments, suggestions welcome.
--
View this message in context:
http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html#a13704209
Sent from the Solr - Dev mailing list archive at Nabble.com.
Thanks for your answers.
I've made some test, the singleton is correctly shared between handlers
in the same core, but not between cores, while putting connection pool
jar (and its dependencies) inside the war, make it works as it should
(but that doesn't look like a solution to me).
It seems to me
I agree we don't want to replicate the servlet container.
If we were to create class loaders not per instance but per 'lib' directory
(not per instance dir as I mentioned earlier but per library directory),
what about the very standard use case where I want to 'reload' a core?
In this case,
On Nov 11, 2007 5:51 AM, Henrib <[EMAIL PROTECTED]> wrote:
> It seems to me multicore should avoid replicating (or restricting itself to)
> features what we can get with multiple web apps; I advocate allowing tighter
> couplings between cores in the former which seems to me closer to user
> expecta
rict independence *and* add sharing core
functionality allowing a wider choice to answer users needs.
--
View this message in context:
http://www.nabble.com/Post-SOLR215-SOLR350-singleton-issue-tf4776980.html#a13690225
Sent from the Solr - Dev mailing list archive at Nabble.com.
perhaps. it depends largely on what the long term goals of multi-core
support are ... if we're striving for "dynamicly" creating "solr contexts"
independently of "servlet contexts" then the current behavior is probably
ideal ... we're protecting the plugins of each SolrCore from
corrupting ea
: 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 -
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.
It is not related to the singleton, AFAIK, as I tested it with a simple
multhread app, and I always got the object created one time
(singletonObject = new getInstance()), while other calls just receive
the already created object.
While if the handler try to call getInstance(), the first time (th
Uhmm I try to explain better, basically is a strange behavior I fighting
with.
I've got a singleton.
Every core have an handler that try to obtain the object by going to
that singleton getInstance() method, which look like this:
public synchronized static SingletonObjectDemo getInstance(){
if
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 see
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-
15 matches
Mail list logo
