Naveen,
The Solr codebase generally uses the base “SolrTestCaseJ4” class and sometimes
mixes in the cloud cluster. I personally write a generic abstract base test
class to fit my needs and have an abstract `getSolrServer` method with an
EmbeddedSolrServer implementation along with a separate
You might consider trying to get the de-duplication done at index time:
https://cwiki.apache.org/confluence/display/solr/De-Duplication that way
the map reduce job wouldn't even be necessary.
When it comes to the map reduce job, you would need to be more specific
with *what* you are doing for
bq. There's no good reason to have 5 with a small cluster and by "small" I
mean < 100s of nodes.
Well, a good reason would be if you want your system to continue to operate
if 2 ZK nodes lose communication with the rest of the cluster or go down
completely. Just to be clear though, the ZK nodes
are one-time
> > operations, usually done manually. Currently uploading the config set is
> > accomplished with zkCli (yes, it's a little clumsy). There's a JIRA to
> put
> > this into solr/bin as a command though. They'd be easy enough to script
> in
> > any given situatio
ecting to zk.
> 3. Upload collection config to zk.
> 4. Call create collection rest api.
> 5. Done. SolrCloud ready to work.
>
> Don't yet have automation for replacing or adding a node.
> On Sep 22, 2015 18:27, "Steve Davids" <sdav...@gmail.com> wrote:
>
&g
Hi,
I am trying to come up with a repeatable process for deploying a Solr Cloud
cluster from scratch along with the appropriate security groups, auto
scaling groups, and custom Solr plugin code. I saw that LucidWorks created
a Solr Scale Toolkit but that seems to be more of a one-shot deal than
Accidentally sent this on the java-users list instead of solr-users...
Hi,
I am attempting to migrate our deployment process over to using the
recently added "Blob Store API" which should simplify things a bit when it
comes to cloud infrastructures for us. Unfortunately, after loading the jar
Sorry for not responding back earlier, I went ahead and created a ticket
here:
https://issues.apache.org/jira/browse/SOLR-7613
It does look somewhat trivial if you just update the current loading
mechanism as Chris describes, I can provide a patch for that if you want.
Though, if you want to go
I am attempting to override some properties in my solrconfig.xml file by
specifying properties in a solrcore.properties file which is uploaded in
Zookeeper's collections/conf directory, though when I go to create a new
collection those properties are never loaded. One work-around is to specify
I have a use-case where I would like to capture click events for individual
users so I can answer questions like show me everything with x text and
that I have clicked before + the inverse of show me everything with x text
that I have *not* clicked. I am currently doing this by sticking the event
Did you happen to set the field ('fl') request parameter? By default the
RealTimeGetHandler returns all stored fields, here is some more information
on the parameter: http://wiki.apache.org/solr/CommonQueryParameters#fl
-Steve
On Tue, Aug 19, 2014 at 11:18 AM, Philippe Soares
I have also experienced a similar problem on our cluster, I went ahead and
opened SOLR-5986 to track the issue. I know Apache Blur has implemented a
mechanism to kill these long running term enumerations, would be fantastic if
Solr can get a similar mechanism.
-Steve
On Apr 15, 2014, at 5:23
I have had this exact same use case and we ended up just setting a header
value, then in a Servlet Filter we read the header value and set the MDC
property within the filter. By reading the header value it didn’t complain
about reading the request before making it to the SolrDispatchFilter. We
13 matches
Mail list logo
