date:20200316

msokolov commented on issue #1316: LUCENE-8929 parallel early termination in 
TopFieldCollector using minmin score
URL: https://github.com/apache/lucene-solr/pull/1316#issuecomment-599479702
 
 
   > I think it would be preferrable to specialize at this point. What do you 
think ?
   
   I tried this out, and although there is some duplication, it is much easier 
to read now - thanks for the idea! I also found a bunch of edge cases while 
doing some deeper testing, and cleaned up the code in IndexSearcher that 
creates the collector managers. Performance improvements are basically 
unchanged; maybe a bit better. I'll post numbers in the JIRA. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8929) Early Terminating CollectorManager

2020-03-16 Thread Michael Sokolov (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060133#comment-17060133
 ] 

Michael Sokolov commented on LUCENE-8929:
-

> . Having different strategies to sort the leaves and to set the number of 
> threads could be dependent on the data and top N size for instance. 

Agreed, different strategies win in different situations. In our case, 
insertion order is not usually correlated with index sort order, although maybe 
we can have some influence there and use the segment-sorting idea + 
single-threaded search, however when indexing is in more-or-less random order, 
I think this approach gets you better latency at some cost to throughput. 

> This makes me wonder where the gains are coming from ?

When it is successful, we collect only the hits we need plus a small buffer 
from each segment, and we do them in parallel, so latency is reduced. 

Latest patch here has the side effect of cleaning up the branching logic in 
IndexSearcher where we choose a strategy, but I realized this is not available 
anywhere else we also use these collectors, nor easily to users specializing 
IndexSearcher's behavior. If we get enough strategies here we may want to 
abstract into a query planner at some point.

Updated perf stats from the patch:

h3. N=10
|| Task||  QPS before||  StdDev||   QPS after||  
StdDev||Pct diff||
|   LowTermLastModSort| 2205.95|  (7.0%)| 2181.02  |(2.5%)| 
  -1.1% (  -9% -8%)|
|  HighTermLastModSort| 1167.99|  (1.2%)| 1274.97  |(1.2%)| 
   9.2% (   6% -   11%)|
|HighTermDayOfYearSort| 1972.26|  (0.8%)| 1987.16  |(0.7%)| 
   0.8% (   0% -2%)|
| LowTermDayOfYearSort|  649.64|  (0.7%)|  669.05  |(2.5%)| 
   3.0% (   0% -6%)|

h3. N=20
|| Task||  QPS before||  StdDev||   QPS after||  
StdDev||Pct diff||
|  LowTermLastModSort| 2239.97|  (8.2%)| 2288.43  |(7.8%)|  
  2.2% ( -12% -   19%)|
|  HighTermLastModSort| 1097.37|  (1.0%)| 1190.45  |(1.4%)| 
   8.5% (   5% -   11%)|

h3. N=100
|| Task||  QPS before||  StdDev||   QPS after||  
StdDev||Pct diff||
| HighTermLastModSort|  847.34|  (1.2%)|  978.83  |(1.6%)|  
 15.5% (  12% -   18%)|
|  LowTermLastModSort| 1540.43|  (4.0%)| 1807.39  |(3.9%)|  
 17.3% (   9% -   26%)|
|LowTermDayOfYearSort|  621.57|  (2.7%)|  656.28  |(1.9%)|  
  5.6% (   0% -   10%)|
|   HighTermDayOfYearSort| 1497.62|  (1.0%)| 1617.08  |(0.9%)|  
  8.0% (   6% -9%)|

h3. N=500
|| Task||  QPS before||  StdDev||   QPS after||  
StdDev||Pct diff||
| HighTermLastModSort|  409.67|  (3.7%)|  825.41  |(2.0%)|  
101.5% (  92% -  111%)|
|  LowTermLastModSort|  555.95|  (7.5%)| 1412.98 |(12.6%)|  
154.2% ( 124% -  188%)|
|LowTermDayOfYearSort|  417.82|  (3.5%)|  653.06 |(10.9%)|  
 56.3% (  40% -   73%)|
|   HighTermDayOfYearSort|  498.74|  (5.8%)| 1044.63 |(22.4%)|  
109.5% (  76% -  146%) |

Note: in all cases the tests were done with the index sorted according to the 
search criterion (these show tests against two different indexes)



> Early Terminating CollectorManager
> --
>
> Key: LUCENE-8929
> URL: https://issues.apache.org/jira/browse/LUCENE-8929
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Atri Sharma
>Priority: Major
>  Time Spent: 7.5h
>  Remaining Estimate: 0h
>
> We should have an early terminating collector manager which accurately tracks 
> hits across all of its collectors and determines when there are enough hits, 
> allowing all the collectors to abort.
> The options for the same are:
> 1) Shared total count : Global "scoreboard" where all collectors update their 
> current hit count. At the end of each document's collection, collector checks 
> if N > threshold, and aborts if true
> 2) State Reporting Collectors: Collectors report their total number of counts 
> collected periodically using a callback mechanism, and get a proceed or abort 
> decision.
> 1) has the overhead of synchronization in the hot path, 2) can collect 
> unnecessary hits before aborting.
> I am planning to work on 2), unless objections



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path

2020-03-16 Thread Tomoko Uchida (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060134#comment-17060134
 ] 

Tomoko Uchida commented on LUCENE-9278:
---

{quote}You can't have circular classpath references though so this "clean" way 
of referencing classes can't be used to link up submodules in our case.
{quote}
Yes, the hard-coded relative path (from "core" to child modules) I mentioned 
above seems to be a trick to make backward direction links that can't be 
represented with @link tag of course.

 

> Make javadoc folder structure follow Gradle project path
> 
>
> Key: LUCENE-9278
> URL: https://issues.apache.org/jira/browse/LUCENE-9278
> Project: Lucene - Core
>  Issue Type: Task
>  Components: general/build
>Reporter: Tomoko Uchida
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Current javadoc folder structure is derived from Ant project name. e.g.:
> [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html]
>  [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html]
> For Gradle build, it should also follow gradle project structure (path) 
> instead of ant one, to keep things simple to manage [1]. Hence, it will look 
> like this:
> [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html]
>  [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html]
> [1] The change was suggested at the conversation between Dawid Weiss and I on 
> a github pr: [https://github.com/apache/lucene-solr/pull/1304]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija merged pull request #1349: Document sort param tiebreak logic

gerlowskija merged pull request #1349: Document sort param tiebreak logic
URL: https://github.com/apache/lucene-solr/pull/1349
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] uschindler commented on issue #1349: Document sort param tiebreak logic

uschindler commented on issue #1349: Document sort param tiebreak logic
URL: https://github.com/apache/lucene-solr/pull/1349#issuecomment-599503010
 
 
   This is specially important for search-after cursors, so maybe we should 
mention this, too!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14337) SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF files

Alexandru Corghencea created SOLR-14337:
---

 Summary: SOLR 8.0 NoClassDefFoundError when change schema and 
index MSOffice and PDF files
 Key: SOLR-14337
 URL: https://issues.apache.org/jira/browse/SOLR-14337
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 8.1, 8.0
Reporter: Alexandru Corghencea


After a schema change, just added a new field in a document and indexing 
documents throws *NoClassDefFoundError* practically for every document MS 
office or PDF that worked before schema change. This error comes out as:
 
"ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr: Expected mime type 
application/octet-stream but got text/html."

 

with {{"Error 500 Server Error".}}

{{}}
 * Linux Ubuntu 18.04
 * Solr 8.0.0
 * Java Oracle 1.8.

{{}}

This happens only at our project version release :)

{{}}

already tried:

{{}}
 * reload core
 * reboot server
 * delete and re-index all

{{}}

Server has enough disk space. Cpu and memory still has reserves during indexing.

{{}}

Maybe there are some temporary junk files left in "data" folder, or elsewhere. 
Or maybe the core gets corrupted after changing schema but it should get 
cleaned when reloaded.
 
{{2019-11-08 20:05:41 ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index 
file
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr: Expected mime type 
application/octet-stream but got text/html. Error 500 
Server ErrorHTTP ERROR 500Problem accessing 
/solr/document/update/extract. Reason:Server ErrorCaused 
by:java.lang.NoClassDefFoundError: Could not initialize class 
javax.imageio.ImageIOat 
org.apache.tika.parser.image.ImageParser.parse(ImageParser.java:177)at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)   
 at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
at org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72)  
  at 
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
at 
org.apache.tika.extractor.EmbeddedDocumentUtil.parseEmbedded(EmbeddedDocumentUtil.java:220)
at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:124)
at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:100)
at 
org.apache.tika.parser.microsoft.WordExtractor.handlePictureCharacterRun(WordExtractor.java:640)
at 
org.apache.tika.parser.microsoft.WordExtractor.handleParagraph(WordExtractor.java:367)
at 
org.apache.tika.parser.microsoft.WordExtractor.handleHeaderFooter(WordExtractor.java:259)
at 
org.apache.tika.parser.microsoft.WordExtractor.parse(WordExtractor.java:182)
at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:175)  
  at org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131) 
   at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)
at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280)   
 at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143)
at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516)at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)  
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)   
 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.nex

[jira] [Updated] (SOLR-14337) SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF files



 [ 
https://issues.apache.org/jira/browse/SOLR-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandru Corghencea updated SOLR-14337:

Description: 
After a schema change, just added a new field in a document and indexing 
documents throws *NoClassDefFoundError* practically for every document MS 
office or PDF that worked before schema change. This error comes out as:
  
"ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html."

 with "Error 500 Server Error".


 * Linux Ubuntu 18.04
 * Solr 8.0.0
 * Java Oracle 1.8.


This happens only at our project version release :)

{

already tried:

 * reload core
 * reboot server
 * delete and re-index all

Server has enough disk space. Cpu and memory still has reserves during indexing.

Maybe there are some temporary junk files left in "data" folder, or elsewhere. 
Or maybe the core gets corrupted after changing schema but it should get 
cleaned when reloaded.
  

2019-11-08 20:05:41 ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html. Error 500 
Server ErrorHTTP ERROR 500Problem accessing 
/solr/document/update/extract. Reason: Server ErrorCaused 
by:java.lang.NoClassDefFoundError: Could not initialize class 
javax.imageio.ImageIO at 
org.apache.tika.parser.image.ImageParser.parse(ImageParser.java:177) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72) at 
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
 at 
org.apache.tika.extractor.EmbeddedDocumentUtil.parseEmbedded(EmbeddedDocumentUtil.java:220)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:124)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:100)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handlePictureCharacterRun(WordExtractor.java:640)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleParagraph(WordExtractor.java:367)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleHeaderFooter(WordExtractor.java:259)
 at 
org.apache.tika.parser.microsoft.WordExtractor.parse(WordExtractor.java:182) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:175) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
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:257)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScop

[jira] [Updated] (SOLR-14337) SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF files



 [ 
https://issues.apache.org/jira/browse/SOLR-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandru Corghencea updated SOLR-14337:

Description: 
After a schema change, just added a new field in a document and indexing 
documents throws *NoClassDefFoundError* practically for every document MS 
office or PDF that worked before schema change. This error comes out as:
  
{{"ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html."}}

 with "Error 500 Server Error".
 * Linux Ubuntu 18.04
 * Solr 8.0.0
 * Java Oracle 1.8.


This happens only at our project version release :)
already tried:

 * reload core
 * reboot server
 * delete and re-index all

Server has enough disk space. Cpu and memory still has reserves during indexing.

Maybe there are some temporary junk files left in "data" folder, or elsewhere. 
Or maybe the core gets corrupted after changing schema but it should get 
cleaned when reloaded.
  

{{2019-11-08 20:05:41 ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index 
file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html. Error 500 
Server ErrorHTTP ERROR 500Problem accessing 
/solr/document/update/extract. Reason: Server ErrorCaused 
by:java.lang.NoClassDefFoundError: Could not initialize class 
javax.imageio.ImageIO at 
org.apache.tika.parser.image.ImageParser.parse(ImageParser.java:177) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72) at 
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
 at 
org.apache.tika.extractor.EmbeddedDocumentUtil.parseEmbedded(EmbeddedDocumentUtil.java:220)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:124)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:100)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handlePictureCharacterRun(WordExtractor.java:640)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleParagraph(WordExtractor.java:367)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleHeaderFooter(WordExtractor.java:259)
 at 
org.apache.tika.parser.microsoft.WordExtractor.parse(WordExtractor.java:182) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:175) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
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:257)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextSco

[jira] [Updated] (SOLR-14337) SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF files



 [ 
https://issues.apache.org/jira/browse/SOLR-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandru Corghencea updated SOLR-14337:

Description: 
After a schema change, just added a new field in a document and indexing 
documents throws *NoClassDefFoundError* practically for every document MS 
office or PDF that worked before schema change. This error comes out as:
  
{{"ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html."}}

 with "Error 500 Server Error".
 * Linux Ubuntu 18.04
 * Solr 8.0.0
 * Java Oracle 1.8.


This happens only at our project version release :)
already tried:

 * reload core
 * reboot server
 * delete and re-index all

Server has enough disk space. Cpu and memory still has reserves during indexing.

Maybe there are some temporary junk files left in "data" folder, or elsewhere. 
Or maybe the core gets corrupted after changing schema but it should get 
cleaned when reloaded.
  

{{2019-11-08 20:05:41 ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index 
file
 org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at [http://localhost:8983/solr:] Expected mime type 
application/octet-stream but got text/html. Error 500 
Server ErrorHTTP ERROR 500Problem accessing 
/solr/document/update/extract. Reason: Server ErrorCaused 
by:java.lang.NoClassDefFoundError: Could not initialize class 
javax.imageio.ImageIO at 
org.apache.tika.parser.image.ImageParser.parse(ImageParser.java:177) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72) at 
org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
 at 
org.apache.tika.extractor.EmbeddedDocumentUtil.parseEmbedded(EmbeddedDocumentUtil.java:220)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:124)
 at 
org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:100)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handlePictureCharacterRun(WordExtractor.java:640)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleParagraph(WordExtractor.java:367)
 at 
org.apache.tika.parser.microsoft.WordExtractor.handleHeaderFooter(WordExtractor.java:259)
 at 
org.apache.tika.parser.microsoft.WordExtractor.parse(WordExtractor.java:182) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:175) at 
org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
 at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559) at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:516) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
 at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) 
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:257)
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
 at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) 
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextSco

[jira] [Resolved] (SOLR-14337) SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF files



 [ 
https://issues.apache.org/jira/browse/SOLR-14337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-14337.
---
Resolution: Not A Problem

99% certain it's one of two things:

1> there's a Tika jar that, for some reason, we couldn't distribute to Solr

2> this error is misleading, sometimes by the time it gets back to the client 
it's munged.

There also might be clues in your Solr log file prior to the stack trace.

I'd look on the Tika site for clues as well.

 

Also, in future, please raise questions like this on the user's list first, the 
Jira is not a support portal. If it's determined that this is really a code 
issue, we can re-open this Jira or raise a new one.

> SOLR 8.0 NoClassDefFoundError when change schema and index MSOffice and PDF 
> files
> -
>
> Key: SOLR-14337
> URL: https://issues.apache.org/jira/browse/SOLR-14337
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 8.0, 8.1
>Reporter: Alexandru Corghencea
>Priority: Major
>
> After a schema change, just added a new field in a document and indexing 
> documents throws *NoClassDefFoundError* practically for every document MS 
> office or PDF that worked before schema change. This error comes out as:
>   
> {{"ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index file
>  org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at [http://localhost:8983/solr:] Expected mime type 
> application/octet-stream but got text/html."}}
>  with "Error 500 Server Error".
>  * Linux Ubuntu 18.04
>  * Solr 8.0.0
>  * Java Oracle 1.8.
> This happens only at our project version release :)
> already tried:
>  * reload core
>  * reboot server
>  * delete and re-index all
> Server has enough disk space. Cpu and memory still has reserves during 
> indexing.
> Maybe there are some temporary junk files left in "data" folder, or 
> elsewhere. Or maybe the core gets corrupted after changing schema but it 
> should get cleaned when reloaded.
>   
> {{2019-11-08 20:05:41 ERROR d.t.d.d.b.d.SolrRequestExecutor - Failed to index 
> file
>  org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at [http://localhost:8983/solr:] Expected mime type 
> application/octet-stream but got text/html.  http-equiv="Content-Type" content="text/html;charset=utf-8"/>Error 500 
> Server ErrorHTTP ERROR 500Problem accessing 
> /solr/document/update/extract. Reason: Server ErrorCaused 
> by:java.lang.NoClassDefFoundError: Could not initialize class 
> javax.imageio.ImageIO at 
> org.apache.tika.parser.image.ImageParser.parse(ImageParser.java:177) at 
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
> org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
> org.apache.tika.parser.DelegatingParser.parse(DelegatingParser.java:72) at 
> org.apache.tika.extractor.ParsingEmbeddedDocumentExtractor.parseEmbedded(ParsingEmbeddedDocumentExtractor.java:102)
>  at 
> org.apache.tika.extractor.EmbeddedDocumentUtil.parseEmbedded(EmbeddedDocumentUtil.java:220)
>  at 
> org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:124)
>  at 
> org.apache.tika.parser.microsoft.AbstractPOIFSExtractor.handleEmbeddedResource(AbstractPOIFSExtractor.java:100)
>  at 
> org.apache.tika.parser.microsoft.WordExtractor.handlePictureCharacterRun(WordExtractor.java:640)
>  at 
> org.apache.tika.parser.microsoft.WordExtractor.handleParagraph(WordExtractor.java:367)
>  at 
> org.apache.tika.parser.microsoft.WordExtractor.handleHeaderFooter(WordExtractor.java:259)
>  at 
> org.apache.tika.parser.microsoft.WordExtractor.parse(WordExtractor.java:182) 
> at org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:175) 
> at org.apache.tika.parser.microsoft.OfficeParser.parse(OfficeParser.java:131) 
> at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:280) at 
> org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:143) at 
> org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:228)
>  at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559) at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711) at 
> org.apach

[GitHub] [lucene-solr] arysin opened a new pull request #1355: LUCENE-9279: Update dictionary version for Ukrainian analyzer

arysin opened a new pull request #1355: LUCENE-9279: Update dictionary version 
for Ukrainian analyzer
URL: https://github.com/apache/lucene-solr/pull/1355
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0

2020-03-16 Thread Andriy Rysin (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060250#comment-17060250
 ] 

Andriy Rysin commented on LUCENE-9279:
--

I've created pull for CHANGES.txt:
https://github.com/apache/lucene-solr/pull/1355





> Update dictionary version for Ukrainian analyzer to 4.9.0
> -
>
> Key: LUCENE-9279
> URL: https://issues.apache.org/jira/browse/LUCENE-9279
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer.
> There's about 80k of new lemmas



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] arysin opened a new pull request #1356: LUCENE-9279: Update dictionary version for Ukrainian analyzer

arysin opened a new pull request #1356: LUCENE-9279: Update dictionary version 
for Ukrainian analyzer
URL: https://github.com/apache/lucene-solr/pull/1356
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0

2020-03-16 Thread Andriy Rysin (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060258#comment-17060258
 ] 

Andriy Rysin commented on LUCENE-9279:
--

Good idea, I've created pull request for 8x as well

> Update dictionary version for Ukrainian analyzer to 4.9.0
> -
>
> Key: LUCENE-9279
> URL: https://issues.apache.org/jira/browse/LUCENE-9279
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer.
> There's about 80k of new lemmas



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] gerlowskija commented on issue #1349: Document sort param tiebreak logic

gerlowskija commented on issue #1349: Document sort param tiebreak logic
URL: https://github.com/apache/lucene-solr/pull/1349#issuecomment-599572742
 
 
   I can imagine how this would be an issue in that context but I haven't seen 
it specifically so I'm a little leery of drafting language that might not be 
100% correct.
   
   If you have language you can suggest I'm happy to get it in and backported 
though?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14328) HdfsDirectory support createTempOutput

2020-03-16 Thread Kevin Risden (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060270#comment-17060270
 ] 

Kevin Risden commented on SOLR-14328:
-

[~Kayne] is this potentially a duplicate of SOLR-14242?

> HdfsDirectory support createTempOutput
> --
>
> Key: SOLR-14328
> URL: https://issues.apache.org/jira/browse/SOLR-14328
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Kayne Wu
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When use HdfsDirectory to build or merge large index with sorted filed n use 
> HdfsDirectory to build or merge large index with sorted filed feature，the 
> HdfsDirectory will throw an UnsupportedOperationException due to  
> createTempOutput(String prefix, String suffix, IOContext context)  method 
> unrealized.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] risdenk commented on issue #1143: SOLR-14328:HdfsDirectory support createTempOutput

risdenk commented on issue #1143: SOLR-14328:HdfsDirectory support 
createTempOutput
URL: https://github.com/apache/lucene-solr/pull/1143#issuecomment-599574140
 
 
   @kaynewu I think this was already resolved in SOLR-14242?  It was fixed 
around around the same time this PR was opened.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393101862
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/handler/component/DistributedExpandComponentTest.java
 ##
 @@ -153,6 +153,23 @@ public void test() throws Exception {
 assertExpandGroupCountAndOrder("group3", 1, results, "9");
 assertExpandGroupCountAndOrder("group4", 1, results, "14");
 
+//Test expand.rows = 0 - no docs only expand count
+
+params = new ModifiableSolrParams();
 
 Review comment:
   done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393101812
 
 

 ##
 File path: 
solr/core/src/test/org/apache/solr/handler/component/TestExpandComponent.java
 ##
 @@ -234,6 +234,21 @@ private void _testExpand(String group, String 
floatAppend, String hint) throws E
 
"/response/lst[@name='expanded']/result[@name='2"+floatAppend+"']/doc[1]/str[@name='id'][.='8']"
 );
 
+//Test expand.rows = 0 - no docs only expand count
+params = new ModifiableSolrParams();
 
 Review comment:
   done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9016) Document how to update web site

2020-03-16 Thread Cassandra Targett (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060292#comment-17060292
 ] 

Cassandra Targett commented on LUCENE-9016:
---

Not sure why it's not showing up here (or I'm just impatient), but I backported 
this to branch_8_5 also. SHA: 18446afd9765407bfdef1b215a03b3cad0ad9a45

> Document how to update web site
> ---
>
> Key: LUCENE-9016
> URL: https://issues.apache.org/jira/browse/LUCENE-9016
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Find all documentation across Wiki, RefGuide, scripts and website itself that 
> talks about how to update or publish the web site, and update accordingly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393111927
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/ExpandComponent.java
 ##
 @@ -668,6 +676,18 @@ public void collect(int docId) throws IOException {
 
   }
 
+  private static Collector getExpandCollector(int limit, Sort sort) throws 
IOException {
 
 Review comment:
   done


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393126595

##
File path: solr/solr-ref-guide/src/collapse-and-expand-results.adoc
##
@@ -142,6 +142,8 @@ The “expand=true” parameter turns on the ExpandComponent.
The ExpandComponen

Inside the expanded section there is a _map_ with each group head pointing to
the expanded documents that are within the group. As applications iterate the
main collapsed result set, they can access the _expanded_ map to retrieve the
expanded groups.

+If you would like to have only the number of documents found from the groups
in the expanded section returned and not the actual documents, you can set
"expand.rows=0". Note that when using "expand.rows=0", score won’t be computed
for the expanded section even when requested so maxScore will not be available.

Review comment:
Thanks for the documentation update. I think this should be part of
`expand.rows=0`. Something like this
https://github.com/apache/lucene-solr/pull/1334/files#diff-9c5999131702feec07a6b7057fa3bcd7R23

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393125271
 
 

 ##
 File path: solr/CHANGES.txt
 ##
 @@ -57,7 +57,7 @@ Improvements
 
 Optimizations
 -
-(No changes)
+* SOLR-8306: Enhance ExpandComponent to allow expand.hits=0 (Marshall Sanders, 
Amelia Henderson)
 
 Review comment:
   Maybe change the wording here, something like `Do not collect expand 
documents when expand.rows=0`
   there is no `expand.hits` parameter


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

munendrasn commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393132417
 
 

 ##
 File path: solr/solr-ref-guide/src/collapse-and-expand-results.adoc
 ##
 @@ -142,6 +142,8 @@ The “expand=true” parameter turns on the ExpandComponent. 
The ExpandComponen
 
 Inside the expanded section there is a _map_ with each group head pointing to 
the expanded documents that are within the group. As applications iterate the 
main collapsed result set, they can access the _expanded_ map to retrieve the 
expanded groups.
 
+If you would like to have only the number of documents found from the groups 
in the expanded section returned and not the actual documents, you can set 
"expand.rows=0". Note that when using "expand.rows=0", score won’t be computed 
for the expanded section even when requested so maxScore will not be available.
 
 Review comment:
   Example 
   ```
   [IMPORTANT]
   
   When `expand.rows=0`, then only the number of documents found for each 
expanded value is returned. Hence, scores won't be computed even if requested. 
`maxScore` is set to 0
   
   ```


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html

Arka Chatterjee created SOLR-14338:
--

 Summary: https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
 Key: SOLR-14338
 URL: https://issues.apache.org/jira/browse/SOLR-14338
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: CDCR
Affects Versions: 8.4.1
Reporter: Arka Chatterjee


[https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]

 

Bi directional updates.

 
 
{{  
1000}}

{{}}

{{/lst }}

{{tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Resolved] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html



 [ 
https://issues.apache.org/jira/browse/SOLR-14338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-14338.
---
Resolution: Incomplete

There's no problem statement here. Nothing to even begin to help figure out 
what you're asking. Closing as incomplete.

 

Please raise questions like this on the user's list, we try to reserve JIRAs 
for known bugs/enhancements rather than usage questions.

See: 
http://lucene.apache.org/solr/community.html#mailing-lists-irc

A _lot_ more people will see your question on that list and may be able to help 
more quickly.

You might want to review: https://wiki.apache.org/solr/UsingMailingLists

If it's determined that this really is a code issue or enhancement to Solr and 
not a configuration/usage problem, we can raise a new JIRA or reopen this one.

> https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
> -
>
> Key: SOLR-14338
> URL: https://issues.apache.org/jira/browse/SOLR-14338
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 8.4.1
>Reporter: Arka Chatterjee
>Priority: Critical
>
> [https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]
>  
> Bi directional updates.
>  
>  
> {{  
> 1000}}
> {{}}
> {{/lst }}
> {{tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Reopened] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html



 [ 
https://issues.apache.org/jira/browse/SOLR-14338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arka Chatterjee reopened SOLR-14338:


Documentation has missing  tag .. please check the link

> https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
> -
>
> Key: SOLR-14338
> URL: https://issues.apache.org/jira/browse/SOLR-14338
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 8.4.1
>Reporter: Arka Chatterjee
>Priority: Critical
>
> [https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]
>  
> Bi directional updates.
>  
>  
> {{  
> 1000}}
> {{}}
> {{/lst }}
> {{tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html



 [ 
https://issues.apache.org/jira/browse/SOLR-14338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arka Chatterjee updated SOLR-14338:
---
Description: 
[https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]

 

Bi directional updates.

 
  
 {{ 
 1000}}

*{\{/lst }}*

{{this tag is missing.}}

  was:
[https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]

 

Bi directional updates.

 
 
{{  
1000}}

{{}}

{{/lst }}

{{tag is missing.}}


> https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
> -
>
> Key: SOLR-14338
> URL: https://issues.apache.org/jira/browse/SOLR-14338
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 8.4.1
>Reporter: Arka Chatterjee
>Priority: Critical
> Attachments: Screen Shot 2020-03-16 at 12.08.46 PM.png
>
>
> [https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]
>  
> Bi directional updates.
>  
>   
>  {{ 
>  1000}}
> *{\{/lst }}*
> {{this tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html



 [ 
https://issues.apache.org/jira/browse/SOLR-14338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arka Chatterjee updated SOLR-14338:
---
Attachment: Screen Shot 2020-03-16 at 12.08.46 PM.png

> https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
> -
>
> Key: SOLR-14338
> URL: https://issues.apache.org/jira/browse/SOLR-14338
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 8.4.1
>Reporter: Arka Chatterjee
>Priority: Critical
> Attachments: Screen Shot 2020-03-16 at 12.08.46 PM.png
>
>
> [https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]
>  
> Bi directional updates.
>  
>  
> {{  
> 1000}}
> {{}}
> {{/lst }}
> {{tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-14338) https://lucene.apache.org/solr/guide/8_4/cdcr-config.html



 [ 
https://issues.apache.org/jira/browse/SOLR-14338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arka Chatterjee updated SOLR-14338:
---
Attachment: Screen Shot 2020-03-16 at 12.08.46 PM.png

> https://lucene.apache.org/solr/guide/8_4/cdcr-config.html
> -
>
> Key: SOLR-14338
> URL: https://issues.apache.org/jira/browse/SOLR-14338
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 8.4.1
>Reporter: Arka Chatterjee
>Priority: Critical
> Attachments: Screen Shot 2020-03-16 at 12.08.46 PM.png, Screen Shot 
> 2020-03-16 at 12.08.46 PM.png
>
>
> [https://lucene.apache.org/solr/guide/8_4/cdcr-config.html]
>  
> Bi directional updates.
>  
>   
>  {{ 
>  1000}}
> *{\{/lst }}*
> {{this tag is missing.}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-11127) REINDEXCOLLECTION command for re-indexing existing collections

2020-03-16 Thread Ishan Chattopadhyaya (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-11127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060353#comment-17060353
 ] 

Ishan Chattopadhyaya commented on SOLR-11127:
-

This feature was very useful for some quick indexing changes that I wanted to 
try out. Thanks!

I needed to re-index docs from only a single shard into a new collection. I 
propose a {{shards}} parameter for such a usecase. I can open a Jira for this, 
if there's no way it can already be done.

> REINDEXCOLLECTION command for re-indexing existing collections
> --
>
> Key: SOLR-11127
> URL: https://issues.apache.org/jira/browse/SOLR-11127
> Project: Solr
>  Issue Type: Task
>Reporter: Steven Rowe
>Assignee: Andrzej Bialecki
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 8.1, master (9.0)
>
> Attachments: SOLR-11127.patch, SOLR-11127.patch, SOLR-11127.patch, 
> SOLR-11127.patch
>
>
> SOLR-9 will switch the Trie fieldtypes in the .system collection's schema 
> to Points.
> Users with pre-7.0 .system collections will no longer be able to use them 
> once Trie fields have been removed (8.0).
> Solr should provide a Collections API command MIGRATESYSTEMCOLLECTION to 
> automatically convert a Trie-based .system collection to a Points-based one.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393158074
 
 

 ##
 File path: solr/CHANGES.txt
 ##
 @@ -57,7 +57,7 @@ Improvements
 
 Optimizations
 -
-(No changes)
+* SOLR-8306: Enhance ExpandComponent to allow expand.hits=0 (Marshall Sanders, 
Amelia Henderson)
 
 Review comment:
   Thanks for that. updated


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

ameliahenderson commented on a change in pull request #1334: SOLR-8306: Enhance 
ExpandComponent to allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#discussion_r393158282
 
 

 ##
 File path: solr/solr-ref-guide/src/collapse-and-expand-results.adoc
 ##
 @@ -142,6 +142,8 @@ The “expand=true” parameter turns on the ExpandComponent. 
The ExpandComponen
 
 Inside the expanded section there is a _map_ with each group head pointing to 
the expanded documents that are within the group. As applications iterate the 
main collapsed result set, they can access the _expanded_ map to retrieve the 
expanded groups.
 
+If you would like to have only the number of documents found from the groups 
in the expanded section returned and not the actual documents, you can set 
"expand.rows=0". Note that when using "expand.rows=0", score won’t be computed 
for the expanded section even when requested so maxScore will not be available.
 
 Review comment:
   Updated. Please let me know if it's still in wrong place


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14325) Core status could be improved to not require an IndexSearcher

2020-03-16 Thread Richard Goodman (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060378#comment-17060378
 ] 

Richard Goodman commented on SOLR-14325:


Hi [~dsmiley], many thanks for your reply to my email. I've been spending all 
day looking at this, and have got something that used a directoryReader instead 
and looked like it worked fine when running a local techproducts instance. 

I'll be testing tomorrow on my dev cluster which will replicate the issue we 
get in our live environment, and let you know my findings, and if successful, 
I'll submit a patch for review :) 

> Core status could be improved to not require an IndexSearcher
> -
>
> Key: SOLR-14325
> URL: https://issues.apache.org/jira/browse/SOLR-14325
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Major
>
> When the core status is told to request "indexInfo", it currently grabs the 
> SolrIndexSearcher but only to grab the Directory.  SolrCore.getIndexSize also 
> only requires the Directory.  By insisting on a SolrIndexSearcher, we 
> potentially block for awhile if the core is in recovery since there is no 
> SolrIndexSearcher.
> [https://lists.apache.org/thread.html/r076218c964e9bd6ed0a53133be9170c3cf36cc874c1b4652120db417%40%3Cdev.lucene.apache.org%3E]
> It'd be nice to have a solution that conditionally used the Directory of the 
> SolrIndexSearcher only if it's present so that we don't waste time creating 
> one either.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0



[ 
https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060380#comment-17060380
 ] 

Munendra S N commented on SOLR-8306:


 [^SOLR-8306.patch] 
Latest patch from PR with updated changes from [~adhenderson]

> Enhance ExpandComponent to allow expand.hits=0
> --
>
> Key: SOLR-8306
> URL: https://issues.apache.org/jira/browse/SOLR-8306
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.3.1
>Reporter: Marshall Sanders
>Assignee: Munendra S N
>Priority: Minor
>  Labels: expand
> Fix For: 5.5
>
> Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, 
> SOLR-8306.patch, SOLR-8306_branch_5x@1715230.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This enhancement allows the ExpandComponent to allow expand.hits=0 for those 
> who don't want an expanded document returned and only want the numFound from 
> the expand section.
> This is useful for "See 54 more like this" use cases, but without the 
> performance hit of gathering an entire expanded document.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0



 [ 
https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N updated SOLR-8306:
---
Attachment: SOLR-8306.patch

> Enhance ExpandComponent to allow expand.hits=0
> --
>
> Key: SOLR-8306
> URL: https://issues.apache.org/jira/browse/SOLR-8306
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.3.1
>Reporter: Marshall Sanders
>Assignee: Munendra S N
>Priority: Minor
>  Labels: expand
> Fix For: 5.5
>
> Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, 
> SOLR-8306.patch, SOLR-8306_branch_5x@1715230.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This enhancement allows the ExpandComponent to allow expand.hits=0 for those 
> who don't want an expanded document returned and only want the numFound from 
> the expand section.
> This is useful for "See 54 more like this" use cases, but without the 
> performance hit of gathering an entire expanded document.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] andyvuong commented on issue #1317: SOLR-13101: Create metadataSuffix znode only at common shard creating api calls

andyvuong commented on issue #1317: SOLR-13101: Create metadataSuffix znode 
only at common shard creating api calls
URL: https://github.com/apache/lucene-solr/pull/1317#issuecomment-599655907
 
 
   cc @yonik 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] yonik merged pull request #1317: SOLR-13101: Create metadataSuffix znode only at common shard creating api calls

yonik merged pull request #1317: SOLR-13101: Create metadataSuffix znode only 
at common shard creating api calls
URL: https://github.com/apache/lucene-solr/pull/1317
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-10157) JSON Facets should give more helpful error msg when users attempt to an unknown aggregation

2020-03-16 Thread Lucene/Solr QA (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-10157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060387#comment-17060387
 ] 

Lucene/Solr QA commented on SOLR-10157:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
57s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m 44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  2m 44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  2m 44s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 76m 46s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 85m  4s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.api.collections.TestHdfsCloudBackupRestore |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-10157 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12996771/SOLR-10157.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene2-us-west.apache.org 4.4.0-170-generic #199-Ubuntu SMP 
Thu Nov 14 01:45:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 6ae69d3 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/715/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/715/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/715/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> JSON Facets should give more helpful error msg when users attempt to an 
> unknown aggregation
> ---
>
> Key: SOLR-10157
> URL: https://issues.apache.org/jira/browse/SOLR-10157
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-10157.patch, SOLR-10157.patch
>
>
> Sample question from a confused solr-user email...
> {noformat}
> > I'm getting this error when I tried to do a division in JSON Facet.
> >
> >   "error":{
> > "msg":"org.apache.solr.search.SyntaxError: Unknown aggregation agg_div 
> > in ('div(4,2)', pos=4)",
> > "code":400}}
> >
> >
> > Is this division function supported in JSON Facet?
> {noformat}
> And the subsequent followup from the same user...
> bq. I found that we can't put div(4,2) directly, as it wouldn't work.
> bq. It will work if I put something like max(div(4,2)).
> 
> It seems like a better error handline code path for 
> {{FunctionQParser.parseAgg}} (once we've confirmed no such aggregation 
> exists) would be:
> * attempt to parse the original string as a regular (non-Agg)ValueSource) 
> function
> ** if that succeeds, give the user an error indicating that this ValueSource 
> must be wrapped in an aggregation
> ** if it fails, continue to throw the original error
> * either way, any error thrown should refer to the _original_ {{id}} before 
> For example: 
> * {{div(price,popularity)}} should throw an error with a msg along the lines 
> of: {{'div' is a per-document function, not a multi-document aggregation 
> function, input: div(price,popularity)}}
> *  {{HOSS(price,popularity)}} on the other hand should throw an error such 
> as: {{Unknown aggregation HOSS in ('HOSS(price,populaity)' ..

[GitHub] [lucene-solr] magibney opened a new pull request #1357: SOLR-13807: Introduce a cache for term facet counts

magibney opened a new pull request #1357: SOLR-13807: Introduce a cache for 
term facet counts
URL: https://github.com/apache/lucene-solr/pull/1357
 
 
   See issue [SOLR-13807](https://issues.apache.org/jira/browse/SOLR-13807). 
The latter of the two commits pushed here is the one associated with this 
PR/issue; the former commit is a "shim" introducing changes from upstream 
dependency [SOLR-13132](https://issues.apache.org/jira/browse/SOLR-13132) (PR 
#751).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] magibney commented on issue #751: SOLR-13132: single sweep iteration over base, foreground, and background sets for "relatedness" calculation

magibney commented on issue #751: SOLR-13132: single sweep iteration over base, 
foreground, and background sets for "relatedness" calculation
URL: https://github.com/apache/lucene-solr/pull/751#issuecomment-599665622
 
 
   Per [@hossman's 
suggestion](https://issues.apache.org/jira/browse/SOLR-13807?focusedCommentId=17059139#comment-17059139),
 force-pushed 27f2e34 including only sweep collection. The "term facet cache" 
component of the original monolithic commit will be tracked separately at 
[SOLR-13807](https://issues.apache.org/jira/browse/SOLR-13807) (PR #1357).


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13807) Caching for term facet counts

2020-03-16 Thread Michael Gibney (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060395#comment-17060395
 ] 

Michael Gibney commented on SOLR-13807:
---

Thanks Chris! This all makes sense. I've pushed a single commit(/patch) to [PR 
#751|https://github.com/apache/lucene-solr/pull/751] incorporating only changes 
for SOLR-13132, and opened new PR with a commit dedicated to facet cache 
(associated with _this_ issue) 
([#1357|https://github.com/apache/lucene-solr/pull/1357]).

My apologies, I'm doing my best to manage this logically! I will indeed stick 
with Github (more for the "git" and less for the "hub" ... or something like 
that), esp. because it made it easier to make the facet cache patch/code 
available while clarifying the dependency of the code as written on some of the 
code reorganization introduced by the patch for SOLR-13132.

> Caching for term facet counts
> -
>
> Key: SOLR-13807
> URL: https://issues.apache.org/jira/browse/SOLR-13807
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Affects Versions: master (9.0), 8.2
>Reporter: Michael Gibney
>Priority: Minor
> Attachments: SOLR-13807__SOLR-13132_test_stub.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr does not have a facet count cache; so for _every_ request, term facets 
> are recalculated for _every_ (facet) field, by iterating over _every_ field 
> value for _every_ doc in the result domain, and incrementing the associated 
> count.
> As a result, subsequent requests end up redoing a lot of the same work, 
> including all associated object allocation, GC, etc. This situation could 
> benefit from integrated caching.
> Because of the domain-based, serial/iterative nature of term facet 
> calculation, latency is proportional to the size of the result domain. 
> Consequently, one common/clear manifestation of this issue is high latency 
> for faceting over an unrestricted domain (e.g., {{\*:\*}}), as might be 
> observed on a top-level landing page that exposes facets. This type of 
> "static" case is often mitigated by external (to Solr) caching, either with a 
> caching layer between Solr and a front-end application, or within a front-end 
> application, or even with a caching layer between the end user and a 
> front-end application.
> But in addition to the overhead of handling this caching elsewhere in the 
> stack (or, for a new user, even being aware of this as a potential issue to 
> mitigate), any external caching mitigation is really only appropriate for 
> relatively static cases like the "landing page" example described above. A 
> Solr-internal facet count cache (analogous to the {{filterCache}}) would 
> provide the following additional benefits:
>  # ease of use/out-of-the-box configuration to address a common performance 
> concern
>  # compact (specifically caching count arrays, without the extra baggage that 
> accompanies a naive external caching approach)
>  # NRT-friendly (could be implemented to be segment-aware)
>  # modular, capable of reusing the same cached values in conjunction with 
> variant requests over the same result domain (this would support common use 
> cases like paging, but also potentially more interesting direct uses of 
> facets). 
>  # could be used for distributed refinement (i.e., if facet counts over a 
> given domain are cached, a refinement request could simply look up the 
> ordinal value for each enumerated term and directly grab the count out of the 
> count array that was cached during the first phase of facet calculation)
>  # composable (e.g., in aggregate functions that calculate values based on 
> facet counts across different domains, like SKG/relatedness – see SOLR-13132)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14325) Core status could be improved to not require an IndexSearcher

2020-03-16 Thread David Smiley (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060423#comment-17060423
 ] 

David Smiley commented on SOLR-14325:
-

Fantastic; I love getting a contribution!

In the description I said It'd be nice to have a solution that conditionally 
used the Directory of the SolrIndexSearcher.  I was thinking about that more 
and I think that would add complexity to getSearcher which is already too 
complex, IMO.  Also, Directory != DirectoryReader, and the latter is what we 
need the most.  It could be interesting if the latest DirectoryReader instance 
could be managed by the SolrCore instead of the SolrIndexSearcher, thus 
allowing it's use in core status without needing the SolrIndexSearcher.  
However I suspect there are complexities in how both replication and a core 
restore bring in a new Directory basically.  FYI [~yo...@apache.org] you might 
have expertise to bring to bear on this topic.

> Core status could be improved to not require an IndexSearcher
> -
>
> Key: SOLR-14325
> URL: https://issues.apache.org/jira/browse/SOLR-14325
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Major
>
> When the core status is told to request "indexInfo", it currently grabs the 
> SolrIndexSearcher but only to grab the Directory.  SolrCore.getIndexSize also 
> only requires the Directory.  By insisting on a SolrIndexSearcher, we 
> potentially block for awhile if the core is in recovery since there is no 
> SolrIndexSearcher.
> [https://lists.apache.org/thread.html/r076218c964e9bd6ed0a53133be9170c3cf36cc874c1b4652120db417%40%3Cdev.lucene.apache.org%3E]
> It'd be nice to have a solution that conditionally used the Directory of the 
> SolrIndexSearcher only if it's present so that we don't waste time creating 
> one either.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Created] (LUCENE-9280) Add ability to skip non-competitive documents on field sort

2020-03-16 Thread Mayya Sharipova (Jira)

Mayya Sharipova created LUCENE-9280:
---

 Summary: Add ability to skip non-competitive documents on field 
sort 
 Key: LUCENE-9280
 URL: https://issues.apache.org/jira/browse/LUCENE-9280
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Mayya Sharipova


Today collectors, once they collect enough docs, can instruct scorers to update 
their iterators to skip non-competitive documents. This is applicable only for 
a case when we need top docs by _score.

It would be nice to also have an ability to skip non-competitive docs when we 
need top docs sorted by other fields different from _score. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer

dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for 
Ukrainian analyzer
URL: https://github.com/apache/lucene-solr/pull/1354#issuecomment-599740707
 
 
   Hmm... Had to revert it because ant builds started complaining about 
offending license files. Could be line endings - will have to check.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9280) Add ability to skip non-competitive documents on field sort

2020-03-16 Thread Mayya Sharipova (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060453#comment-17060453
 ] 

Mayya Sharipova commented on LUCENE-9280:
-

draft PR: [https://github.com/apache/lucene-solr/pull/1351]

> Add ability to skip non-competitive documents on field sort 
> 
>
> Key: LUCENE-9280
> URL: https://issues.apache.org/jira/browse/LUCENE-9280
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>
> Today collectors, once they collect enough docs, can instruct scorers to 
> update their iterators to skip non-competitive documents. This is applicable 
> only for a case when we need top docs by _score.
> It would be nice to also have an ability to skip non-competitive docs when we 
> need top docs sorted by other fields different from _score. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0

2020-03-16 Thread Dawid Weiss (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060454#comment-17060454
 ] 

Dawid Weiss commented on LUCENE-9279:
-

Something is not right - builds started failing after this pull request has 
been integrated. Will have to look into it.

> Update dictionary version for Ukrainian analyzer to 4.9.0
> -
>
> Key: LUCENE-9279
> URL: https://issues.apache.org/jira/browse/LUCENE-9279
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer.
> There's about 80k of new lemmas



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for Ukrainian analyzer

dweiss commented on issue #1354: LUCENE-9279: Update dictionary version for 
Ukrainian analyzer
URL: https://github.com/apache/lucene-solr/pull/1354#issuecomment-599751647
 
 
   The checksums didn't have trailing LF. Use 'gradlew updateLicenses' - makes 
life easier.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-9279) Update dictionary version for Ukrainian analyzer to 4.9.0

2020-03-16 Thread Dawid Weiss (Jira)



[ 
https://issues.apache.org/jira/browse/LUCENE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060460#comment-17060460
 ] 

Dawid Weiss commented on LUCENE-9279:
-

Checksums must have a trailing LF for ant builds not to complain, it seems. I 
corrected master but could you make sure the same is applied to PR 1355? Thanks.

> Update dictionary version for Ukrainian analyzer to 4.9.0
> -
>
> Key: LUCENE-9279
> URL: https://issues.apache.org/jira/browse/LUCENE-9279
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Update morfologik dictionary version to 4.9.0 for Ukrainian analyzer.
> There's about 80k of new lemmas



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Assigned] (SOLR-13948) Tooltip popup for replica information in cloud view clipping



 [ 
https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-13948:
-

Assignee: (was: Erick Erickson)

> Tooltip popup for replica information in cloud view clipping
> 
>
> Key: SOLR-13948
> URL: https://issues.apache.org/jira/browse/SOLR-13948
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 7.7.2
>Reporter: Richard Goodman
>Priority: Minor
> Attachments: SOLR-13948.patch, SOLR-13948.patch, after.png, 
> before.png, graph_overflow.png, nodes_overflow.png
>
>
> Our replicas typically have a long name, which has never really a problem for 
> us. But with the new feature in 7.7.2 _(at least for us was new than our 
> previous solr version)_ when on the cloud view and looking at the status of 
> collections, when hovering over a node ip and seeing the tooltip popup of the 
> replica information, this information will go over the tooltip window if the 
> replica name is of a certain size.
> This small patch fixes this, I've attached some screenshots of a before and 
> after, as well as the patch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13948) Tooltip popup for replica information in cloud view clipping



[ 
https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060462#comment-17060462
 ] 

Erick Erickson commented on SOLR-13948:
---

There are a bunch of overflows, and since this hasn't received any attention 
and my UI skills are limited at best I'm putting it back in the unassigned 
queue.

> Tooltip popup for replica information in cloud view clipping
> 
>
> Key: SOLR-13948
> URL: https://issues.apache.org/jira/browse/SOLR-13948
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 7.7.2
>Reporter: Richard Goodman
>Priority: Minor
> Attachments: SOLR-13948.patch, SOLR-13948.patch, after.png, 
> before.png, graph_overflow.png, nodes_overflow.png
>
>
> Our replicas typically have a long name, which has never really a problem for 
> us. But with the new feature in 7.7.2 _(at least for us was new than our 
> previous solr version)_ when on the cloud view and looking at the status of 
> collections, when hovering over a node ip and seeing the tooltip popup of the 
> replica information, this information will go over the tooltip window if the 
> replica name is of a certain size.
> This small patch fixes this, I've attached some screenshots of a before and 
> after, as well as the patch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-13948) Tooltip popup for replica information in cloud view clipping

2020-03-16 Thread Richard Goodman (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-13948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060463#comment-17060463
 ] 

Richard Goodman commented on SOLR-13948:


Hi Erik, 

No problem, I have recently managed to get to grips with the angular side of 
things in the code base, so hoping soon when I have the time, to finish this as 
desired :) 

Sorry for the delay

> Tooltip popup for replica information in cloud view clipping
> 
>
> Key: SOLR-13948
> URL: https://issues.apache.org/jira/browse/SOLR-13948
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 7.7.2
>Reporter: Richard Goodman
>Priority: Minor
> Attachments: SOLR-13948.patch, SOLR-13948.patch, after.png, 
> before.png, graph_overflow.png, nodes_overflow.png
>
>
> Our replicas typically have a long name, which has never really a problem for 
> us. But with the new feature in 7.7.2 _(at least for us was new than our 
> previous solr version)_ when on the cloud view and looking at the status of 
> collections, when hovering over a node ip and seeing the tooltip popup of the 
> replica information, this information will go over the tooltip window if the 
> replica name is of a certain size.
> This small patch fixes this, I've attached some screenshots of a before and 
> after, as well as the patch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Resolved] (SOLR-13964) Separate out functional changes from the gradle_8 branch unrelated to the Gradle build



 [ 
https://issues.apache.org/jira/browse/SOLR-13964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-13964.
---
Resolution: Won't Fix

This is superseded by all the great work Dawid is guiding.

> Separate out functional changes from the gradle_8 branch unrelated to the 
> Gradle build
> --
>
> Key: SOLR-13964
> URL: https://issues.apache.org/jira/browse/SOLR-13964
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I should have a patch today with these, there are only a few.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0

2020-03-16 Thread Lucene/Solr QA (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060486#comment-17060486
 ] 

Lucene/Solr QA commented on SOLR-8306:
--

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} 
| {color:red} SOLR-8306 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help. 
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-8306 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12996857/SOLR-8306.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/716/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Enhance ExpandComponent to allow expand.hits=0
> --
>
> Key: SOLR-8306
> URL: https://issues.apache.org/jira/browse/SOLR-8306
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.3.1
>Reporter: Marshall Sanders
>Assignee: Munendra S N
>Priority: Minor
>  Labels: expand
> Fix For: 5.5
>
> Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, 
> SOLR-8306.patch, SOLR-8306_branch_5x@1715230.patch
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> This enhancement allows the ExpandComponent to allow expand.hits=0 for those 
> who don't want an expanded document returned and only want the numFound from 
> the expand section.
> This is useful for "See 54 more like this" use cases, but without the 
> performance hit of gathering an entire expanded document.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-14317) HttpClusterStateProvider throws exception when only one node down

2020-03-16 Thread Lyle (Jira)



[ 
https://issues.apache.org/jira/browse/SOLR-14317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060597#comment-17060597
 ] 

Lyle commented on SOLR-14317:
-

 Hi [~ichattopadhyaya], Can you please help review attached patch? I will add 
more patch for branch_8x and branch_7_7 if this patch has no issue.

> HttpClusterStateProvider throws exception when only one node down
> -
>
> Key: SOLR-14317
> URL: https://issues.apache.org/jira/browse/SOLR-14317
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.1, 7.7.2
>Reporter: Lyle
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-14317.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When create a CloudSolrClient with solrUrls, if the first url in the solrUrls 
> list is invalid or server is down, it will throw exception directly rather 
> than try remaining url.
> In 
> [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L65],
>  if fetchLiveNodes(initialClient) have any IOException, in 
> [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L648],
>  exceptions will be caught and throw SolrServerException to the upper caller, 
> while no IOExceptioin will be caught in 
> HttpClusterStateProvider.fetchLiveNodes(HttpClusterStateProvider.java:200).
> The SolrServerException should be caught as well in 
> [https://github.com/apache/lucene-solr/blob/branch_7_7/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpClusterStateProvider.java#L69],
>  so that if first node provided in solrUrs down, we can try to use the second 
> to fetch live nodes.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[GitHub] [lucene-solr] munendrasn commented on issue #1334: SOLR-8306: Enhance ExpandComponent to allow expand.hits=0

munendrasn commented on issue #1334: SOLR-8306: Enhance ExpandComponent to 
allow expand.hits=0
URL: https://github.com/apache/lucene-solr/pull/1334#issuecomment-599875285
 
 
   I had to rebase with master due to some conflicts


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0



 [ 
https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N updated SOLR-8306:
---
Attachment: SOLR-8306.patch

> Enhance ExpandComponent to allow expand.hits=0
> --
>
> Key: SOLR-8306
> URL: https://issues.apache.org/jira/browse/SOLR-8306
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.3.1
>Reporter: Marshall Sanders
>Assignee: Munendra S N
>Priority: Minor
>  Labels: expand
> Fix For: 5.5
>
> Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, 
> SOLR-8306.patch, SOLR-8306.patch, SOLR-8306_branch_5x@1715230.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> This enhancement allows the ExpandComponent to allow expand.hits=0 for those 
> who don't want an expanded document returned and only want the numFound from 
> the expand section.
> This is useful for "See 54 more like this" use cases, but without the 
> performance hit of gathering an entire expanded document.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (SOLR-8306) Enhance ExpandComponent to allow expand.hits=0



[ 
https://issues.apache.org/jira/browse/SOLR-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17060630#comment-17060630
 ] 

Munendra S N commented on SOLR-8306:


 [^SOLR-8306.patch] 
Rebased with  latest master

> Enhance ExpandComponent to allow expand.hits=0
> --
>
> Key: SOLR-8306
> URL: https://issues.apache.org/jira/browse/SOLR-8306
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.3.1
>Reporter: Marshall Sanders
>Assignee: Munendra S N
>Priority: Minor
>  Labels: expand
> Fix For: 5.5
>
> Attachments: SOLR-8306.patch, SOLR-8306.patch, SOLR-8306.patch, 
> SOLR-8306.patch, SOLR-8306.patch, SOLR-8306_branch_5x@1715230.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> This enhancement allows the ExpandComponent to allow expand.hits=0 for those 
> who don't want an expanded document returned and only want the numFound from 
> the expand section.
> This is useful for "See 54 more like this" use cases, but without the 
> performance hit of gathering an entire expanded document.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Updated] (LUCENE-8908) Specified default value not returned for query() when doc doesn't match



 [ 
https://issues.apache.org/jira/browse/LUCENE-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Munendra S N updated LUCENE-8908:
-
Attachment: LUCENE-8908.patch

> Specified default value not returned for query() when doc doesn't match
> ---
>
> Key: LUCENE-8908
> URL: https://issues.apache.org/jira/browse/LUCENE-8908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Bill Bell
>Priority: Major
> Attachments: LUCENE-8908.patch, LUCENE-8908.patch, SOLR-7845.patch, 
> SOLR-7845.patch
>
>
> The 2 arg version of the "query()" was designed so that the second argument 
> would specify the value used for any document that does not match the query 
> pecified by the first argument -- but the "exists" property of the resulting 
> ValueSource only takes into consideration wether or not the document matches 
> the query -- and ignores the use of the second argument.
> 
> The work around is to ignore the 2 arg form of the query() function, and 
> instead wrap he query function in def().
> for example:  {{def(query($something), $defaultval)}} instead of 
> {{query($something, $defaultval)}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

[jira] [Commented] (LUCENE-8908) Specified default value not returned for query() when doc doesn't match