Re: CoreContainer can store the appcontext, host and port of the Solr application
Sure. Henri. I'll raise an issue and we can decide as to where to keep it On Mon, Aug 25, 2008 at 6:28 PM, Henrib <[EMAIL PROTECTED]> wrote: > > > > Noble Paul നോബിള് नोब्ळ् wrote: >> >> I am not much worried about where we store it. CoreContainer just >> occurred me as an easy place . The problem we are trying to solve is >> non-availability of this information anywhere . >> > > We are in no functional disagreement and I'm merely trying to point an > opportunistic feature reuse. > Oh well.. > > > -- > View this message in context: > http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19143418.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > -- --Noble Paul
Re: CoreContainer can store the appcontext, host and port of the Solr application
Noble Paul നോബിള് नोब्ळ् wrote: > > I am not much worried about where we store it. CoreContainer just > occurred me as an easy place . The problem we are trying to solve is > non-availability of this information anywhere . > We are in no functional disagreement and I'm merely trying to point an opportunistic feature reuse. Oh well.. -- View this message in context: http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19143418.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: CoreContainer can store the appcontext, host and port of the Solr application
On Mon, Aug 25, 2008 at 4:38 PM, Henrib <[EMAIL PROTECTED]> wrote: > > > Might be irrelevant but do we have to store this information in the > CoreContainer ? I am not much worried about where we store it. CoreContainer just occurred me as an easy place . The problem we are trying to solve is non-availability of this information anywhere . > Couldn't we use core-container (master) & core properties (slave) to store > that information ? > These would be filled from the servlet filter (on the master side) in the > core-container properties. > To make them widely available to handlers, these properties should be > accessible through the SolrResourceLoader (which is accessible easily). > > > -- > View this message in context: > http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19141820.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > -- --Noble Paul
Re: CoreContainer can store the appcontext, host and port of the Solr application
Might be irrelevant but do we have to store this information in the CoreContainer ? Couldn't we use core-container (master) & core properties (slave) to store that information ? These would be filled from the servlet filter (on the master side) in the core-container properties. To make them widely available to handlers, these properties should be accessible through the SolrResourceLoader (which is accessible easily). -- View this message in context: http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19141820.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: CoreContainer can store the appcontext, host and port of the Solr application
On Mon, Aug 25, 2008 at 11:25 AM, Noble Paul നോബിള് नोब्ळ् < [EMAIL PROTECTED]> wrote: > This is a part of requirement for SOLR-561 . It will be a very nice > feature to have the admin console of the master show details of the > slaves also. To do so The master must know about the slaves. The > slaves may be able to register themselves with master but the slaves > do not know the port number and the context in which the app is > deployed. +1 This can also enable cumulative stats for the whole cluster making the master admin a one-stop shop for all kinds of statistics. We may also be able to do push based replication instead of poll based with this information. Configuring the information of slaves in the master itself is a problem -- slaves can go down and may be replaced without the master knowing anything about them in current deployment methods. We should also be able to configure this information in the replication handler's config itself rather than relying on the first request. -- Regards, Shalin Shekhar Mangar.
