date:20201001



muse-dev[bot] commented on a change in pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#discussion_r498037436



##
File path: solr/core/src/java/org/apache/solr/api/CustomContainerPlugins.java
##
@@ -163,6 +174,47 @@ public synchronized void refresh() {
 }
   }
 
+  private void handleClusterSingleton(ApiInfo newApiInfo, ApiInfo oldApiInfo) {
+if (newApiInfo != null) {
+  // register new api
+  Object instance = newApiInfo.getInstance();
+  if (instance instanceof ClusterSingleton) {
+ClusterSingleton singleton = (ClusterSingleton) instance;
+
coreContainer.getClusterSingletons().getSingletons().put(singleton.getName(), 
singleton);
+// easy check to see if we should immediately start this singleton
+if (coreContainer.getClusterEventProducer() != null &&
+coreContainer.getClusterEventProducer().isRunning()) {
+  try {
+singleton.start();
+  } catch (Exception exc) {
+log.warn("Exception starting ClusterSingleton {}: {}", newApiInfo, 
exc);
+  }
+}
+  }
+  if (instance instanceof ClusterEventListener) {
+// XXX nocommit obtain a list of supported event types from the config
+ClusterEvent.EventType[] types = ClusterEvent.EventType.values();
+try {
+  
coreContainer.getClusterEventProducer().registerListener((ClusterEventListener) 
instance, types);
+} catch (Exception exc) {
+  log.warn("Exception adding ClusterEventListener {}: {}", newApiInfo, 
exc);
+}
+  }
+}
+if (oldApiInfo != null) {
+  // stop & unregister the old api
+  Object instance = oldApiInfo.getInstance();
+  if (instance instanceof ClusterSingleton) {
+ClusterSingleton singleton = (ClusterSingleton) instance;
+singleton.stop();
+
coreContainer.getClusterSingletons().getSingletons().remove(singleton.getName());
+  }
+  if (instance instanceof ClusterEventListener) {
+
coreContainer.getClusterEventProducer().unregisterListener((ClusterEventListener)
 instance);

Review comment:
   *NULL_DEREFERENCE:*  object returned by 
`CustomContainerPlugins.coreContainer.getClusterEventProducer()` could be null 
and is dereferenced at line 213.





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

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



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

[jira] [Commented] (SOLR-14151) Make schema components load from packages



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

Ishan Chattopadhyaya commented on SOLR-14151:
-

[~tflobbe], this build was triggered after Noble did a flawed cherry-pick from 
master to branch_8x. I fixed it immediately after that, but this run may have 
been triggered between those two commits.

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 13.5h
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



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

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

[jira] [Commented] (SOLR-14151) Make schema components load from packages



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

Ishan Chattopadhyaya commented on SOLR-14151:
-

bq. Ishan Chattopadhyaya looks good on branch_8x.
Thanks Daniel.

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 13.5h
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



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

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

[GitHub] [lucene-solr] chatman commented on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.



chatman commented on pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-701962594


   I see that things like these are getting added to solr-core:
   
   CollectionsAddedEvent
   CollectionsRemovedEvent
   NodesDownEvent
   ReplicasDownEvent
   ClusterPropertiesChangedEvent
   
   Reminded me of "Lousiana is expecting a rain event": 
https://www.youtube.com/watch?v=vdPy5Ikn7dw



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

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



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

[GitHub] [lucene-solr] chatman commented on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.



chatman commented on pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-701966468


   > IMHO ClusterEventListener-s make sense only if they are also 
ClusterSingleton-s
   
   So, does this mean that ClusterSingleton is the trojan horse with which come 
so many *Event classes into solr-core? If I can  convince Noble and you on not 
putting ClusterSingleton interface into solr-core (and instead have a separate 
module for that), can we get away without such classes (and potentially tons 
more for other Events in future) in the core?



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

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



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

[GitHub] [lucene-solr] bruno-roustant closed pull request #1934: SOLR-14905: Update commons-io version to 2.8.0

2020-10-01 Thread ASF subversion and git services (Jira)



bruno-roustant closed pull request #1934:
URL: https://github.com/apache/lucene-solr/pull/1934


   



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

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



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

[jira] [Commented] (SOLR-14905) Update commons-io version to 2.8.0 due to security vulnerability



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

ASF subversion and git services commented on SOLR-14905:


Commit 167c3050df57a0e2558119e83fe3223fb66e9bf1 in lucene-solr's branch 
refs/heads/master from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=167c305 ]

SOLR-14905: Upgrade commons-io version to 2.8.0.
Closes #1934


> Update commons-io version to 2.8.0 due to security vulnerability
> 
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The 
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the 
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556, 
> https://issues.apache.org/jira/browse/IO-559) 



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

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

[jira] [Comment Edited] (SOLR-14749) Provide a clean API for cluster-level event processing



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

Noble Paul edited comment on SOLR-14749 at 10/1/20, 8:17 AM:
-

Here is my official -1 on this PR. There is not reason why this should belong 
to core


was (Author: noble.paul):
Here is my official -1 on this PR

> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: clean-api
> Fix For: master (9.0)
>
>  Time Spent: 14h 10m
>  Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean, 
> strongly typed API for the functionality formerly known as "triggers" - that 
> is, a component for generating cluster-level events corresponding to changes 
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing 
> in 9.0. However, this functionality is crucial for implementing the automatic 
> collection repair and re-balancing as the cluster state changes (nodes going 
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers 
> that at least can perform automatic collection repair (maintaining the 
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using 
> existing CollectionAdmin API, which in turn may use the placement plugins 
> from SOLR-14613.
> h3. Division of responsibility
>  * built-in Solr components (non-pluggable):
>  ** cluster state monitoring and event generation,
>  ** simple scheduler to periodically generate scheduled events
>  * plugins:
>  ** automatic collection repair on {{nodeLost}} events (provided by default)
>  ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
>  ** reporting (eg. requesting additional node provisioning)
>  ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one 
> designated node in the cluster. Currently the easiest way to implement this 
> is to run them on the Overseer leader node.



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

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

[jira] [Commented] (SOLR-14749) Provide a clean API for cluster-level event processing



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

Noble Paul commented on SOLR-14749:
---

Here is my official -1 on this PR

> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: clean-api
> Fix For: master (9.0)
>
>  Time Spent: 14h 10m
>  Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean, 
> strongly typed API for the functionality formerly known as "triggers" - that 
> is, a component for generating cluster-level events corresponding to changes 
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing 
> in 9.0. However, this functionality is crucial for implementing the automatic 
> collection repair and re-balancing as the cluster state changes (nodes going 
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers 
> that at least can perform automatic collection repair (maintaining the 
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using 
> existing CollectionAdmin API, which in turn may use the placement plugins 
> from SOLR-14613.
> h3. Division of responsibility
>  * built-in Solr components (non-pluggable):
>  ** cluster state monitoring and event generation,
>  ** simple scheduler to periodically generate scheduled events
>  * plugins:
>  ** automatic collection repair on {{nodeLost}} events (provided by default)
>  ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
>  ** reporting (eg. requesting additional node provisioning)
>  ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one 
> designated node in the cluster. Currently the easiest way to implement this 
> is to run them on the Overseer leader node.



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

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

[jira] [Comment Edited] (SOLR-14749) Provide a clean API for cluster-level event processing

2020-10-01 Thread ASF subversion and git services (Jira)



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

Noble Paul edited comment on SOLR-14749 at 10/1/20, 8:26 AM:
-

Here is my official -1 on this PR. We would like to have  a proper discussion 
around why why this should belong to core. We do not want to repeat the same 
mistakes we did with the previous autoscaling


was (Author: noble.paul):
Here is my official -1 on this PR. There is not reason why this should belong 
to core

> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: clean-api
> Fix For: master (9.0)
>
>  Time Spent: 14h 10m
>  Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean, 
> strongly typed API for the functionality formerly known as "triggers" - that 
> is, a component for generating cluster-level events corresponding to changes 
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing 
> in 9.0. However, this functionality is crucial for implementing the automatic 
> collection repair and re-balancing as the cluster state changes (nodes going 
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers 
> that at least can perform automatic collection repair (maintaining the 
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using 
> existing CollectionAdmin API, which in turn may use the placement plugins 
> from SOLR-14613.
> h3. Division of responsibility
>  * built-in Solr components (non-pluggable):
>  ** cluster state monitoring and event generation,
>  ** simple scheduler to periodically generate scheduled events
>  * plugins:
>  ** automatic collection repair on {{nodeLost}} events (provided by default)
>  ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
>  ** reporting (eg. requesting additional node provisioning)
>  ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one 
> designated node in the cluster. Currently the easiest way to implement this 
> is to run them on the Overseer leader node.



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

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

[jira] [Commented] (SOLR-14835) Solr 8.6.x log starts with "XmlConfiguration Ignored arg" warning from Jetty



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

ASF subversion and git services commented on SOLR-14835:


Commit a50c108433c9c5fc79f7ccd7bf309ad3b2e5fe3d in lucene-solr's branch 
refs/heads/branch_8_6 from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a50c108 ]

SOLR-14835: Add a note about incorrect Jetty message.


> Solr 8.6.x log starts with "XmlConfiguration Ignored arg" warning from Jetty
> 
>
> Key: SOLR-14835
> URL: https://issues.apache.org/jira/browse/SOLR-14835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.6.2
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Trivial
>
> After moving to 8.6.2 the first lines of the solr.log are
> {noformat}
> 2020-09-06 18:19:09.164 INFO  (main) [   ] o.e.j.u.log Logging initialized 
> @1197ms to org.eclipse.jetty.util.log.Slf4jLog
> 2020-09-06 18:19:09.226 WARN  (main) [   ] o.e.j.u.l.o.e.j.x.XmlConfiguration 
> Ignored arg: 
>  class="com.codahale.metrics.jetty9.InstrumentedQueuedThreadPool"> name="registry">
>  class="com.codahale.metrics.SharedMetricRegistries">solr.jetty
>   
>   
> {noformat}
> This config is declared here: 
> https://github.com/apache/lucene-solr/blob/5154b6008f54c9d096f5efe9ae347492c23dd780/solr/server/etc/jetty.xml#L33
>  and has been there for a long time, so I assume it's the bump in Jetty 
> version that's causing it now.
> I'm seeing this in 8.6.2, but I've not gone back to check other versions



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

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

[jira] [Resolved] (SOLR-14835) Solr 8.6.x log starts with "XmlConfiguration Ignored arg" warning from Jetty

2020-10-01 Thread Andrzej Bialecki (Jira)



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

Andrzej Bialecki resolved SOLR-14835.
-
Fix Version/s: 8.6.3
   Resolution: Not A Problem

Summary: the message is invalid due to a bug in Jetty 9.4.27, and it will be 
resolved by a Jetty upgrade.

> Solr 8.6.x log starts with "XmlConfiguration Ignored arg" warning from Jetty
> 
>
> Key: SOLR-14835
> URL: https://issues.apache.org/jira/browse/SOLR-14835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.6.2
>Reporter: Colvin Cowie
>Assignee: Andrzej Bialecki
>Priority: Trivial
> Fix For: 8.6.3
>
>
> After moving to 8.6.2 the first lines of the solr.log are
> {noformat}
> 2020-09-06 18:19:09.164 INFO  (main) [   ] o.e.j.u.log Logging initialized 
> @1197ms to org.eclipse.jetty.util.log.Slf4jLog
> 2020-09-06 18:19:09.226 WARN  (main) [   ] o.e.j.u.l.o.e.j.x.XmlConfiguration 
> Ignored arg: 
>  class="com.codahale.metrics.jetty9.InstrumentedQueuedThreadPool"> name="registry">
>  class="com.codahale.metrics.SharedMetricRegistries">solr.jetty
>   
>   
> {noformat}
> This config is declared here: 
> https://github.com/apache/lucene-solr/blob/5154b6008f54c9d096f5efe9ae347492c23dd780/solr/server/etc/jetty.xml#L33
>  and has been there for a long time, so I assume it's the bump in Jetty 
> version that's causing it now.
> I'm seeing this in 8.6.2, but I've not gone back to check other versions



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

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

[jira] [Commented] (SOLR-14749) Provide a clean API for cluster-level event processing

2020-10-01 Thread ASF subversion and git services (Jira)



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

Ishan Chattopadhyaya commented on SOLR-14749:
-

bq. I would like to see a separate PR for ClusterSingleton and commit that 
separately.

[~noble.paul], my objections to putting ClusterSingleton in solr-core stands. 
But, I shall not veto on these grounds if all of you are convinced that is the 
only way forward. Here's another reason why I am not pleased to have it: 
https://github.com/apache/lucene-solr/pull/1758#issuecomment-701966468. 
Unfortunately, I am very busy at the moment (personal travel and other work) 
and won't be able to engage/help in this issue; apologies (will probably have a 
more relaxed schedule after 15-20 days).

> Provide a clean API for cluster-level event processing
> --
>
> Key: SOLR-14749
> URL: https://issues.apache.org/jira/browse/SOLR-14749
> Project: Solr
>  Issue Type: Improvement
>  Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>  Labels: clean-api
> Fix For: master (9.0)
>
>  Time Spent: 14h 10m
>  Remaining Estimate: 0h
>
> This is a companion issue to SOLR-14613 and it aims at providing a clean, 
> strongly typed API for the functionality formerly known as "triggers" - that 
> is, a component for generating cluster-level events corresponding to changes 
> in the cluster state, and a pluggable API for processing these events.
> The 8x triggers have been removed so this functionality is currently missing 
> in 9.0. However, this functionality is crucial for implementing the automatic 
> collection repair and re-balancing as the cluster state changes (nodes going 
> down / up, becoming overloaded / unused / decommissioned, etc).
> For this reason we need this API and a default implementation of triggers 
> that at least can perform automatic collection repair (maintaining the 
> desired replication factor in presence of live node changes).
> As before, the actual changes to the collections will be executed using 
> existing CollectionAdmin API, which in turn may use the placement plugins 
> from SOLR-14613.
> h3. Division of responsibility
>  * built-in Solr components (non-pluggable):
>  ** cluster state monitoring and event generation,
>  ** simple scheduler to periodically generate scheduled events
>  * plugins:
>  ** automatic collection repair on {{nodeLost}} events (provided by default)
>  ** re-balancing of replicas (periodic or on {{nodeAdded}} events)
>  ** reporting (eg. requesting additional node provisioning)
>  ** scheduled maintenance (eg. removing inactive shards after split)
> h3. Other considerations
> These plugins (unlike the placement plugins) need to execute on one 
> designated node in the cluster. Currently the easiest way to implement this 
> is to run them on the Overseer leader node.



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

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

[jira] [Commented] (SOLR-14905) Update commons-io version to 2.8.0 due to security vulnerability



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

ASF subversion and git services commented on SOLR-14905:


Commit db4bc94480a4a122dae031619cffeef8b9b1aa8f in lucene-solr's branch 
refs/heads/branch_8x from Bruno Roustant
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db4bc94 ]

SOLR-14905: Upgrade commons-io version to 2.8.0.

Closes #1935


> Update commons-io version to 2.8.0 due to security vulnerability
> 
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The 
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the 
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556, 
> https://issues.apache.org/jira/browse/IO-559) 



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

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

[GitHub] [lucene-solr] bruno-roustant closed pull request #1935: SOLR-14905: Update commons-io version to 2.8.0



bruno-roustant closed pull request #1935:
URL: https://github.com/apache/lucene-solr/pull/1935


   



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

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



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

[jira] [Resolved] (SOLR-14905) Update commons-io version to 2.8.0 due to security vulnerability

2020-10-01 Thread Bruno Roustant (Jira)



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

Bruno Roustant resolved SOLR-14905.
---
Fix Version/s: 8.7
   Resolution: Fixed

Thanks [~nazerke], this is in.

> Update commons-io version to 2.8.0 due to security vulnerability
> 
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The 
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the 
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556, 
> https://issues.apache.org/jira/browse/IO-559) 



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

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

[GitHub] [lucene-solr] murblanc commented on pull request #1758: SOLR-14749: Provide a clean API for cluster-level event processing, Initial draft.



murblanc commented on pull request #1758:
URL: https://github.com/apache/lucene-solr/pull/1758#issuecomment-702014402


   The way I look at this: can code other than Solr Core know what happens 
within Solr core to generate the corresponding events? I would tend to say no. 
I'm not talking about implementation shortcuts (Solr core internal DB a.k.a. 
Zookeeper being accessible to the world and can be used to generate some of the 
events) but fundamentally what state changes do these events (or some of these 
events) represent and where does that state live?



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

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



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

[jira] [Created] (LUCENE-9552) Add a LatLonPoint query that accepts an array of LatLonGeometries

2020-10-01 Thread Ignacio Vera (Jira)

Ignacio Vera created LUCENE-9552:


 Summary: Add a LatLonPoint query that accepts an array of 
LatLonGeometries
 Key: LUCENE-9552
 URL: https://issues.apache.org/jira/browse/LUCENE-9552
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ignacio Vera


LatLonPoint currently support three types of queries, against a bound box, an 
array of polygons or by distance (circle). Therefore if you currently want to 
combine a query with two of those geometries, a user will need to combine the 
query with a boolean OR.

It would be a nice addition to have a query that accepts an array of 
LatLonGeometries and generates that boolean OR query in a single query. 



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

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

[jira] [Created] (LUCENE-9553) Add a XYPoint query that accepts an array of XYGeometries

2020-10-01 Thread Ignacio Vera (Jira)

Ignacio Vera created LUCENE-9553:


 Summary: Add a XYPoint query that accepts an array of XYGeometries
 Key: LUCENE-9553
 URL: https://issues.apache.org/jira/browse/LUCENE-9553
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ignacio Vera


Similar to LUCENE-9553, it would be nice to have a query accepts an array of 
LatLonGeometries.



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

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

[jira] [Commented] (SOLR-14905) Update commons-io version to 2.8.0 due to security vulnerability



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

David Smiley commented on SOLR-14905:
-

I was looking forward to seeing Nazerke as the "author" of this commit... :-/.  
Any way, CHANGES.txt is proper.  Thanks Nazerke!  (and Bruno for helping)

> Update commons-io version to 2.8.0 due to security vulnerability
> 
>
> Key: SOLR-14905
> URL: https://issues.apache.org/jira/browse/SOLR-14905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 8.6.2
>Reporter: Nazerke Seidan
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The 
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the 
> hostname value received from user input before processing client requests.
> The issue has been fixed in 2.7 onward:
> (https://issues.apache.org/jira/browse/IO-556, 
> https://issues.apache.org/jira/browse/IO-559) 



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

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

[GitHub] [lucene-solr] dsmiley merged pull request #1927: SOLR-12987: Deprecated plugins are logged once and with log category …



dsmiley merged pull request #1927:
URL: https://github.com/apache/lucene-solr/pull/1927


   



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

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



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

[GitHub] [lucene-solr] dsmiley commented on pull request #1927: SOLR-12987: Deprecated plugins are logged once and with log category …

2020-10-01 Thread ASF subversion and git services (Jira)



dsmiley commented on pull request #1927:
URL: https://github.com/apache/lucene-solr/pull/1927#issuecomment-702102376


   "cname" is the class name as configured/given, which might be fully 
qualified (have the package) or might be abbreviated like 
"solr.DataImportHandler".



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

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



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

[jira] [Commented] (SOLR-12987) Log deprecation warnings to separate log file



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

ASF subversion and git services commented on SOLR-12987:


Commit 9cadbf04b6556b227580a7d72f7af51fcf3083f3 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9cadbf0 ]

SOLR-12987: Deprecated plugins are logged once and with log category 
org.apache.solr.DEPRECATED (#1927)



> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Resolved] (SOLR-12987) Log deprecation warnings to separate log file

2020-10-01 Thread ASF subversion and git services (Jira)



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

David Smiley resolved SOLR-12987.
-
Fix Version/s: 8.7
   Resolution: Fixed

> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Commented] (SOLR-12987) Log deprecation warnings to separate log file



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

ASF subversion and git services commented on SOLR-12987:


Commit 798b67b97ad31c16f10dcb74dc212f065e3edfd3 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=798b67b ]

SOLR-12987: Deprecated plugins are logged once and with log category 
org.apache.solr.DEPRECATED (#1927)

(cherry picked from commit 9cadbf04b6556b227580a7d72f7af51fcf3083f3)


> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Commented] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org

2020-10-01 Thread Uwe Schindler (Jira)



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

Uwe Schindler commented on LUCENE-9548:
---

Hi,
documentation for ASF Jenkins is here (you won't get username/pass from them), 
but on all Jenkins nodes a gradle.properties file is deployed with some 
user/pass properties:
https://cwiki.apache.org/confluence/display/INFRA/Gradle+Installations

We just have to adapt the property names for username and password to the 
naming used there. Sorry for not respondig earlier.

> Publish master (9.x) snapshots to https://repository.apache.org
> ---
>
> Key: LUCENE-9548
> URL: https://issues.apache.org/jira/browse/LUCENE-9548
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We should start publishing snapshot JARs to Apache repositories. I'm not sure 
> how to set it all up with gradle but maybe there are other Apache projects 
> that use gradle and we could peek at their config? Mostly it's about signing 
> artifacts (how to pass credentials for signing) and setting up Nexus 
> deployment repository.



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

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

[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1921: SOLR-14829: Improve documentation for Request Handlers in RefGuide and solrconfig.xml



gerlowskija commented on a change in pull request #1921:
URL: https://github.com/apache/lucene-solr/pull/1921#discussion_r498307070



##
File path: solr/solr-ref-guide/src/common-query-parameters.adoc
##
@@ -307,11 +307,13 @@ The `echoParams` parameter controls what information 
about request parameters is
 
 The `echoParams` parameter accepts the following values:
 
-* `explicit`: This is the default value. Only parameters included in the 
actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) 
will be added to the `params` section of the response header.
+* `explicit`: Only parameters included in the actual request, plus the `_` 
parameter (which is a 64-bit numeric timestamp) will be added to the `params` 
section of the response header.

Review comment:
   No, I don't know anything about it.  This is the first I've heard of an 
underscore param.
   
   It may be duplicitous with the 'rid' stuff I added recently, but that's not 
necessarily the case.  e.g. There's nothing here that suggests that a '_' value 
gets passed without change to shard-requests, afaict.  But it's worth following 
up on for sure, thanks for pointing it out @dsmiley 
   
   > I'm having trouble searching for it.
   No kidding!  Whoever put this in didn't have searchability in mind, that's 
for sure haha.





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

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



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

[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1921: SOLR-14829: Improve documentation for Request Handlers in RefGuide and solrconfig.xml

2020-10-01 Thread ASF subversion and git services (Jira)



gerlowskija commented on a change in pull request #1921:
URL: https://github.com/apache/lucene-solr/pull/1921#discussion_r498307070



##
File path: solr/solr-ref-guide/src/common-query-parameters.adoc
##
@@ -307,11 +307,13 @@ The `echoParams` parameter controls what information 
about request parameters is
 
 The `echoParams` parameter accepts the following values:
 
-* `explicit`: This is the default value. Only parameters included in the 
actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) 
will be added to the `params` section of the response header.
+* `explicit`: Only parameters included in the actual request, plus the `_` 
parameter (which is a 64-bit numeric timestamp) will be added to the `params` 
section of the response header.

Review comment:
   No, I don't know anything about it.  This is the first I've heard of an 
underscore param.
   
   It may be duplicitous with the 'rid' stuff I added recently, but that's not 
necessarily the case.  e.g. There's nothing here that suggests that a '_' value 
gets passed without change to shard-requests, afaict.  But it's worth following 
up on for sure, thanks for pointing it out @dsmiley 
   
   > I'm having trouble searching for it.
   
   No kidding!  Whoever put this in didn't have searchability in mind, that's 
for sure haha.





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

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



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

[jira] [Commented] (SOLR-14787) Inequality support in Payload Check query parser

2020-10-01 Thread Gus Heck (Jira)



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

Gus Heck commented on SOLR-14787:
-

Hmm now I suspect my IDE had somehow got confused WRT 9.0 match version or 
perhaps I was reading a wrong window, but trying fresh today  I just reproduced 
the NOUN VERB failure again with a freshly started IDE but this time failing 
with the appropriate 8.7 match version messages... 

That said, but the build still passes when I do this
{code:java}
gus@ns-l1:~/projects/apache/lucene-solr/fork/lucene-solr8$ ant test 
-Dtests.class=org.apache.solr.search.TestPayloadCheckQParserPlugin > 
build.out.txt
gus@ns-l1:~/projects/apache/lucene-solr/fork/lucene-solr8$ grep NOUN 
build.out.txt 
   [junit4]   2> 5995 INFO  
(TEST-TestPayloadCheckQParserPlugin.test-seed#[39C6574AF7C1723D]) [ ] 
o.a.s.c.S.Request [collection1]  webapp=null path=null 
params={q={!payload_check+f%3Dvals_dps+payloads%3D'NOUN+VERB'}cat+jumped&fl=*,score&wt=xml}
 hits=1 status=0 QTime=4
   [junit4]   2> 6004 INFO  
(TEST-TestPayloadCheckQParserPlugin.test-seed#[39C6574AF7C1723D]) [ ] 
o.a.s.c.S.Request [collection1]  webapp=null path=null 
params={q={!payload_check+f%3Dvals_dps+payloads%3D'VERB+NOUN'}cat+jumped&fl=*,score&wt=xml}
 hits=0 status=0 QTime=0
{code}
Note the hits=1 above vs hits=0 I get in the ide running of the same test
{code:java}
3618 INFO  (TEST-TestPayloadCheckQParserPlugin.test-seed#[C26FC0AC309214A9]) [  
   ] o.a.s.c.S.Request [collection1]  webapp=null path=null 
params={q={!payload_check+f%3Dvals_dps+payloads%3D'NOUN+VERB'}cat+jumped&fl=*,score&wt=xml}
 hits=0 status=0 QTime=2
{code}

> Inequality support in Payload Check query parser
> 
>
> Key: SOLR-14787
> URL: https://issues.apache.org/jira/browse/SOLR-14787
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The goal of this ticket/pull request is to support a richer set of matching 
> and filtering based on term payloads.  This patch extends the 
> PayloadCheckQueryParser to add a new local param for "op"
> The value of OP could be one of the following
>  * gt - greater than
>  * gte - greater than or equal
>  * lt - less than
>  * lte - less than or equal
> default value for "op" if not specified is to be the current behavior of 
> equals.
> Additionally to the operation you can specify a threshold local parameter
> This will provide the ability to search for the term "cat" so long as the 
> payload has a value of greater than 0.75.  
> One use case is to classify a document into various categories with an 
> associated confidence or probability that the classification is correct.  
> That can be indexed into a delimited payload field.  The searches can find 
> and match documents that were tagged with the "cat" category with a 
> confidence of greater than 0.5.
> Example Document
> {code:java}
> { 
>   "id":"doc_1",
>   "classifications_payload":["cat|0.75 dog|2.0"]
> }
> {code}
> Example Syntax
> {code:java}
> {!payload_check f=classifications_payload payloads='1' op='gt' 
> threshold='0.5'}cat  {code}
>  
>  
>  
>  



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

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

[jira] [Commented] (SOLR-14792) Remove VelocityResponseWriter from Solr 9



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

ASF subversion and git services commented on SOLR-14792:


Commit 45dc2615c7063ca81d5c9b53d0f299afe714c41f in lucene-solr's branch 
refs/heads/master from Erik Hatcher
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=45dc261 ]

SOLR-14792: Remove /browse references from example and docs


> Remove VelocityResponseWriter from Solr 9
> -
>
> Key: SOLR-14792
> URL: https://issues.apache.org/jira/browse/SOLR-14792
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 9
>Reporter: Erik Hatcher
>Priority: Blocker
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> VelocityResponseWriter was deprecated in SOLR-14065.   It can now be removed 
> from 9's code branch.



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

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

[jira] [Commented] (SOLR-14792) Remove VelocityResponseWriter from Solr 9

2020-10-01 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-14792:


Commit 1af17a5f0151a4f4a0be864c17c510a244771b7b in lucene-solr's branch 
refs/heads/master from Erik Hatcher
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1af17a5 ]

SOLR-14792: add removal message to major changes section of ref guide


> Remove VelocityResponseWriter from Solr 9
> -
>
> Key: SOLR-14792
> URL: https://issues.apache.org/jira/browse/SOLR-14792
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 9
>Reporter: Erik Hatcher
>Priority: Blocker
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> VelocityResponseWriter was deprecated in SOLR-14065.   It can now be removed 
> from 9's code branch.



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

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

[GitHub] [lucene-solr] arafalov commented on a change in pull request #1921: SOLR-14829: Improve documentation for Request Handlers in RefGuide and solrconfig.xml



arafalov commented on a change in pull request #1921:
URL: https://github.com/apache/lucene-solr/pull/1921#discussion_r498314131



##
File path: solr/solr-ref-guide/src/common-query-parameters.adoc
##
@@ -307,11 +307,13 @@ The `echoParams` parameter controls what information 
about request parameters is
 
 The `echoParams` parameter accepts the following values:
 
-* `explicit`: This is the default value. Only parameters included in the 
actual request, plus the `_` parameter (which is a 64-bit numeric timestamp) 
will be added to the `params` section of the response header.
+* `explicit`: Only parameters included in the actual request, plus the `_` 
parameter (which is a 64-bit numeric timestamp) will be added to the `params` 
section of the response header.

Review comment:
   I did not see the evidence of that parameter in 9.0 when I tried to 
reproduce some basic searches. But, I did not have time to do a full-dive to 
see when it was introduced or - perhaps - removed. So, I did not update that 
documentation section. It may be completely wrong as well (just as 
echoParams=explicit being default).





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

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



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

[GitHub] [lucene-solr] ctargett commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



ctargett commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702230956


   What happened in the past when I attempted to move to Jekyll 4 is that the 
.adoc files just simply wouldn't be converted to HTML - it would say there were 
no files to convert. This is what happened when Jenkins moved to Cloudbees and 
the wrong version caused the Jenkins build for branch_8x to fail for 2 months 
until Infra fixed the gemset installed on the nodes to install specifically 
Jekyll 3.5.2.
   
   That seems to be working fine now here because you (I think inadvertently 
because you didn't mention reading the Jekyll docs on migrating from 3 to 4) 
hit upon the cause of the problem which was the way the `jekyll-asciidoc` 
plugin in `_config.yml` was defined: using `gems` to define it was deprecated 
and that deprecation was removed in Jekyll 4 so the only supported way to do it 
is now `plugins`. Which is what this PR (and Hoss' patch from SOLR-14889, now 
in master) changes it to. This all makes sense - Jekyll doesn't know anything 
about .adoc files without the plugin.
   
   I did read the migration docs for Jekyll and I don't see anything that we 
should be concerned about that should require more extensive review before 
making the change. Knowing why it failed before and why it isn't now makes me 
feel easier about upgrading entirely.
   
   Re: the syntax highlighter styling. I tested both ways of doing it, and 
noticed a small difference in overall size (1Mb) and makes the HTML a bit 
simpler if we include it as a CSS file. By the same token, as I mentioned that 
CSS is something we have to maintain going forward.  But I am leaning toward 
being OK with going the CSS route. I think, though, that it needs some 
attribution in the CSS file itself - license/copyright info and comments about 
where we got it so it's clear where to go in the future when it needs to be 
updated.
   
   Hoss's changes from SOLR-14889 are committed to `master` now, so this needs 
to be updated to take out the stuff you're doing that is now already in 
`master`.



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

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



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

[GitHub] [lucene-solr] arafalov commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



arafalov commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702245180


   Inadvertently is right. I was just working backwards from the latest 
versions and fixing warnings and it worked except for theme names. I checked 
the source and visually and did not see any serious problems. I did not even 
realize it was such a significant issue before. I guess the time helped those 
3rd party packages to smooth the edges. 
   
   I'll redo this on top of Hoss's changes shortly. Will also do a short 
comment in css file. Not sure what to do about the license though, it is 
generated by the tool and does not seem to be licensed in any way itself.



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

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



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

[GitHub] [lucene-solr] ctargett commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



ctargett commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702263023


   > Not sure what to do about the license though, it is generated by the tool 
and does not seem to be licensed in any way itself.
   
   The license and copyright would belong to the Rouge project, so you could 
add the copyright notice as in the license at 
https://github.com/rouge-ruby/rouge/blob/master/LICENSE and a link to the 
project. Then a note about how the CSS was generated (or link to docs on it) as 
helper tips for anyone who comes after you who wants to re-generate the CSS.



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

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



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

[GitHub] [lucene-solr] ctargett edited a comment on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



ctargett edited a comment on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702263023


   > Not sure what to do about the license though, it is generated by the tool 
and does not seem to be licensed in any way itself.
   
   The license and copyright would belong to the Rouge project, so you could 
add the copyright notice as in the license at 
https://github.com/rouge-ruby/rouge/blob/master/LICENSE and a link to the 
project. Then a note about how the CSS was generated (or link to docs on it) as 
helper tips for anyone who comes after you who wants to re-generate the CSS.
   
   I don't think we need to include the license with Lucene/Solr's license 
framework - we're not shipping a copy nor a "significant" portion of Rouge, 
just one CSS file. IMO providing the copyright is fine.



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

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



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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Jonathan Revusky commented on LUCENE-9533:
--

Success?

Well... I suppose it depends on your definition of the word "success".

If you do want to know what happened with it, I explained the situation 
[here][(https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).|https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).]

There is a forum. Weiss (or anybody) can comment. I don't see much point. I am 
confident that my characterisation of what happened is accurate – even 
including the rather nasty comment about the millionaire who can't get laid in 
a whorehouse.

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[jira] [Comment Edited] (LUCENE-9533) Consider switching to javacc21



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

Jonathan Revusky edited comment on LUCENE-9533 at 10/1/20, 5:33 PM:


Success?

Well... I suppose it depends on your definition of the word "success".

If you do want to know what happened with it, I explained the situation 
[here|[https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/|https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).]].

There is a forum. Weiss (or anybody) can comment. I don't see much point. I am 
confident that my characterisation of what happened is accurate – even 
including the rather nasty comment about the millionaire who can't get laid in 
a whorehouse.


was (Author: revusky):
Success?

Well... I suppose it depends on your definition of the word "success".

If you do want to know what happened with it, I explained the situation 
[here][(https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).|https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).]

There is a forum. Weiss (or anybody) can comment. I don't see much point. I am 
confident that my characterisation of what happened is accurate – even 
including the rather nasty comment about the millionaire who can't get laid in 
a whorehouse.

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[jira] [Comment Edited] (LUCENE-9533) Consider switching to javacc21



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

Jonathan Revusky edited comment on LUCENE-9533 at 10/1/20, 5:34 PM:


Success?

Well... I suppose it depends on your definition of the word "success".

If you do want to know what happened with it, I explained the situation here:

[https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/|https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).]

There is a forum. Weiss (or anybody) can comment. I don't see much point 
though. I am confident that my characterisation of what happened is accurate – 
even including the rather nasty simile of the millionaire who can't get laid in 
a whorehouse.


was (Author: revusky):
Success?

Well... I suppose it depends on your definition of the word "success".

If you do want to know what happened with it, I explained the situation 
[here|[https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/|https://www.freemarker.es/2020/10/01/close-encounters-of-the-apache-kind/).]].

There is a forum. Weiss (or anybody) can comment. I don't see much point. I am 
confident that my characterisation of what happened is accurate – even 
including the rather nasty comment about the millionaire who can't get laid in 
a whorehouse.

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[GitHub] [lucene-solr] ctargett commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



ctargett commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702293474


   There are two new warnings I noticed being output with these changes: 
`Improper use of Lexer#lex - this method does not receive options. This will 
become an error in a future version.` This is a Rouge error.
   
   We don't get verbose output with the Gradle build, so I ran Jekyll locally 
without Gradle to see if I could catch where these occur. They both happen when 
processing `response-writers.adoc`. If I had to guess, my first one would be 
that Rouge is balking at the Ruby code and misinterpreting it as inputs for 
itself. I have no idea if there are syntax shortcuts in that example or if it's 
really real Ruby...it's not making anything look any different than what it 
always has, though.



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

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



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

[jira] [Commented] (SOLR-14151) Make schema components load from packages

2020-10-01 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--

bq. this build was triggered after Noble did a flawed cherry-pick from master 
to branch_8x. I fixed it immediately after that, but this run may have been 
triggered between those two commits.
Ah, thanks Ishan!

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 13.5h
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



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

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

[jira] [Created] (SOLR-14909) Add replica is very slow on a large cluster

2020-10-01 Thread Varun Thacker (Jira)

Varun Thacker created SOLR-14909:


 Summary: Add replica is very slow on a large cluster
 Key: SOLR-14909
 URL: https://issues.apache.org/jira/browse/SOLR-14909
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.6
Reporter: Varun Thacker


We create ~100 collections every day for new incoming data

We first issue a create-collection request for all the collections (4 shards 
and createNodeSet=empty). This would create collections with no replicas

We then issue async add-replica calls for all the shards creating 1 replica 
each. 100 collection X 4 shards = 400 add-replica calls. All the add replica 
calls pass the node parameter telling Solr where the replica should be created

The cluster has 190 nodes currently and when we upgraded to Solr 7.7.3 we 
noticed that the add replicas took 2 hours and 45 mins to complete! Clearly 
something was wrong as the same cluster previously running Solr 7.3.1 was 
taking a few mins only.

A thread dump of the overseer showed a 100 threads stuck here ( Why 100? That's 
the Solr default thread pool size set by MAX_PARALLEL_TASKS in 
OverseerTaskProcessor )

 
{code:java}
"OverseerThreadFactory-13-thread-1226-processing-n:10.128.18.69:8983_solr" 
#11163 prio=5 os_prio=0 cpu=0.69ms elapsed=987.97s tid=0x7f01f8051000 
nid=0xd7a waiting for monitor entry [0x7f01c1121000]
 java.lang.Thread.State: BLOCKED (on object monitor)
 at java.lang.Object.wait(java.base@11.0.5/Native Method)
 - waiting on 
 at 
org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper$SessionRef.get(PolicyHelper.java:449)
 - waiting to re-lock in wait() <0x0007259e6a98> (a java.lang.Object)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper.getSession(PolicyHelper.java:493)
 at 
org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper.getReplicaLocations(PolicyHelper.java:121)
 at 
org.apache.solr.cloud.api.collections.Assign.getPositionsUsingPolicy(Assign.java:382)
 at 
org.apache.solr.cloud.api.collections.Assign$PolicyBasedAssignStrategy.assign(Assign.java:630)
 at 
org.apache.solr.cloud.api.collections.Assign.getNodesForNewReplicas(Assign.java:368)
 at 
org.apache.solr.cloud.api.collections.AddReplicaCmd.buildReplicaPositions(AddReplicaCmd.java:360)
 at 
org.apache.solr.cloud.api.collections.AddReplicaCmd.addReplica(AddReplicaCmd.java:146)
 at 
org.apache.solr.cloud.api.collections.AddReplicaCmd.call(AddReplicaCmd.java:91)
 at 
org.apache.solr.cloud.api.collections.OverseerCollectionMessageHandler.processMessage(OverseerCollectionMessageHandler.java:294)
{code}
 

 

It's strange because each add-replica API call would create a single replica 
and specify which node is must be created on.

 

Assign.getNodesForNewReplicas is where the slowdown was and we noticed 
SKIP_NODE_ASSIGNMENT flag ( 
https://github.com/apache/lucene-solr/commit/17cb1b17172926d0d9aed3dfd3b9adb90cf65e0f#diff-ee29887eff6e474e58fcf3c02077f179R355
 ) that the overseer reads could have skipped the method from being called.

So we started passing SKIP_NODE_ASSIGNMENT=true and still no luck! The replicas 
took just as long to create. It turned out that the Collections Handler wasn't 
passing the SKIP_NODE_ASSIGNMENT parameter to the overseer.

The add replica call only passes a specific set of params to the overseer 
https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.7.3/solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java#L823
 . We changed this to also pass SKIP_NODE_ASSIGNMENT.

Now when we try to create the replicas it takes 4 minutes approximately vs 2 
hours 45 mins that it was taking previosuly.

Only master respects that param to the overseer ( 
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java#L938
 ) . However it doesn't matter in master because the autoscaling framework is 
gone ( https://github.com/apache/lucene-solr/commit/cc0c111/ )

I believe this will be seen in all versions since Solr 7.6 ( 
https://issues.apache.org/jira/browse/SOLR-12739 ) through every 8.x release

Lastly, I manually tried to add a replica with and without the flag. Without 
the flag it took 20 second and with the flag 2 seconds.



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

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

[GitHub] [lucene-solr] arafalov commented on pull request #1923: SOLR-14900: Reference Guide build cleanup/module upgrade



arafalov commented on pull request #1923:
URL: https://github.com/apache/lucene-solr/pull/1923#issuecomment-702309291


   I thought this was kind of general error. Now that I know it is a specific 
file, I will dig in deeper and see if it can be eliminated.
   
   The warning AFAIK is about the method that used to silently accept extra 
parameters and now is doing it loudly and threatens to quit in the future. So, 
the output may not change. But it is annoying to replace two old warnings with 
one new. So, if we can figure it out and remove it, that would be nice.



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

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



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

[jira] [Reopened] (SOLR-12987) Log deprecation warnings to separate log file

2020-10-01 Thread Chris M. Hostetter (Jira)



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

Chris M. Hostetter reopened SOLR-12987:
---

breaks gradle check...

 
{noformat}

 > Task :solr:core:validateSourcePatterns FAILED
invalid logging pattern [not private static final, uses static class name]: 
/home/hossman/lucene/dev/solr/core/src/java/org/apache/solr/logging/DeprecationLog.java
invalid logger name [log, uses static class name, not specialized logger]: 
/home/hossman/lucene/dev/solr/core/src/java/org/apache/solr/logging/DeprecationLog.java


...

* Where:
Script 
'/home/hossman/lucene/dev/gradle/validation/validate-source-patterns.gradle' 
line: 324* What went wrong:
Execution failed for task ':solr:core:validateSourcePatterns'.
> Found 2 violations in source files (invalid logger name [log, uses static 
> class name, not specialized logger], invalid logging pattern [not private 
> static final, uses static class name]).{noformat}

> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Commented] (SOLR-14787) Inequality support in Payload Check query parser

2020-10-01 Thread Gus Heck (Jira)



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

Gus Heck commented on SOLR-14787:
-

So after spending some more time with this I have the following thoughts:
 # The threshold parameter is redundant with the payloads parameter. This 
should all be choosing operators in the same manner in the code, with "equals" 
being the default operator rather than having two distinct code paths. I think 
{{"\{!payload_check f=vals_dpf payloads='0.75' op='gt'}one"}} makes more sense. 
This also opens up the possibility of testing vs multiple payload values just 
like the equals case. Accepting a different operator per payload value can be a 
future enhancement however if anyone wants it.
 # There is a lucene class change here and so there definitely should be lucene 
level tests and we should have a lucene ticket too.
 # As you mentioned in a separate channel, this doesn't work with integers ( 
ie. {{"\{!payload_check f=vals_dpi payloads='1' op='gt' threshold='0.75'}A"}} 
won't work... this is because the integer payload (from the index, not the 
query) gets decoded as a float and winds up being some very very small value 
(saw it in debug, forgot to copy it down, but something ten to the minus 14 
IIRC), so this deceptively gives wrong answers and does not throw errors which 
is bad. I think this needs to be addressed by communicating the payload type to 
the query at the lucene layer (where folks are responsible for knowing the 
types info of their own fields) and deriving it from schema at the solr level 
where folks expect stuff to just work, because they declared a schema. 
Additionally, by analogy with range queries, probably strings should work via 
lexical order but possibly that could be for future enhancement, since 
users are less likely to expect strings to work in the same fashion as floats.
 # I'm still trying to explain why I get different results in IDE vs build 
here, but the build and the running applications is the important thing.
 # Needs docs of course

> Inequality support in Payload Check query parser
> 
>
> Key: SOLR-14787
> URL: https://issues.apache.org/jira/browse/SOLR-14787
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Kevin Watters
>Assignee: Gus Heck
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The goal of this ticket/pull request is to support a richer set of matching 
> and filtering based on term payloads.  This patch extends the 
> PayloadCheckQueryParser to add a new local param for "op"
> The value of OP could be one of the following
>  * gt - greater than
>  * gte - greater than or equal
>  * lt - less than
>  * lte - less than or equal
> default value for "op" if not specified is to be the current behavior of 
> equals.
> Additionally to the operation you can specify a threshold local parameter
> This will provide the ability to search for the term "cat" so long as the 
> payload has a value of greater than 0.75.  
> One use case is to classify a document into various categories with an 
> associated confidence or probability that the classification is correct.  
> That can be indexed into a delimited payload field.  The searches can find 
> and match documents that were tagged with the "cat" category with a 
> confidence of greater than 0.5.
> Example Document
> {code:java}
> { 
>   "id":"doc_1",
>   "classifications_payload":["cat|0.75 dog|2.0"]
> }
> {code}
> Example Syntax
> {code:java}
> {!payload_check f=classifications_payload payloads='1' op='gt' 
> threshold='0.5'}cat  {code}
>  
>  
>  
>  



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

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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Dawid Weiss commented on LUCENE-9533:
-

Your public writeup is just as insulting as your private messages to me, 
Jonathan. I don't understand why you're doing this or to whom your message is 
addressed but I am not really interested in any conversation with you anymore. 
You should seek professional help.

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Jonathan Revusky commented on LUCENE-9533:
--

Dawid, what I wrote just describes what happened. If there is any factual 
inaccuracy in what I said, then by all means point it out. If you don't point 
out any factual inaccuracy, you're tacitly admitting that everything I say is 
true. (You do realize that, don't you?)

As for _why_ I wrote what I did, well, I never even hid the fact that you 
really truly and utterly pissed me off. I considered your behavior in the whole 
matter utterly execrable, but I also thought that it kind of exemplified a 
certain cultural malaise.

So, I provide a certain sort of public service by doing that. To you 
specifically and you guys generally. You behave that way 100 times and 99 times 
nobody will say anything. You met the 100th person who decided not to turn the 
other cheek.

So... live and learn...

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[GitHub] [lucene-solr] dweiss commented on pull request #1905: LUCENE-9488 Release with Gradle Part 2



dweiss commented on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-702369827


   I think it looks good now! If there's anything else we can follow-up.
   
   On Thu, Oct 1, 2020 at 12:13 AM Mike Drob  wrote:
   
   > Dawid, it took me a few tries of going through your comments and other
   > examples in the code but I think it finally dawned on me what you meant as
   > the proper way to do it. Each task can export its own outputs as an
   > artifact, that's the piece that was missing in my mental model. Please take
   > another look?
   >
   > There's another piece where the Luke log4j dependency was causing a
   > duplicate entry error in the archives... not sure if you were getting the
   > same error or not. Otherwise the output zip looks pretty close to the real
   > thing from 8x
   >
   > —
   > You are receiving this because your review was requested.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



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

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



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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Ishan Chattopadhyaya commented on LUCENE-9533:
--

Jonathon, thanks for reaching out to Apache Lucene with your offer for help. As 
you noted in your blog, we are community from diverse cultures, and 
misunderstandings can ensue often. It happens many times, but I believe 
everyone is acting in good faith. Recently, I was very badly behaved towards 
fellow committers, and I have only regretted that since.

I hope you can please calm down and help us with suggestions/thoughts/patches 
on how you think we should proceed with this issue. And by the way, welcome to 
this project: we value your help and hence I earnestly repeat what Dawid said, 
your patches are very welcome.

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[GitHub] [lucene-solr] mayya-sharipova opened a new pull request #1937: LUCENE-9541 ConjunctionDISI sub-iterators check



mayya-sharipova opened a new pull request #1937:
URL: https://github.com/apache/lucene-solr/pull/1937


   Ensure sub-iterators of a conjunction iterator don't advance outside
   of it.
   Add assertions for checking that all sub-iterators are always on the
   same document.



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

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



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

[jira] [Commented] (SOLR-12987) Log deprecation warnings to separate log file



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

David Smiley commented on SOLR-12987:
-

Oh that's embarassing!  It seems I can resolve this violation by declaring a 
logger that DeprecationLog won't actually use ;-).

> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Commented] (LUCENE-9541) BitSetConjunctionDISI doesn't advance based on its components

2020-10-01 Thread Mayya Sharipova (Jira)



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

Mayya Sharipova commented on LUCENE-9541:
-

Caught with [~jpountz] offline, and we have decided to add checks that assert 
that all sub-iterators are on the same document all the time. 

> BitSetConjunctionDISI doesn't advance based on its components
> -
>
> Key: LUCENE-9541
> URL: https://issues.apache.org/jira/browse/LUCENE-9541
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Not completely sure if this is a bug.
> BitSetConjuctionDISI advances based on its lead  – DocIdSetIterator iterator, 
> and doesn't consider that its another component – BitSetIterator may have 
> already advanced passed a certain doc. This may result in duplicate documents.
> For example if BitSetConjuctionDISI  _disi_ is composed of DocIdSetIterator 
> _a_ of docs  [0,1] and BitSetIterator _b_ of docs [0,1].  Doing `b.nextDoc()` 
> we are collecting doc0,  doing `disi.nextDoc` we again  collecting the same 
> doc0.
> It seems that other conjunction iterators don't have this behaviour, if we 
> are advancing any of their component pass a certain document, the whole 
> conjunction iterator will also be advanced pass this document. 
>  
> This behaviour was exposed in this 
> [PR|https://github.com/apache/lucene-solr/pull/1903]. 
>  



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

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

[GitHub] [lucene-solr] mayya-sharipova commented on a change in pull request #1937: LUCENE-9541 ConjunctionDISI sub-iterators check

2020-10-01 Thread ASF subversion and git services (Jira)



mayya-sharipova commented on a change in pull request #1937:
URL: https://github.com/apache/lucene-solr/pull/1937#discussion_r498511026



##
File path: lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java
##
@@ -140,6 +141,13 @@ private static void addTwoPhaseIterator(TwoPhaseIterator 
twoPhaseIter, List allIterators,
   List twoPhaseIterators) {
+
+// assert that all sub-iterators are on the same doc ID

Review comment:
   @jpountz  Is this a correct assumption?  or could we start with 
iterators that are not on the same document? 





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

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



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

[jira] [Commented] (SOLR-12987) Log deprecation warnings to separate log file



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

ASF subversion and git services commented on SOLR-12987:


Commit 6c3b1aa5ca2cdaaa63be73fb5425fd3b372d40b4 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6c3b1aa ]

SOLR-12987: Fix precommit


> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[jira] [Reopened] (SOLR-14663) ConfigSets CREATE does not set trusted flag

2020-10-01 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe reopened SOLR-14663:
--
  Assignee: Tomas Eduardo Fernandez Lobbe

> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag

2020-10-01 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe commented on SOLR-14663:
--

This does seem like a bug to me. Sorry Andras, I wasn't aware of this Jira 
issue when I started looking, so I didn't use your patch, but I think this one 
addresses the problem too. 

> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[jira] [Updated] (SOLR-14663) ConfigSets CREATE does not set trusted flag

2020-10-01 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe updated SOLR-14663:
-
Attachment: SOLR-14663.patch

> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag

2020-10-01 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-14663:


Commit 8f2f80bbb3c35fef036dce3162f4f03bf465e5f2 in lucene-solr's branch 
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f2f80b ]

SOLR-14663: Copy ConfigSet root data from base ConfigSet when using CREATE 
command


> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[jira] [Commented] (SOLR-12987) Log deprecation warnings to separate log file

2020-10-01 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-12987:


Commit c41db675915129d9b749ff07a9d774f50e731bfc in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c41db67 ]

SOLR-12987: Fix precommit

(cherry picked from commit 6c3b1aa5ca2cdaaa63be73fb5425fd3b372d40b4)


> Log deprecation warnings to separate log file
> -
>
> Key: SOLR-12987
> URL: https://issues.apache.org/jira/browse/SOLR-12987
> Project: Solr
>  Issue Type: New Feature
>  Components: logging
>Reporter: Jan Høydahl
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.7
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> As discussed in solr-user list:
> {quote}When instructing people in what to do before upgrading to a new 
> version, we often tell them to check for deprecation log messages and fix 
> those before upgrading. Normally you'll see the most important logs as WARN 
> level in the Admin UI log tab just after startup and first use. But I'm 
> wondering if it also makes sense to introduce a separate 
> DeprecationLogger.log(foo) that is configured in log4j2.xml to log to a 
> separate logs/deprecation.log to make it easier to check this from the 
> command line. If the file is non-empty you have work to do :)
> {quote}



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

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

[GitHub] [lucene-solr] jpountz commented on a change in pull request #1937: LUCENE-9541 ConjunctionDISI sub-iterators check

2020-10-01 Thread ASF subversion and git services (Jira)



jpountz commented on a change in pull request #1937:
URL: https://github.com/apache/lucene-solr/pull/1937#discussion_r498523124



##
File path: lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java
##
@@ -227,6 +236,7 @@ private int doNext(int doc) throws IOException {
 
   @Override
   public int advance(int target) throws IOException {
+assertItersOnSameDoc();

Review comment:
   can we avoid iterating over all sub iterators unless assertions are 
enabled?

##
File path: lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java
##
@@ -140,6 +141,13 @@ private static void addTwoPhaseIterator(TwoPhaseIterator 
twoPhaseIter, List allIterators,
   List twoPhaseIterators) {
+
+// assert that all sub-iterators are on the same doc ID
+int curDoc = allIterators.size() > 0 ? allIterators.get(0).docID() : 
twoPhaseIterators.get(0).approximation.docID();
+boolean iteratorsOnTheSameDoc = allIterators.stream().allMatch(it -> 
it.docID() == curDoc);
+iteratorsOnTheSameDoc = iteratorsOnTheSameDoc && 
twoPhaseIterators.stream().allMatch(it -> it.approximation().docID() == curDoc);
+assert iteratorsOnTheSameDoc : "Sub-iterators of ConjunctionDISI are not 
the same document!";

Review comment:
   let's make it an IllegalArgumentException?

##
File path: lucene/core/src/java/org/apache/lucene/search/ConjunctionDISI.java
##
@@ -140,6 +141,13 @@ private static void addTwoPhaseIterator(TwoPhaseIterator 
twoPhaseIter, List allIterators,
   List twoPhaseIterators) {
+
+// assert that all sub-iterators are on the same doc ID

Review comment:
   this is the invariant between iterations indeed





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

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



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

[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag



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

ASF subversion and git services commented on SOLR-14663:


Commit 83d2ba1ad3a09f4d4788ee527652164f5511f469 in lucene-solr's branch 
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=83d2ba1 ]

SOLR-14663: Copy ConfigSet root data from base ConfigSet when using CREATE 
command


> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[GitHub] [lucene-solr] madrob commented on a change in pull request #1905: LUCENE-9488 Release with Gradle Part 2

2020-10-01 Thread ASF subversion and git services (Jira)



madrob commented on a change in pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#discussion_r498535024



##
File path: lucene/packaging/build.gradle
##
@@ -0,0 +1,160 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+// This project puts together a "distribution", assembling dependencies from
+// various other projects.
+
+plugins {
+id 'distribution'
+}
+
+description = 'Lucene distribution packaging'
+
+// Declare all subprojects that should be included in binary distribution.
+// By default everything is included, unless explicitly excluded.
+def includeInBinaries = project(":lucene").subprojects.findAll {subproject ->
+return !(subproject.path in [
+":lucene:packaging",
+":lucene:analysis",
+":lucene:luke", // nocommit - Encountered duplicate path 
"luke/lib/log4j-core-2.13.2.jar"

Review comment:
   @dweiss this is still a problem, not sure why it comes up or how to 
resolve it.





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

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



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

[jira] [Assigned] (SOLR-14888) Echo directory to run Solr from for the "assemble" and "dev" targets in the Gradle build

2020-10-01 Thread Mike Drob (Jira)



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

Mike Drob reassigned SOLR-14888:


Assignee: Mike Drob

> Echo directory to run Solr from for the "assemble" and "dev" targets in the 
> Gradle build
> 
>
> Key: SOLR-14888
> URL: https://issues.apache.org/jira/browse/SOLR-14888
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Mike Drob
>Priority: Major
>
> This used to happen. As per [~mdrob] opening a JIRA.



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

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

[jira] [Commented] (SOLR-14888) Echo directory to run Solr from for the "assemble" and "dev" targets in the Gradle build

2020-10-01 Thread Mike Drob (Jira)



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

Mike Drob commented on SOLR-14888:
--

I'll handle this while doing LUCENE-9488

https://github.com/apache/lucene-solr/pull/1905/files#diff-52fb62e7c18e74cca83ad07f6d61ba78R33

> Echo directory to run Solr from for the "assemble" and "dev" targets in the 
> Gradle build
> 
>
> Key: SOLR-14888
> URL: https://issues.apache.org/jira/browse/SOLR-14888
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Priority: Major
>
> This used to happen. As per [~mdrob] opening a JIRA.



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

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

[jira] [Commented] (SOLR-14663) ConfigSets CREATE does not set trusted flag



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

ASF subversion and git services commented on SOLR-14663:


Commit e001c2221812a0ba9e9378855040ce72f93eced4 in lucene-solr's branch 
refs/heads/branch_8_6 from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e001c22 ]

SOLR-14663: Copy ConfigSet root data from base ConfigSet when using CREATE 
command


> ConfigSets CREATE does not set trusted flag
> ---
>
> Key: SOLR-14663
> URL: https://issues.apache.org/jira/browse/SOLR-14663
> Project: Solr
>  Issue Type: Task
>Reporter: Andras Salamon
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Attachments: SOLR-14663.patch, SOLR-14663.patch
>
>
> If I upload a configset using [ConfigSets 
> API|https://lucene.apache.org/solr/guide/8_6/configsets-api.html] UPLOAD Solr 
> sets the trusted flag. The config set will be trusted if authentication is 
> enabled and the upload operation is performed as an authenticated request.
> On the other hand if I use the ConfigSets API CREATE which creates a new 
> configset based on an already uploaded one, this flag will not be set, so the 
> configset will be effectively untrusted.
> I don't really understand the difference here, I think CREATE API call should 
> set this flag just like UPLOAD sets it.



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

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

[GitHub] [lucene-solr] thelabdude opened a new pull request #1938: SOLR-14766: Remove restlet as dependency for the ManagedResource API

thelabdude opened a new pull request #1938:
URL: https://github.com/apache/lucene-solr/pull/1938

# Description

Here’s a quick pass at keeping the existing ManagedResource API endpoints in
place but without using Restlet. Now that I’ve gone through this code again, it
seems like Restlet was more aspirational than technically required to support
the current functionality. As I said on the mailing list, I don’t know the
history of why Restlet was introduced so I can’t say much more about that.

What I do know is that it’s not needed to support the ManagedResource
endpoints we have today. In a nutshell, RestManager keeps a mapping from a PATH
(e.g. /schema/analysis/stopwords/english) to a ManagedResource impl and Restlet
is used to route REST requests for the PATH to a ManagedResource. There’s a
ManagedEndpoint used as the shim between Restlet and the ManagedResource that’s
just details ...

In this PR, I’ve simply replaced the Restlet routing logic with a
SolrRequestHandler that resolves the ManagedResource for a PATH using the
RestManager’s mapping. Put simply, plugging into the Restlet routing logic
isn’t necessary for Managed Resources. Not to mention, there’s some rigid
mapping to /schema in places, so I’m not certain we achieved the supposed goal
of supporting dynamic mapping of path to resource that Restlet provides.

As has been discussed on the mailing list, we could just remove all of this
ManagedResource code from master but that requires us to come up with some LTR
specific request handler to allow managing models and features. However, the
approach in this PR doesn’t feel too dirty to me and avoids breaking the
existing APIs for stopwords / synonyms / LTR models & features.

I’m happy to go either way here but wanted to see what it would take to
remove Restlet but keep the existing endpoints and this work accomplishes that.

# Solution

Please provide a short description of the approach taken to implement your
solution.

# Tests

Please describe the tests you've developed or run to confirm this patch
implements the feature or solves the problem.

# Checklist

Please review the following and check all that apply:

- [x] I have reviewed the guidelines for [How to
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms
to the standards described there to the best of my ability.
- [x] I have created a Jira issue and added the issue ID to my pull request
title.
- [ ] I have given Solr maintainers
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
to contribute to my PR branch. (optional but recommended)
- [x] I have developed this patch against the `master` branch.
- [x] I have run `./gradlew check`.
- [x] I have added tests for my changes.
- [ ] I have added documentation for the [Ref
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide)
(for Solr changes only).

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

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

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

[jira] [Commented] (SOLR-14766) Deprecate ManagedResources from Solr

2020-10-01 Thread Timothy Potter (Jira)



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

Timothy Potter commented on SOLR-14766:
---

Here's a start: https://github.com/apache/lucene-solr/pull/1938

> Deprecate ManagedResources from Solr
> 
>
> Key: SOLR-14766
> URL: https://issues.apache.org/jira/browse/SOLR-14766
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Timothy Potter
>Priority: Major
>  Labels: deprecation
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This feature has the following problems. 
> * It's insecure because it is using restlet
> * Nobody knows that code enough to even remove the restlet dependency
> * Restlest dependency on Solr exists just because of this
> We should deprecate this from 8.7 and remove it from master



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

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

[GitHub] [lucene-solr] muse-dev[bot] commented on a change in pull request #1938: SOLR-14766: Remove restlet as dependency for the ManagedResource API



muse-dev[bot] commented on a change in pull request #1938:
URL: https://github.com/apache/lucene-solr/pull/1938#discussion_r498581982



##
File path: solr/core/src/java/org/apache/solr/rest/RestManager.java
##
@@ -326,44 +327,46 @@ public void doInit() throws ResourceException {
   }
 }
   }
-  
+
   if (managedResource == null) {
-if (Method.PUT.equals(getMethod()) || Method.POST.equals(getMethod())) 
{
+final String method = getSolrRequest().getHttpMethod();
+if ("PUT".equals(method) || "POST".equals(method)) {

Review comment:
   *UNSAFE_HASH_EQUALS:*  Unsafe comparison of hash that are susceptible to 
timing attack 
[(details)](https://find-sec-bugs.github.io/bugs.htm#UNSAFE_HASH_EQUALS)





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

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



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

[jira] [Updated] (SOLR-14766) Deprecate ManagedResources from Solr



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

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

> Deprecate ManagedResources from Solr
> 
>
> Key: SOLR-14766
> URL: https://issues.apache.org/jira/browse/SOLR-14766
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Timothy Potter
>Priority: Major
>  Labels: deprecation
> Attachments: SOLR-14766.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This feature has the following problems. 
> * It's insecure because it is using restlet
> * Nobody knows that code enough to even remove the restlet dependency
> * Restlest dependency on Solr exists just because of this
> We should deprecate this from 8.7 and remove it from master



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

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

[jira] [Commented] (SOLR-14766) Deprecate ManagedResources from Solr



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

Noble Paul commented on SOLR-14766:
---

[~thelabdude]
 The patch avoids special handling for rest manager in {{HttpSolrCall}}


 You may apply it directly to your branch

> Deprecate ManagedResources from Solr
> 
>
> Key: SOLR-14766
> URL: https://issues.apache.org/jira/browse/SOLR-14766
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Timothy Potter
>Priority: Major
>  Labels: deprecation
> Attachments: SOLR-14766.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This feature has the following problems. 
> * It's insecure because it is using restlet
> * Nobody knows that code enough to even remove the restlet dependency
> * Restlest dependency on Solr exists just because of this
> We should deprecate this from 8.7 and remove it from master



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

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

[GitHub] [lucene-solr] dsmiley merged pull request #1740: LUCENE-9458: WDGF and WDF should tie-break by endOffset

2020-10-01 Thread ASF subversion and git services (Jira)



dsmiley merged pull request #1740:
URL: https://github.com/apache/lucene-solr/pull/1740


   



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

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



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

[jira] [Commented] (LUCENE-9458) WordDelimiterGraphFilter (and non-graph) should tie-break order using end offset



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

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

Commit 0303063e12049d9b470757c5ef2fb9afa6c5cd18 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0303063 ]

LUCENE-9458: WDGF should tie-break by endOffset (#1740)

Can happen with catenateAll and not generating word xor number part when the 
input ends with the non-generated sub-token.
Fuzzing revealed that only start & end offsets are needed to order sub-tokens.

> WordDelimiterGraphFilter (and non-graph) should tie-break order using end 
> offset
> 
>
> Key: LUCENE-9458
> URL: https://issues.apache.org/jira/browse/LUCENE-9458
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> WordDelimiterGraphFilter and WordDelimiterFilter do not consult the end 
> offset in their sub-token _ordering_.  In the event of a tie-break, I propose 
> the longer token come first.  This usually happens already, but not always, 
> and so this also feels like an inconsistency when you see it.  This issue can 
> be thought of as a bug fix to LUCENE-9006 or an improvement; I have no strong 
> feelings on the issue classification.  Before reading further, definitely 
> read that issue.
> I see this is a problem when using CATENATE_ALL with either 
> GENERATE_WORD_PARTS xor GENERATE_NUMBER_PARTS when the input ends with that 
> part not being generated.  Consider the input: "other-9" and let's assume we 
> want to catenate all, generate word parts, but nothing else (not numbers).  
> This should be tokenized in this order: "other9", "other" but today is 
> emitted in reverse order.
>  



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

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

[jira] [Commented] (LUCENE-9458) WordDelimiterGraphFilter (and non-graph) should tie-break order using end offset

2020-10-01 Thread ASF subversion and git services (Jira)



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

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

Commit 587f7302b9de62f840d85ca325a660a9fbe1e3b0 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=587f730 ]

LUCENE-9458: WDGF should tie-break by endOffset (#1740)

Can happen with catenateAll and not generating word xor number part when the 
input ends with the non-generated sub-token.
Fuzzing revealed that only start & end offsets are needed to order sub-tokens.

(cherry picked from commit 0303063e12049d9b470757c5ef2fb9afa6c5cd18)


> WordDelimiterGraphFilter (and non-graph) should tie-break order using end 
> offset
> 
>
> Key: LUCENE-9458
> URL: https://issues.apache.org/jira/browse/LUCENE-9458
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> WordDelimiterGraphFilter and WordDelimiterFilter do not consult the end 
> offset in their sub-token _ordering_.  In the event of a tie-break, I propose 
> the longer token come first.  This usually happens already, but not always, 
> and so this also feels like an inconsistency when you see it.  This issue can 
> be thought of as a bug fix to LUCENE-9006 or an improvement; I have no strong 
> feelings on the issue classification.  Before reading further, definitely 
> read that issue.
> I see this is a problem when using CATENATE_ALL with either 
> GENERATE_WORD_PARTS xor GENERATE_NUMBER_PARTS when the input ends with that 
> part not being generated.  Consider the input: "other-9" and let's assume we 
> want to catenate all, generate word parts, but nothing else (not numbers).  
> This should be tokenized in this order: "other9", "other" but today is 
> emitted in reverse order.
>  



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

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

[jira] [Commented] (LUCENE-9458) WordDelimiterGraphFilter (and non-graph) should tie-break order using end offset

2020-10-01 Thread ASF subversion and git services (Jira)



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

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

Commit 587f7302b9de62f840d85ca325a660a9fbe1e3b0 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=587f730 ]

LUCENE-9458: WDGF should tie-break by endOffset (#1740)

Can happen with catenateAll and not generating word xor number part when the 
input ends with the non-generated sub-token.
Fuzzing revealed that only start & end offsets are needed to order sub-tokens.

(cherry picked from commit 0303063e12049d9b470757c5ef2fb9afa6c5cd18)


> WordDelimiterGraphFilter (and non-graph) should tie-break order using end 
> offset
> 
>
> Key: LUCENE-9458
> URL: https://issues.apache.org/jira/browse/LUCENE-9458
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> WordDelimiterGraphFilter and WordDelimiterFilter do not consult the end 
> offset in their sub-token _ordering_.  In the event of a tie-break, I propose 
> the longer token come first.  This usually happens already, but not always, 
> and so this also feels like an inconsistency when you see it.  This issue can 
> be thought of as a bug fix to LUCENE-9006 or an improvement; I have no strong 
> feelings on the issue classification.  Before reading further, definitely 
> read that issue.
> I see this is a problem when using CATENATE_ALL with either 
> GENERATE_WORD_PARTS xor GENERATE_NUMBER_PARTS when the input ends with that 
> part not being generated.  Consider the input: "other-9" and let's assume we 
> want to catenate all, generate word parts, but nothing else (not numbers).  
> This should be tokenized in this order: "other9", "other" but today is 
> emitted in reverse order.
>  



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

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

[jira] [Resolved] (LUCENE-9458) WordDelimiterGraphFilter (and non-graph) should tie-break order using end offset



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

David Smiley resolved LUCENE-9458.
--
Fix Version/s: 8.7
   Resolution: Fixed

> WordDelimiterGraphFilter (and non-graph) should tie-break order using end 
> offset
> 
>
> Key: LUCENE-9458
> URL: https://issues.apache.org/jira/browse/LUCENE-9458
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.7
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> WordDelimiterGraphFilter and WordDelimiterFilter do not consult the end 
> offset in their sub-token _ordering_.  In the event of a tie-break, I propose 
> the longer token come first.  This usually happens already, but not always, 
> and so this also feels like an inconsistency when you see it.  This issue can 
> be thought of as a bug fix to LUCENE-9006 or an improvement; I have no strong 
> feelings on the issue classification.  Before reading further, definitely 
> read that issue.
> I see this is a problem when using CATENATE_ALL with either 
> GENERATE_WORD_PARTS xor GENERATE_NUMBER_PARTS when the input ends with that 
> part not being generated.  Consider the input: "other-9" and let's assume we 
> want to catenate all, generate word parts, but nothing else (not numbers).  
> This should be tokenized in this order: "other9", "other" but today is 
> emitted in reverse order.
>  



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

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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Ishan Chattopadhyaya commented on LUCENE-9533:
--

Oh! I didn't realise it was already marked as a WONTFIX. I didn't see the 
technical reason for doing so, but I guess the boat has sailed. 🙁

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[GitHub] [lucene-solr] noblepaul commented on pull request #1938: SOLR-14766: Remove restlet as dependency for the ManagedResource API

2020-10-01 Thread ASF subversion and git services (Jira)



noblepaul commented on pull request #1938:
URL: https://github.com/apache/lucene-solr/pull/1938#issuecomment-702507313


   I've given a patch to be applied over this branch



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

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



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

[jira] [Commented] (LUCENE-9032) Make public: BaseTokenStreamTestCase.checkResetException



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

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

Commit 2aa51fe77caf60392f1352076888e447ad2b56e0 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2aa51fe ]

LUCENE-9032: BaseTokenStreamTestCase minor...
* make checkResetException() public
* one assertAnalyzesTo variant should be calling checkAnalysisConsistency (only 
used by OpenNLP tests now)


> Make public: BaseTokenStreamTestCase.checkResetException
> 
>
> Key: LUCENE-9032
> URL: https://issues.apache.org/jira/browse/LUCENE-9032
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> Ideally {{BaseTokenStreamTestCase.checkResetException}} would be public so 
> that 3rd party projects can test this.  assertTokenStreamContents is public, 
> checkAnalysisConsistency is public, assertAnalyzesTo is public.  It's 
> currently possible to _indirectly_ get this check because assertAnalyzesTo 
> will call it, but this forces the use of RandomizedTesting and 3rd parties 
> might not be using that.



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

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

[jira] [Commented] (LUCENE-9032) Make public: BaseTokenStreamTestCase.checkResetException

2020-10-01 Thread ASF subversion and git services (Jira)



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

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

Commit 9b5823fa72acb432346e9096fe322a645fdeaf8c in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b5823f ]

LUCENE-9032: BaseTokenStreamTestCase minor...
* make checkResetException() public
* one assertAnalyzesTo variant should be calling checkAnalysisConsistency (only 
used by OpenNLP tests now)

(cherry picked from commit 2aa51fe77caf60392f1352076888e447ad2b56e0)


> Make public: BaseTokenStreamTestCase.checkResetException
> 
>
> Key: LUCENE-9032
> URL: https://issues.apache.org/jira/browse/LUCENE-9032
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> Ideally {{BaseTokenStreamTestCase.checkResetException}} would be public so 
> that 3rd party projects can test this.  assertTokenStreamContents is public, 
> checkAnalysisConsistency is public, assertAnalyzesTo is public.  It's 
> currently possible to _indirectly_ get this check because assertAnalyzesTo 
> will call it, but this forces the use of RandomizedTesting and 3rd parties 
> might not be using that.



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

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

[jira] [Resolved] (LUCENE-9032) Make public: BaseTokenStreamTestCase.checkResetException



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

David Smiley resolved LUCENE-9032.
--
Fix Version/s: 8.7
   Resolution: Fixed

> Make public: BaseTokenStreamTestCase.checkResetException
> 
>
> Key: LUCENE-9032
> URL: https://issues.apache.org/jira/browse/LUCENE-9032
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/test-framework
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.7
>
>
> Ideally {{BaseTokenStreamTestCase.checkResetException}} would be public so 
> that 3rd party projects can test this.  assertTokenStreamContents is public, 
> checkAnalysisConsistency is public, assertAnalyzesTo is public.  It's 
> currently possible to _indirectly_ get this check because assertAnalyzesTo 
> will call it, but this forces the use of RandomizedTesting and 3rd parties 
> might not be using that.



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

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

[GitHub] [lucene-solr] dsmiley commented on pull request #1938: SOLR-14766: Remove restlet as dependency for the ManagedResource API



dsmiley commented on pull request #1938:
URL: https://github.com/apache/lucene-solr/pull/1938#issuecomment-702515974


   The title of this PR refers to SOLR-14766 which is about deprecation and/or 
removal of managed resources overall.
   I think this PR should be retitled to link to 
https://issues.apache.org/jira/browse/SOLR-14659 
   



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

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



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

[jira] [Commented] (LUCENE-9533) Consider switching to javacc21



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

Dawid Weiss commented on LUCENE-9533:
-

Please file another issue or reopen and assign yourself if you like, Ishan. I 
don't think I'll be returning to this one. 

> Consider switching to javacc21
> --
>
> Key: LUCENE-9533
> URL: https://issues.apache.org/jira/browse/LUCENE-9533
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Priority: Minor
>
> There is an actively maintained interesting "fork", here:
> https://github.com/javacc21/javacc21
> I didn't look at what it generates but the list of features is impressive and 
> the quality of current javacc-generated code is... well, it looks like 1999. 
> It'd be interesting to look into it and assess if it's worth switching to.



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

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

[GitHub] [lucene-solr] dweiss commented on pull request #1905: LUCENE-9488 Release with Gradle Part 2



dweiss commented on pull request #1905:
URL: https://github.com/apache/lucene-solr/pull/1905#issuecomment-702532515


   I'll take a look later today.
   
   On Fri, Oct 2, 2020 at 12:02 AM Mike Drob  wrote:
   
   > *@madrob* commented on this pull request.
   > --
   >
   > In lucene/packaging/build.gradle
   > :
   >
   > > +// This project puts together a "distribution", assembling dependencies 
from
   > +// various other projects.
   > +
   > +plugins {
   > +id 'distribution'
   > +}
   > +
   > +description = 'Lucene distribution packaging'
   > +
   > +// Declare all subprojects that should be included in binary distribution.
   > +// By default everything is included, unless explicitly excluded.
   > +def includeInBinaries = project(":lucene").subprojects.findAll 
{subproject ->
   > +return !(subproject.path in [
   > +":lucene:packaging",
   > +":lucene:analysis",
   > +":lucene:luke", // nocommit - Encountered duplicate path 
"luke/lib/log4j-core-2.13.2.jar"
   >
   > @dweiss  this is still a problem, not sure why
   > it comes up or how to resolve it.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   



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

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



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

[jira] [Comment Edited] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org



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

Dawid Weiss edited comment on LUCENE-9548 at 10/2/20, 6:58 AM:
---

Hi Uwe. I've changed credential property names to use those mentioned on that 
cwiki page so in theory it should work if you run this from jenkins:
{code}
gradlew mavenToApacheSnapshots
{code}

I also added other task aliases for convention tasks (which have fairly long 
names):
{code}
mavenToApacheSnapshots - Publish Maven JARs and POMs to Apache Snapshots 
repository: https://repository.apache.org/content/repositories/snapshots
mavenToLocalFolder - Publish Maven JARs and POMs locally to 
[...]\build\maven-local
mavenToLocalRepo - Publish Maven JARs and POMs to current user's local maven 
repository.
{code}

We should probably add ApacheReleases repository too for final releases (or 
create a bundle uploadable to Nexus?).



was (Author: dweiss):
Hi Uwe. I've changed credential property names to use those mentioned on that 
cwiki page so in theory it should work if you run this from jenkins:
{code}
gradlew mavenToApacheSnapshots
{code}

I also added other task aliases for convention tasks (which have fairly long 
names):
{code}
mavenToApacheSnapshots - Publish Maven JARs and POMs to Apache Snapshots 
repository: https://repository.apache.org/content/repositories/snapshots
mavenToLocalFolder - Publish Maven JARs and POMs locally to 
[...]\build\maven-local
mavenToLocalRepo - Publish Maven JARs and POMs to current user's local maven 
repository.
{code}

We should probably add ApacheReleases repository too for final releases (or 
create a bundle uploadable to Nexus?).


> Publish master (9.x) snapshots to https://repository.apache.org
> ---
>
> Key: LUCENE-9548
> URL: https://issues.apache.org/jira/browse/LUCENE-9548
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We should start publishing snapshot JARs to Apache repositories. I'm not sure 
> how to set it all up with gradle but maybe there are other Apache projects 
> that use gradle and we could peek at their config? Mostly it's about signing 
> artifacts (how to pass credentials for signing) and setting up Nexus 
> deployment repository.



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

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

[jira] [Commented] (LUCENE-9548) Publish master (9.x) snapshots to https://repository.apache.org