Re: Classify stream expression questions

[Joe Obernberger]

Thank you Joel - I'm using a ModifiableSolrParams object to build the 
parameters for Solr (hope this is what you want)


toString() returns:

expr=classify(model(models,id%3D"MODEL1014",cacheMillis%3D5000),search(COL,df%3D"FULL_DOCUMENT",q%3D"Collection:(COLLECT2000)+AND+DocTimestamp:[2017-08-14T04:00:00Z+TO+2017-08-16T03:59:00Z]",fl%3D"id,score",sort%3D"id+asc"),field%3D"ClusterText")=/stream=true=id=id+asc=100

This collection has 100 shards with 3 replicas each, so I would expect 
100*20 = 2000 results?  Although I'm classifying on ClusterText, for the 
results, I only need an ID.  At present, I can build a model and 
classify a single, or set of documents as they come into the system.  
However, if I want to use a model as a search, then I'm asking Solr to 
classify a lot of docs, but I actually only want to return docs that 
have a probability of n or higher.


-Joe


On 8/14/2017 10:46 PM, Joel Bernstein wrote:

My math was off again ... If you have 20 results from 50 shards that would
produce the 1000 results.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 10:17 PM, Joel Bernstein  wrote:


Actually my math was off. You would need 200 shards to get to 1000 result.
How many shards do you have?

The expression you provided also didn't include the ClusterText field in
field list of the search. So perhaps it's missing other parameters.

If you include all the parameters I may be able to spot the issue.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 10:10 PM, Joel Bernstein 
wrote:


It looks like you just need to set the rows parameter in the search
expression. If you don't set rows the default will be 20 I believe, which
will pull to top 20 docs from each shard. If you have 5 shards than the
1000 results would make sense.

You can parallelize the whole expression by wrapping it in a parallel
expression. You'll need to set the partitionKeys in the search expression
to do this.

If you have a large number of records to process I would recommend batch
processing. This blog explains the parallel batch framework:

http://joelsolr.blogspot.com/2016/10/solr-63-batch-jobs-para
llel-etl-and.html






Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 7:53 PM, Joe Obernberger <
joseph.obernber...@gmail.com> wrote:


Hi All - I'm using the classify stream expression and the results
returned are always limited to 1,000.  Where do I specify the number to
return?  The stream expression that I'm using looks like:

classify(model(models,id="MODEL1014",cacheMillis=5000),searc
h(COL,df="FULL_DOCUMENT",q="Collection:(COLLECT2000) AND
DocTimestamp:[2017-08-14T04:00:00Z TO 
2017-08-15T03:59:00Z]",fl="id,score",sort="id
asc"),field="ClusterText")

When I read this (code snipet):

  stream.open();
 while (true) {
 Tuple tuple = stream.read();
 if (tuple.EOF) {
 break;
 }
 Double probabilty = (Double)
tuple.fields.get("probability_d");
 String docID = (String) tuple.fields.get("id");

I get back 1,000 results.  Another question is if there is a way to
parallelize the classify call to other worker nodes?  Thank you!

-Joe




---
This email has been checked for viruses by AVG.
http://www.avg.com

Re: Classify stream expression questions

[Joel Bernstein]

My math was off again ... If you have 20 results from 50 shards that would
produce the 1000 results.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 10:17 PM, Joel Bernstein  wrote:

> Actually my math was off. You would need 200 shards to get to 1000 result.
> How many shards do you have?
>
> The expression you provided also didn't include the ClusterText field in
> field list of the search. So perhaps it's missing other parameters.
>
> If you include all the parameters I may be able to spot the issue.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Mon, Aug 14, 2017 at 10:10 PM, Joel Bernstein 
> wrote:
>
>> It looks like you just need to set the rows parameter in the search
>> expression. If you don't set rows the default will be 20 I believe, which
>> will pull to top 20 docs from each shard. If you have 5 shards than the
>> 1000 results would make sense.
>>
>> You can parallelize the whole expression by wrapping it in a parallel
>> expression. You'll need to set the partitionKeys in the search expression
>> to do this.
>>
>> If you have a large number of records to process I would recommend batch
>> processing. This blog explains the parallel batch framework:
>>
>> http://joelsolr.blogspot.com/2016/10/solr-63-batch-jobs-para
>> llel-etl-and.html
>>
>>
>>
>>
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Mon, Aug 14, 2017 at 7:53 PM, Joe Obernberger <
>> joseph.obernber...@gmail.com> wrote:
>>
>>> Hi All - I'm using the classify stream expression and the results
>>> returned are always limited to 1,000.  Where do I specify the number to
>>> return?  The stream expression that I'm using looks like:
>>>
>>> classify(model(models,id="MODEL1014",cacheMillis=5000),searc
>>> h(COL,df="FULL_DOCUMENT",q="Collection:(COLLECT2000) AND
>>> DocTimestamp:[2017-08-14T04:00:00Z TO 
>>> 2017-08-15T03:59:00Z]",fl="id,score",sort="id
>>> asc"),field="ClusterText")
>>>
>>> When I read this (code snipet):
>>>
>>>  stream.open();
>>> while (true) {
>>> Tuple tuple = stream.read();
>>> if (tuple.EOF) {
>>> break;
>>> }
>>> Double probabilty = (Double)
>>> tuple.fields.get("probability_d");
>>> String docID = (String) tuple.fields.get("id");
>>>
>>> I get back 1,000 results.  Another question is if there is a way to
>>> parallelize the classify call to other worker nodes?  Thank you!
>>>
>>> -Joe
>>>
>>>
>>
>

Time taken for CheckIndex on a core

[Shashank Pedamallu]

Hi,

I was looking for a reliable method to check if my core was in a consistent 
readable state and came across org.apache.lucene.index.CheckIndex class. 
However, when I tried to run this command multiple times from the command-line 
via the main utility method provided, it takes long time to run for the first 
time, while subsequent runs are much much faster. Can someone explain why this 
is? Does Solr/Lucene cache the results of CheckIndex? Note that the attempt 
runs are on the same core with same segments.

Here are the results from attempt 1:
 grep "check integrity" checkFastIndex70e0a5core7_a1.out
test: check integrity.OK [took 37.747 sec]
test: check integrity.OK [took 37.572 sec]
test: check integrity.OK [took 36.763 sec]
test: check integrity.OK [took 35.927 sec]
test: check integrity.OK [took 35.714 sec]
test: check integrity.OK [took 37.975 sec]
test: check integrity.OK [took 37.685 sec]
test: check integrity.OK [took 35.516 sec]
test: check integrity.OK [took 9.359 sec]
test: check integrity.OK [took 2.016 sec]
test: check integrity.OK [took 5.014 sec]
test: check integrity.OK [took 3.276 sec]
test: check integrity.OK [took 2.134 sec]
test: check integrity.OK [took 0.525 sec]
test: check integrity.OK [took 0.304 sec]
test: check integrity.OK [took 0.099 sec]
test: check integrity.OK [took 0.409 sec]
test: check integrity.OK [took 0.160 sec]
test: check integrity.OK [took 0.130 sec]
test: check integrity.OK [took 0.449 sec]
test: check integrity.OK [took 0.229 sec]
test: check integrity.OK [took 0.093 sec]
test: check integrity.OK [took 0.019 sec]
test: check integrity.OK [took 0.083 sec]
test: check integrity.OK [took 0.177 sec]
test: check integrity.OK [took 0.001 sec]
test: check integrity.OK [took 0.000 sec]
test: check integrity.OK [took 0.023 sec]
test: check integrity.OK [took 0.002 sec]
test: check integrity.OK [took 0.006 sec]
test: check integrity.OK [took 0.000 sec]

Results from attempt 2:
grep "check integrity" checkFastIndex70e0a5core7_a2.out
test: check integrity.OK [took 1.904 sec]
test: check integrity.OK [took 1.785 sec]
test: check integrity.OK [took 1.704 sec]
test: check integrity.OK [took 1.594 sec]
test: check integrity.OK [took 1.338 sec]
test: check integrity.OK [took 1.414 sec]
test: check integrity.OK [took 1.490 sec]
test: check integrity.OK [took 1.291 sec]
test: check integrity.OK [took 0.366 sec]
test: check integrity.OK [took 0.072 sec]
test: check integrity.OK [took 0.183 sec]
test: check integrity.OK [took 0.175 sec]
test: check integrity.OK [took 0.072 sec]
test: check integrity.OK [took 0.020 sec]
test: check integrity.OK [took 0.012 sec]
test: check integrity.OK [took 0.004 sec]
test: check integrity.OK [took 0.028 sec]
test: check integrity.OK [took 0.009 sec]
test: check integrity.OK [took 0.007 sec]
test: check integrity.OK [took 0.021 sec]
test: check integrity.OK [took 0.013 sec]
test: check integrity.OK [took 0.005 sec]
test: check integrity.OK [took 0.001 sec]
test: check integrity.OK [took 0.004 sec]
test: check integrity.OK [took 0.006 sec]
test: check integrity.OK [took 0.000 sec]
test: check integrity.OK [took 0.000 sec]
test: check integrity.OK [took 0.001 sec]
test: check integrity.OK [took 0.000 sec]
test: check integrity.OK [took 0.000 sec]
test: check integrity.OK [took 0.000 sec]

This probably falls under lucene code, so, please let me know if I have to post 
it in lucene group for an answer.

Thanks,
Shashank

Re: Classify stream expression questions

[Joel Bernstein]

Actually my math was off. You would need 200 shards to get to 1000 result.
How many shards do you have?

The expression you provided also didn't include the ClusterText field in
field list of the search. So perhaps it's missing other parameters.

If you include all the parameters I may be able to spot the issue.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 10:10 PM, Joel Bernstein  wrote:

> It looks like you just need to set the rows parameter in the search
> expression. If you don't set rows the default will be 20 I believe, which
> will pull to top 20 docs from each shard. If you have 5 shards than the
> 1000 results would make sense.
>
> You can parallelize the whole expression by wrapping it in a parallel
> expression. You'll need to set the partitionKeys in the search expression
> to do this.
>
> If you have a large number of records to process I would recommend batch
> processing. This blog explains the parallel batch framework:
>
> http://joelsolr.blogspot.com/2016/10/solr-63-batch-jobs-
> parallel-etl-and.html
>
>
>
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Mon, Aug 14, 2017 at 7:53 PM, Joe Obernberger <
> joseph.obernber...@gmail.com> wrote:
>
>> Hi All - I'm using the classify stream expression and the results
>> returned are always limited to 1,000.  Where do I specify the number to
>> return?  The stream expression that I'm using looks like:
>>
>> classify(model(models,id="MODEL1014",cacheMillis=5000),searc
>> h(COL,df="FULL_DOCUMENT",q="Collection:(COLLECT2000) AND
>> DocTimestamp:[2017-08-14T04:00:00Z TO 
>> 2017-08-15T03:59:00Z]",fl="id,score",sort="id
>> asc"),field="ClusterText")
>>
>> When I read this (code snipet):
>>
>>  stream.open();
>> while (true) {
>> Tuple tuple = stream.read();
>> if (tuple.EOF) {
>> break;
>> }
>> Double probabilty = (Double)
>> tuple.fields.get("probability_d");
>> String docID = (String) tuple.fields.get("id");
>>
>> I get back 1,000 results.  Another question is if there is a way to
>> parallelize the classify call to other worker nodes?  Thank you!
>>
>> -Joe
>>
>>
>

Re: Classify stream expression questions

[Joel Bernstein]

It looks like you just need to set the rows parameter in the search
expression. If you don't set rows the default will be 20 I believe, which
will pull to top 20 docs from each shard. If you have 5 shards than the
1000 results would make sense.

You can parallelize the whole expression by wrapping it in a parallel
expression. You'll need to set the partitionKeys in the search expression
to do this.

If you have a large number of records to process I would recommend batch
processing. This blog explains the parallel batch framework:

http://joelsolr.blogspot.com/2016/10/solr-63-batch-jobs-parallel-etl-and.html






Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Aug 14, 2017 at 7:53 PM, Joe Obernberger <
joseph.obernber...@gmail.com> wrote:

> Hi All - I'm using the classify stream expression and the results returned
> are always limited to 1,000.  Where do I specify the number to return?  The
> stream expression that I'm using looks like:
>
> classify(model(models,id="MODEL1014",cacheMillis=5000),searc
> h(COL,df="FULL_DOCUMENT",q="Collection:(COLLECT2000) AND
> DocTimestamp:[2017-08-14T04:00:00Z TO 
> 2017-08-15T03:59:00Z]",fl="id,score",sort="id
> asc"),field="ClusterText")
>
> When I read this (code snipet):
>
>  stream.open();
> while (true) {
> Tuple tuple = stream.read();
> if (tuple.EOF) {
> break;
> }
> Double probabilty = (Double) tuple.fields.get("probability_
> d");
> String docID = (String) tuple.fields.get("id");
>
> I get back 1,000 results.  Another question is if there is a way to
> parallelize the classify call to other worker nodes?  Thank you!
>
> -Joe
>
>

Re: RE: Comparison of Solr with Sharepoint Search

[Ahmet Arslan]

Hi,
https://manifoldcf.apache.org is used to crawl content from SharePoint and 
index into Solr.

Ahmet


On Monday, August 14, 2017, 9:05:20 PM GMT+3, jmahuang  
wrote:


Sir,

Can SOLR search existing SharePoint document libraries and lists?

Thanks!



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350502.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Comparison of Solr with Sharepoint Search

[Rick Leir]

To get the content into Solr, you need to configure the SharePoint crawler and 
content processor so that your custom script gets called (I think that is 
possible, but have never done it). The script needs to post the content of each 
page to the Solr RESTful interface.

On August 14, 2017 2:10:40 PM EDT, John Bickerstaff  
wrote:
>Anything that Solr searches must exist in the Solr index.
>
>You could do it, but you'd need to get those documents into Solr
>"format"
>and indexed by Solr...  Then you could return results that include a
>link
>to the actual doc in SharePoint.
>
>On Mon, Aug 14, 2017 at 11:08 AM, jmahuang 
>wrote:
>
>> Sir,
>>
>> Can SOLR search existing SharePoint document libraries and lists?
>>
>> Thanks!
>>
>>
>>
>> --
>> View this message in context: http://lucene.472066.n3.
>>
>nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350502.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

Classify stream expression questions

[Joe Obernberger]

Hi All - I'm using the classify stream expression and the results 
returned are always limited to 1,000.  Where do I specify the number to 
return?  The stream expression that I'm using looks like:


classify(model(models,id="MODEL1014",cacheMillis=5000),search(COL,df="FULL_DOCUMENT",q="Collection:(COLLECT2000) 
AND DocTimestamp:[2017-08-14T04:00:00Z TO 
2017-08-15T03:59:00Z]",fl="id,score",sort="id asc"),field="ClusterText")


When I read this (code snipet):

 stream.open();
while (true) {
Tuple tuple = stream.read();
if (tuple.EOF) {
break;
}
Double probabilty = (Double) 
tuple.fields.get("probability_d");

String docID = (String) tuple.fields.get("id");

I get back 1,000 results.  Another question is if there is a way to 
parallelize the classify call to other worker nodes?  Thank you!


-Joe

Re: Comparison of Solr with Sharepoint Search

[obat wanita]

http://jualobatcytoteclegal.com/jual...aborsi-malang/
Sepertinya setelah sekian lama anda mencari informasi tentang itu, baru hari
ini anda menemukan web kami ini.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350516.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Comparison of Solr with Sharepoint Search

[John Bickerstaff]

Anything that Solr searches must exist in the Solr index.

You could do it, but you'd need to get those documents into Solr "format"
and indexed by Solr...  Then you could return results that include a link
to the actual doc in SharePoint.

On Mon, Aug 14, 2017 at 11:08 AM, jmahuang  wrote:

> Sir,
>
> Can SOLR search existing SharePoint document libraries and lists?
>
> Thanks!
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
> nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350502.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Re: Comparison of Solr with Sharepoint Search

[jmahuang]

Hoss,

Sorry I cannot open these links:

http://old.nabble.com/SOLR-X-FAST-to14284618.html
http://old.nabble.com/Replacing-FAST-functionality-at-sesam.no-td19186109.html
http://old.nabble.com/Experiences-from-migrating-from-FAST-to-Solr-td26371613.html
http://sesat.no/moving-from-fast-to-solr-review.html

Would you please tell me their current URL?

Thanks!



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350501.html
Sent from the Solr - User mailing list archive at Nabble.com.

RE: Comparison of Solr with Sharepoint Search

[jmahuang]

Sir,

Can SOLR search existing SharePoint document libraries and lists?

Thanks!



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Comparison-of-Solr-with-Sharepoint-Search-tp498534p4350502.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Unable to write response, client closed connection or we are shutting down

[Rick Leir]

Nawab
What test software do you use? What else is happening when the exception occurs?
Cheers -- Rick

On August 12, 2017 1:48:19 PM EDT, Nawab Zada Asad Iqbal  
wrote:
>Hi,
>
>I am executing a query performance test against my solr 6.6 setup and I
>noticed following exception every now and then. What do I need to do?
>
>Aug 11, 2017 08:40:07 AM INFO  (qtp761960786-250) [   x:filesearch]
>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:199)
>at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:420)
>at org.eclipse.jetty.io.WriteFlusher.completeWrite(
>WriteFlusher.java:375)
>at org.eclipse.jetty.io.SelectChannelEndPoint$3.run(
>SelectChannelEndPoint.java:107)
>at org.eclipse.jetty.io.SelectChannelEndPoint.onSelected(
>SelectChannelEndPoint.java:193)
>at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.
>processSelected(ManagedSelector.java:283)
>at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(
>ManagedSelector.java:181)
>at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
>executeProduceConsume(ExecuteProduceConsume.java:249)
>at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.
>produceConsume(ExecuteProduceConsume.java:148)
>   at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(
>ExecuteProduceConsume.java:136)
>at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
>QueuedThreadPool.java:671)
>at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(
>QueuedThreadPool.java:589)
>at java.lang.Thread.run(Thread.java:748)
>Caused by: java.io.IOException: Broken pipe
>at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
>at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
>at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
>at sun.nio.ch.IOUtil.write(IOUtil.java:51)
>at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
>at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:177)
>
>
>
>Apart from that, I also noticed that the query response time is longer
>than
>I expected, while the memory utilization stays <= 35%. I thought that
>somewhere I have set maxThreads (Jetty) to a very low number, however I
>am
>falling back on default which is 1 (so that shouldn't be a
>problem).
>
>
>Thanks
>Nawab

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

RE: 6.6.0 getNumShards() NPE?!

[Markus Jelsma]

Sure!

Any plugin that has SolrCore has the problem, a RequestHandler for example:

  public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) 
throws Exception {
LOG.info("numShards: "+ 
core.getCoreDescriptor().getCloudDescriptor().getNumShards());
  }

2017-08-14 15:20:54.995 INFO  (qtp475266352-20) [c:logs s:shard1 r:core_node3 
x:collection1_shard1_replica2] i.o.l.h.CacheHandler numShards: null
2017-08-14 15:20:58.753 INFO  (qtp475266352-15) [c:logs s:shard1 r:core_node2 
x:collection1_shard1_replica1] i.o.l.h.CacheHandler numShards: 2
2017-08-14 15:24:43.589 INFO  (qtp475266352-237) [c:logs s:shard2 r:core_node1 
x:logs_shard2_replica1] i.o.l.h.CheckerCacheHandler numShards: 2
2017-08-14 15:24:57.446 INFO  (qtp475266352-21) [c:logs s:shard2 r:core_node4 
x:logs_shard2_replica2] i.o.l.h.CheckerCacheHandler numShards: null

The problem is very consistent.

Thanks,
Markus
 
-Original message-
> From:Shalin Shekhar Mangar 
> Sent: Monday 14th August 2017 15:13
> To: solr-user@lucene.apache.org
> Subject: Re: 6.6.0 getNumShards() NPE?!
> 
> Can you please post the steps to reproduce this?
> 
> On Thu, Aug 10, 2017 at 4:12 PM, Markus Jelsma
>  wrote:
> > I can now reproduce it on the two shard, two replica cluster.
> >
> > It does NOT happen on the collection_shard1_replica1 and 
> > collection_shard2_replica1 nodes.
> >
> > It happens consistently on the collection_shard1_replica2 and 
> > collection_shard2_replica2 nodes.
> >
> > Any ideas?
> >
> > -Original message-
> >> From:Markus Jelsma 
> >> Sent: Thursday 10th August 2017 12:34
> >> To: Solr-user 
> >> Subject: 6.6.0 getNumShards() NPE?!
> >>
> >> Hello,
> >>
> >> Having trouble, again, with CloudDescriptor and friend, getting the number 
> >> of shards of the collection. It sometimes returns 1 for a collection of 
> >> two shards. Having this code:
> >>
> >>   cloudDescriptor = core.getCoreDescriptor().getCloudDescriptor();
> >>   return cloudDescriptor.getNumShards();
> >>
> >> In some cases cloudDescriptor.getNumShards() throws an NPE. Am i doing 
> >> something wrong?
> >>
> >> Thanks,
> >> Markus
> >>
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 

Re: ConcurrentUpdateSolrClient example?

[Jason Gerlowski]

Ah, glad you figured it out.  And thanks for the clarification.  That
does look like something that could/should be improved though.
QueueSize could be given a reasonable (and documented) default, to
save people from the IAE.  I'll take a look this afternoon and create
a JIRA if there's not a rationale behind this (which there might be).

On Mon, Aug 14, 2017 at 2:23 AM, Paul Smith Parker
 wrote:
> Hello Jason,
>
> I figured it out:
>
> 1) ConcurrentUpdateSolrClient build = new 
> ConcurrentUpdateSolrClient.Builder("http://localhost:8389/solr/core;).build();
> 2) ConcurrentUpdateSolrClient build = new 
> ConcurrentUpdateSolrClient.Builder("http://localhost:8389/solr/core;)
> .withQueueSize(20)
> .build();
>
> 1) fails with an IllegalArgumentException due to the fact the the queue size 
> is not specified.
> 2) works as expected.
>
> Cheers,
> P.
>
>> On 13 Aug 2017, at 22:58, Jason Gerlowski  wrote:
>>
>> Hi Paul,
>>
>> I'll try reproducing this with the snippet provided, but I don't see
>> anything inherently wrong with the Builder usage you mentioned, assuming
>> the Solr base URL you provided is correct.
>>
>> It would be easier to troubleshoot your issue though if you included some
>> more information about the NPE you're seeing. Could you post the stacktrace
>> to help others investigate please?
>>
>> Best,
>>
>> Jason
>>
>> On Aug 13, 2017 5:43 AM, "Paul Smith Parker" 
>> wrote:
>>
>>> Hello,
>>>
>>> I can’t find an example on how to properly instantiate/configure an
>>> instance of ConcurrentUpdateSolrClient.
>>>
>>> I tried this but it gives me a NPE:
>>>
>>> ConcurrentUpdateSolrClient solrClient = new ConcurrentUpdateSolrClient.
>>> Builder(“http://localhost:8389/solr /
>>> core").build();
>>>
>>> While this seems to work (it should use an internal httpClient):
>>> ConcurrentUpdateSolrClient solrClient = new ConcurrentUpdateSolrClient.
>>> Builder(“http://localhost:8389/solr /core")
>>>.withHttpClient(null)
>>>.withQueueSize(1000)
>>>.withThreadCount(20)
>>>.build();
>>>
>>> Is this the correct way to set it up?
>>>
>>> Thanks,
>>> P.
>

Re: 6.6.0 getNumShards() NPE?!

[Shalin Shekhar Mangar]

Can you please post the steps to reproduce this?

On Thu, Aug 10, 2017 at 4:12 PM, Markus Jelsma
 wrote:
> I can now reproduce it on the two shard, two replica cluster.
>
> It does NOT happen on the collection_shard1_replica1 and 
> collection_shard2_replica1 nodes.
>
> It happens consistently on the collection_shard1_replica2 and 
> collection_shard2_replica2 nodes.
>
> Any ideas?
>
> -Original message-
>> From:Markus Jelsma 
>> Sent: Thursday 10th August 2017 12:34
>> To: Solr-user 
>> Subject: 6.6.0 getNumShards() NPE?!
>>
>> Hello,
>>
>> Having trouble, again, with CloudDescriptor and friend, getting the number 
>> of shards of the collection. It sometimes returns 1 for a collection of two 
>> shards. Having this code:
>>
>>   cloudDescriptor = core.getCoreDescriptor().getCloudDescriptor();
>>   return cloudDescriptor.getNumShards();
>>
>> In some cases cloudDescriptor.getNumShards() throws an NPE. Am i doing 
>> something wrong?
>>
>> Thanks,
>> Markus
>>



-- 
Regards,
Shalin Shekhar Mangar.

Re: ConcurrentUpdateSolrClient example?

[Paul Smith Parker]

Hello Jason,

I figured it out:

1) ConcurrentUpdateSolrClient build = new 
ConcurrentUpdateSolrClient.Builder("http://localhost:8389/solr/core;).build();
2) ConcurrentUpdateSolrClient build = new 
ConcurrentUpdateSolrClient.Builder("http://localhost:8389/solr/core;)
.withQueueSize(20)
.build();

1) fails with an IllegalArgumentException due to the fact the the queue size is 
not specified.
2) works as expected.

Cheers,
P.

> On 13 Aug 2017, at 22:58, Jason Gerlowski  wrote:
> 
> Hi Paul,
> 
> I'll try reproducing this with the snippet provided, but I don't see
> anything inherently wrong with the Builder usage you mentioned, assuming
> the Solr base URL you provided is correct.
> 
> It would be easier to troubleshoot your issue though if you included some
> more information about the NPE you're seeing. Could you post the stacktrace
> to help others investigate please?
> 
> Best,
> 
> Jason
> 
> On Aug 13, 2017 5:43 AM, "Paul Smith Parker" 
> wrote:
> 
>> Hello,
>> 
>> I can’t find an example on how to properly instantiate/configure an
>> instance of ConcurrentUpdateSolrClient.
>> 
>> I tried this but it gives me a NPE:
>> 
>> ConcurrentUpdateSolrClient solrClient = new ConcurrentUpdateSolrClient.
>> Builder(“http://localhost:8389/solr /
>> core").build();
>> 
>> While this seems to work (it should use an internal httpClient):
>> ConcurrentUpdateSolrClient solrClient = new ConcurrentUpdateSolrClient.
>> Builder(“http://localhost:8389/solr /core")
>>.withHttpClient(null)
>>.withQueueSize(1000)
>>.withThreadCount(20)
>>.build();
>> 
>> Is this the correct way to set it up?
>> 
>> Thanks,
>> P.