Hi Stefan,
I have opened issue SOLR-4302 and attached the suggested patch.
Regards,
Shahar.
-Original Message-
From: Stefan Matheis [mailto:matheis.ste...@gmail.com]
Sent: Sunday, January 13, 2013 3:11 PM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS performance
ene.apache.org (mailto:solr-user@lucene.apache.org)
> Subject: Re: CoreAdmin STATUS performance
>
> On 1/10/2013 2:09 AM, Shahar Davidson wrote:
> > As for your first question, the core info needs to be gathered upon every
> > search request because cores are created dynamic
request time from around 800ms to around 1ms-4ms.
Regards,
Shahar.
-Original Message-
From: Shawn Heisey [mailto:s...@elyograg.org]
Sent: Thursday, January 10, 2013 5:14 PM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS performance
On 1/10/2013 2:09 AM, Shahar Davidson wrote
Thanks for sharing this info, Per - this info may prove to be valuable for me
in the future.
Shahar.
-Original Message-
From: Per Steffensen [mailto:st...@designware.dk]
Sent: Thursday, January 10, 2013 6:10 PM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS performance
ated dynamically, who handles their creation (client/server)
and how is it done?
I'd love to hear more about it!
Appreciate your help,
Shahar.
-Original Message-
From: Per Steffensen [mailto:st...@designware.dk]
Sent: Thursday, January 10, 2013 1:23 PM
To: solr-user@lucene.apache.org
S
On 1/10/2013 2:09 AM, Shahar Davidson wrote:
As for your first question, the core info needs to be gathered upon every
search request because cores are created dynamically.
When a user initiates a search request, the system must be aware of all
available cores in order to execute distributed se
erver)
and how is it done?
I'd love to hear more about it!
Appreciate your help,
Shahar.
-Original Message-
From: Per Steffensen [mailto:st...@designware.dk]
Sent: Thursday, January 10, 2013 1:23 PM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS performance
On 1/1
On 1/10/13 10:09 AM, Shahar Davidson wrote:
search request, the system must be aware of all available cores in order to
execute distributed search on_all_ relevant cores
For this purpose I would definitely recommend that you go "SolrCloud".
Further more we do something "ekstra":
We have sever
Thanks Per.
I'm currently not using SolrCloud but that's a good tip to keep in mind.
Thanks,
Shahar.
-Original Message-
From: Per Steffensen [mailto:st...@designware.dk]
Sent: Thursday, January 10, 2013 10:02 AM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS p
nstead of collecting everything)
Thanks,
Shahar.
-Original Message-
From: Shawn Heisey [mailto:s...@elyograg.org]
Sent: Thursday, January 10, 2013 2:52 AM
To: solr-user@lucene.apache.org
Subject: Re: CoreAdmin STATUS performance
On 1/9/2013 8:38 AM, Shahar Davidson wrote:
> I have a client
If you are using ZK-coordinating Solr (SolrCloud - you need 4.0+) you
can maintain a in-memory always-up-to-date data-structure containing the
information - ClusterState. You can get it through CloudSolrServer og
ZkStateReader that you connect to ZK once and it will automatically
update the in-
On 1/9/2013 8:38 AM, Shahar Davidson wrote:
I have a client app that uses SolrJ and which requires to collect the names
(and just the names) of all loaded cores.
I have about 380 Solr Cores on a single Solr server (net indices size is about
220GB).
Running the STATUS action takes about 800ms -
On 1/9/2013 10:38 AM, Shahar Davidson wrote:
> Hi All,
>
> I have a client app that uses SolrJ and which requires to collect the names
> (and just the names) of all loaded cores.
> I have about 380 Solr Cores on a single Solr server (net indices size is
> about 220GB).
>
> Running the STATUS ac
Hi All,
I have a client app that uses SolrJ and which requires to collect the names
(and just the names) of all loaded cores.
I have about 380 Solr Cores on a single Solr server (net indices size is about
220GB).
Running the STATUS action takes about 800ms - that seems a bit too long, given
my
14 matches
Mail list logo
