as for the second option:
If you look inside SolrResourceLoader, you will notice that before a
CoreContainer is created, a new class loader is also created
line:111
this.classLoader = createClassLoader(null, parent);
however, this parent object is always null, because it is called from:
public SolrResourceLoader( String instanceDir )
{
this( instanceDir, null, null );
}
but if you were able to replace the second null (parent class loader) with
a classloader of your own choice - ie. one that loads your singleton (but
only that singleton, you don't want to share other objects), your cores
should be able to see/share that object
so, as you can see, if you test it and it works, you may fill a JIRA ticket
and help other folks out there (i was too lazy and worked around it in the
past - but that wasn't a good solution). If there a well justified reason
to share objects, it seems weird the core is using 'null' as a parent class
loader
HTH,
roman
On Sun, Jun 30, 2013 at 2:18 PM, Peyman Faratin <pey...@robustlinks.com>wrote:
> I see. If I wanted to try the second option ("find a place inside solr
> before the core is created") then where would that place be in the flow of
> app waking up? Currently what I am doing is each core loads its app caches
> via a requesthandler (in solrconfig.xml) that initializes the java class
> that does the loading. For instance:
>
> <requestHandler name="/cachedResources" class="solr.SearchHandler"
> startup="lazy" >
> <arr name="last-components">
> <str>AppCaches</str>
> </arr>
> </requestHandler>
> <searchComponent name="AppCaches"
> class="com.name.Project.AppCaches"/>
>
>
> So each core has its own so specific cachedResources handler. Where in
> SOLR would I need to place the AppCaches code to make it visible to all
> other cores then?
>
> thank you Roman
>
> On Jun 29, 2013, at 10:58 AM, Roman Chyla <roman.ch...@gmail.com> wrote:
>
> > Cores can be reloaded, they are inside solrcore loader /I forgot the
> exact
> > name/, and they will have different classloaders /that's servlet thing/,
> so
> > if you want singletons you must load them outside of the core, using a
> > parent classloader - in case of jetty, this means writing your own jetty
> > initialization or config to force shared class loaders. or find a place
> > inside the solr, before the core is created. Google for montysolr to see
> > the example of the first approach.
> >
> > But, unless you really have no other choice, using singletons is IMHO a
> bad
> > idea in this case
> >
> > Roman
> >
> > On 29 Jun 2013 10:18, "Peyman Faratin" <pey...@robustlinks.com> wrote:
> >>
> >> its the singleton pattern, where in my case i want an object (which is
> > RAM expensive) to be a centralized coordinator of application logic.
> >>
> >> thank you
> >>
> >> On Jun 29, 2013, at 1:16 AM, Shalin Shekhar Mangar <
> shalinman...@gmail.com>
> > wrote:
> >>
> >>> There is very little shared between multiple cores (instanceDir paths,
> >>> logging config maybe?). Why are you trying to do this?
> >>>
> >>> On Sat, Jun 29, 2013 at 1:14 AM, Peyman Faratin <
> pey...@robustlinks.com>
> > wrote:
> >>>> Hi
> >>>>
> >>>> I have a multicore setup (in 4.3.0). Is it possible for one core to
> > share an instance of its class with other cores at run time? i.e.
> >>>>
> >>>> At run time core 1 makes an instance of object O_i
> >>>>
> >>>> core 1 --> object O_i
> >>>> core 2
> >>>> ---
> >>>> core n
> >>>>
> >>>> then can core K access O_i? I know they can share properties but is it
> > possible to share objects?
> >>>>
> >>>> thank you
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Shalin Shekhar Mangar.
> >>
>
>
