[jira] [Reopened] (SOLR-9562) Minimize queried collections for time series alias

[David Smiley (JIRA)]

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

David Smiley reopened SOLR-9562:


tl;dr: I'm re-opening for further discussion on the merits of collection based 
time series.  I'm leaning towards this solution now.  

I did look at the patch closer.  It solves one aspect of time series, namely 
what the title says: "minimize queried collections for time series alias" (an 
optimization); and that's it.  That is okay as a first step I guess. It's still 
on the client to write new data to the appropriate collection (routing writes), 
and also to eventually delete the oldest collections, and to actually create 
new collections and perhaps add to an alias while it's at it.  So yeah most 
things are for other issues :-)

Elsewhere, [~janhoy] said:
bq. Question: Is shard-level the best abstraction here or could time-based use 
cases just as well be solved on the collection level? Create a write-alias 
pointing to the newest collection, and read aliases pointing to all or some 
other subset of collections. In this setup, newer collections could have larger 
replicationFactor to support more queries. And you could reduce #shards for 
older collections, merge collections and define the oldest collections as 
"archive" which are loaded lazily on demand only etc... People do this already 
and one could imagine built-in support for all the collection creation and 
alias housekeeping.

Sounds good but I have some questions about some of the potential bonus 
features you mentioned.  Like what is the methodology to reducing the numShards 
of a collection while keeping overall data set searchable and no oddities like 
temporarily searching/counting copies of the same document?  And likewise for 
merging collections?

A disadvantage to the shard/DocRouter approach (SOLR-9690) is that the 
numShards & replicationFactor, and node placement rules etc. are fixed and 
governed at the collection level, not per-shard. But if shard==time-slice then 
there's a good chance we want to make different choices for the most recent 
shard. And there are still scalability issues (Overseer related) with very 
large numbers of shards that is not present if done at the collection level 
(will be solved eventually I'm sure).  I think for this feature we ought to 
cater to very high scalability in diverse use cases, and that probably means 
collection based time slices.  

Maybe there's room for a hybrid where shard based time series is used for all 
data, but it is augmented by an additional "realtime" collection (optional 
feature) for the most recent data that can of course have it's own 
configuration catering to both realtime search and high write volume.  Then we 
devise a way to move the data from the RT collection to the archive collection. 
 Perhaps a big optimize and then copy the segment(s) across the RT shards over 
to one new index involving the MERGEINDEXES admin command.  I spoke about this 
hybrid as a small piece of a larger talk at last year's L/S Revolution but 
didn't ultimately have time to implement this strategy.  I did at least get to 
much of the shard based time series portion.

[~ehatcher] I wonder if LucidWorks might be interested in open-sourcing 
Fusion's time series capability, assuming it's in a suitable shape to be 
donated (e.g. written in Java, etc.)?  I've seen it but not tried it; I don't 
have insight into the particulars of it's approach.  Regardless I've set aside 
my time to improve Solr to help get something committed so that Solr has this 
capability (be it collection based time slices or shard based time slices).

> Minimize queried collections for time series alias
> --
>
> Key: SOLR-9562
> URL: https://issues.apache.org/jira/browse/SOLR-9562
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Eungsop Yoo
>Priority: Minor
> Attachments: SOLR-9562.patch, SOLR-9562-v2.patch
>
>
> For indexing time series data(such as large log data), we can create a new 
> collection regularly(hourly, daily, etc.) with a write alias and create a 
> read alias for all of those collections. But all of the collections of the 
> read alias are queried even if we search over very narrow time window. In 
> this case, the docs to be queried may be stored in very small portion of 
> collections. So we don't need to do that.
> I suggest this patch for read alias to minimize queried collections. Three 
> parameters for CREATEALIAS action are added.
> || Key || Type || Required || Default || Description ||
> | timeField | string | No | | The time field name for time series data. It 
> should be date type. |
> | dateTimeFormat | string | No | | The format of timestamp for collection 
> creation. Every collection 

[jira] [Created] (SOLR-11185) Make DIH work with Schemaless mode.

[Kshitij Shukla (JIRA)]

Kshitij Shukla created SOLR-11185:
-

 Summary: Make DIH work with Schemaless mode.
 Key: SOLR-11185
 URL: https://issues.apache.org/jira/browse/SOLR-11185
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - DataImportHandler, Data-driven Schema, Schema 
and Analysis
Reporter: Kshitij Shukla
Priority: Minor


Hello Everyone, 

Hope you are all doing well.
Recently I have trying to make work a solr schemaless configuration with 
DIH(mysql 5.6). After working on it around 4-5 Hrs I realized that schemaless 
with DIH wont work. It might be my assumptions and chances are any of you might 
know a way to make them together work. If so, please let me know how, if not 
can this be treated as the improvement?

Best regards



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11178) Change error handling in AutoScalingHandler to be consistent w/ other APIs

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-11178:
--
Attachment: SOLR-11178.patch

> Change error handling in AutoScalingHandler to be consistent w/ other APIs
> --
>
> Key: SOLR-11178
> URL: https://issues.apache.org/jira/browse/SOLR-11178
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11178.patch
>
>
> AutoScalingHandler throws errors for each single error in the payload. 
> config, schema and security API doesn't behave like that. They throw one 
> single error which contains all the errors in the payload. This should be 
> fixed in 7.0 as well because it will break backward compatibility in clients .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Muktesh Mehta (JIRA)]

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

Muktesh Mehta commented on LUCENE-7188:
---

[~yo...@apache.org] [~dsmi...@mac.com] We are using Solr 5.1 and facing same 
issue. Is the only way to solve this issue upgrading Solr version? Can 
[https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b31c398] fix be 
backported  to 5.1?

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1, 6.0.1, 5.5.1, 7.0
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, 

[jira] [Commented] (LUCENE-7897) RangeQuery optimization in IndexOrDocValuesQuery

[Murali Krishna P (JIRA)]

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

Murali Krishna P commented on LUCENE-7897:
--

Thanks Adrien for the patch. The changes look good from my perspective. 
However, it would be better if someone who is more familiar with this part of 
the code also reviews it. For example, I am not very sure about he opt() method 
where you removed the pq which was ordering the optionalScorers in a particular 
way earlier.

Does the daily benchmark have the right dataset and query to track the 
improvement?

> RangeQuery optimization in IndexOrDocValuesQuery 
> -
>
> Key: LUCENE-7897
> URL: https://issues.apache.org/jira/browse/LUCENE-7897
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk, 7.0
>Reporter: Murali Krishna P
> Attachments: LUCENE-7897.patch
>
>
> For range queries, Lucene uses either Points or Docvalues based on cost 
> estimation 
> (https://lucene.apache.org/core/6_5_0/core/org/apache/lucene/search/IndexOrDocValuesQuery.html).
>  Scorer is chosen based on the minCost here: 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/Boolean2ScorerSupplier.java#L16
> However, the cost calculation for TermQuery and IndexOrDocvalueQuery seems to 
> have same weightage. Essentially, cost depends upon the docfreq in TermDict, 
> number of points visited and number of docvalues. In a situation where 
> docfreq is not too restrictive, this is lot of lookups for docvalues and 
> using points would have been better.
> Following query with 1M matches, takes 60ms with docvalues, but only 27ms 
> with points. If I change the query to "message:*", which matches all docs, it 
> choses the points(since cost is same), but with message:xyz it choses 
> docvalues eventhough doc frequency is 1million which results in many docvalue 
> fetches. Would it make sense to change the cost of docvalues query to be 
> higher or use points if the docfreq is too high for the term query(find an 
> optimum threshold where points cost < docvalue cost)?
> {noformat}
> {
>   "query": {
> "bool": {
>   "must": [
> {
>   "query_string": {
> "query": "message:xyz"
>   }
> },
> {
>   "range": {
> "@timestamp": {
>   "gte": 149865240,
>   "lte": 149890500,
>   "format": "epoch_millis"
> }
>   }
> }
>   ]
> }
>   }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11182:
--

+1 LGTM

> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: LUCENE-7906-AreaShape.patch

Hi [~daddywri],

Attached is a new Patch with the new proposed interface GeoAreaShape.  It was 
trivial to add this new interface for existing Shapes.

I created a new composite for GeoAreaShape and use it as the base class for 
GeoCompositePolygon.

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_141) - Build # 193 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/193/
Java: 32bit/jdk1.8.0_141 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([84A72A68018704C8:3B586BC2DF7DE454]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions(StreamExpressionTest.java:6037)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14085 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.StreamExpressionTest
   [junit4]   2> Creating dataDir: 

[jira] [Created] (SOLR-11188) Hi CPU utilization when highlighting mergecontiguous=true

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-11188:
-

 Summary: Hi CPU utilization when highlighting mergecontiguous=true
 Key: SOLR-11188
 URL: https://issues.apache.org/jira/browse/SOLR-11188
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


A user's list thread indicates that Solr 6.3 has very high CPU utilization with 
highlighting and mergecontiguous=true. This is a marker to see if we can 
reproduce. Notes:

1> this was pre-unifiedhighlighter. 
2> unknown whether this is still an issue in more recent Solrs

I'll ask the OP to comment here with additional details.

Assigning to myself to track, I wont do any work on this for quite a while so 
anyone who wants to please take it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 893ea166ef286a7118c3ac5ffc90f27e5b94789d in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=893ea16 ]

LUCENE-7906: Add missing override, fixing javadoc


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11163) Normalizer fails to restore itself when reload or restart solr cores.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11163:


Commit 5c136fd8fdfe27d2c3b1e379951db4c14bb2ae17 in lucene-solr's branch 
refs/heads/branch_7_0 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c136fd ]

SOLR-11163: Fix contrib/ltr Normalizer persistence after solr core reload or 
restart.
(Yuki Yano via Christine Poerschke)


> Normalizer fails to restore itself when reload or restart solr cores.
> -
>
> Key: SOLR-11163
> URL: https://issues.apache.org/jira/browse/SOLR-11163
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: 6.6
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
> Attachments: SOLR-11163.patch, SOLR-11163.patch
>
>
> Normalizer fails to restore itself from json file of its parameters when 
> reload or restart solr cores.
> This is because Normalizer#paramsToMap generates Map of parameters with 
> double quoted like below:
> {code:JavaScript}
> {
>   "min": "\"0.0\"",
>   "max": "\"1.0\""
> }
> {code}
> With the example above, Normalizer#newInstance fails to invoke setters due to 
> the failure of Float#parseFloat("\"0.0\"").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9371:
---

Commit 41e9c17443cb27e6b62e9a244e4503b234bcd0db in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=41e9c17 ]

Correct SOLR_STOP_WAIT value in Solr Ref Guide (it changed from 5 to 180s in 
SOLR-9371).


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.3, 7.0
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11072) Implement trigger for searchRate event type

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-11072:


Assignee: Andrzej Bialecki 

> Implement trigger for searchRate event type
> ---
>
> Key: SOLR-11072
> URL: https://issues.apache.org/jira/browse/SOLR-11072
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: 7.1
>
>
> Implement support for triggers based on searchRate event type. This can be 
> used to add replicas when the rate of queries increases over a threshold and 
> remains high for a configurable period of time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11187) TestModelManagerPersistence improvements

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11187:
---
Attachment: SOLR-11187.patch

Attaching the {{TestModelManagerPersistence}} portion of [~yuyano]'s SOLR-11163 
patch.

> TestModelManagerPersistence improvements
> 
>
> Key: SOLR-11187
> URL: https://issues.apache.org/jira/browse/SOLR-11187
> Project: Solr
>  Issue Type: Test
>  Components: contrib - LTR
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11187.patch
>
>
> For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

FWIW, the commit messages for this ticket describe it as LUCENE-7606, not 7906. 
 My apologies!!


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

Sure -- this is Windows 10, an older JDK 8: C:\Program
Files\Java\jdk1.8.0_05

Anything else you are interested in?

Karl


On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:

> Hi Karl,
>
> I looked at a couple of the errors, and they were all in "[source]"
> sections, which should be exempted from the “unescaped symbol” check, which
> is performed in the "-validate-source-patterns” target in the top-level
> build.xml.  The groovy method “checkForUnescapedSymbolSubstitutions” is
> where this “[source]” section exemption is supposed to happen.
>
> The “-validate-source-patterns” target depends on “resolve-groovy”, which
> pins the version, so I don’t think this is an issue of stale build tools.
>
> I don’t know how to reproduce the problem you’re seeing, so I’m not sure
> how to fix it.  Could you provide details on your platform?
>
> --
> Steve
> www.lucidworks.com
>
> > On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
> >
> > 'When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?'
> >
> > This is on master, and yes, my work area is up to date.
> > Any other ideas?  Have the required versions of some of the build tools
> changed recently or something?
> >
> > Karl
> >
> >
> >
> > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett 
> wrote:
> > Those are documentation-lint validations added via SOLR-10883 for the
> > Solr Ref Guide (committed weeks ago).
> >
> > When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?
> >
> > On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright  wrote:
> > >
> > > Getting this output:
> > >
> > > ...
> > > [source-patterns] Unescaped symbol "->" on line #84:
> > > solr/solr-ref-guide/src/res
> > > ponse-writers.adoc
> > > [source-patterns] Unescaped symbol "->" on line #185:
> > > solr/solr-ref-guide/src/re
> > > sponse-writers.adoc
> > > [source-patterns] Unescaped symbol "->" on line #87:
> > > solr/solr-ref-guide/src/res
> > > ult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #114:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #127:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #162:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #168:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #185:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #191:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #196:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #42:
> > > solr/solr-ref-guide/src/sch
> > > ema-factory-definition-in-solrconfig.adoc
> > > [source-patterns] Unescaped symbol "->" on line #73:
> > > solr/solr-ref-guide/src/sch
> > > ema-factory-definition-in-solrconfig.adoc
> > > [source-patterns] Unescaped symbol "->" on line #131:
> > > solr/solr-ref-guide/src/sc
> > > hemaless-mode.adoc
> > > [source-patterns] Unescaped symbol "->" on line #153:
> > > solr/solr-ref-guide/src/sc
> > > hemaless-mode.adoc
> > > [source-patterns] Unescaped symbol "<-" on line #43:
> > > solr/solr-ref-guide/src/sol
> > > r-jdbc-r.adoc
> > > [source-patterns] Unescaped symbol "<-" on line #45:
> > > solr/solr-ref-guide/src/sol
> > > r-jdbc-r.adoc
> > > [source-patterns] Unescaped symbol "<-" on line #48:
> > > solr/solr-ref-guide/src/sol
> > > r-jdbc-r.adoc
> > > [source-patterns] Unescaped symbol "->" on line #46:
> > > solr/solr-ref-guide/src/spe
> > > ll-checking.adoc
> > > [source-patterns] Unescaped symbol "->" on line #106:
> > > solr/solr-ref-guide/src/sp
> > > ell-checking.adoc
> > > [source-patterns] Unescaped symbol "<=" on line #443:
> > > solr/solr-ref-guide/src/st
> > > ream-evaluators.adoc
> > > [source-patterns] Unescaped symbol "<=" on line #444:
> > > solr/solr-ref-guide/src/st
> > > ream-evaluators.adoc
> > > [source-patterns] Unescaped symbol "<=" on line #445:
> > > solr/solr-ref-guide/src/st
> > > ream-evaluators.adoc
> > > [source-patterns] Unescaped symbol "<=" on line #446:
> > > solr/solr-ref-guide/src/st
> > > ream-evaluators.adoc
> > > [source-patterns] Unescaped symbol "->" on line #38:
> > > solr/solr-ref-guide/src/tak
> > > ing-solr-to-production.adoc
> > > [source-patterns] Unescaped symbol "->" on line #41:
> > > solr/solr-ref-guide/src/the
> > > -query-elevation-component.adoc
> > > [source-patterns] Unescaped symbol "->" on line #88:
> > > solr/solr-ref-guide/src/the
> > > -query-elevation-component.adoc
> > > [source-patterns] Unescaped symbol "->" on line #89:
> > > 

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 4a882739592aea109503c8e62c5730cd9b6ea64b in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a88273 ]

LUCENE-7906: Add missing override, fixing javadoc


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 752d57ef4e2e128fd03dccb681a3e0a05557f3b5 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=752d57e ]

LUCENE-7906: Add missing constructor to make precommit happy


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit daa12d18cade4fec523d53ceac3a3594aee017f4 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=daa12d1 ]

LUCENE-7906: Add missing constructor to make precommit happy


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9371:
---

Commit 227dbad4f71468613e8431322dcaf481caab07d0 in lucene-solr's branch 
refs/heads/branch_7_0 from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=227dbad ]

Correct SOLR_STOP_WAIT value in Solr Ref Guide (it changed from 5 to 180s in 
SOLR-9371).


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.3, 7.0
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

RE: ant precommit failing due to the solr dev guide

[Uwe Schindler]

I see no problems on windows jenkins and no problems on my local computer.

 

Steve’s script has a regex for matching newlines, but this one looks correct. 
Would it be possible to check, how the newlines look like on your *.adoc files 
(e.g., post a hexdump)?

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Thursday, August 3, 2017 5:33 PM
To: dev@lucene.apache.org
Subject: RE: ant precommit failing due to the solr dev guide

 

Hi,

 

Could be an newline issue in the groovy script… On windows some regex using \n 
or similar won’t match….

 

I will check on my system.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Karl Wright [mailto:daddy...@gmail.com] 
Sent: Thursday, August 3, 2017 5:08 PM
To: Lucene/Solr dev  >
Subject: Re: ant precommit failing due to the solr dev guide

 

Sure -- this is Windows 10, an older JDK 8: C:\Program Files\Java\jdk1.8.0_05

 

Anything else you are interested in?

 

Karl

 

 

On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  > wrote:

Hi Karl,

I looked at a couple of the errors, and they were all in "[source]" sections, 
which should be exempted from the “unescaped symbol” check, which is performed 
in the "-validate-source-patterns” target in the top-level build.xml.  The 
groovy method “checkForUnescapedSymbolSubstitutions” is where this “[source]” 
section exemption is supposed to happen.

The “-validate-source-patterns” target depends on “resolve-groovy”, which pins 
the version, so I don’t think this is an issue of stale build tools.

I don’t know how to reproduce the problem you’re seeing, so I’m not sure how to 
fix it.  Could you provide details on your platform?

--
Steve
www.lucidworks.com  


> On Aug 3, 2017, at 10:20 AM, Karl Wright   > wrote:
>
> 'When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?'
>
> This is on master, and yes, my work area is up to date.
> Any other ideas?  Have the required versions of some of the build tools 
> changed recently or something?
>
> Karl
>
>
>
> On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett   > wrote:
> Those are documentation-lint validations added via SOLR-10883 for the
> Solr Ref Guide (committed weeks ago).
>
> When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?
>
> On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright   > wrote:
> >
> > Getting this output:
> >
> > ...
> > [source-patterns] Unescaped symbol "->" on line #84:
> > solr/solr-ref-guide/src/res
> > ponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #87:
> > solr/solr-ref-guide/src/res
> > ult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #114:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #127:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #162:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #168:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #191:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #196:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #42:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #73:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #131:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "->" on line #153:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "<-" on line #43:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #45:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #48:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "->" on line #46:
> > 

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

I've come up with a different and less invasive way of fixing this.  If tests 
look good, will attach it soon.

I also tested the specific problem.  I created three cores and put minimal 
schemas in all of them.  The "bar" core had no name, but version="1.6".  The 
baz core had the "default-config" name, but no version.  The foo core was 
missing both.  This is what was logged:

{noformat}
2017-08-03 13:55:20.583 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema [baz] Schema name=default-config
2017-08-03 13:55:20.640 WARN  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema [foo] schema has no name, using exampleSchema
2017-08-03 13:55:20.661 WARN  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema [bar] schema has no name, using exampleSchema
2017-08-03 13:55:20.837 INFO  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.6 with uniqueid field id
2017-08-03 13:55:20.842 INFO  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.0 with uniqueid field id
2017-08-03 13:55:20.843 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema Loaded schema default-config/1.0 with uniqueid field id
{noformat}

The test suite is running now, it's a little less than ten percent done with no 
failures yet.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if either the name or version 
> is missing from the schema.  Although I can state that the user's minimal 
> config/schema are not very useful, Solr should not blow up without a useful 
> error message, and in this case, I think it should have worked, only emitting 
> a WARN message and assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-11153:

Description: 
A user on the mailing list was getting a very arcane error trying to load a 
very minimal solrconfig and schema.  The error was ultimately caused by NPE in 
SchemaXmlWriter.java at line 85.

The actual problem turned out to be a missing "name" attribute from the top 
level XML "schema" element in the file.

{code}


  


  
  _id
  

  

{code}

As written, the code will explode with an NPE if the name is missing from the 
schema.  Although I can state that the user's minimal config/schema are not 
very useful, Solr should not blow up without a useful error message, and in 
this case, I think it should have worked, only emitting a WARN message and 
assuming a default name.


  was:
A user on the mailing list was getting a very arcane error trying to load a 
very minimal solrconfig and schema.  The error was ultimately caused by NPE in 
SchemaXmlWriter.java at line 85.

The actual problem turned out to be a missing "name" attribute from the top 
level XML "schema" element in the file.

{code}


  


  
  _id
  

  

{code}

As written, the code will explode with an NPE if either the name or version is 
missing from the schema.  Although I can state that the user's minimal 
config/schema are not very useful, Solr should not blow up without a useful 
error message, and in this case, I think it should have worked, only emitting a 
WARN message and assuming a default name.



> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit c6ae0496627236b0108941e35cb4646935ad53c3 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c6ae049 ]

LUCENE-7906: Add missing override, fixing javadoc


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9371:
---

Commit 78b6e5031a49b7328cb27704a583044ebbcfe91d in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=78b6e50 ]

Correct SOLR_STOP_WAIT value in Solr Ref Guide (it changed from 5 to 180s in 
SOLR-9371).


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.3, 7.0
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

I committed this to master, branch_6x, and branch_7x.

[~ivera], I highly recommend "beasting" the new tests to see if we get anything 
out of them under more extreme conditions.  If very few iterations require a 
lot of time to come up with good shapes, it might worth reconsidering shape 
construction in the tests so that it is less likely to arrive at crazy shapes 
that need to be discarded.  We want to achieve confidence that the tests are in 
fact heavily exercising the logic you've written.

Thanks again for the contribution!  I will be looking forward to using this 
code myself in the next few months, depending on how things go.



> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

'When I run `ant precommit` on master on my machine, I don't get those
errors. Is your branch out of date perhaps?'

This is on master, and yes, my work area is up to date.
Any other ideas?  Have the required versions of some of the build tools
changed recently or something?

Karl



On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett 
wrote:

> Those are documentation-lint validations added via SOLR-10883 for the
> Solr Ref Guide (committed weeks ago).
>
> When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?
>
> On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright  wrote:
> >
> > Getting this output:
> >
> > ...
> > [source-patterns] Unescaped symbol "->" on line #84:
> > solr/solr-ref-guide/src/res
> > ponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #87:
> > solr/solr-ref-guide/src/res
> > ult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #114:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #127:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #162:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #168:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #191:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #196:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #42:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #73:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #131:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "->" on line #153:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "<-" on line #43:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #45:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #48:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "->" on line #46:
> > solr/solr-ref-guide/src/spe
> > ll-checking.adoc
> > [source-patterns] Unescaped symbol "->" on line #106:
> > solr/solr-ref-guide/src/sp
> > ell-checking.adoc
> > [source-patterns] Unescaped symbol "<=" on line #443:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #444:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #445:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #446:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "->" on line #38:
> > solr/solr-ref-guide/src/tak
> > ing-solr-to-production.adoc
> > [source-patterns] Unescaped symbol "->" on line #41:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #88:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #89:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #294:
> > solr/solr-ref-guide/src/to
> > kenizers.adoc
> > [source-patterns] Unescaped symbol "->" on line #361:
> > solr/solr-ref-guide/src/tr
> > ansforming-and-indexing-custom-json.adoc
> > [source-patterns] Unescaped symbol "->" on line #365:
> > solr/solr-ref-guide/src/tr
> > ansforming-and-indexing-custom-json.adoc
> > [source-patterns] Unescaped symbol "->" on line #367:
> > solr/solr-ref-guide/src/tr
> > ansforming-and-indexing-custom-json.adoc
> > [source-patterns] Unescaped symbol "->" on line #60:
> > solr/solr-ref-guide/src/uim
> > a-integration.adoc
> > [source-patterns] Unescaped symbol "->" on line #65:
> > solr/solr-ref-guide/src/uim
> > a-integration.adoc
> > [source-patterns] Unescaped symbol "->" on line #199:
> > solr/solr-ref-guide/src/up
> > loading-data-with-index-handlers.adoc
> > [source-patterns] Unescaped symbol "->" on line #209:
> > solr/solr-ref-guide/src/up
> > loading-data-with-index-handlers.adoc
> > [source-patterns] Unescaped symbol "->" on line #184:
> > solr/solr-ref-guide/src/up
> > loading-data-with-solr-cell-using-apache-tika.adoc
> > 

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 934db4a9c42af1186617afead7edb8dcebcb18eb in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=934db4a ]

LUCENE-7906: Fix ant precommit issue with test license header.


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: ant precommit failing due to the solr dev guide

[Steve Rowe]

Hi Karl,

I looked at a couple of the errors, and they were all in "[source]" sections, 
which should be exempted from the “unescaped symbol” check, which is performed 
in the "-validate-source-patterns” target in the top-level build.xml.  The 
groovy method “checkForUnescapedSymbolSubstitutions” is where this “[source]” 
section exemption is supposed to happen.

The “-validate-source-patterns” target depends on “resolve-groovy”, which pins 
the version, so I don’t think this is an issue of stale build tools. 

I don’t know how to reproduce the problem you’re seeing, so I’m not sure how to 
fix it.  Could you provide details on your platform?

--
Steve
www.lucidworks.com

> On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
> 
> 'When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?'
> 
> This is on master, and yes, my work area is up to date.
> Any other ideas?  Have the required versions of some of the build tools 
> changed recently or something?
> 
> Karl
> 
> 
> 
> On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett  
> wrote:
> Those are documentation-lint validations added via SOLR-10883 for the
> Solr Ref Guide (committed weeks ago).
> 
> When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?
> 
> On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright  wrote:
> >
> > Getting this output:
> >
> > ...
> > [source-patterns] Unescaped symbol "->" on line #84:
> > solr/solr-ref-guide/src/res
> > ponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #87:
> > solr/solr-ref-guide/src/res
> > ult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #114:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #127:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #162:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #168:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #191:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #196:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #42:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #73:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #131:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "->" on line #153:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "<-" on line #43:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #45:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #48:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "->" on line #46:
> > solr/solr-ref-guide/src/spe
> > ll-checking.adoc
> > [source-patterns] Unescaped symbol "->" on line #106:
> > solr/solr-ref-guide/src/sp
> > ell-checking.adoc
> > [source-patterns] Unescaped symbol "<=" on line #443:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #444:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #445:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #446:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "->" on line #38:
> > solr/solr-ref-guide/src/tak
> > ing-solr-to-production.adoc
> > [source-patterns] Unescaped symbol "->" on line #41:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #88:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #89:
> > solr/solr-ref-guide/src/the
> > -query-elevation-component.adoc
> > [source-patterns] Unescaped symbol "->" on line #294:
> > solr/solr-ref-guide/src/to
> > kenizers.adoc
> > [source-patterns] Unescaped symbol "->" on line #361:
> > solr/solr-ref-guide/src/tr
> > ansforming-and-indexing-custom-json.adoc
> > [source-patterns] Unescaped symbol "->" on line #365:
> > solr/solr-ref-guide/src/tr
> > ansforming-and-indexing-custom-json.adoc

[jira] [Updated] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey updated SOLR-11153:

Attachment: SOLR-11153.patch

Another updated patch.  This time the code changes are all in IndexSchema.  One 
of the main test schemas has been modified to remove "name" and "version" so 
hopefully this specific problem will get tested.

> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

RE: ant precommit failing due to the solr dev guide

[Uwe Schindler]

Hi,

 

Could be an newline issue in the groovy script… On windows some regex using \n 
or similar won’t match….

 

I will check on my system.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Karl Wright [mailto:daddy...@gmail.com] 
Sent: Thursday, August 3, 2017 5:08 PM
To: Lucene/Solr dev 
Subject: Re: ant precommit failing due to the solr dev guide

 

Sure -- this is Windows 10, an older JDK 8: C:\Program Files\Java\jdk1.8.0_05

 

Anything else you are interested in?

 

Karl

 

 

On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  > wrote:

Hi Karl,

I looked at a couple of the errors, and they were all in "[source]" sections, 
which should be exempted from the “unescaped symbol” check, which is performed 
in the "-validate-source-patterns” target in the top-level build.xml.  The 
groovy method “checkForUnescapedSymbolSubstitutions” is where this “[source]” 
section exemption is supposed to happen.

The “-validate-source-patterns” target depends on “resolve-groovy”, which pins 
the version, so I don’t think this is an issue of stale build tools.

I don’t know how to reproduce the problem you’re seeing, so I’m not sure how to 
fix it.  Could you provide details on your platform?

--
Steve
www.lucidworks.com  


> On Aug 3, 2017, at 10:20 AM, Karl Wright   > wrote:
>
> 'When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?'
>
> This is on master, and yes, my work area is up to date.
> Any other ideas?  Have the required versions of some of the build tools 
> changed recently or something?
>
> Karl
>
>
>
> On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett   > wrote:
> Those are documentation-lint validations added via SOLR-10883 for the
> Solr Ref Guide (committed weeks ago).
>
> When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?
>
> On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright   > wrote:
> >
> > Getting this output:
> >
> > ...
> > [source-patterns] Unescaped symbol "->" on line #84:
> > solr/solr-ref-guide/src/res
> > ponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #87:
> > solr/solr-ref-guide/src/res
> > ult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #114:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #127:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #162:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #168:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #191:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #196:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #42:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #73:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #131:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "->" on line #153:
> > solr/solr-ref-guide/src/sc
> > hemaless-mode.adoc
> > [source-patterns] Unescaped symbol "<-" on line #43:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #45:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "<-" on line #48:
> > solr/solr-ref-guide/src/sol
> > r-jdbc-r.adoc
> > [source-patterns] Unescaped symbol "->" on line #46:
> > solr/solr-ref-guide/src/spe
> > ll-checking.adoc
> > [source-patterns] Unescaped symbol "->" on line #106:
> > solr/solr-ref-guide/src/sp
> > ell-checking.adoc
> > [source-patterns] Unescaped symbol "<=" on line #443:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #444:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #445:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "<=" on line #446:
> > solr/solr-ref-guide/src/st
> > ream-evaluators.adoc
> > [source-patterns] Unescaped symbol "->" 

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

In parallel with running tests on Windows, I did "ant precommit" on a Linux 
machine with my patch applied.  There are failures that have nothing to do with 
my patch.  They look related to LUCENE-7194.  Lots of forbidden usages of 
java.lang.Math#toRadians(double) in a couple of spatial3d test classes.

I double-checked that my checkout of master was up to date and unmodified 
except for my patch for this issue.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit dd00446bb912cbb7143d4e8d2394ac9960735f49 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dd00446 ]

LUCENE-7906: Add missing constructor to make precommit happy


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9714) Ability to configure STOP_PORT

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9714:
---

Hello [~omar_abdelnabi] - thanks for attaching a patch. Your patch appears to 
be specifically for the

bq. ... Another related issue ... wondering about support for generally opting 
out of forceful kills ...

part of the conversation above. Could I suggest a separate 'new feature' JIRA 
issue/ticket since SOLR_PORT and SOLR_KILL_AFTER_WAIT configuration are related 
but independent features?


> Ability to configure STOP_PORT
> --
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools, SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: hu xiaodong
>Priority: Minor
> Attachments: SOLR-9714.patch, SOLR-9714.patch, SOLR-9714.patch
>
>
> Our system just has port planning,we have the requirement to configure what 
> to use as stop port explicitly. but now I can configure the stop_port on the 
> starting script($SOLR_HOME/bin/solr), but can not use the port to stop solr 
> gracefully. I think the script has a little problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11189) Provisioning actions for autoscaling

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-11189:


 Summary: Provisioning actions for autoscaling
 Key: SOLR-11189
 URL: https://issues.apache.org/jira/browse/SOLR-11189
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: AutoScaling
Reporter: Andrzej Bialecki 
 Fix For: master (8.0)


Autoscaling should be able to provision new nodes when necessary, or 
decommission no longer needed nodes. Solr should support a few common platforms 
out of the box (eg. AWS and Azure) with an API for integration with other 
platforms.

Auto-provisioning can already be implemented as a {{TriggerAction}}, however 
there are common non-trivial aspects that should be supported by the framework, 
such as:
* authentication to cluster manager APIs
* ability to consider cost vs. performance tradeoffs and constraints (avoiding 
over-provisioning and under-provisioning)
* maintaining cluster stability (avoiding trashing) while reacting with small 
delay and lag. These aspects will likely require some form of feedback loop 
controller.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11187) TestModelManagerPersistence improvements

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-11187:
--

 Summary: TestModelManagerPersistence improvements
 Key: SOLR-11187
 URL: https://issues.apache.org/jira/browse/SOLR-11187
 Project: Solr
  Issue Type: Test
  Components: contrib - LTR
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11167) bin/solr uses $SOLR_STOP_WAIT during start

[Omar Abdelnabi (JIRA)]

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

Omar Abdelnabi updated SOLR-11167:
--
Attachment: SOLR-11167.patch

Attaching a patch

> bin/solr uses $SOLR_STOP_WAIT during start
> --
>
> Key: SOLR-11167
> URL: https://issues.apache.org/jira/browse/SOLR-11167
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11167.patch
>
>
> bin/solr using $SOLR_STOP_WAIT during start is unexpected, I think it would 
> be clearer to have a separate $SOLR_START_WAIT variable.
> related minor thing: SOLR_STOP_WAIT is mentioned in solr.in.sh but not in 
> solr.in.cmd equivalent.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

[~cpoerschke], "ant precommit" for me blows up on the solr dev guide.  I've 
been blocked from using it for days.  I opened a discussion thread in the dev 
list.

Perhaps you know why this is happening for me?


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11163) Normalizer fails to restore itself when reload or restart solr cores.

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11163:
---
Attachment: SOLR-11163.patch

Hello [~yuyano] - thanks for identifying this problem and creating a patch to 
fix it. I have separated out your {{TestModelManagerPersistence}} improvements 
into SOLR-11187 and attaching here slightly revised 
{{Test(MinMax|Standard)Normalizer}} changes i.e. in the 
{{implTest(MinMax|Standard)}} method some {{\"}} quotes needed removing to make 
all the tests pass again.


> Normalizer fails to restore itself when reload or restart solr cores.
> -
>
> Key: SOLR-11163
> URL: https://issues.apache.org/jira/browse/SOLR-11163
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: 6.6
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
> Attachments: SOLR-11163.patch, SOLR-11163.patch
>
>
> Normalizer fails to restore itself from json file of its parameters when 
> reload or restart solr cores.
> This is because Normalizer#paramsToMap generates Map of parameters with 
> double quoted like below:
> {code:JavaScript}
> {
>   "min": "\"0.0\"",
>   "max": "\"1.0\""
> }
> {code}
> With the example above, Normalizer#newInstance fails to invoke setters due to 
> the failure of Float#parseFloat("\"0.0\"").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11187) TestModelManagerPersistence improvements

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-11187.

   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

Thanks [~yuyano]!

> TestModelManagerPersistence improvements
> 
>
> Key: SOLR-11187
> URL: https://issues.apache.org/jira/browse/SOLR-11187
> Project: Solr
>  Issue Type: Test
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11187.patch
>
>
> For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11163) Normalizer fails to restore itself when reload or restart solr cores.

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-11163.

   Resolution: Fixed
Fix Version/s: master (8.0)
   7.0

Thanks [~yuyano]!

> Normalizer fails to restore itself when reload or restart solr cores.
> -
>
> Key: SOLR-11163
> URL: https://issues.apache.org/jira/browse/SOLR-11163
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: 6.6
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11163.patch, SOLR-11163.patch
>
>
> Normalizer fails to restore itself from json file of its parameters when 
> reload or restart solr cores.
> This is because Normalizer#paramsToMap generates Map of parameters with 
> double quoted like below:
> {code:JavaScript}
> {
>   "min": "\"0.0\"",
>   "max": "\"1.0\""
> }
> {code}
> With the example above, Normalizer#newInstance fails to invoke setters due to 
> the failure of Float#parseFloat("\"0.0\"").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7906:
--

[~daddywri], thanks for committing this new feature, I hope it will prove very 
useful as well for my use case.  I am already using them in LUCENE with very 
promising results.

The big offender is the CONTAINS test as finding the right shape can be 
difficult because there is too much freedom. I have considered removing it all 
together as the feature is tested in the WITHIN test (being the opposite case). 
Then the tests converge quite fast.





> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11188) Hi CPU utilization when highlighting mergecontiguous=true

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11188:
-

Just skimming, nothing substantial, was looking into the code of *master* 
branch:

DefaultHighlighter :: 331-344
{code}
  //merge any contiguous fragments to improve readability
  if(mergeContiguousFragments)
  {
mergeContiguousFragments(frag);
ArrayList fragTexts = new ArrayList<>();
for (int i = 0; i < frag.length; i++)
{
  if ((frag[i] != null) && (frag[i].getScore() > 0))
  {
fragTexts.add(frag[i]);
  }
}
frag= fragTexts.toArray(new TextFragment[0]);
  }
{code}

Why do we have a *boolean* and a *function* with same name, 
{{mergeContiguousFragments}}? :(

Anyway the function: mergeContiguousFragments(frag ...)
{code}
private void mergeContiguousFragments(TextFragment[] frag)
  {
boolean mergingStillBeingDone;
if (frag.length > 1)
  do
  {
mergingStillBeingDone = false; //initialise loop control flag
//for each fragment, scan other frags looking for contiguous blocks
for (int i = 0; i < frag.length; i++)
{
  if (frag[i] == null)
  {
continue;
  }
  //merge any contiguous blocks
  for (int x = 0; x < frag.length; x++)
  {
if (frag[x] == null)
{
  continue;
}
if (frag[i] == null)
{
  break;
}
TextFragment frag1 = null;
TextFragment frag2 = null;
int frag1Num = 0;
int frag2Num = 0;
int bestScoringFragNum;
int worstScoringFragNum;
//if blocks are contiguous
if (frag[i].follows(frag[x]))
{
  frag1 = frag[x];
  frag1Num = x;
  frag2 = frag[i];
  frag2Num = i;
}
else
  if (frag[x].follows(frag[i]))
  {
frag1 = frag[i];
frag1Num = i;
frag2 = frag[x];
frag2Num = x;
  }
//merging required..
if (frag1 != null)
{
  if (frag1.getScore() > frag2.getScore())
  {
bestScoringFragNum = frag1Num;
worstScoringFragNum = frag2Num;
  }
  else
  {
bestScoringFragNum = frag2Num;
worstScoringFragNum = frag1Num;
  }
  frag1.merge(frag2);
  frag[worstScoringFragNum] = null;
  mergingStillBeingDone = true;
  frag[bestScoringFragNum] = frag1;
}
  }
}
  }
  while (mergingStillBeingDone);
  }
{code}

There is a valid condition on which the function returns, I don't see 
unreachable code here. Maybe on earlier versions or pardon me if I am looking 
at entirely different module / component.

> Hi CPU utilization when highlighting mergecontiguous=true
> -
>
> Key: SOLR-11188
> URL: https://issues.apache.org/jira/browse/SOLR-11188
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>
> A user's list thread indicates that Solr 6.3 has very high CPU utilization 
> with highlighting and mergecontiguous=true. This is a marker to see if we can 
> reproduce. Notes:
> 1> this was pre-unifiedhighlighter. 
> 2> unknown whether this is still an issue in more recent Solrs
> I'll ask the OP to comment here with additional details.
> Assigning to myself to track, I wont do any work on this for quite a while so 
> anyone who wants to please take it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9371) Fix bin/solr script calculations - start/stop wait time and RMI_PORT

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9371:
---

Commit bdb3ad58a825662b6491590d9335f6944ea3f0c0 in lucene-solr's branch 
refs/heads/branch_6x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bdb3ad5 ]

Correct SOLR_STOP_WAIT value in Solr Ref Guide (it changed from 5 to 180s in 
SOLR-9371).


> Fix bin/solr script calculations - start/stop wait time and RMI_PORT
> 
>
> Key: SOLR-9371
> URL: https://issues.apache.org/jira/browse/SOLR-9371
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 6.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Fix For: 6.3, 7.0
>
> Attachments: SOLR-9371.patch, SOLR-9371.patch, SOLR-9371.patch
>
>
> The bin/solr script doesn't wait long enough for Solr to stop before it sends 
> the KILL signal to the process.  The start could use a longer wait too.
> Also, the RMI_PORT is calculated by simply prefixing the port number with a 
> "1" instead of adding 1.  If the solr port has five digits, then the rmi 
> port will be invalid, because it will be greater than 65535.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-11153 at 8/3/17 2:10 PM:
-

I've come up with a different and less invasive way of fixing this.  If tests 
look good, will attach it soon.

I also tested the specific problem.  I created three cores and put minimal 
schemas in all of them.  The "bar" core had no name, but version="1.6".  The 
baz core had the "default-config" name, but no version.  The foo core was 
missing both.  This is what was logged when I stopped and started the modified 
server:

{noformat}
2017-08-03 13:55:20.583 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema [baz] Schema name=default-config
2017-08-03 13:55:20.640 WARN  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema [foo] schema has no name, using exampleSchema
2017-08-03 13:55:20.661 WARN  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema [bar] schema has no name, using exampleSchema
2017-08-03 13:55:20.837 INFO  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.6 with uniqueid field id
2017-08-03 13:55:20.842 INFO  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.0 with uniqueid field id
2017-08-03 13:55:20.843 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema Loaded schema default-config/1.0 with uniqueid field id
{noformat}

The test suite is running now, it's a little less than ten percent done with no 
failures yet.



was (Author: elyograg):
I've come up with a different and less invasive way of fixing this.  If tests 
look good, will attach it soon.

I also tested the specific problem.  I created three cores and put minimal 
schemas in all of them.  The "bar" core had no name, but version="1.6".  The 
baz core had the "default-config" name, but no version.  The foo core was 
missing both.  This is what was logged:

{noformat}
2017-08-03 13:55:20.583 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema [baz] Schema name=default-config
2017-08-03 13:55:20.640 WARN  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema [foo] schema has no name, using exampleSchema
2017-08-03 13:55:20.661 WARN  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema [bar] schema has no name, using exampleSchema
2017-08-03 13:55:20.837 INFO  (coreLoadExecutor-6-thread-1) [   x:bar] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.6 with uniqueid field id
2017-08-03 13:55:20.842 INFO  (coreLoadExecutor-6-thread-3) [   x:foo] 
o.a.s.s.IndexSchema Loaded schema exampleSchema/1.0 with uniqueid field id
2017-08-03 13:55:20.843 INFO  (coreLoadExecutor-6-thread-2) [   x:baz] 
o.a.s.s.IndexSchema Loaded schema default-config/1.0 with uniqueid field id
{noformat}

The test suite is running now, it's a little less than ten percent done with no 
failures yet.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if either the name or version 
> is missing from the schema.  Although I can state that the user's minimal 
> config/schema are not very useful, Solr should not blow up without a useful 
> error message, and in this case, I think it should have worked, only emitting 
> a WARN message and assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7897) RangeQuery optimization in IndexOrDocValuesQuery

[Murali Krishna P (JIRA)]

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

Murali Krishna P commented on LUCENE-7897:
--

Patched this into my elasticsearch setup and saw expected 2x improvement  (15ms 
instead of 30ms for 126476 hits), thanks a lot Adrien!


> RangeQuery optimization in IndexOrDocValuesQuery 
> -
>
> Key: LUCENE-7897
> URL: https://issues.apache.org/jira/browse/LUCENE-7897
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk, 7.0
>Reporter: Murali Krishna P
> Attachments: LUCENE-7897.patch
>
>
> For range queries, Lucene uses either Points or Docvalues based on cost 
> estimation 
> (https://lucene.apache.org/core/6_5_0/core/org/apache/lucene/search/IndexOrDocValuesQuery.html).
>  Scorer is chosen based on the minCost here: 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/Boolean2ScorerSupplier.java#L16
> However, the cost calculation for TermQuery and IndexOrDocvalueQuery seems to 
> have same weightage. Essentially, cost depends upon the docfreq in TermDict, 
> number of points visited and number of docvalues. In a situation where 
> docfreq is not too restrictive, this is lot of lookups for docvalues and 
> using points would have been better.
> Following query with 1M matches, takes 60ms with docvalues, but only 27ms 
> with points. If I change the query to "message:*", which matches all docs, it 
> choses the points(since cost is same), but with message:xyz it choses 
> docvalues eventhough doc frequency is 1million which results in many docvalue 
> fetches. Would it make sense to change the cost of docvalues query to be 
> higher or use points if the docfreq is too high for the term query(find an 
> optimum threshold where points cost < docvalue cost)?
> {noformat}
> {
>   "query": {
> "bool": {
>   "must": [
> {
>   "query_string": {
> "query": "message:xyz"
>   }
> },
> {
>   "range": {
> "@timestamp": {
>   "gte": 149865240,
>   "lte": 149890500,
>   "format": "epoch_millis"
> }
>   }
> }
>   ]
> }
>   }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11187) TestModelManagerPersistence improvements

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11187:
---
Reporter: Yuki Yano  (was: Christine Poerschke)

> TestModelManagerPersistence improvements
> 
>
> Key: SOLR-11187
> URL: https://issues.apache.org/jira/browse/SOLR-11187
> Project: Solr
>  Issue Type: Test
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11187.patch
>
>
> For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit e9ce58b20e182361790edf79a44c38e006395c38 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9ce58b ]

LUCENE-7906: Fix ant precommit issue with test license header.


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

[~ivera], I'm getting an "ant documentation-lint" error for the new class 
GeoCompositeAreaShape; says there's missing javadoc.  I can't find anything 
obviously wrong with it however.


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11187) TestModelManagerPersistence improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11187:


Commit c0a6ffe75d11a8ab9c47bcb6a87ac137e07efb6c in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0a6ffe ]

SOLR-11187: contrib/ltr TestModelManagerPersistence improvements. (Yuki Yano 
via Christine Poerschke)

* in testFeaturePersistence() method fix some assertJDelete vs. assertJQ 
copy/paste type issues
* add testFilePersistence() method


> TestModelManagerPersistence improvements
> 
>
> Key: SOLR-11187
> URL: https://issues.apache.org/jira/browse/SOLR-11187
> Project: Solr
>  Issue Type: Test
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11187.patch
>
>
> For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on LUCENE-7906:
-

The https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39d6be4 commit 
for this ticket appears to have broken {{ant precommit}} - specifically saying 
_Rat problems were found!_ re: missing Apache License header(s).

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-9714) Ability to configure STOP_PORT

[Omar Abdelnabi (JIRA)]

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

Omar Abdelnabi updated SOLR-9714:
-
Attachment: SOLR-9714.patch

Attaching a patch

> Ability to configure STOP_PORT
> --
>
> Key: SOLR-9714
> URL: https://issues.apache.org/jira/browse/SOLR-9714
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools, SolrCloud
>Affects Versions: 5.5.3, 6.2.1
>Reporter: hu xiaodong
>Priority: Minor
> Attachments: SOLR-9714.patch, SOLR-9714.patch, SOLR-9714.patch
>
>
> Our system just has port planning,we have the requirement to configure what 
> to use as stop port explicitly. but now I can configure the stop_port on the 
> starting script($SOLR_HOME/bin/solr), but can not use the port to stop solr 
> gracefully. I think the script has a little problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit a381bdbaaab60c9d53a574ba1c8a4b4815b51b85 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a381bdb ]

LUCENE-7906: Fix ant precommit issue with test license header.


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11163) Normalizer fails to restore itself when reload or restart solr cores.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11163:


Commit c297180cca19eff3f9ace04ef8e56e8418151bd0 in lucene-solr's branch 
refs/heads/master from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c297180 ]

SOLR-11163: Fix contrib/ltr Normalizer persistence after solr core reload or 
restart.
(Yuki Yano via Christine Poerschke)


> Normalizer fails to restore itself when reload or restart solr cores.
> -
>
> Key: SOLR-11163
> URL: https://issues.apache.org/jira/browse/SOLR-11163
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: 6.6
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
> Attachments: SOLR-11163.patch, SOLR-11163.patch
>
>
> Normalizer fails to restore itself from json file of its parameters when 
> reload or restart solr cores.
> This is because Normalizer#paramsToMap generates Map of parameters with 
> double quoted like below:
> {code:JavaScript}
> {
>   "min": "\"0.0\"",
>   "max": "\"1.0\""
> }
> {code}
> With the example above, Normalizer#newInstance fails to invoke setters due to 
> the failure of Float#parseFloat("\"0.0\"").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11187) TestModelManagerPersistence improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11187:


Commit a7fc7b6463a549f756c05971be4a6211b9c3a1e3 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a7fc7b6 ]

SOLR-11187: contrib/ltr TestModelManagerPersistence improvements. (Yuki Yano 
via Christine Poerschke)

* in testFeaturePersistence() method fix some assertJDelete vs. assertJQ 
copy/paste type issues
* add testFilePersistence() method


> TestModelManagerPersistence improvements
> 
>
> Key: SOLR-11187
> URL: https://issues.apache.org/jira/browse/SOLR-11187
> Project: Solr
>  Issue Type: Test
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11187.patch
>
>
> For clarity splitting this out from semi-related SOLR-11163 bug fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11163) Normalizer fails to restore itself when reload or restart solr cores.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11163:


Commit defefef87d78e86320bf178ac19f92a73f930277 in lucene-solr's branch 
refs/heads/branch_7x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=defefef ]

SOLR-11163: Fix contrib/ltr Normalizer persistence after solr core reload or 
restart.
(Yuki Yano via Christine Poerschke)


> Normalizer fails to restore itself when reload or restart solr cores.
> -
>
> Key: SOLR-11163
> URL: https://issues.apache.org/jira/browse/SOLR-11163
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Affects Versions: 6.6
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
> Attachments: SOLR-11163.patch, SOLR-11163.patch
>
>
> Normalizer fails to restore itself from json file of its parameters when 
> reload or restart solr cores.
> This is because Normalizer#paramsToMap generates Map of parameters with 
> double quoted like below:
> {code:JavaScript}
> {
>   "min": "\"0.0\"",
>   "max": "\"1.0\""
> }
> {code}
> With the example above, Normalizer#newInstance fails to invoke setters due to 
> the failure of Float#parseFloat("\"0.0\"").



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

The second test run on Windows passed solr-core completely but had one failure 
in solrj that doesn't look related to the patch.

> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

RE: ant precommit failing due to the solr dev guide

[Uwe Schindler]

Oh, I think I know:

Java 8 update 5: Please update and try again. Such old versions had problems in 
String#split(), I don’t exactly remember but they were able to return some 
duplicate/empty tokens.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Thursday, August 3, 2017 6:28 PM
To: 'dev@lucene.apache.org' 
Subject: RE: ant precommit failing due to the solr dev guide

 

I see no problems on windows jenkins and no problems on my local computer.

 

Steve’s script has a regex for matching newlines, but this one looks correct. 
Would it be possible to check, how the newlines look like on your *.adoc files 
(e.g., post a hexdump)?

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Thursday, August 3, 2017 5:33 PM
To: dev@lucene.apache.org  
Subject: RE: ant precommit failing due to the solr dev guide

 

Hi,

 

Could be an newline issue in the groovy script… On windows some regex using \n 
or similar won’t match….

 

I will check on my system.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Karl Wright [mailto:daddy...@gmail.com] 
Sent: Thursday, August 3, 2017 5:08 PM
To: Lucene/Solr dev  >
Subject: Re: ant precommit failing due to the solr dev guide

 

Sure -- this is Windows 10, an older JDK 8: C:\Program Files\Java\jdk1.8.0_05

 

Anything else you are interested in?

 

Karl

 

 

On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  > wrote:

Hi Karl,

I looked at a couple of the errors, and they were all in "[source]" sections, 
which should be exempted from the “unescaped symbol” check, which is performed 
in the "-validate-source-patterns” target in the top-level build.xml.  The 
groovy method “checkForUnescapedSymbolSubstitutions” is where this “[source]” 
section exemption is supposed to happen.

The “-validate-source-patterns” target depends on “resolve-groovy”, which pins 
the version, so I don’t think this is an issue of stale build tools.

I don’t know how to reproduce the problem you’re seeing, so I’m not sure how to 
fix it.  Could you provide details on your platform?

--
Steve
www.lucidworks.com  


> On Aug 3, 2017, at 10:20 AM, Karl Wright   > wrote:
>
> 'When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?'
>
> This is on master, and yes, my work area is up to date.
> Any other ideas?  Have the required versions of some of the build tools 
> changed recently or something?
>
> Karl
>
>
>
> On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett   > wrote:
> Those are documentation-lint validations added via SOLR-10883 for the
> Solr Ref Guide (committed weeks ago).
>
> When I run `ant precommit` on master on my machine, I don't get those
> errors. Is your branch out of date perhaps?
>
> On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright   > wrote:
> >
> > Getting this output:
> >
> > ...
> > [source-patterns] Unescaped symbol "->" on line #84:
> > solr/solr-ref-guide/src/res
> > ponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sponse-writers.adoc
> > [source-patterns] Unescaped symbol "->" on line #87:
> > solr/solr-ref-guide/src/res
> > ult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #114:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #127:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #162:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #168:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #185:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #191:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #196:
> > solr/solr-ref-guide/src/re
> > sult-clustering.adoc
> > [source-patterns] Unescaped symbol "->" on line #42:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > [source-patterns] Unescaped symbol "->" on line #73:
> > solr/solr-ref-guide/src/sch
> > ema-factory-definition-in-solrconfig.adoc
> > 

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

The new patch was created because I noticed that if there's no version, 1.0 is 
already assumed by IndexSchema, and if there's no name, this fact is logged 
before the NPE the original user encountered -- but no action is taken other 
than logging a warning.

With the patch, the user's schema should load as-is.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

With the first test run with an early version of the new patch, I got three 
failures in tests for solr-core.  They did not look related to my patch.

On a second test run that is still underway, where I had updated the patch to 
remove "name" and "version" from one of the test schemas to actually test this 
problem, more than half of the solr-core tests have been done with no failures 
yet.  The first run had its failures before that point.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11076) New /autoscaling/history API to return past cluster events and actions

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-11076:


Assignee: Andrzej Bialecki 

> New /autoscaling/history API to return past cluster events and actions
> --
>
> Key: SOLR-11076
> URL: https://issues.apache.org/jira/browse/SOLR-11076
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
>
> SOLR-11031 stores events and actions performed in response to those events in 
> the `.system` collection. We should expose this historical data through a new 
> API accessible at {{/autoscaling/history}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11153:
---

I ran precommit yesterday with no problems. What version of the JDK? Uwe made a 
comment recently about older JDKs having a problem that might be relevant.

> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11190) GraphQuery not working if field has only docValues

[Karthik Ramachandran (JIRA)]

Karthik Ramachandran created SOLR-11190:
---

 Summary: GraphQuery not working if field has only docValues
 Key: SOLR-11190
 URL: https://issues.apache.org/jira/browse/SOLR-11190
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Affects Versions: 6.6
Reporter: Karthik Ramachandran


Graph traversal is not working if field has only docValues since the 
construction of leaf or parent node queries uses only TermQuery.
\\ \\
{code:xml|title=managed-schema|borderStyle=solid}






id




{code}

{code}
curl -XPOST -H 'Content-Type: application/json' 
'http://localhost:8983/solr/graph/update' --data-binary ' {
 "add" : { "doc" : { "id" : "1", "name" : "Root1" } },
 "add" : { "doc" : { "id" : "2", "name" : "Root2" } },
 "add" : { "doc" : { "id" : "3", "name" : "Root3" } },
 "add" : { "doc" : { "id" : "11", "parentid" : "1", "name" : "Root1 Child1" } },
 "add" : { "doc" : { "id" : "12", "parentid" : "1", "name" : "Root1 Child2" } },
 "add" : { "doc" : { "id" : "13", "parentid" : "1", "name" : "Root1 Child3" } },
 "add" : { "doc" : { "id" : "21", "parentid" : "2", "name" : "Root2 Child1" } },
 "add" : { "doc" : { "id" : "22", "parentid" : "2", "name" : "Root2 Child2" } },
 "add" : { "doc" : { "id" : "121", "parentid" : "12", "name" : "Root12 Child1" 
} },
 "add" : { "doc" : { "id" : "122", "parentid" : "12", "name" : "Root12 Child2" 
} },
 "add" : { "doc" : { "id" : "131", "parentid" : "13", "name" : "Root13 Child1" 
} },
 "commit" : {}
}'
{code}

{code}
http://localhost:8983/solr/graph/select?q=*:*={!graph from=parentid 
to=id}id:1
or
http://localhost:8983/solr/graph/select?q=*:*={!graph from=id 
to=parentid}id:122
{code}





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11182:


Commit a13a966a01013d5376fe466040302ea56c0b77c3 in lucene-solr's branch 
refs/heads/branch_7x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a13a966 ]

SOLR-11182: A split shard failure on IOException should be logged


> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11182:


Commit 8cd2942e354687b6f655ef831d5d525d63dd46a8 in lucene-solr's branch 
refs/heads/master from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8cd2942 ]

SOLR-11182: A split shard failure on IOException should be logged


> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11191) Shard Split doesn't work on indexes that have nested documents

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-11191:


 Summary: Shard Split doesn't work on indexes that have nested 
documents
 Key: SOLR-11191
 URL: https://issues.apache.org/jira/browse/SOLR-11191
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


The split shard command doesn't split a shard correctly when the index has 
parent-child documents.

The way split shard works is it goes through all documents id's in that shard 
and then decides which sub-shard would it belong in . It is not aware of the 
parent child relationship during this process

So the parent-child documents could be orphaned and end up in different shard
Secondly, even with the routing of parent and child documents were the same 
split shards needs to re-index them as a block



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-11182:
-
Affects Version/s: 6.5
   6.6

> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11182:


Commit 1f00dff0994c499f3d7051c3f76ba7603654b4e9 in lucene-solr's branch 
refs/heads/branch_7_0 from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1f00dff ]

SOLR-11182: A split shard failure on IOException should be logged


> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11182) Solr doesn't log IOException if a shard split fails

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-11182.
--
   Resolution: Fixed
Fix Version/s: 7.0

Thanks Shalin for the review!

> Solr doesn't log IOException if a shard split fails
> ---
>
> Key: SOLR-11182
> URL: https://issues.apache.org/jira/browse/SOLR-11182
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5, 6.6
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 7.0
>
> Attachments: SOLR-11182.patch
>
>
> During a split shard operation the last message I see in the Solr logs was 
> this
> {code}
> date time INFO  (parallelCoreAdminExecutor... SPLIT) [   ] 
> o.a.s.u.SolrIndexWriter Calling setCommitData with 
> IW:org.apache.solr.update.SolrIndexWriter@hex
> {code}
> But the split never completed according the the request status API.
> {code}
> ...
>   "Operation splitshard caused exception:": 
> "org.apache.solr.common.SolrException:org.apache.solr.common.SolrException",
>   "exception": {
> "msg": null,
> "rspCode": 500
>   }
> {code}
> {{SolrIndexSplitter#split}} throws an IOException and in 
> DirectUpdateHandler2#split we catch it but never log an exception. We should 
> log the error and also throw it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11061) Add a spins metric for all directory paths

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-11061:


Assignee: Andrzej Bialecki 

> Add a spins metric for all directory paths
> --
>
> Key: SOLR-11061
> URL: https://issues.apache.org/jira/browse/SOLR-11061
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: 7.1
>
>
> See org.apache.lucene.util.IOUtils.spins. It currently only works for linux 
> and is used by ConcurrentMergeScheduler to set defaults for maxThreadCount 
> and maxMergeCount.
> We should expose this as a metric for solr.data.home and each core's data 
> dir. One thing to note is that the CMS overrides the value detected by the 
> spins method using {{lucene.cms.override_spins}} system property. This 
> property is supposed to be for tests but if it is set then the metrics API 
> should also take that into account.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

bq. What version of the JDK?

root@bigindy5:/index/src/lucene-solr# java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)

It is Oracle Java installed into Ubuntu 14 with a PPA.  I can upgrade it easily 
enough, which would likely make it 8u144.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7188:
--

The change is in the 5x series, just not back in 5.1 in particular.  You could 
back-port this yourself, in a fork.  Alternatively, you could probably fork 
NRTCachingDirectoryFactory with the related classes to fix yourself locally, 
then plug into solrconfig.

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>Assignee: Yonik Seeley
> Fix For: 6.1, 6.0.1, 5.5.1, 7.0
>
> Attachments: LUCENE-7188.patch
>
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+178) - Build # 20252 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20252/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

All tests passed

Build Log:
[...truncated 30893 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:601)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:602)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:603)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:604)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+178) - Build # 195 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/195/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest

Error Message:
8 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=11920, 
name=zkCallback-974-thread-4, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=11788, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[2034E0BC2B524864]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)   
  at 
java.base@9/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)3) 
Thread[id=11919, name=zkCallback-974-thread-3, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=11787, 
name=TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[2034E0BC2B524864]-SendThread(127.0.0.1:38295),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)5) 
Thread[id=11789, name=zkCallback-974-thread-1, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)6) 
Thread[id=11930, name=zkCallback-974-thread-5, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 

[jira] [Commented] (SOLR-10842) Move quickstart.html to Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10842:
--

I think I'm finally done with what I wanted to do here.

I read through the tutorial again, and it could likely use more incremental 
improvement, but that could be done later or once it's on master.

I decided the running-solr.adoc page was redundant - I moved its content about 
starting Solr after install/unpack to the installing-solr page. 

I also moved some of the pages under Getting Started to improved the flow - 
Upgrading a Solr Cluster now follows directly after Taking Solr to Production, 
which fits since they go together somewhat.

Upgrading Solr has been renamed to Solr Upgrade Notes to reflect the fact it's 
not an Upgrade Guide. With all of the above changes, I'm OK with keeping 
Getting Started as a name for the entire section, so don't plan to change that 
as I previously thought I might.

I'll give this a day or two and commit it to master if there isn't any feedback.

> Move quickstart.html to Ref Guide
> -
>
> Key: SOLR-10842
> URL: https://issues.apache.org/jira/browse/SOLR-10842
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10842.patch
>
>
> The Solr Quick Start at https://lucene.apache.org/solr/quickstart.html has 
> been problematic to keep up to date - until Ishan just updated it yesterday 
> for 6.6, it said "6.2.1", so hadn't been updated for several releases.
> Now that the Ref Guide is in AsciiDoc format, we can easily use variables for 
> package versions, and it could be released as part of the Ref Guide and kept 
> up to date. It could also integrate links to more information on topics, and 
> users would already be IN the docs, so they would not need to wonder where 
> the docs are.
> There are a few places on the site that will need to be updated to point to 
> the new location, but I can also put a redirect rule into .htaccess so people 
> are redirected to the new location if there are other links "in the wild" 
> that we cannot control. This allows it to be versioned also, if that becomes 
> necessary.
> As part of this, I would like to also update the entire "Getting Started" 
> section of the Ref Guide, which is effectively identical to what was in the 
> first release of the Ref Guide back in 2009 for Solr 1.4 and is in serious 
> need of reconsideration.
> My thought is that moving the page + redoing the Getting Started section 
> would be for 7.0, but if folks are excited about this idea I could move the 
> page for 6.6 and hold off redoing the larger section until 7.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11023:
--
Attachment: SOLR-11023.patch

WIP patch, hopefully code complete, more testing needed (described by Hoss'ss 
nocommits in EnumFieldTest).

Changes from Hoss'ss patch: Most nocommits are resolved.  I renamed 
HuperDuperEnumField to EnumFieldType. I decided not to support uninversion in 
EnumFieldType (I couldn't figure out how to make it work), and also to require 
docValues, since I think it would be a trap to allow a situation where sorting 
isn't supported over a field that claims to support arbitrary sorting over the 
enum values.  I've added a test to throw an exception when docvalues aren't 
enabled for an EnumFieldType field.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Lynn Monson (JIRA)]

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

Lynn Monson updated SOLR-11181:
---
Attachment: SOLR-11181.patch

This patch corrects the issue on master.

The patch removes the manual attachment of -src and -javadoc resources when 
invoking m2-deploy of pom.xml files.  The -src and -javadoc resources are 
already deployed implicitly as part of the pom.xml deploy.  Including the 
resources explicity is redundant and causes the redunant PUT to the maven 
repository.

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Priority: Minor
> Attachments: SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 23d383765b1effaf1df8fd5a0132d32dd17b6840 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23d3837 ]

LUCENE-7906: More fixes for precommit breakage: can't use Math.toRadians


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit ac1727d9480645f28c8ea749b622b3f60c8951d7 in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ac1727d ]

LUCENE-7906: More fixes for precommit breakage: can't use Math.toRadians


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_141) - Build # 20253 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20253/
Java: 32bit/jdk1.8.0_141 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=19229, name=jetty-launcher-2637-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=19241, name=jetty-launcher-2637-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=19229, name=jetty-launcher-2637-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on LUCENE-7906:
-

Commit 08be919d3e4029f7ab53dc37a62e7cfd764b03e7 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08be919d ]

LUCENE-7906: More fixes for precommit breakage: can't use Math.toRadians


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11023 at 8/3/17 6:55 PM:
---

WIP patch, hopefully code complete, more testing needed (described by Hoss'ss 
nocommits in EnumFieldTest).

Changes from Hoss'ss patch: Most nocommits are resolved.  I renamed 
HuperDuperEnumField to EnumFieldType. I decided not to support uninversion in 
EnumFieldType (I couldn't figure out how to make it work), and also to require 
docValues, since I think it would be a trap to allow a situation where sorting 
isn't supported over a field that claims to support arbitrary sorting over the 
enum values.  I've added a test to ensure that an exception is thrown when 
docvalues aren't enabled for an EnumFieldType field.


was (Author: steve_rowe):
WIP patch, hopefully code complete, more testing needed (described by Hoss'ss 
nocommits in EnumFieldTest).

Changes from Hoss'ss patch: Most nocommits are resolved.  I renamed 
HuperDuperEnumField to EnumFieldType. I decided not to support uninversion in 
EnumFieldType (I couldn't figure out how to make it work), and also to require 
docValues, since I think it would be a trap to allow a situation where sorting 
isn't supported over a field that claims to support arbitrary sorting over the 
enum values.  I've added a test to throw an exception when docvalues aren't 
enabled for an EnumFieldType field.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11153) Incomplete schema results in mysterious error

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11153:
-

Upgraded to Oracle 8u144 and I'm still seeing forbidden-api failures.

I eventually tracked down the problem to commits made this morning (in my 
timezone) for LUCENE-7606.


> Incomplete schema results in mysterious error
> -
>
> Key: SOLR-11153
> URL: https://issues.apache.org/jira/browse/SOLR-11153
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.4, 5.0, 6.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-11153.patch, SOLR-11153.patch, SOLR-11153.patch, 
> SOLR-11153.patch
>
>
> A user on the mailing list was getting a very arcane error trying to load a 
> very minimal solrconfig and schema.  The error was ultimately caused by NPE 
> in SchemaXmlWriter.java at line 85.
> The actual problem turned out to be a missing "name" attribute from the top 
> level XML "schema" element in the file.
> {code}
> 
> 
>   
>  required="true"/>
>  required="true"/>
>   
>   _id
>   
> 
>   
> 
> {code}
> As written, the code will explode with an NPE if the name is missing from the 
> schema.  Although I can state that the user's minimal config/schema are not 
> very useful, Solr should not blow up without a useful error message, and in 
> this case, I think it should have worked, only emitting a WARN message and 
> assuming a default name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7606) CustomAnalyzer.normalize only applies the last token filter

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-7606:
--

The commits this morning for this issue have broken precommit, by adding tests 
back in that use Math.toRadians, which was added to the forbidden-apis 
configuration by LUCENE-7194.


> CustomAnalyzer.normalize only applies the last token filter
> ---
>
> Key: LUCENE-7606
> URL: https://issues.apache.org/jira/browse/LUCENE-7606
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 7.0, 6.4
>
> Attachments: LUCENE-7606.patch
>
>
> This had not been uncovered by testing since we only tested with one token 
> filter at most.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (64bit/jdk1.8.0_141) - Build # 138 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/138/
Java: 64bit/jdk1.8.0_141 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.FieldFacetExtrasCloudTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([D6A92C496610243E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:59)
at 
org.apache.solr.analytics.facet.FieldFacetExtrasCloudTest.beforeClass(FieldFacetExtrasCloudTest.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica_t3","base_url":"http://127.0.0.1:37319","node_name":"127.0.0.1:37319_","state":"active","type":"TLOG","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/26)={   
"pullReplicas":"0",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:40833;,   
"core":"c8n_1x3_lf_shard1_replica_t1",   
"node_name":"127.0.0.1:40833_",   "type":"TLOG"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica_t2",   
"base_url":"http://127.0.0.1:34241;,   "node_name":"127.0.0.1:34241_",  
 "state":"down",   "type":"TLOG"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica_t3",   
"base_url":"http://127.0.0.1:37319;,   "node_name":"127.0.0.1:37319_",  
 "state":"active",   "type":"TLOG",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false",   "nrtReplicas":"0",   
"tlogReplicas":"3"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

Thanks, I'll update.

Karl


On Thu, Aug 3, 2017 at 12:30 PM, Uwe Schindler  wrote:

> Oh, I think I know:
>
> Java 8 update 5: Please update and try again. Such old versions had
> problems in String#split(), I don’t exactly remember but they were able to
> return some duplicate/empty tokens.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler [mailto:u...@thetaphi.de]
> *Sent:* Thursday, August 3, 2017 6:28 PM
> *To:* 'dev@lucene.apache.org' 
> *Subject:* RE: ant precommit failing due to the solr dev guide
>
>
>
> I see no problems on windows jenkins and no problems on my local computer.
>
>
>
> Steve’s script has a regex for matching newlines, but this one looks
> correct. Would it be possible to check, how the newlines look like on your
> *.adoc files (e.g., post a hexdump)?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler [mailto:u...@thetaphi.de ]
> *Sent:* Thursday, August 3, 2017 5:33 PM
> *To:* dev@lucene.apache.org
> *Subject:* RE: ant precommit failing due to the solr dev guide
>
>
>
> Hi,
>
>
>
> Could be an newline issue in the groovy script… On windows some regex
> using \n or similar won’t match….
>
>
>
> I will check on my system.
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Karl Wright [mailto:daddy...@gmail.com ]
> *Sent:* Thursday, August 3, 2017 5:08 PM
> *To:* Lucene/Solr dev 
> *Subject:* Re: ant precommit failing due to the solr dev guide
>
>
>
> Sure -- this is Windows 10, an older JDK 8: C:\Program
> Files\Java\jdk1.8.0_05
>
>
>
> Anything else you are interested in?
>
>
>
> Karl
>
>
>
>
>
> On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:
>
> Hi Karl,
>
> I looked at a couple of the errors, and they were all in "[source]"
> sections, which should be exempted from the “unescaped symbol” check, which
> is performed in the "-validate-source-patterns” target in the top-level
> build.xml.  The groovy method “checkForUnescapedSymbolSubstitutions” is
> where this “[source]” section exemption is supposed to happen.
>
> The “-validate-source-patterns” target depends on “resolve-groovy”, which
> pins the version, so I don’t think this is an issue of stale build tools.
>
> I don’t know how to reproduce the problem you’re seeing, so I’m not sure
> how to fix it.  Could you provide details on your platform?
>
> --
> Steve
> www.lucidworks.com
>
>
> > On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
> >
> > 'When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?'
> >
> > This is on master, and yes, my work area is up to date.
> > Any other ideas?  Have the required versions of some of the build tools
> changed recently or something?
> >
> > Karl
> >
> >
> >
> > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett 
> wrote:
> > Those are documentation-lint validations added via SOLR-10883 for the
> > Solr Ref Guide (committed weeks ago).
> >
> > When I run `ant precommit` on master on my machine, I don't get those
> > errors. Is your branch out of date perhaps?
> >
> > On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright  wrote:
> > >
> > > Getting this output:
> > >
> > > ...
> > > [source-patterns] Unescaped symbol "->" on line #84:
> > > solr/solr-ref-guide/src/res
> > > ponse-writers.adoc
> > > [source-patterns] Unescaped symbol "->" on line #185:
> > > solr/solr-ref-guide/src/re
> > > sponse-writers.adoc
> > > [source-patterns] Unescaped symbol "->" on line #87:
> > > solr/solr-ref-guide/src/res
> > > ult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #114:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #127:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #162:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #168:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #185:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #191:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #196:
> > > solr/solr-ref-guide/src/re
> > > sult-clustering.adoc
> > > [source-patterns] Unescaped symbol "->" on line #42:
> > > solr/solr-ref-guide/src/sch
> > > ema-factory-definition-in-solrconfig.adoc
> > > [source-patterns] Unescaped symbol "->" on line #73:
> > > 

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11181:
---

Thanks [~lmonson], great sleuthing!  I'll do a manual test run with your patch 
against the Apache snapshot repo before I commit, probably tomorrow.

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Priority: Minor
> Attachments: SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-11181:
-

Assignee: Steve Rowe

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+178) - Build # 196 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/196/
Java: 64bit/jdk-9-ea+178 -XX:+UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

All tests passed

Build Log:
[...truncated 30988 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:550)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:558)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:566)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:574)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:601)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:602)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:603)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 
org.apache.lucene.spatial3d.geom.SimpleGeoPolygonRelationshipsTest 
(SimpleGeoPolygonRelationshipsTest.java:604)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toRadians(double) 
[Use home-grown methods instead]
[forbidden-apis]   in 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi [~ichattopadhyaya],
Status for Today:
- Testing the new QPS calculation logic. 
Regards

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> Screenshot from 2017-07-30 20-30-05.png, SOLR-10317.patch, SOLR-10317.patch, 
> solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

1.8.0_45 didn't work either; downloading _144 now (will take a while).

Karl


On Thu, Aug 3, 2017 at 5:09 PM, Karl Wright  wrote:

> Thanks, I'll update.
>
> Karl
>
>
> On Thu, Aug 3, 2017 at 12:30 PM, Uwe Schindler  wrote:
>
>> Oh, I think I know:
>>
>> Java 8 update 5: Please update and try again. Such old versions had
>> problems in String#split(), I don’t exactly remember but they were able to
>> return some duplicate/empty tokens.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Uwe Schindler [mailto:u...@thetaphi.de]
>> *Sent:* Thursday, August 3, 2017 6:28 PM
>> *To:* 'dev@lucene.apache.org' 
>> *Subject:* RE: ant precommit failing due to the solr dev guide
>>
>>
>>
>> I see no problems on windows jenkins and no problems on my local computer.
>>
>>
>>
>> Steve’s script has a regex for matching newlines, but this one looks
>> correct. Would it be possible to check, how the newlines look like on your
>> *.adoc files (e.g., post a hexdump)?
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Uwe Schindler [mailto:u...@thetaphi.de ]
>> *Sent:* Thursday, August 3, 2017 5:33 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* RE: ant precommit failing due to the solr dev guide
>>
>>
>>
>> Hi,
>>
>>
>>
>> Could be an newline issue in the groovy script… On windows some regex
>> using \n or similar won’t match….
>>
>>
>>
>> I will check on my system.
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> http://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Karl Wright [mailto:daddy...@gmail.com ]
>> *Sent:* Thursday, August 3, 2017 5:08 PM
>> *To:* Lucene/Solr dev 
>> *Subject:* Re: ant precommit failing due to the solr dev guide
>>
>>
>>
>> Sure -- this is Windows 10, an older JDK 8: C:\Program
>> Files\Java\jdk1.8.0_05
>>
>>
>>
>> Anything else you are interested in?
>>
>>
>>
>> Karl
>>
>>
>>
>>
>>
>> On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:
>>
>> Hi Karl,
>>
>> I looked at a couple of the errors, and they were all in "[source]"
>> sections, which should be exempted from the “unescaped symbol” check, which
>> is performed in the "-validate-source-patterns” target in the top-level
>> build.xml.  The groovy method “checkForUnescapedSymbolSubstitutions” is
>> where this “[source]” section exemption is supposed to happen.
>>
>> The “-validate-source-patterns” target depends on “resolve-groovy”, which
>> pins the version, so I don’t think this is an issue of stale build tools.
>>
>> I don’t know how to reproduce the problem you’re seeing, so I’m not sure
>> how to fix it.  Could you provide details on your platform?
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>>
>> > On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
>> >
>> > 'When I run `ant precommit` on master on my machine, I don't get those
>> > errors. Is your branch out of date perhaps?'
>> >
>> > This is on master, and yes, my work area is up to date.
>> > Any other ideas?  Have the required versions of some of the build tools
>> changed recently or something?
>> >
>> > Karl
>> >
>> >
>> >
>> > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>> > Those are documentation-lint validations added via SOLR-10883 for the
>> > Solr Ref Guide (committed weeks ago).
>> >
>> > When I run `ant precommit` on master on my machine, I don't get those
>> > errors. Is your branch out of date perhaps?
>> >
>> > On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright  wrote:
>> > >
>> > > Getting this output:
>> > >
>> > > ...
>> > > [source-patterns] Unescaped symbol "->" on line #84:
>> > > solr/solr-ref-guide/src/res
>> > > ponse-writers.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #185:
>> > > solr/solr-ref-guide/src/re
>> > > sponse-writers.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #87:
>> > > solr/solr-ref-guide/src/res
>> > > ult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #114:
>> > > solr/solr-ref-guide/src/re
>> > > sult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #127:
>> > > solr/solr-ref-guide/src/re
>> > > sult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #162:
>> > > solr/solr-ref-guide/src/re
>> > > sult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #168:
>> > > solr/solr-ref-guide/src/re
>> > > sult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #185:
>> > > solr/solr-ref-guide/src/re
>> > > sult-clustering.adoc
>> > > [source-patterns] Unescaped symbol "->" on line #191:
>> > > solr/solr-ref-guide/src/re
>> > > 

[jira] [Comment Edited] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-11023 at 8/4/17 12:35 AM:


More complete WIP patch, almost done.

The tests are mostly fleshed out; there is one remaining nocommit, to add a 
test of set queries over an enum field.

Also, the docs need fixing up to mention the new type and the fact that the old 
type is deprecated.

I created SOLR-11193 for problems with multi-valued EnumField; I don't plan on 
blocking 7.0 for fixes there.  I've put assumes in EnumFieldTest to avoid 
testing the problematic functionality with EnumField.


was (Author: steve_rowe):
More complete WIP patch, almost done.

The tests are mostly fleshed out; there is one remaining nocommit, to add a 
test of set queries over.

Also, the docs need fixing up to mention the new type and the fact that the old 
type is deprecated.

I created SOLR-11193 for problems with multi-valued EnumField; I don't plan on 
blocking 7.0 for fixes there.  I've put assumes in EnumFieldTest to avoid 
testing the problematic functionality with EnumField.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch, SOLR-11023.patch, 
> SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11189) Provisioning actions for autoscaling

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11189:
--

Sounds cool!

We also need to ensure that the nodes provisioned or decommissioned by this 
action are not discovered again by other nodeLost or nodeAdded triggers.

> Provisioning actions for autoscaling
> 
>
> Key: SOLR-11189
> URL: https://issues.apache.org/jira/browse/SOLR-11189
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
> Fix For: master (8.0)
>
>
> Autoscaling should be able to provision new nodes when necessary, or 
> decommission no longer needed nodes. Solr should support a few common 
> platforms out of the box (eg. AWS and Azure) with an API for integration with 
> other platforms.
> Auto-provisioning can already be implemented as a {{TriggerAction}}, however 
> there are common non-trivial aspects that should be supported by the 
> framework, such as:
> * authentication to cluster manager APIs
> * ability to consider cost vs. performance tradeoffs and constraints 
> (avoiding over-provisioning and under-provisioning)
> * maintaining cluster stability (avoiding trashing) while reacting with small 
> delay and lag. These aspects will likely require some form of feedback loop 
> controller.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10701) sort=parentfield(name,{!child}) asc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-10701:

Attachment: SOLR-10701.patch

[^SOLR-10701.patch] goes with test.
This provides usage for LUCENE-7835. 

Here is the question: {{ToChildBlockJoinSortField}} in LUCENE-7835 allows 
passing child docs where sort field values are supplied. However, I don't see 
an easy way to pass it with Solr syntax 
({{q=\{!child..}...=parentfield(name) asc}}). [~jove4015], does it seems 
useful as-is?  

> sort=parentfield(name,{!child}) asc
> ---
>
> Key: SOLR-10701
> URL: https://issues.apache.org/jira/browse/SOLR-10701
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10701.patch, SOLR-10701.patch
>
>
> It's a twin-bro for SOLR-10521. When searching by {{\{!child}}} query we need 
> to order kids by a parent field. {{sort=parentfield(name,$q) asc}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10701) sort=parentfield(name,{!child}) asc

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10701 at 8/4/17 4:09 AM:
-

[^SOLR-10701.patch] goes with test.
This provides usage for LUCENE-7835. 

Here is the question: {{ToChildBlockJoinSortField}} in LUCENE-7835 allows 
passing child docs where sort field values are supplied. However, I don't see 
an easy way to pass it with Solr syntax 
({{q=\{!child..}...=parentfield(name) asc}}).

[~jove4015], does it seems useful as-is? 

The patch also introduces {{BlockJoinParentQParser.AllParentsQuerySupplier}} 
which is implemented by {{BlockJoinParentQParser.AllParentsAware}} 
{{BlockJoinChildQParser.AllParentsAwareToChildQuery}}. I wonder whether it's 
good enough to come in. 


was (Author: mkhludnev):
[^SOLR-10701.patch] goes with test.
This provides usage for LUCENE-7835. 

Here is the question: {{ToChildBlockJoinSortField}} in LUCENE-7835 allows 
passing child docs where sort field values are supplied. However, I don't see 
an easy way to pass it with Solr syntax 
({{q=\{!child..}...=parentfield(name) asc}}). [~jove4015], does it seems 
useful as-is?  

> sort=parentfield(name,{!child}) asc
> ---
>
> Key: SOLR-10701
> URL: https://issues.apache.org/jira/browse/SOLR-10701
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10701.patch, SOLR-10701.patch
>
>
> It's a twin-bro for SOLR-10521. When searching by {{\{!child}}} query we need 
> to order kids by a parent field. {{sort=parentfield(name,$q) asc}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10734) Multithreaded test/support for AtomicURP broken

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10734:

Attachment: testMaster_2500
testResults7_10
testResultsMaster_10
SOLR-10734.patch

I ran local beasts on system for master: 10 and 2500 rounds and branch_7x: 100 
for the patch uploaded recently in JIRA and it ran successfully. I am attaching 
the beast results too.

Changes done as explained above:
{code}
  // there is no gurantee of all the threads getting executed, even if one 
passes, concurrency works.
  public void testMultipleThreads() throws Exception {
clearIndex();
String[] strings = new String[5];
for (int i=0; i<5; i++) {
  strings[i] = generateRandomString();
}

List threads = new ArrayList<>(100);
int finalCount = 0; //int_i

AtomicUpdateProcessorFactory factory = new AtomicUpdateProcessorFactory();
factory.inform(h.getCore());

for (int i = 0; i < 10; i++) {
  int index = random().nextInt(5);
  Thread t = new Thread() {
@Override
public void run() {
  AddUpdateCommand cmd = new AddUpdateCommand(new 
LocalSolrQueryRequest(h.getCore(),
  new ModifiableSolrParams()
  .add("processor", "atomic")
  .add("atomic.cat", "add")
  .add("atomic.int_i", "inc")
  .add("commit","true")

  ));

  cmd.solrDoc = new SolrInputDocument();
  cmd.solrDoc.addField("id", 10); //hardcoded id=2
  cmd.solrDoc.addField("cat", strings[index]);
  cmd.solrDoc.addField("int_i", index);

  try {
factory.getInstance(cmd.getReq(), new SolrQueryResponse(),
new DistributedUpdateProcessor(cmd.getReq(), new 
SolrQueryResponse(),
new RunUpdateProcessor(cmd.getReq(), 
null))).processAdd(cmd);
  } catch (IOException e) {
  }
}
  };
  threads.add(t);
  t.start();
  finalCount += index; //int_i
}

for (Thread thread: threads) thread.join();

assertU(commit());

assertQ("Check the total number of docs",
req("q", "id:10"), "//result[@numFound=1]");


StringJoiner queryString = new StringJoiner(" OR ");
for(String string: strings) {
  queryString.add(string);
}

assertQ("Check the total number of docs",
req("q", "cat:(" + queryString.toString()+")")
, "//result[@numFound=1]");

assertQ("Check the total number of docs",
req("q", "int_i:[* TO " + finalCount+"]")
, "//result[@numFound=1]");

  }
{code}

significant changes:

cat:(A OR B OR C OR D) // proper parenthesized OR seperated query terms
int_i:[* to max_possible_sum] // range query for int_i, practically 0 to 
max_possible_sum

{code}
StringJoiner queryString = new StringJoiner(" OR ");
for(String string: strings) {
  queryString.add(string);
}
assertQ("Check the total number of docs",
req("q", "cat:(" + queryString.toString()+")")
, "//result[@numFound=1]");
assertQ("Check the total number of docs",
req("q", "int_i:[* TO " + finalCount+"]")
, "//result[@numFound=1]");
{code}

the thought process for the above is atleast one of the threads should execute 
for multiple seeds and multiple test configurations, heavy or light. This is 
the best I got, please let me know if anything else can be done in this regard. 
I understand we are approaching 7.0 release and we have this fixed in later 
version.

> Multithreaded test/support for AtomicURP broken
> ---
>
> Key: SOLR-10734
> URL: https://issues.apache.org/jira/browse/SOLR-10734
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
> Fix For: master (8.0), 7.1
>
> Attachments: log-snippet, Screen Shot 2017-05-31 at 4.50.23 PM.png, 
> SOLR-10734.patch, SOLR-10734.patch, SOLR-10734.patch, testMaster_2500, 
> testResults7_10, testResultsMaster_10
>
>
> The multithreaded test doesn't actually start the threads, but only invokes 
> the run directly. The join afterwards doesn't do anything, hence.
> {code}
> diff --git 
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
>  
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> index f3f833d..10b7770 100644
> --- 
> a/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> +++ 
> b/solr/core/src/test/org/apache/solr/update/processor/AtomicUpdateProcessorFactoryTest.java
> @@ -238,7 +238,7 @@ public class AtomicUpdateProcessorFactoryTest extends 
> SolrTestCaseJ4 {
>  

[jira] [Updated] (SOLR-11193) EnumField: multivalued sort and range queries don't work

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11193:
--
Description: 
In adding a non-Trie-based EnumField alternative in SOLR-11023, multi-valued 
sort and range tests fail for EnumField in EnumFieldTest.

Since EnumField will be deprecated in 7.0 (in favor of the SOLR-11023 
alternative) and removed in 8.0, I don't plan on blocking the 7.0 release for 
these problems.

  was:
In adding a non-Trie-based EnumField alternative in SOLR-11023, multi-valued 
sort and range tests fail for EnumField.

Since EnumField will be deprecated in 7.0 (in favor of the SOLR-11023 
alternative) and removed in 8.0, I don't plan on blocking the 7.0 release for 
these problems.


> EnumField: multivalued sort and range queries don't work
> 
>
> Key: SOLR-11193
> URL: https://issues.apache.org/jira/browse/SOLR-11193
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> In adding a non-Trie-based EnumField alternative in SOLR-11023, multi-valued 
> sort and range tests fail for EnumField in EnumFieldTest.
> Since EnumField will be deprecated in 7.0 (in favor of the SOLR-11023 
> alternative) and removed in 8.0, I don't plan on blocking the 7.0 release for 
> these problems.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: ant precommit failing due to the solr dev guide

[Karl Wright]

_144 also doesn't work for me.

Looking at one of the .adoc files, the checkout has CR/LF at the end of the
line, right after the "->" eg:



Is your git configured to checkout in native format?

Karl


On Thu, Aug 3, 2017 at 5:42 PM, Karl Wright  wrote:

> 1.8.0_45 didn't work either; downloading _144 now (will take a while).
>
> Karl
>
>
> On Thu, Aug 3, 2017 at 5:09 PM, Karl Wright  wrote:
>
>> Thanks, I'll update.
>>
>> Karl
>>
>>
>> On Thu, Aug 3, 2017 at 12:30 PM, Uwe Schindler  wrote:
>>
>>> Oh, I think I know:
>>>
>>> Java 8 update 5: Please update and try again. Such old versions had
>>> problems in String#split(), I don’t exactly remember but they were able to
>>> return some duplicate/empty tokens.
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> *From:* Uwe Schindler [mailto:u...@thetaphi.de]
>>> *Sent:* Thursday, August 3, 2017 6:28 PM
>>> *To:* 'dev@lucene.apache.org' 
>>> *Subject:* RE: ant precommit failing due to the solr dev guide
>>>
>>>
>>>
>>> I see no problems on windows jenkins and no problems on my local
>>> computer.
>>>
>>>
>>>
>>> Steve’s script has a regex for matching newlines, but this one looks
>>> correct. Would it be possible to check, how the newlines look like on your
>>> *.adoc files (e.g., post a hexdump)?
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> *From:* Uwe Schindler [mailto:u...@thetaphi.de ]
>>> *Sent:* Thursday, August 3, 2017 5:33 PM
>>> *To:* dev@lucene.apache.org
>>> *Subject:* RE: ant precommit failing due to the solr dev guide
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> Could be an newline issue in the groovy script… On windows some regex
>>> using \n or similar won’t match….
>>>
>>>
>>>
>>> I will check on my system.
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> *From:* Karl Wright [mailto:daddy...@gmail.com ]
>>> *Sent:* Thursday, August 3, 2017 5:08 PM
>>> *To:* Lucene/Solr dev 
>>> *Subject:* Re: ant precommit failing due to the solr dev guide
>>>
>>>
>>>
>>> Sure -- this is Windows 10, an older JDK 8: C:\Program
>>> Files\Java\jdk1.8.0_05
>>>
>>>
>>>
>>> Anything else you are interested in?
>>>
>>>
>>>
>>> Karl
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 3, 2017 at 11:04 AM, Steve Rowe  wrote:
>>>
>>> Hi Karl,
>>>
>>> I looked at a couple of the errors, and they were all in "[source]"
>>> sections, which should be exempted from the “unescaped symbol” check, which
>>> is performed in the "-validate-source-patterns” target in the top-level
>>> build.xml.  The groovy method “checkForUnescapedSymbolSubstitutions” is
>>> where this “[source]” section exemption is supposed to happen.
>>>
>>> The “-validate-source-patterns” target depends on “resolve-groovy”,
>>> which pins the version, so I don’t think this is an issue of stale build
>>> tools.
>>>
>>> I don’t know how to reproduce the problem you’re seeing, so I’m not sure
>>> how to fix it.  Could you provide details on your platform?
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>>
>>> > On Aug 3, 2017, at 10:20 AM, Karl Wright  wrote:
>>> >
>>> > 'When I run `ant precommit` on master on my machine, I don't get those
>>> > errors. Is your branch out of date perhaps?'
>>> >
>>> > This is on master, and yes, my work area is up to date.
>>> > Any other ideas?  Have the required versions of some of the build
>>> tools changed recently or something?
>>> >
>>> > Karl
>>> >
>>> >
>>> >
>>> > On Thu, Aug 3, 2017 at 9:18 AM, Cassandra Targett <
>>> casstarg...@gmail.com> wrote:
>>> > Those are documentation-lint validations added via SOLR-10883 for the
>>> > Solr Ref Guide (committed weeks ago).
>>> >
>>> > When I run `ant precommit` on master on my machine, I don't get those
>>> > errors. Is your branch out of date perhaps?
>>> >
>>> > On Thu, Aug 3, 2017 at 7:56 AM, Karl Wright 
>>> wrote:
>>> > >
>>> > > Getting this output:
>>> > >
>>> > > ...
>>> > > [source-patterns] Unescaped symbol "->" on line #84:
>>> > > solr/solr-ref-guide/src/res
>>> > > ponse-writers.adoc
>>> > > [source-patterns] Unescaped symbol "->" on line #185:
>>> > > solr/solr-ref-guide/src/re
>>> > > sponse-writers.adoc
>>> > > [source-patterns] Unescaped symbol "->" on line #87:
>>> > > solr/solr-ref-guide/src/res
>>> > > ult-clustering.adoc
>>> > > [source-patterns] Unescaped symbol "->" on line #114:
>>> > > solr/solr-ref-guide/src/re
>>> > > sult-clustering.adoc
>>> > > [source-patterns] Unescaped symbol "->" on line #127:
>>> > > solr/solr-ref-guide/src/re
>>> > > 

[jira] [Created] (SOLR-11192) Deploying maven artifacts should provide a way to use a custom settings.xml file

[Lynn Monson (JIRA)]

Lynn Monson created SOLR-11192:
--

 Summary: Deploying maven artifacts should provide a way to use a 
custom settings.xml file
 Key: SOLR-11192
 URL: https://issues.apache.org/jira/browse/SOLR-11192
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: 6.6, 5.5.4, 4.10.4, 7.0, master (8.0), 7.1
Reporter: Lynn Monson
Priority: Minor
 Fix For: master (8.0), 7.1


Maven, and the related maven plugins used by the ANT build system, provide a 
way to specify a custom settings file describing your maven repositories.

However, the current ANT build system does not provide a way to pass the name 
of such a settings file to maven.

This issue proposed to add a m2.settings.file ANT property that could be used 
to specify the settings file.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.0-Linux (32bit/jdk-9-ea+178) - Build # 139 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/139/
Java: 32bit/jdk-9-ea+178 -client -XX:+UseParallelGC --illegal-access=deny

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest

Error Message:
9 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest: 1) Thread[id=4760, 
name=zkCallback-724-thread-1, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=4964, name=zkCallback-724-thread-4, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=4757, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@9/java.lang.Thread.run(Thread.java:844)4) 
Thread[id=4962, name=zkCallback-724-thread-2, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)5) 
Thread[id=4963, name=zkCallback-724-thread-3, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462)
 at 
java.base@9/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361)
 at 
java.base@9/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1085)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9/java.lang.Thread.run(Thread.java:844)6) 
Thread[id=4980, name=zkCallback-724-thread-5, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeTest] at 
java.base@9/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
 at