Re: SolrCloud CDCR issue

2018-08-10 Thread cdatta
I followed the exact steps you suggested. Now I am not seeing that error. 

INFO  - 2018-08-10 15:23:58.159; [c:collection_name s:shard2 r:core_node13
x:collection_name_shard2_replica_n10]
org.apache.solr.handler.CdcrReplicator; Forwarded 10 updates to target
collection_name

However, in destination DC, I am seeing different numFounds per retry. Even
after CORE reload it's not showing exact same number.

Source: Total Doc: 1310
Destination: Total Doc :1310
 :908
 :457

I stopped the indexing and waited for the max autocommit interval for that
collection to expire. Even after that, did not get consistent results. Do I
have to send explicit hard commit? 

Source/Desination DC: I am seeing following error now though a. Not sure if
this is related to an existing CDCR JIRA I saw.

org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://host:8983/solr/collection_name_shard1_replica_n2:
Expected mime type application/octet-stream but got text/html. 


Error 401 require authentication


HTTP ERROR 401

Problem accessing /solr/collection_name_shard1_replica_n2/cdcr. Reason:
require authentication



  at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:607)
  at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
  at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
  at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
  at org.apache.solr.handler.CdcrUpdateLogSynchronizer$UpdateLogSynchronis

org.apache.solr.common.SolrException: Unable to locate core
collection_name_shard1_replica_n2
  at
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$5(CoreAdminOperation.java:149)
  at
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:358)
  at
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)


Here is our security.json

{
  "authentication":{
"blockUnknown":true,
"class":"solr.BasicAuthPlugin",
"credentials":{
  "solr":"--REDACTED--",
  "admin":"--REDACTED--",
  "solr_dev":"--REDACTED--",
  "app_2_user":"--REDACTED--",
  "app_1_user":"--REDACTED--"},
"":{"v":6}},
  "authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"permissions":[
  {
"name":"security-edit",
"role":"admin",
"index":1},
  {
"name":"collection-admin-read",
"role":[
  "read",
  "read_write",
  "admin"],
"index":2},
  {
"name":"read",
"role":[
  "read",
  "read_write",
  "admin"],
"index":3},
  {
"name":"core-admin-read",
"role":[
  "read",
  "read_write",
  "admin"],
"index":4},
  {
"name":"schema-read",
"role":[
  "read",
  "read_write",
  "admin"],
"index":5},
  {
"name":"config-read",
"role":[
  "read",
  "read_write",
  "admin"],
"index":6},
  {
"name":"admin-ui",
"path":"/",
"role":[
  "read",
  "read_write",
  "admin"],
"index":7},
  {
"collection":null,
"path":"/admin/zookeeper",
"role":["admin"],
"index":8},
  {
"collection":"*",
"path":"/admin/file",
"role":["admin"],
"index":9},
  {
"collection":"*",
"path":"/admin/files",
"role":"admin",
"index":10},
  {
"collection":"*",
"path":"/dataimport",
"role":["admin"],
"index":11},
  {
"name":"collection-admin-edit",
"role":["admin"],
"index":12},
  {
"name":"update",
"role":[
  "admin",
  "read_write"],
"index":13},
  {
"name":"schema-edit",
"role":["admin"],
"index":14},
  {
"name":"config-edit",
"role":["admin"],
"index":15},
  {
"name":"core-admin-edit",
"role":["admin"],
"index":16}],
"user-role":{
  "solr":"admin",
  "app_1_user":"read_write",
  "solr_dev":"read",
  "app_2_user":"read_write",
  "admin":["admin"]},
"":{"v":19}}}




--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: Solr Multiple Hostnames

2018-08-10 Thread Shawn Heisey

On 8/10/2018 11:12 AM, Kelly Rusk wrote:

I want traffic passed over https to flow through the load balancer and resolve 
on the Solr servers by an address of https://solr.mydomain.com:8983/solr. The 
hostname I have set for the Solr Master is master.mydomain.com and the Slave is 
slave.mydomain.com.

So, are you stating that so long as my DNS has an entry for the domain of  
https://solr.mydomain.com:8983/solr it should work, even if the individual Solr 
servers have their host set as master.mydomain.com or slave.mydomain.com.


Any request you send that's properly formatted will be answered.  If DNS 
sends it to Solr, the port is correct, the protocol is correct, and all 
that, it should work.  You could have the following host header in the 
HTTP request that Solr receives and it would work:


Host: wibble.frongle.spoof

The *load balancer* might care about the host header, but unless you 
tweak the jetty config to accomplish something different than Solr ships 
with, Solr will not care what the host header contains.  You won't even 
*need* a Host header.


When you configure a replication slave, you give it a URL for the 
master.  That must be a good URL, of course.  The master doesn't get 
told about the slaves.


Thanks,
Shawn



Re: Solr 7.1 nodes shutting down

2018-08-10 Thread Shawn Heisey

On 8/10/2018 1:20 PM, Joe Obernberger wrote:
Hi All - having an issue that seems to be related to the machine being 
under a high CPU load.  Occasionally a node will fall out of the solr 
cloud cluster.  It will be using 200% CPU and show the following 
exception:


2018-08-10 15:36:43.416 INFO  (qtp1908316405-203450) [c:models 
s:shard3 r:core_node17 x:models_shard3_replica_n14] 
o.a.s.s.HttpSolrCall Unable to write response, client closed 
connection or we are shutting down

org.eclipse.jetty.io.EofException: Closed


EofException means that the TCP connection got closed. Because the 
timeout that can cause such a disconnection is typically configured for 
either 50 or 60 seconds, something *extreme* has happened in order for 
that timeout to be exceeded.


With no real information to go on, I would guess that you're having 
extreme GC pauses, probably from your heap being too small.


If that's not it, figuring out the problem is going to be an involved 
process that could take a while.  You might want to hang out in the IRC 
channel for a more interactive chat.


Thanks,
Shawn



Re: 4 days and no solution - please help on Solr

2018-08-10 Thread ☼ R Nair
Thanks Christoper and Jason. Problem solved. What you mentioned works.

Thanks a million. Have a good weekend.

Best,
Ravion

On Fri, Aug 10, 2018 at 3:31 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Ravion,
>
> What's wrong with "update request"? Updating a document that does not
> exist... will add it.
>
> -chris
>
> On 8/10/18 3:01 PM, ☼ R Nair wrote:
> > Do you feel that this is only partially complete?
> >
> > Best, Ravion
> >
> > On Fri, Aug 10, 2018, 1:37 PM ☼ R Nair 
> wrote:
> >
> >> I saw this. Please provide for add. My issue is with add. There is no
> >> "AddRequesg". So how to do that, thanks
> >>
> >> Best Ravion
> >>
> >> On Fri, Aug 10, 2018, 12:58 PM Jason Gerlowski 
> >> wrote:
> >>
> >>> The "setBasicAuthCredentials" method works on all SolrRequest
> >>> implementations.  There's a corresponding SolrRequest object for most
> >>> common Solr APIs.  As you mentioned, I used QueryRequest above, but
> >>> the same approach works for any SolrRequest object.
> >>>
> >>> The specific one for indexing is "UpdateRequest".  Here's a short
> example
> >>> below:
> >>>
> >>> final List docsToIndex = new ArrayList<>();
> >>> ...Prepare your docs for indexing
> >>> final UpdateRequest update = new UpdateRequest();
> >>> update.add(docsToIndex);
> >>> update.setBasicAuthCredentials("solr", "solrRocks");
> >>> update.process(client, "techproducts");
> >>> On Fri, Aug 10, 2018 at 12:47 PM ☼ R Nair 
> >>> wrote:
> 
>  Hi Jason,
> 
>  Thanks for replying.
> 
>  I am adding a document, not querying. I am using 7.3 apis. Adding a
>  document is done via solrclient.add(). How to set authentication
> in
>  this case? Seems I can't use SolrRequest.
> 
>  Thx, bye
>  RAVION
> 
>  On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski  >
>  wrote:
> 
> > I'd tried to type my previous SolrJ example snippet from memory.
> That
> > didn't work out so great.  I've corrected it below:
> >
> > final List zkUrls = new ArrayList<>();
> > zkUrls.add("localhost:9983");
> > final SolrClient client = new CloudSolrClient.Builder(zkUrls,
> > Optional.empty()).build();
> >
> > final Map queryParamMap = new HashMap >>> String>();
> > queryParamMap.put("q", "*:*");
> > final QueryRequest query = new QueryRequest(new
> > MapSolrParams(queryParamMap));
> > query.setBasicAuthCredentials("solr", "solrRocks");
> >
> > query.process(client, "techproducts"); // or, client.request(query)
> > On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski <
> >>> gerlowsk...@gmail.com>
> > wrote:
> >>
> >> I would also recommend removing the username/password from your Solr
> >> base URL.  You might be able to get things working that way, but
> >>> it's
> >> definitely less common, and it wouldn't surprise me if some parts of
> >> SolrJ mishandle a URL in that format.  Though that's just a hunch on
> >> my part.
> >> On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski <
> >>> gerlowsk...@gmail.com>
> > wrote:
> >>>
> >>> Hi Ravion,
> >>>
> >>> (Note: I'm not sure what Solr version you're using.  My answer
> >>> below
> >>> assumes Solr 7 APIs.  These APIs don't change often, but you might
> >>> find them under slightly different names in your version of Solr.)
> >>>
> >>> SolrJ provides 2 ways (that I know of) to provide basic auth
> > credentials.
> >>>
> >>> The first (and IMO simplest) way is to use the
> >>> setBasicAuthCredentials
> >>> method on each individual SolrRequest.  You can see what this
> >>> looks
> >>> like in the example below:
> >>>
> >>> final SolrClient client = new
> >>>
> >>> CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> >>> client.setDefaultCollection("collection1");
> >>> SolrQuery req = new SolrQuery("*:*");
> >>> req.setBasicAuthCredentials("yourUsername", "yourPassword);
> >>> client.query(req);
> >>>
> >>> SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which
> >>> reads
> >>> the username/password from Java system properties, and is used to
> >>> configure the HttpClient that SolrJ creates internally for sending
> >>> requests.  I find this second method a little more complex, and it
> >>> looks like you're providing your own HttpClient anyways, so for
> >>> both
> >>> those reasons I'd recommend sticking with the first approach (at
> >>> least
> >>> while you're getting things up and running).
> >>>
> >>> Hope that helps.
> >>>
> >>> Best,
> >>>
> >>> Jason
> >>>
> >>> On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair <
> >>> ravishankar.n...@gmail.com>
> > wrote:
> 
>  Dear all,
> 
>  I have tried my best to do it - searched all Google. But I an=m
>  unsuccessful. Kindly help.
> 
>  We have a solo environment. Its secur

Highlighting is not working with docValues only String field

2018-08-10 Thread Karthik Ramachandran
We are using Solr 7.2.1, highlighting is not working with docValues only String 
field.

Should I open a JIRA for this?

Schema:

  id
  
  
  
  
  


Data:
[{"id":1,"name":"Testing line 1"},{"id":2,"name":"Testing line 
2"},{"id":3,"name":"Testing line 3"}]

Query:
http://localhost:8983/solr/test/select?q=Testing*&df=name&hl=true&hl.fl=name,name1

Response:
{"response":{"numFound":3,"start":0,"docs":[{"id":"1","name":"Testing line 
1","name1":"Testing line 1"},{"id":"2","name":"Testing line 2","name1":"Testing 
line 2"},{"id":"3","name":"Testing line 3","name1":"Testing line 
3"}]},"highlighting":{"1":{"name":["Testing line 
1"]},"2":{"name":["Testing line 2"]},"3":{"name":["Testing 
line 3"]}}}


With Thanks & Regards
Karthik Ramachandran
P Please don't print this e-mail unless you really need to

***Legal Disclaimer***
"This communication may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message by mistake,
please advise the sender by reply email and delete the message. Thank you."
**


Re: Solr admin client crash - caused by too many fields

2018-08-10 Thread Erick Erickson
The analysis page is not all that efficient and can take a long time
to execute, especially with 60K fields.

Having that many fields is almost always a cause to revisit your
design and cut the number of fields down. Solr can cope (well, except
for the analysis page and some other edge cases), but having that many
fields is usually an anti-pattern.

FWIW,
Erick

On Fri, Aug 10, 2018 at 8:34 AM, Shawn Heisey  wrote:
> On 8/10/2018 7:38 AM, ruby wrote:
>>
>> I have 60 thousand fields in schema. When I go to the Analysis page to
>> analyze a field content
>>
>>
>> http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=xyz&analysis.query=xyz&analysis.fieldname=field1&verbose_output=0
>>
>> the admin panel crashes and shows error: Connection to Solr lost. Please
>> see
>> Solr instance.
>>
>> The Solr log shows following error:
>>
>> 2018-08-10 09:37:49.745 INFO  (qtp870698190-19) [   x:collection1]
>> o.a.s.c.S.Request [collection1]  webapp=/solr path=/admin/luke
>> params={show=schema&wt=json&_=1533908056267} status=0 QTime=17709
>> 2018-08-10 09:37:49.748 INFO  (qtp870698190-19) [   x:collection1]
>> o.a.s.s.HttpSolrCall Unable to write response, client closed connection or
>> we are shutting down
>> org.eclipse.jetty.io.EofException
>
>
> EofException is an indication that a TCP connection was closed by the other
> side, which eventually gets noticed when this side tries to send data down
> the connection.  Since idle timeouts that haven't been changed are typically
> either 50 or 60 seconds, this would indicate that something took a VERY long
> time to happen, so one end or the other eventually gave up.  It takes a bit
> of time to transfer information about 6 fields, but even with that many
> I would not expect the admin UI's processes to take long enough for
> EofException to occur.
>
> What is the heap size on your Solr install?  You might be running into a
> situation where the heap is too small and Java is spending a HUGE amount of
> time doing garbage collection - long enough for idle timeouts to be
> exceeded.  The default heap size that Solr uses out of the box is 512MB,
> which is very small.
>
> Thanks,
> Shawn
>


Re: 4 days and no solution - please help on Solr

2018-08-10 Thread Christopher Schultz
Ravion,

What's wrong with "update request"? Updating a document that does not
exist... will add it.

-chris

On 8/10/18 3:01 PM, ☼ R Nair wrote:
> Do you feel that this is only partially complete?
> 
> Best, Ravion
> 
> On Fri, Aug 10, 2018, 1:37 PM ☼ R Nair  wrote:
> 
>> I saw this. Please provide for add. My issue is with add. There is no
>> "AddRequesg". So how to do that, thanks
>>
>> Best Ravion
>>
>> On Fri, Aug 10, 2018, 12:58 PM Jason Gerlowski 
>> wrote:
>>
>>> The "setBasicAuthCredentials" method works on all SolrRequest
>>> implementations.  There's a corresponding SolrRequest object for most
>>> common Solr APIs.  As you mentioned, I used QueryRequest above, but
>>> the same approach works for any SolrRequest object.
>>>
>>> The specific one for indexing is "UpdateRequest".  Here's a short example
>>> below:
>>>
>>> final List docsToIndex = new ArrayList<>();
>>> ...Prepare your docs for indexing
>>> final UpdateRequest update = new UpdateRequest();
>>> update.add(docsToIndex);
>>> update.setBasicAuthCredentials("solr", "solrRocks");
>>> update.process(client, "techproducts");
>>> On Fri, Aug 10, 2018 at 12:47 PM ☼ R Nair 
>>> wrote:

 Hi Jason,

 Thanks for replying.

 I am adding a document, not querying. I am using 7.3 apis. Adding a
 document is done via solrclient.add(). How to set authentication in
 this case? Seems I can't use SolrRequest.

 Thx, bye
 RAVION

 On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski 
 wrote:

> I'd tried to type my previous SolrJ example snippet from memory.  That
> didn't work out so great.  I've corrected it below:
>
> final List zkUrls = new ArrayList<>();
> zkUrls.add("localhost:9983");
> final SolrClient client = new CloudSolrClient.Builder(zkUrls,
> Optional.empty()).build();
>
> final Map queryParamMap = new HashMap>> String>();
> queryParamMap.put("q", "*:*");
> final QueryRequest query = new QueryRequest(new
> MapSolrParams(queryParamMap));
> query.setBasicAuthCredentials("solr", "solrRocks");
>
> query.process(client, "techproducts"); // or, client.request(query)
> On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski <
>>> gerlowsk...@gmail.com>
> wrote:
>>
>> I would also recommend removing the username/password from your Solr
>> base URL.  You might be able to get things working that way, but
>>> it's
>> definitely less common, and it wouldn't surprise me if some parts of
>> SolrJ mishandle a URL in that format.  Though that's just a hunch on
>> my part.
>> On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski <
>>> gerlowsk...@gmail.com>
> wrote:
>>>
>>> Hi Ravion,
>>>
>>> (Note: I'm not sure what Solr version you're using.  My answer
>>> below
>>> assumes Solr 7 APIs.  These APIs don't change often, but you might
>>> find them under slightly different names in your version of Solr.)
>>>
>>> SolrJ provides 2 ways (that I know of) to provide basic auth
> credentials.
>>>
>>> The first (and IMO simplest) way is to use the
>>> setBasicAuthCredentials
>>> method on each individual SolrRequest.  You can see what this
>>> looks
>>> like in the example below:
>>>
>>> final SolrClient client = new
>>>
>>> CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
>>> client.setDefaultCollection("collection1");
>>> SolrQuery req = new SolrQuery("*:*");
>>> req.setBasicAuthCredentials("yourUsername", "yourPassword);
>>> client.query(req);
>>>
>>> SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which
>>> reads
>>> the username/password from Java system properties, and is used to
>>> configure the HttpClient that SolrJ creates internally for sending
>>> requests.  I find this second method a little more complex, and it
>>> looks like you're providing your own HttpClient anyways, so for
>>> both
>>> those reasons I'd recommend sticking with the first approach (at
>>> least
>>> while you're getting things up and running).
>>>
>>> Hope that helps.
>>>
>>> Best,
>>>
>>> Jason
>>>
>>> On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair <
>>> ravishankar.n...@gmail.com>
> wrote:

 Dear all,

 I have tried my best to do it - searched all Google. But I an=m
 unsuccessful. Kindly help.

 We have a solo environment. Its secured with userid and
>>> password.

 I used

>
>>> CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
 method to access it. The url is of the form
>>> http:/userid:password@/
 passionbytes.com/solr. I set defaultCollectionName later.
 In mycloseablehttpclient, I set Basic Authentication with
 CredentialProvider and gave url, port, userid and password.
 I have changed HTTPCLIENT to 4.4.1 version, eve

Solr 7.1 nodes shutting down

2018-08-10 Thread Joe Obernberger
Hi All - having an issue that seems to be related to the machine being 
under a high CPU load.  Occasionally a node will fall out of the solr 
cloud cluster.  It will be using 200% CPU and show the following exception:


2018-08-10 15:36:43.416 INFO  (qtp1908316405-203450) [c:models s:shard3 
r:core_node17 x:models_shard3_replica_n14] o.a.s.s.HttpSolrCall Unable 
to write response, client closed connection or we are shutting down

org.eclipse.jetty.io.EofException: Closed
    at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:659)
    at 
org.apache.commons.io.output.ProxyOutputStream.write(ProxyOutputStream.java:55)
    at 
org.apache.solr.response.QueryResponseWriterUtil$1.write(QueryResponseWriterUtil.java:54)

    at java.io.OutputStream.write(OutputStream.java:116)
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
    at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
    at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
    at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207)
    at org.apache.solr.util.FastWriter.flush(FastWriter.java:140)
    at org.apache.solr.util.FastWriter.flushBuffer(FastWriter.java:154)
    at 
org.apache.solr.response.TextResponseWriter.close(TextResponseWriter.java:96)
    at 
org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:73)
    at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
    at 
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:789)

    at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:526)
    at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
    at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
    at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)
    at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
    at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
    at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
    at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
    at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
    at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
    at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
    at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
    at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
    at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)

    at org.eclipse.jetty.server.Server.handle(Server.java:530)
    at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:347)
    at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:256)
    at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
    at 
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
    at 
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
    at 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
    at 
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
    at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
    at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)

    at java.lang.Thread.run(Thread.java:748)

This is followed by a bunch of exceptions such as:


2018-08-10 19:15:58.989 ERROR (qtp1908316405-209211) [

Re: 4 days and no solution - please help on Solr

2018-08-10 Thread ☼ R Nair
Do you feel that this is only partially complete?

Best, Ravion

On Fri, Aug 10, 2018, 1:37 PM ☼ R Nair  wrote:

> I saw this. Please provide for add. My issue is with add. There is no
> "AddRequesg". So how to do that, thanks
>
> Best Ravion
>
> On Fri, Aug 10, 2018, 12:58 PM Jason Gerlowski 
> wrote:
>
>> The "setBasicAuthCredentials" method works on all SolrRequest
>> implementations.  There's a corresponding SolrRequest object for most
>> common Solr APIs.  As you mentioned, I used QueryRequest above, but
>> the same approach works for any SolrRequest object.
>>
>> The specific one for indexing is "UpdateRequest".  Here's a short example
>> below:
>>
>> final List docsToIndex = new ArrayList<>();
>> ...Prepare your docs for indexing
>> final UpdateRequest update = new UpdateRequest();
>> update.add(docsToIndex);
>> update.setBasicAuthCredentials("solr", "solrRocks");
>> update.process(client, "techproducts");
>> On Fri, Aug 10, 2018 at 12:47 PM ☼ R Nair 
>> wrote:
>> >
>> > Hi Jason,
>> >
>> > Thanks for replying.
>> >
>> > I am adding a document, not querying. I am using 7.3 apis. Adding a
>> > document is done via solrclient.add(). How to set authentication in
>> > this case? Seems I can't use SolrRequest.
>> >
>> > Thx, bye
>> > RAVION
>> >
>> > On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski 
>> > wrote:
>> >
>> > > I'd tried to type my previous SolrJ example snippet from memory.  That
>> > > didn't work out so great.  I've corrected it below:
>> > >
>> > > final List zkUrls = new ArrayList<>();
>> > > zkUrls.add("localhost:9983");
>> > > final SolrClient client = new CloudSolrClient.Builder(zkUrls,
>> > > Optional.empty()).build();
>> > >
>> > > final Map queryParamMap = new HashMap> String>();
>> > > queryParamMap.put("q", "*:*");
>> > > final QueryRequest query = new QueryRequest(new
>> > > MapSolrParams(queryParamMap));
>> > > query.setBasicAuthCredentials("solr", "solrRocks");
>> > >
>> > > query.process(client, "techproducts"); // or, client.request(query)
>> > > On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski <
>> gerlowsk...@gmail.com>
>> > > wrote:
>> > > >
>> > > > I would also recommend removing the username/password from your Solr
>> > > > base URL.  You might be able to get things working that way, but
>> it's
>> > > > definitely less common, and it wouldn't surprise me if some parts of
>> > > > SolrJ mishandle a URL in that format.  Though that's just a hunch on
>> > > > my part.
>> > > > On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski <
>> gerlowsk...@gmail.com>
>> > > wrote:
>> > > > >
>> > > > > Hi Ravion,
>> > > > >
>> > > > > (Note: I'm not sure what Solr version you're using.  My answer
>> below
>> > > > > assumes Solr 7 APIs.  These APIs don't change often, but you might
>> > > > > find them under slightly different names in your version of Solr.)
>> > > > >
>> > > > > SolrJ provides 2 ways (that I know of) to provide basic auth
>> > > credentials.
>> > > > >
>> > > > > The first (and IMO simplest) way is to use the
>> setBasicAuthCredentials
>> > > > > method on each individual SolrRequest.  You can see what this
>> looks
>> > > > > like in the example below:
>> > > > >
>> > > > > final SolrClient client = new
>> > > > >
>> CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
>> > > > > client.setDefaultCollection("collection1");
>> > > > > SolrQuery req = new SolrQuery("*:*");
>> > > > > req.setBasicAuthCredentials("yourUsername", "yourPassword);
>> > > > > client.query(req);
>> > > > >
>> > > > > SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which
>> reads
>> > > > > the username/password from Java system properties, and is used to
>> > > > > configure the HttpClient that SolrJ creates internally for sending
>> > > > > requests.  I find this second method a little more complex, and it
>> > > > > looks like you're providing your own HttpClient anyways, so for
>> both
>> > > > > those reasons I'd recommend sticking with the first approach (at
>> least
>> > > > > while you're getting things up and running).
>> > > > >
>> > > > > Hope that helps.
>> > > > >
>> > > > > Best,
>> > > > >
>> > > > > Jason
>> > > > >
>> > > > > On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair <
>> ravishankar.n...@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > Dear all,
>> > > > > >
>> > > > > > I have tried my best to do it - searched all Google. But I an=m
>> > > > > > unsuccessful. Kindly help.
>> > > > > >
>> > > > > > We have a solo environment. Its secured with userid and
>> password.
>> > > > > >
>> > > > > > I used
>> > > > > >
>> > >
>> CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
>> > > > > > method to access it. The url is of the form
>> http:/userid:password@/
>> > > > > > passionbytes.com/solr. I set defaultCollectionName later.
>> > > > > > In mycloseablehttpclient, I set Basic Authentication with
>> > > > > > CredentialProvider and gave url, port, userid and password.
>> > > > > > I have changed HTTPCLIENT to 4.4.1 version, 

Re: 4 days and no solution - please help on Solr

2018-08-10 Thread ☼ R Nair
I saw this. Please provide for add. My issue is with add. There is no
"AddRequesg". So how to do that, thanks

Best Ravion

On Fri, Aug 10, 2018, 12:58 PM Jason Gerlowski 
wrote:

> The "setBasicAuthCredentials" method works on all SolrRequest
> implementations.  There's a corresponding SolrRequest object for most
> common Solr APIs.  As you mentioned, I used QueryRequest above, but
> the same approach works for any SolrRequest object.
>
> The specific one for indexing is "UpdateRequest".  Here's a short example
> below:
>
> final List docsToIndex = new ArrayList<>();
> ...Prepare your docs for indexing
> final UpdateRequest update = new UpdateRequest();
> update.add(docsToIndex);
> update.setBasicAuthCredentials("solr", "solrRocks");
> update.process(client, "techproducts");
> On Fri, Aug 10, 2018 at 12:47 PM ☼ R Nair 
> wrote:
> >
> > Hi Jason,
> >
> > Thanks for replying.
> >
> > I am adding a document, not querying. I am using 7.3 apis. Adding a
> > document is done via solrclient.add(). How to set authentication in
> > this case? Seems I can't use SolrRequest.
> >
> > Thx, bye
> > RAVION
> >
> > On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski 
> > wrote:
> >
> > > I'd tried to type my previous SolrJ example snippet from memory.  That
> > > didn't work out so great.  I've corrected it below:
> > >
> > > final List zkUrls = new ArrayList<>();
> > > zkUrls.add("localhost:9983");
> > > final SolrClient client = new CloudSolrClient.Builder(zkUrls,
> > > Optional.empty()).build();
> > >
> > > final Map queryParamMap = new HashMap String>();
> > > queryParamMap.put("q", "*:*");
> > > final QueryRequest query = new QueryRequest(new
> > > MapSolrParams(queryParamMap));
> > > query.setBasicAuthCredentials("solr", "solrRocks");
> > >
> > > query.process(client, "techproducts"); // or, client.request(query)
> > > On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski <
> gerlowsk...@gmail.com>
> > > wrote:
> > > >
> > > > I would also recommend removing the username/password from your Solr
> > > > base URL.  You might be able to get things working that way, but it's
> > > > definitely less common, and it wouldn't surprise me if some parts of
> > > > SolrJ mishandle a URL in that format.  Though that's just a hunch on
> > > > my part.
> > > > On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski <
> gerlowsk...@gmail.com>
> > > wrote:
> > > > >
> > > > > Hi Ravion,
> > > > >
> > > > > (Note: I'm not sure what Solr version you're using.  My answer
> below
> > > > > assumes Solr 7 APIs.  These APIs don't change often, but you might
> > > > > find them under slightly different names in your version of Solr.)
> > > > >
> > > > > SolrJ provides 2 ways (that I know of) to provide basic auth
> > > credentials.
> > > > >
> > > > > The first (and IMO simplest) way is to use the
> setBasicAuthCredentials
> > > > > method on each individual SolrRequest.  You can see what this looks
> > > > > like in the example below:
> > > > >
> > > > > final SolrClient client = new
> > > > >
> CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> > > > > client.setDefaultCollection("collection1");
> > > > > SolrQuery req = new SolrQuery("*:*");
> > > > > req.setBasicAuthCredentials("yourUsername", "yourPassword);
> > > > > client.query(req);
> > > > >
> > > > > SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which
> reads
> > > > > the username/password from Java system properties, and is used to
> > > > > configure the HttpClient that SolrJ creates internally for sending
> > > > > requests.  I find this second method a little more complex, and it
> > > > > looks like you're providing your own HttpClient anyways, so for
> both
> > > > > those reasons I'd recommend sticking with the first approach (at
> least
> > > > > while you're getting things up and running).
> > > > >
> > > > > Hope that helps.
> > > > >
> > > > > Best,
> > > > >
> > > > > Jason
> > > > >
> > > > > On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair <
> ravishankar.n...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > Dear all,
> > > > > >
> > > > > > I have tried my best to do it - searched all Google. But I an=m
> > > > > > unsuccessful. Kindly help.
> > > > > >
> > > > > > We have a solo environment. Its secured with userid and password.
> > > > > >
> > > > > > I used
> > > > > >
> > > CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> > > > > > method to access it. The url is of the form
> http:/userid:password@/
> > > > > > passionbytes.com/solr. I set defaultCollectionName later.
> > > > > > In mycloseablehttpclient, I set Basic Authentication with
> > > > > > CredentialProvider and gave url, port, userid and password.
> > > > > > I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
> > > > > >
> > > > > > Still, I get the JSON response from server, saying the URL did
> not
> > > return
> > > > > > the state information from SOLR. It says HTTP 401 ,
> Authentication
> > > Required.
> > > > > >
> > > > > > This is fourt

Faceting with nested Document

2018-08-10 Thread Rajesh Kumar
Hi All,

I am trying to do faceting with "tag and exclude" on nested document
Below nested document sample
{"master_id":"8219",
"color_label":["White"],
"price":1550.0,
"product_id":"8220",
"size_label":["XS"],
"color_option_id":["82"],
"product":"PomPom Summer Dress",
"child_sku":"VJ17MSCL02MAY-XS",
"size_option_id":["94"],}

  {
"title":"PomPom Summer Dress",
"color_label":["White"],
"price":1550.0,
"product_id":"8219",
"color_option_id":["82"],
"product":"PomPom Summer Dress",
"master_sku":"VJ17MSCL02MAY",
"master_id":"0",}
My objective is to get count of products for the field like
color_label,size_label then filter query on these fields.Below is the query
which i m using to get products with size label "L" with faceting
query?q=title:pant&fq={!tag=label}size_label:L&fl=size_label,color_label,id,[child
parentFilter=master_id:0]&
json.facet={
size_label :
{type: terms,
field: size_label,
domain: { blockChildren:"master_id:0",excludeTags:label}
}
}

"response":{"numFound":0,"start":0,"docs":[]
  },
  "facets":{
"count":0,
"size_label":{
  "buckets":[{
  "val":"L",
  "count":39},
{
  "val":"M",
  "count":39},
{
  "val":"XS",
  "count":30},
{
  "val":"XXL",
  "count":30}]}}}

here is no product in response (numFound=0) but still getting "facets"
node. Please help me to understand where i am doing wrong

Regards
Rajesh Kumar


RE: Solr Multiple Hostnames

2018-08-10 Thread Kelly Rusk
Hi Shawn,

I want traffic passed over https to flow through the load balancer and resolve 
on the Solr servers by an address of https://solr.mydomain.com:8983/solr. The 
hostname I have set for the Solr Master is master.mydomain.com and the Slave is 
slave.mydomain.com.

So, are you stating that so long as my DNS has an entry for the domain of  
https://solr.mydomain.com:8983/solr it should work, even if the individual Solr 
servers have their host set as master.mydomain.com or slave.mydomain.com.

Regards,

Kelly

-Original Message-
From: Shawn Heisey  
Sent: Thursday, August 9, 2018 11:00 PM
To: solr-user@lucene.apache.org
Subject: Re: Solr Multiple Hostnames

On 8/9/2018 8:37 PM, Kelly Rusk wrote:
> Is it possible to have mutiple hostnames for a single Solr node, akin to an 
> IIS Website with multiple host headers?

Solr doesn't pay attention to any host header in the HTTP request.  If Solr 
receives the traffic on its TCP port, it will answer, no matter what host value 
you send.  It's not possible to configure even one name, let alone multiple 
names.

What is it that you're trying to accomplish that has you thinking you need to 
add another hostname?  I read your message, but I do not see the end goal.

https://home.apache.org/~hossman/#xyproblem

Thanks,
Shawn



Re: 4 days and no solution - please help on Solr

2018-08-10 Thread Jason Gerlowski
The "setBasicAuthCredentials" method works on all SolrRequest
implementations.  There's a corresponding SolrRequest object for most
common Solr APIs.  As you mentioned, I used QueryRequest above, but
the same approach works for any SolrRequest object.

The specific one for indexing is "UpdateRequest".  Here's a short example below:

final List docsToIndex = new ArrayList<>();
...Prepare your docs for indexing
final UpdateRequest update = new UpdateRequest();
update.add(docsToIndex);
update.setBasicAuthCredentials("solr", "solrRocks");
update.process(client, "techproducts");
On Fri, Aug 10, 2018 at 12:47 PM ☼ R Nair  wrote:
>
> Hi Jason,
>
> Thanks for replying.
>
> I am adding a document, not querying. I am using 7.3 apis. Adding a
> document is done via solrclient.add(). How to set authentication in
> this case? Seems I can't use SolrRequest.
>
> Thx, bye
> RAVION
>
> On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski 
> wrote:
>
> > I'd tried to type my previous SolrJ example snippet from memory.  That
> > didn't work out so great.  I've corrected it below:
> >
> > final List zkUrls = new ArrayList<>();
> > zkUrls.add("localhost:9983");
> > final SolrClient client = new CloudSolrClient.Builder(zkUrls,
> > Optional.empty()).build();
> >
> > final Map queryParamMap = new HashMap();
> > queryParamMap.put("q", "*:*");
> > final QueryRequest query = new QueryRequest(new
> > MapSolrParams(queryParamMap));
> > query.setBasicAuthCredentials("solr", "solrRocks");
> >
> > query.process(client, "techproducts"); // or, client.request(query)
> > On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski 
> > wrote:
> > >
> > > I would also recommend removing the username/password from your Solr
> > > base URL.  You might be able to get things working that way, but it's
> > > definitely less common, and it wouldn't surprise me if some parts of
> > > SolrJ mishandle a URL in that format.  Though that's just a hunch on
> > > my part.
> > > On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski 
> > wrote:
> > > >
> > > > Hi Ravion,
> > > >
> > > > (Note: I'm not sure what Solr version you're using.  My answer below
> > > > assumes Solr 7 APIs.  These APIs don't change often, but you might
> > > > find them under slightly different names in your version of Solr.)
> > > >
> > > > SolrJ provides 2 ways (that I know of) to provide basic auth
> > credentials.
> > > >
> > > > The first (and IMO simplest) way is to use the setBasicAuthCredentials
> > > > method on each individual SolrRequest.  You can see what this looks
> > > > like in the example below:
> > > >
> > > > final SolrClient client = new
> > > > CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> > > > client.setDefaultCollection("collection1");
> > > > SolrQuery req = new SolrQuery("*:*");
> > > > req.setBasicAuthCredentials("yourUsername", "yourPassword);
> > > > client.query(req);
> > > >
> > > > SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which reads
> > > > the username/password from Java system properties, and is used to
> > > > configure the HttpClient that SolrJ creates internally for sending
> > > > requests.  I find this second method a little more complex, and it
> > > > looks like you're providing your own HttpClient anyways, so for both
> > > > those reasons I'd recommend sticking with the first approach (at least
> > > > while you're getting things up and running).
> > > >
> > > > Hope that helps.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > > > On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair 
> > wrote:
> > > > >
> > > > > Dear all,
> > > > >
> > > > > I have tried my best to do it - searched all Google. But I an=m
> > > > > unsuccessful. Kindly help.
> > > > >
> > > > > We have a solo environment. Its secured with userid and password.
> > > > >
> > > > > I used
> > > > >
> > CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> > > > > method to access it. The url is of the form http:/userid:password@/
> > > > > passionbytes.com/solr. I set defaultCollectionName later.
> > > > > In mycloseablehttpclient, I set Basic Authentication with
> > > > > CredentialProvider and gave url, port, userid and password.
> > > > > I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
> > > > >
> > > > > Still, I get the JSON response from server, saying the URL did not
> > return
> > > > > the state information from SOLR. It says HTTP 401 , Authentication
> > Required.
> > > > >
> > > > > This is fourth day on this problem. Any help is appreciated. I have
> > done
> > > > > whatever is available through documentation and/or Google.
> > > > >
> > > > > Best,
> > > > > Ravion
> >


RE: sharding and placement of replicas

2018-08-10 Thread Oakley, Craig (NIH/NLM/NCBI) [C]
Note that I usually create collections with commands which contain (for example)

solr/admin/collections?action=CREATE&name=collectest&collection.configName=collectest&numShards=1&replicationFactor=1&createNodeSet=

I give one node in the createNodeSet and then ADDREPLICA to the other node.

In case this were related, I now tried it a different way, using a command 
which contains

solr/admin/collections?action=CREATE&name=collectest5&collection.configName=collectest&numShards=1&replicationFactor=2&createNodeSet=

I gave both nodes in the createNodeSet in this case. It created one replica on 
each node (each node being on a different host at the same port). This is what 
I would consider the expected behavior (refraining from putting two replicas of 
the same one shard on the same node)

After this I ran a command including

solr/admin/collections?action=SPLITSHARD&collection=collectest5&shard=shard1&indent=on&async=test20180810h

The result was still the same: one of the four new shards was on one node and 
the other three were all together on the node from which I issued this command 
(including putting two replicas of the same shard on the same node).





I am wondering whether there are any examples of this actually working (any 
examples of SPLITSHARD occasionally placing replicas of the each shard on 
different hosts than other replicas of the same shards)


-Original Message-
From: Oakley, Craig (NIH/NLM/NCBI) [C] [mailto:craig.oak...@nih.gov] 
Sent: Thursday, August 09, 2018 5:08 PM
To: solr-user@lucene.apache.org
Subject: RE: sharding and placement of replicas

Okay, I've tried again with two nodes running Solr7.4 on different hosts.

Before SPLITSHARD, collectest2_shard1_replica_n1 was on the host nosqltest22, 
and collectest2_shard1_replica_n3 was on the host nosqltest11

After running SPLITSHARD (on the nosqltest22 node), only 
collectest2_shard1_0_replica0 was added to nosqltest11; nosqltest22 became the 
location for collectest2_shard1_0_replica_n5 and 
collectest2_shard1_1_replica_n6 and collectest2_shard1_1_replica0 (and so if 
nosqltest22 were to be down, shard1_1 would not be available).


-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com] 
Sent: Tuesday, July 31, 2018 5:16 PM
To: solr-user 
Subject: Re: sharding and placement of replicas

Right, two JVMs on the same physical host with different ports are
"different Solrs" by default. If you had two replicas per shard and
both were on either Solr instance (same port) that would be
unexpected.

Problem is that this would have been a bug clear back in the Solr 4x
days so the fact that you say you saw it on 6.6 would be unexpected.

Of course if you have three replicas and two instances, I'd absolutely
expect that two replicas would be on one of them for each shard.

Best,
Erick

On Tue, Jul 31, 2018 at 12:24 PM, Oakley, Craig (NIH/NLM/NCBI) [C]
 wrote:
> In my case, when trying on Solr7.4 (in response to Shawn Heisey's 6/19/18 
> comment "If this is a provable and reproducible bug, and it's still a problem 
> in the current stable branch"), I had only installed Solr7.4 on one host, and 
> so I was testing with two nodes on the same host (different port numbers). I 
> had previously had the same symptom when the two nodes were on different 
> hosts, but that was with Solr6.6 -- I can try it again with Solr7.4 with two 
> hosts and report back.
>
> -Original Message-
> From: Shawn Heisey [mailto:apa...@elyograg.org]
> Sent: Tuesday, July 31, 2018 2:26 PM
> To: solr-user@lucene.apache.org
> Subject: Re: sharding and placement of replicas
>
> On 7/27/2018 8:26 PM, Erick Erickson wrote:
>> Yes with some fiddling as far as "placement rules", start here:
>> https://lucene.apache.org/solr/guide/6_6/rule-based-replica-placement.html
>>
>> The idea (IIUC) is that you provide a snitch" that identifies what
>> "rack" the Solr instance is on and can define placement rules that
>> define "don't put more than one thingy on the same rack". "Thingy"
>> here is replica, shard, whatever as defined by other placement rules.
>
> I'd like to see an improvement in Solr's behavior when nothing has been
> configured in auto-scaling or rule-based replica placement.  Configuring
> those things is certainly an option, but I think we can do better even
> without that config.
>
> I believe that Solr already has some default intelligence that keeps
> multiple replicas from ending up on the same *node* when possible ... I
> would like this to also be aware of *hosts*.
>
> Craig hasn't yet indicated whether there is more than one node per host,
> so I don't know whether the behavior he's seeing should be considered a bug.
>
> If somebody gives one machine multiple names/addresses and uses
> different hostnames in their SolrCloud config for one actual host, then
> it wouldn't be able to do any better than it does now, but if there are
> matches in the hostname part of different entries in live_nodes, then I
> think the improvem

Re: 4 days and no solution - please help on Solr

2018-08-10 Thread ☼ R Nair
Hi Jason,

Thanks for replying.

I am adding a document, not querying. I am using 7.3 apis. Adding a
document is done via solrclient.add(). How to set authentication in
this case? Seems I can't use SolrRequest.

Thx, bye
RAVION

On Fri, Aug 10, 2018, 10:46 AM Jason Gerlowski 
wrote:

> I'd tried to type my previous SolrJ example snippet from memory.  That
> didn't work out so great.  I've corrected it below:
>
> final List zkUrls = new ArrayList<>();
> zkUrls.add("localhost:9983");
> final SolrClient client = new CloudSolrClient.Builder(zkUrls,
> Optional.empty()).build();
>
> final Map queryParamMap = new HashMap();
> queryParamMap.put("q", "*:*");
> final QueryRequest query = new QueryRequest(new
> MapSolrParams(queryParamMap));
> query.setBasicAuthCredentials("solr", "solrRocks");
>
> query.process(client, "techproducts"); // or, client.request(query)
> On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski 
> wrote:
> >
> > I would also recommend removing the username/password from your Solr
> > base URL.  You might be able to get things working that way, but it's
> > definitely less common, and it wouldn't surprise me if some parts of
> > SolrJ mishandle a URL in that format.  Though that's just a hunch on
> > my part.
> > On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski 
> wrote:
> > >
> > > Hi Ravion,
> > >
> > > (Note: I'm not sure what Solr version you're using.  My answer below
> > > assumes Solr 7 APIs.  These APIs don't change often, but you might
> > > find them under slightly different names in your version of Solr.)
> > >
> > > SolrJ provides 2 ways (that I know of) to provide basic auth
> credentials.
> > >
> > > The first (and IMO simplest) way is to use the setBasicAuthCredentials
> > > method on each individual SolrRequest.  You can see what this looks
> > > like in the example below:
> > >
> > > final SolrClient client = new
> > > CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> > > client.setDefaultCollection("collection1");
> > > SolrQuery req = new SolrQuery("*:*");
> > > req.setBasicAuthCredentials("yourUsername", "yourPassword);
> > > client.query(req);
> > >
> > > SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which reads
> > > the username/password from Java system properties, and is used to
> > > configure the HttpClient that SolrJ creates internally for sending
> > > requests.  I find this second method a little more complex, and it
> > > looks like you're providing your own HttpClient anyways, so for both
> > > those reasons I'd recommend sticking with the first approach (at least
> > > while you're getting things up and running).
> > >
> > > Hope that helps.
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair 
> wrote:
> > > >
> > > > Dear all,
> > > >
> > > > I have tried my best to do it - searched all Google. But I an=m
> > > > unsuccessful. Kindly help.
> > > >
> > > > We have a solo environment. Its secured with userid and password.
> > > >
> > > > I used
> > > >
> CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> > > > method to access it. The url is of the form http:/userid:password@/
> > > > passionbytes.com/solr. I set defaultCollectionName later.
> > > > In mycloseablehttpclient, I set Basic Authentication with
> > > > CredentialProvider and gave url, port, userid and password.
> > > > I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
> > > >
> > > > Still, I get the JSON response from server, saying the URL did not
> return
> > > > the state information from SOLR. It says HTTP 401 , Authentication
> Required.
> > > >
> > > > This is fourth day on this problem. Any help is appreciated. I have
> done
> > > > whatever is available through documentation and/or Google.
> > > >
> > > > Best,
> > > > Ravion
>


Re: SolrCloud CDCR issue

2018-08-10 Thread Amrit Sarkar
Honestly, any of the in that case. Please follow the following steps;

1. Stop CDCR on cluster-1
2. Stop CDCR on cluster-2
Both the above steps are critical.
3. Shut down all nodes of cluster-1
4. Shut down all nodes of cluster-2
5. Start all nodes at cluster-1
6. Start all nodes at cluster-2
7. Start CDCR on cluster-1
Go to logs and verify "forwarding has been started"
8. Start CDCR on cluster-2
Do the same sanity check.

I understand this is unnecessarily complex but it is the manner CDCR was
designed in the beginning. Please give it a shot and let us know.

Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.lucidworks.com
Twitter http://twitter.com/lucidworks
LinkedIn: https://www.linkedin.com/in/sarkaramrit2
Medium: https://medium.com/@sarkaramrit2


On Fri, Aug 10, 2018 at 9:09 PM cdatta  wrote:

> Really appreciate your response.
> I saw this information in some of your earlier posts related to CDCR. We
> are
> using our Cloud Cluster as an Active/Active settings and bi-directional
> CDCR.
> In that case, which one should we start first?
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>


Re: SolrCloud CDCR issue

2018-08-10 Thread cdatta
Really appreciate your response.
I saw this information in some of your earlier posts related to CDCR. We are
using our Cloud Cluster as an Active/Active settings and bi-directional
CDCR.
In that case, which one should we start first?



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: Solr admin client crash - caused by too many fields

2018-08-10 Thread Shawn Heisey

On 8/10/2018 7:38 AM, ruby wrote:

I have 60 thousand fields in schema. When I go to the Analysis page to
analyze a field content

http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=xyz&analysis.query=xyz&analysis.fieldname=field1&verbose_output=0

the admin panel crashes and shows error: Connection to Solr lost. Please see
Solr instance.

The Solr log shows following error:

2018-08-10 09:37:49.745 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.c.S.Request [collection1]  webapp=/solr path=/admin/luke
params={show=schema&wt=json&_=1533908056267} status=0 QTime=17709
2018-08-10 09:37:49.748 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.s.HttpSolrCall Unable to write response, client closed connection or
we are shutting down
org.eclipse.jetty.io.EofException


EofException is an indication that a TCP connection was closed by the 
other side, which eventually gets noticed when this side tries to send 
data down the connection.  Since idle timeouts that haven't been changed 
are typically either 50 or 60 seconds, this would indicate that 
something took a VERY long time to happen, so one end or the other 
eventually gave up.  It takes a bit of time to transfer information 
about 6 fields, but even with that many I would not expect the admin 
UI's processes to take long enough for EofException to occur.


What is the heap size on your Solr install?  You might be running into a 
situation where the heap is too small and Java is spending a HUGE amount 
of time doing garbage collection - long enough for idle timeouts to be 
exceeded.  The default heap size that Solr uses out of the box is 512MB, 
which is very small.


Thanks,
Shawn



Re: Solr unable to start up after setting up SSL in Solr 7.4.0

2018-08-10 Thread Jan Høydahl
Hi,

Did you solve your issue? SSL should work ootb in 7.4, the class that your 
error says is not found exists, so there must be some setup issues.
How did you install Solr, how do you start it, what is the content of your 
solr.in .sh etc

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 11. jul. 2018 kl. 17:23 skrev Zheng Lin Edwin Yeo :
> 
> Hi,
> 
> I found that if we replace the following files with the copy from Solr
> 7.3.1, the SSL can work
> - jetty.xml
> - jetty-http.xml
> - jetty-https.xml
> - jetty-ssl.xml
> 
> But the copies that comes with Solr 7.4.0 are not working.
> 
> I found there are some differences in the file, but not sure if there are
> other changes required, or if there are bugs in the copies in Solr 7.4.0?
> 
> Regards,
> Edwin
> 
> On 4 July 2018 at 11:20, Zheng Lin Edwin Yeo  wrote:
> 
>> Hi,
>> 
>> Would like to check, if there are any major changes in the way the SSL
>> works for Solr 7.4.0?
>> 
>> I have tried to set up with the same method that I used for Solr 7.3.1,
>> but after setting it up, the Solr is unable to load.
>> 
>> Below is the error message that I get.
>> 
>> Caused by: java.security.PrivilegedActionException:
>> java.lang.ClassNotFoundExcep
>> tion: org.apache.solr.util.configuration.SSLConfigurationsFactory
>>at java.security.AccessController.doPrivileged(Native Method)
>>at org.eclipse.jetty.xml.XmlConfiguration.main(
>> XmlConfiguration.java:150
>> 8)
>>... 7 more
>> Caused by: java.lang.ClassNotFoundException: org.apache.solr.util.
>> configuration.
>> SSLConfigurationsFactory
>>at java.net.URLClassLoader.findClass(Unknown Source)
>>at java.lang.ClassLoader.loadClass(Unknown Source)
>>at java.lang.ClassLoader.loadClass(Unknown Source)
>>at org.eclipse.jetty.util.Loader.loadClass(Loader.java:65)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.call(Xml
>> Configuration.java:784)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.configur
>> e(XmlConfiguration.java:469)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.configur
>> e(XmlConfiguration.java:410)
>>at org.eclipse.jetty.xml.XmlConfiguration.configure(
>> XmlConfiguration.jav
>> a:308)
>>at org.eclipse.jetty.xml.XmlConfiguration$1.run(
>> XmlConfiguration.java:15
>> 55)
>>at org.eclipse.jetty.xml.XmlConfiguration$1.run(
>> XmlConfiguration.java:15
>> 09)
>>... 9 more
>> java.lang.reflect.InvocationTargetException
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>at java.lang.reflect.Method.invoke(Unknown Source)
>>at org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
>>at org.eclipse.jetty.start.Main.start(Main.java:486)
>>at org.eclipse.jetty.start.Main.main(Main.java:77)
>> Caused by: java.security.PrivilegedActionException:
>> java.lang.ClassNotFoundExcep
>> tion: org.apache.solr.util.configuration.SSLConfigurationsFactory
>>at java.security.AccessController.doPrivileged(Native Method)
>>at org.eclipse.jetty.xml.XmlConfiguration.main(
>> XmlConfiguration.java:150
>> 8)
>>... 7 more
>> Caused by: java.lang.ClassNotFoundException: org.apache.solr.util.
>> configuration.
>> SSLConfigurationsFactory
>>at java.net.URLClassLoader.findClass(Unknown Source)
>>at java.lang.ClassLoader.loadClass(Unknown Source)
>>at java.lang.ClassLoader.loadClass(Unknown Source)
>>at org.eclipse.jetty.util.Loader.loadClass(Loader.java:65)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.call(Xml
>> Configuration.java:784)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.configur
>> e(XmlConfiguration.java:469)
>>at org.eclipse.jetty.xml.XmlConfiguration$
>> JettyXmlConfiguration.configur
>> e(XmlConfiguration.java:410)
>>at org.eclipse.jetty.xml.XmlConfiguration.configure(
>> XmlConfiguration.jav
>> a:308)
>>at org.eclipse.jetty.xml.XmlConfiguration$1.run(
>> XmlConfiguration.java:15
>> 55)
>>at org.eclipse.jetty.xml.XmlConfiguration$1.run(
>> XmlConfiguration.java:15
>> 09)
>>... 9 more
>> 
>> Usage: java -jar $JETTY_HOME/start.jar [options] [properties] [configs]
>>   java -jar $JETTY_HOME/start.jar --help  # for more information
>> 
>> 
>> Regards,
>> Edwin
>> 



Re: 4 days and no solution - please help on Solr

2018-08-10 Thread Jason Gerlowski
I'd tried to type my previous SolrJ example snippet from memory.  That
didn't work out so great.  I've corrected it below:

final List zkUrls = new ArrayList<>();
zkUrls.add("localhost:9983");
final SolrClient client = new CloudSolrClient.Builder(zkUrls,
Optional.empty()).build();

final Map queryParamMap = new HashMap();
queryParamMap.put("q", "*:*");
final QueryRequest query = new QueryRequest(new MapSolrParams(queryParamMap));
query.setBasicAuthCredentials("solr", "solrRocks");

query.process(client, "techproducts"); // or, client.request(query)
On Fri, Aug 10, 2018 at 10:12 AM Jason Gerlowski  wrote:
>
> I would also recommend removing the username/password from your Solr
> base URL.  You might be able to get things working that way, but it's
> definitely less common, and it wouldn't surprise me if some parts of
> SolrJ mishandle a URL in that format.  Though that's just a hunch on
> my part.
> On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski  
> wrote:
> >
> > Hi Ravion,
> >
> > (Note: I'm not sure what Solr version you're using.  My answer below
> > assumes Solr 7 APIs.  These APIs don't change often, but you might
> > find them under slightly different names in your version of Solr.)
> >
> > SolrJ provides 2 ways (that I know of) to provide basic auth credentials.
> >
> > The first (and IMO simplest) way is to use the setBasicAuthCredentials
> > method on each individual SolrRequest.  You can see what this looks
> > like in the example below:
> >
> > final SolrClient client = new
> > CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> > client.setDefaultCollection("collection1");
> > SolrQuery req = new SolrQuery("*:*");
> > req.setBasicAuthCredentials("yourUsername", "yourPassword);
> > client.query(req);
> >
> > SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which reads
> > the username/password from Java system properties, and is used to
> > configure the HttpClient that SolrJ creates internally for sending
> > requests.  I find this second method a little more complex, and it
> > looks like you're providing your own HttpClient anyways, so for both
> > those reasons I'd recommend sticking with the first approach (at least
> > while you're getting things up and running).
> >
> > Hope that helps.
> >
> > Best,
> >
> > Jason
> >
> > On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair  wrote:
> > >
> > > Dear all,
> > >
> > > I have tried my best to do it - searched all Google. But I an=m
> > > unsuccessful. Kindly help.
> > >
> > > We have a solo environment. Its secured with userid and password.
> > >
> > > I used
> > > CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> > > method to access it. The url is of the form http:/userid:password@/
> > > passionbytes.com/solr. I set defaultCollectionName later.
> > > In mycloseablehttpclient, I set Basic Authentication with
> > > CredentialProvider and gave url, port, userid and password.
> > > I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
> > >
> > > Still, I get the JSON response from server, saying the URL did not return
> > > the state information from SOLR. It says HTTP 401 , Authentication 
> > > Required.
> > >
> > > This is fourth day on this problem. Any help is appreciated. I have done
> > > whatever is available through documentation and/or Google.
> > >
> > > Best,
> > > Ravion


Re: 4 days and no solution - please help on Solr

2018-08-10 Thread Jason Gerlowski
I would also recommend removing the username/password from your Solr
base URL.  You might be able to get things working that way, but it's
definitely less common, and it wouldn't surprise me if some parts of
SolrJ mishandle a URL in that format.  Though that's just a hunch on
my part.
On Fri, Aug 10, 2018 at 10:09 AM Jason Gerlowski  wrote:
>
> Hi Ravion,
>
> (Note: I'm not sure what Solr version you're using.  My answer below
> assumes Solr 7 APIs.  These APIs don't change often, but you might
> find them under slightly different names in your version of Solr.)
>
> SolrJ provides 2 ways (that I know of) to provide basic auth credentials.
>
> The first (and IMO simplest) way is to use the setBasicAuthCredentials
> method on each individual SolrRequest.  You can see what this looks
> like in the example below:
>
> final SolrClient client = new
> CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
> client.setDefaultCollection("collection1");
> SolrQuery req = new SolrQuery("*:*");
> req.setBasicAuthCredentials("yourUsername", "yourPassword);
> client.query(req);
>
> SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which reads
> the username/password from Java system properties, and is used to
> configure the HttpClient that SolrJ creates internally for sending
> requests.  I find this second method a little more complex, and it
> looks like you're providing your own HttpClient anyways, so for both
> those reasons I'd recommend sticking with the first approach (at least
> while you're getting things up and running).
>
> Hope that helps.
>
> Best,
>
> Jason
>
> On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair  wrote:
> >
> > Dear all,
> >
> > I have tried my best to do it - searched all Google. But I an=m
> > unsuccessful. Kindly help.
> >
> > We have a solo environment. Its secured with userid and password.
> >
> > I used
> > CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> > method to access it. The url is of the form http:/userid:password@/
> > passionbytes.com/solr. I set defaultCollectionName later.
> > In mycloseablehttpclient, I set Basic Authentication with
> > CredentialProvider and gave url, port, userid and password.
> > I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
> >
> > Still, I get the JSON response from server, saying the URL did not return
> > the state information from SOLR. It says HTTP 401 , Authentication Required.
> >
> > This is fourth day on this problem. Any help is appreciated. I have done
> > whatever is available through documentation and/or Google.
> >
> > Best,
> > Ravion


Re: Rich Text Format - Clob

2018-08-10 Thread Alexandre Rafalovitch
I think you need ClobTransformer at some point in the processing:
https://lucene.apache.org/solr/guide/7_4/uploading-structured-data-store-data-with-the-data-import-handler.html#clobtransformer

Regards,
   Alex.

On 10 August 2018 at 10:02, tfaltinat  wrote:
> Hi,
>
> we have an Oracle database where we store Rtf content into a Clob column.
> Now we try to index those records but we just want to get the plain text,
> same as Tika does. I tried to use the TikaEntityProcessor but I’m getting
> the following error message:
>
> ClassCastException: java.io.StringReader cannot be cast to
> java.io.InputStream
>
> The configuration looks like this:
>
> 
>
>  query="select SOLUTION_ID, SOLUTION_TXT SOLUTION_TXT from IT_SOLUTION where
> SOLUTION_ID = '${ts3_it_solution_text_search.SOLUTION_ID}'">
> 
>  processor="TikaEntityProcessor" url="${SV_SOLVE_TXT.text_4}"
> dataField="SV_SOLVE_TXT.text_4"  dataSource="f1" >
> 
> 
> 
>
> Thx & Regards,
> Torsten
>
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: 4 days and no solution - please help on Solr

2018-08-10 Thread Jason Gerlowski
Hi Ravion,

(Note: I'm not sure what Solr version you're using.  My answer below
assumes Solr 7 APIs.  These APIs don't change often, but you might
find them under slightly different names in your version of Solr.)

SolrJ provides 2 ways (that I know of) to provide basic auth credentials.

The first (and IMO simplest) way is to use the setBasicAuthCredentials
method on each individual SolrRequest.  You can see what this looks
like in the example below:

final SolrClient client = new
CloudSolrCLient.Builder(solrURLs).withHttpClient(myHttpClient).build();
client.setDefaultCollection("collection1");
SolrQuery req = new SolrQuery("*:*");
req.setBasicAuthCredentials("yourUsername", "yourPassword);
client.query(req);

SolrJ also has a PreemptiveBasicAuthClientBuilderFactory, which reads
the username/password from Java system properties, and is used to
configure the HttpClient that SolrJ creates internally for sending
requests.  I find this second method a little more complex, and it
looks like you're providing your own HttpClient anyways, so for both
those reasons I'd recommend sticking with the first approach (at least
while you're getting things up and running).

Hope that helps.

Best,

Jason

On Thu, Aug 9, 2018 at 5:47 PM ☼ R Nair  wrote:
>
> Dear all,
>
> I have tried my best to do it - searched all Google. But I an=m
> unsuccessful. Kindly help.
>
> We have a solo environment. Its secured with userid and password.
>
> I used
> CloudSolrClient.Builder(solrURLs).withHttpClient(mycloseablehttpclient)
> method to access it. The url is of the form http:/userid:password@/
> passionbytes.com/solr. I set defaultCollectionName later.
> In mycloseablehttpclient, I set Basic Authentication with
> CredentialProvider and gave url, port, userid and password.
> I have changed HTTPCLIENT to 4.4.1 version, even tried 4.5.3.
>
> Still, I get the JSON response from server, saying the URL did not return
> the state information from SOLR. It says HTTP 401 , Authentication Required.
>
> This is fourth day on this problem. Any help is appreciated. I have done
> whatever is available through documentation and/or Google.
>
> Best,
> Ravion


Rich Text Format - Clob

2018-08-10 Thread tfaltinat
Hi,

we have an Oracle database where we store Rtf content into a Clob column.
Now we try to index those records but we just want to get the plain text,
same as Tika does. I tried to use the TikaEntityProcessor but I’m getting
the following error message:

ClassCastException: java.io.StringReader cannot be cast to
java.io.InputStream

The configuration looks like this:










Thx & Regards,
Torsten




--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Solr admin client crash - caused by too many fields

2018-08-10 Thread ruby
I have 60 thousand fields in schema. When I go to the Analysis page to
analyze a field content

http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=xyz&analysis.query=xyz&analysis.fieldname=field1&verbose_output=0

the admin panel crashes and shows error: Connection to Solr lost. Please see
Solr instance. 

The Solr log shows following error:

2018-08-10 09:37:49.745 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.c.S.Request [collection1]  webapp=/solr path=/admin/luke
params={show=schema&wt=json&_=1533908056267} status=0 QTime=17709
2018-08-10 09:37:49.748 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.s.HttpSolrCall Unable to write response, client closed connection or
we are shutting down
org.eclipse.jetty.io.EofException
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:197)
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:419)
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:313)
at 
org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:141)
at
org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:732)
at
org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
at
org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224)
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:512)


Any idea how to fix this issue?

Thanks



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Solr admin client crash - caused by too many fields

2018-08-10 Thread ruby
I have 60 thousand fields in schema. When I go to the Analysis page to
analyze a field content

http://localhost:8983/solr/#/collection1/analysis?analysis.fieldvalue=xyz&analysis.query=xyz&analysis.fieldname=field1&verbose_output=0

the admin panel crashes and shows error: Connection to Solr lost. Please see
Solr instance. 

The Solr log shows following error:

2018-08-10 09:37:49.745 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.c.S.Request [collection1]  webapp=/solr path=/admin/luke
params={show=schema&wt=json&_=1533908056267} status=0 QTime=17709
2018-08-10 09:37:49.748 INFO  (qtp870698190-19) [   x:collection1]
o.a.s.s.HttpSolrCall Unable to write response, client closed connection or
we are shutting down
org.eclipse.jetty.io.EofException
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:197)
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:419)
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:313)
at 
org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:141)
at
org.eclipse.jetty.server.HttpConnection$SendCallback.process(HttpConnection.java:732)
at
org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241)
at
org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224)
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:512)


Any idea how to fix this issue?

Thanks



--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html


Re: SolrCloud CDCR issue

2018-08-10 Thread Amrit Sarkar
To the concerned,

WARN : [c:collection_name s:shard2 r:core_node11
> x:collection_name_shard2_replica_n8]
> org.apache.solr.handler.CdcrRequestHandler; The log reader for target
> collection collection_name is not initialised @ collection_name:shard2
>

This means the source cluster was started first and then target. You need
to shut down all the nodes both at source and target. Get the targe nodes
up, all of them before starting the source ones. Logs will be initialized
positively.

Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.lucidworks.com
Twitter http://twitter.com/lucidworks
LinkedIn: https://www.linkedin.com/in/sarkaramrit2
Medium: https://medium.com/@sarkaramrit2


On Fri, Aug 3, 2018 at 11:33 PM cdatta  wrote:

> Any pointers?
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>