[jira] [Closed] (SOLR-12331) How to backup solr collection

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey closed SOLR-12331.
---

> How to backup solr collection
> -
>
> Key: SOLR-12331
> URL: https://issues.apache.org/jira/browse/SOLR-12331
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Paul Williams
>Priority: Critical
>  Labels: Backup/Restore, backup, collection, location, newbie, 
> restore
>
> Hello Solr experts,
> I am new to solr and have a lot to learn, but I have been tasked with writing 
> a backup and restore demo. I have a question regarding the location of the 
> backup when taking a backup.
> In my address box I have the following URL to get my backup started...
> [http://IPADDRESS:8983/solr/#/collections?action=BACKUP=test_catalog=|http://ipaddress:8983/solr/#/collections?action=BACKUP=test_catalog=]
> ...so the documentation says I should back up to a shared drive, but shared 
> drive where? Is the shared drive on the zookeeper, or on my local machine? If 
> on the zookeeper, do I need to create a backup directory first? And if on my 
> local machine, what do I need to type in?
> I am also interested to know if it is possible to backup to an Azure blob?
> What is the difference between the location and repository?
> I would really appreciate any guidance, there appears to be no step by step 
> on the internet (hard to believe I know), but if there is I cannot find it. 
> If I end up creating one from help received here, I will be only too happy to 
> share it to the greater community.
>  
> Thank you.
> Kind Regards,
> Paul.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12331) How to backup solr collection

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey resolved SOLR-12331.
-
   Resolution: Invalid
Fix Version/s: (was: 7.3.1)

This issue tracker is not a support portal.  Please use support resources like 
the mailing list or the IRC channel to get help.  If after discussion it is 
determined that there is a bug in Solr, then we can open an issue in this 
tracker.

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

An example of a shared drive is storage mounted via NFS on all the SolrCloud 
servers in the same location.  Or in the case of Windows, a shared drive 
mounted from a file server.


> How to backup solr collection
> -
>
> Key: SOLR-12331
> URL: https://issues.apache.org/jira/browse/SOLR-12331
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Backup/Restore
>Affects Versions: 7.3.1
>Reporter: Paul Williams
>Priority: Critical
>  Labels: Backup/Restore, backup, collection, location, newbie, 
> restore
>
> Hello Solr experts,
> I am new to solr and have a lot to learn, but I have been tasked with writing 
> a backup and restore demo. I have a question regarding the location of the 
> backup when taking a backup.
> In my address box I have the following URL to get my backup started...
> [http://IPADDRESS:8983/solr/#/collections?action=BACKUP=test_catalog=|http://ipaddress:8983/solr/#/collections?action=BACKUP=test_catalog=]
> ...so the documentation says I should back up to a shared drive, but shared 
> drive where? Is the shared drive on the zookeeper, or on my local machine? If 
> on the zookeeper, do I need to create a backup directory first? And if on my 
> local machine, what do I need to type in?
> I am also interested to know if it is possible to backup to an Azure blob?
> What is the difference between the location and repository?
> I would really appreciate any guidance, there appears to be no step by step 
> on the internet (hard to believe I know), but if there is I cannot find it. 
> If I end up creating one from help received here, I will be only too happy to 
> share it to the greater community.
>  
> Thank you.
> Kind Regards,
> Paul.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-11453:
-

That's a good question on the sysprop.  I have no idea how many users might 
want to enable/disable separate logfiles, but if it's wanted frequently, it 
would be better to have it controlled by a setting in solr.in.sh in the same 
way as the heap size.

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch, 
> slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12331) How to backup solr collection

2018-05-08 Thread Paul Williams (JIRA)
Paul Williams created SOLR-12331:


 Summary: How to backup solr collection
 Key: SOLR-12331
 URL: https://issues.apache.org/jira/browse/SOLR-12331
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Backup/Restore
Affects Versions: 7.3.1
Reporter: Paul Williams
 Fix For: 7.3.1


Hello Solr experts,

I am new to solr and have a lot to learn, but I have been tasked with writing a 
backup and restore demo. I have a question regarding the location of the backup 
when taking a backup.

In my address box I have the following URL to get my backup started...

[http://IPADDRESS:8983/solr/#/collections?action=BACKUP=test_catalog=|http://ipaddress:8983/solr/#/collections?action=BACKUP=test_catalog=]

...so the documentation says I should back up to a shared drive, but shared 
drive where? Is the shared drive on the zookeeper, or on my local machine? If 
on the zookeeper, do I need to create a backup directory first? And if on my 
local machine, what do I need to type in?

I am also interested to know if it is possible to backup to an Azure blob?

What is the difference between the location and repository?

I would really appreciate any guidance, there appears to be no step by step on 
the internet (hard to believe I know), but if there is I cannot find it. If I 
end up creating one from help received here, I will be only too happy to share 
it to the greater community.

 

Thank you.

Kind Regards,

Paul.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker resolved SOLR-12265.
--
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-11453:
-

Looks like I didn't get the last of the changes actually saved before I created 
the patch.  Uploaded another version.

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch, 
> slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[VOTE] Release Lucene/Solr 7.3.1 RC2

2018-05-08 Thread Đạt Cao Mạnh
Please vote for release candidate 2 for Lucene/Solr 7.3.1

The artifact can be downloaded from:
*https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC2-revae0705edb59eaa567fe13ed3a222fdadc7153680/
*

You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
*https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC2-revae0705edb59eaa567fe13ed3a222fdadc7153680
*

Here’s my +1
SUCCESS! [0:53:47.443795]


[jira] [Updated] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey updated SOLR-11453:

Attachment: slowlog-informational.patch

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch, 
> slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12265:


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

SOLR-12265: Upgrade to Jetty 9.4.10

(cherry picked from commit 1705e4f)


> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11453:
--

{quote}I have plans to try and create a log4j config that uses a sysprop to 
decide whether to log slow requests to a separate file, but it's not something 
that I expect to come together quickly.
{quote}
Checkout StartupLoggingUtils#muteConsole on how we disable console logs when 
not running in foreground mode.  We could use a similar trick.

 

Do we really want to add a sysprop? My thoughts are to enable it by default and 
then if a user doesn't want it he can change the log4j2.xml himself.  

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey edited comment on SOLR-11453 at 5/9/18 4:41 AM:
-

New version of the informational patch.  Summary of things different from your 
patch:

 * SolrCore main javadoc added as already mentioned.
 * The requestLog field has no need to be public.  Set to private.
 * Removed string concatenation from logging messages, switched to slf4j \{\} 
parameters.  A bunch of concatenation for things other than slf4j logging still 
exists.
 * Removed most usages of isXxxxEnabled logging level checks.
 * Added serialVersionUID to an anonymous class. Hopefully the number that 
eclipse generated matches the one that Java auto-assigned.  Prior experience 
shows that having eclipse generate this value on a class always makes the same 
number, so I think there's a possibility that it is indeed the same number that 
Java assigns at compile time if it's not present.  I actually have no idea 
whether this is flagged as a warning by anything other than my IDE.  If we 
leave serialVersionUID out of a class that implement Serializable, then change 
the code in that class in a way that changes the automatically generated 
serialVersionUID, different versions of Solr will not be able to send/receive 
that object in Javabin.

I kept one isDebugEnabled usage for a situation where a logging parameter comes 
from a method that builds a string with StringBuilder instead of using already 
built objects -- could be slow.  Also added TODO on that to figure out whether 
logging the same info at DEBUG and INFO is actually necessary.

I have plans to try and create a log4j config that uses a sysprop to decide 
whether to log slow requests to a separate file, but it's not something that I 
expect to come together quickly.  I will likely need to learn groovy, since I 
don't think we want slow javascript code running for every single log message.  
I also need to figure out whether adding groovy as a dependency for Solr will 
cause issues with the parts of the build system that already use groovy.



was (Author: elyograg):
New version of the informational patch.  Summary of things different from your 
patch:

 * SolrCore main javadoc added as already mentioned.
 * The requestLog field has no need to be public.  Set to private.
 * Removed string concatenation from logging messages, switched to slf4j \{\} 
parameters.  A bunch of concatenation for things other than slf4j logging still 
exists.
 * Removed most usages of isXxxxEnabled logging level checks.
 * Added serialVersionUID to an anonymous class. Hopefully the number that 
eclipse generated matches the one that Java auto-assigned.  Prior experience 
shows that having eclipse generate this value on a class always makes the same 
number, so I think there's a possibility that it is indeed the same number that 
Java assigns at compile time if it's not present.

I kept one isDebugEnabled usage for a situation where a logging parameter comes 
from a method that builds a string with StringBuilder instead of using already 
built objects -- could be slow.  Also added TODO on that to figure out whether 
logging the same info at DEBUG and INFO is actually necessary.

I have plans to try and create a log4j config that uses a sysprop to decide 
whether to log slow requests to a separate file, but it's not something that I 
expect to come together quickly.  I will likely need to learn groovy, since I 
don't think we want slow javascript code running for every single log message.  
I also need to figure out whether adding groovy as a dependency for Solr will 
cause issues with the parts of the build system that already use groovy.


> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger 

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 582 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/582/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC

33 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([F460FE8C64D59ED9:A7D9BC3C86C40B23]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
should have fired an event

Stack Trace:
java.lang.AssertionError: should have fired an event
at 

[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-11453:
-

New version of the informational patch.  Summary of things different from your 
patch:

 * SolrCore main javadoc added as already mentioned.
 * The requestLog field has no need to be public.  Set to private.
 * Removed string concatenation from logging messages, switched to slf4j \{\} 
parameters.  A bunch of concatenation for things other than slf4j logging still 
exists.
 * Removed most usages of isXxxxEnabled logging level checks.
 * Added serialVersionUID to an anonymous class. Hopefully the number that 
eclipse generated matches the one that Java auto-assigned.  Prior experience 
shows that having eclipse generate this value on a class always makes the same 
number, so I think there's a possibility that it is indeed the same number that 
Java assigns at compile time if it's not present.

I kept one isDebugEnabled usage for a situation where a logging parameter comes 
from a method that builds a string with StringBuilder instead of using already 
built objects -- could be slow.  Also added TODO on that to figure out whether 
logging the same info at DEBUG and INFO is actually necessary.

I have plans to try and create a log4j config that uses a sysprop to decide 
whether to log slow requests to a separate file, but it's not something that I 
expect to come together quickly.  I will likely need to learn groovy, since I 
don't think we want slow javascript code running for every single log message.  
I also need to figure out whether adding groovy as a dependency for Solr will 
cause issues with the parts of the build system that already use groovy.


> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker updated SOLR-12265:
-
Affects Version/s: (was: 7.3)

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: Review Request 66967: SolrCmdDistributor retries requestss from leader to followers

2018-05-08 Thread Tomás Fernández Löbbe

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/66967/
---

(Updated May 9, 2018, 4:33 a.m.)


Review request for lucene.


Changes
---

Don't retry on DBQ


Repository: lucene-solr


Description
---

SolrCmdDistributor retries requestss from leader to followers


Diffs (updated)
-

  solr/core/src/java/org/apache/solr/update/SolrCmdDistributor.java 08b397fbb2 
  solr/core/src/java/org/apache/solr/update/StreamingSolrClients.java 
316aa455a1 
  
solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
 d5e4194b15 
  
solr/core/src/java/org/apache/solr/update/processor/TimeRoutedAliasUpdateProcessor.java
 224bd4b6ba 
  solr/core/src/test/org/apache/solr/cloud/ChaosMonkeySafeLeaderTest.java 
76c1984a0d 
  solr/core/src/test/org/apache/solr/update/MockStreamingSolrClients.java 
72d39ff89b 
  solr/core/src/test/org/apache/solr/update/SolrCmdDistributorTest.java 
1699b0d70d 


Diff: https://reviews.apache.org/r/66967/diff/4/

Changes: https://reviews.apache.org/r/66967/diff/3-4/


Testing
---


Thanks,

Tomás Fernández Löbbe



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12265:


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

SOLR-12265: Upgrade to Jetty 9.4.10


> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 216 - Still Unstable

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/216/

6 tests failed.
FAILED:  org.apache.solr.cloud.RollingRestartTest.test

Error Message:
Unable to restart (#7): CloudJettyRunner 
[url=https://127.0.0.1:34482/collection1_shard2_replica_n49]

Stack Trace:
java.lang.AssertionError: Unable to restart (#7): CloudJettyRunner 
[url=https://127.0.0.1:34482/collection1_shard2_replica_n49]
at 
__randomizedtesting.SeedInfo.seed([C779118A6F794AB4:4F2D2E50C185274C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:103)
at 
org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey updated SOLR-11453:

Attachment: slowlog-informational.patch

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12307) Stop endless spin java.io.IOException: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /autoscaling.json

2018-05-08 Thread JIRA

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

Tomás Fernández Löbbe commented on SOLR-12307:
--

+1. That's what we do in other overseer threads. Maybe we also want to do the 
same if the exception is an instance of 
{{KeeperException.SessionExpiredException}}

> Stop endless spin java.io.IOException: 
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode 
> = Session expired for /autoscaling.json 
> -
>
> Key: SOLR-12307
> URL: https://issues.apache.org/jira/browse/SOLR-12307
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12307.patch
>
>
> When ZK expires one loop continue spinning pointlessly that hurts CI so often 
> {code}
>   [junit4]   2>at
> org.apache.solr.client.solrj.cloud.DistribStateManager.getAutoScalingConfig(DistribStateManager.java:83)
> ~[java/:?]
>[junit4]   2>at
> org.apache.solr.cloud.autoscaling.OverseerTriggerThread.run(OverseerTriggerThread.java:131)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7960:
-

{quote}
I made the min/max parameters required on the factory because the constructor 
without any size parameters is deprecated. Is this something you don't like at 
all, or something you would only want to see in master?
{quote}

what does it mean "not making that change in the backport to 7x" ?
As i suggested above: consider making the patch against master fully backwards 
compatible. We can review it, then it can be committed, merged cleanly and 
safely back to 7.x. After that, remove the deprecations in master in a separate 
dedicated commit.

It seems like more work, but I think its less work than trying to do a 
shortcut, because you can have confidence you don't break stuff. "Making 
changes during backports" seems like trouble, and having a confusing patch 
makes the code review hard. The current one is confusing because it isn't 
really appropriate for either master (it has deprecations) nor 7x (it breaks 
backwards)


> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-12265:
--

Thanks Mark for validating! I've uploaded the patch. Will commit this soon

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker updated SOLR-12265:
-
Attachment: SOLR-12265.patch

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12265.patch
>
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-12265:


+1 on the upgrade. Looks like lots of bug fixes.

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.10

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-12265:
--

Anyone has any objections with the upgrade?

Otherwise tests pass and there is no API change involved. Simply updating the 
ivy-versions.properties file

> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8 
> We're seeing this WARN very sporadically ( maybe one in every 100k requests ) 
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) - 
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) 
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
>  ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124) 
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
>  ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for 
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28 
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0 
> of 
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
>  of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a 
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was 
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x 
> and then in Jetty 9.4.9 this class has undergone quite a few changes 
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
>  . 
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

2018-05-08 Thread Varun Thacker (JIRA)

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

Varun Thacker commented on SOLR-11453:
--

Hi Shawn,

Thanks for working on the patch. Few things I wanted to ask you.
{quote}bq.  I noticed the SolrCore class has an empty top-level Javadoc. Which 
makes precommit pass, but doesn't give anyone any information about the class. 
That's a rather glaring omission IMHO.
{quote}
Makes sense. I'll fold this change in.

 
{quote}In accordance with some best practices mentioned on SOLR-12286, I 
removed usages of "log.isXxxxEnabled()" methods. That is the idea I was most 
interested in telling you about.
{quote}
These are logging lines that would get used for every update and search 
request. If by any chance removing the isDebugEnabled on these creates a ton of 
objects then this won't be good. I'd rather be pedantic and not change it here? 
What do you think?
{quote}One of the warnings I noticed in eclipse is that serialVersionUID was 
missing from an inner anonymous class, so I had eclipse add that. Also not 
important for this issue.
{quote}
Do you know if our precommit also lists this as a warning? I'm open to adding 
this as but was just curious?
 
Have you had a chance to look at my patch? Do those changes look good? If yes 
then I'll fold these enhancements that you added and commit it tomorrow

> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Affects Versions: 7.0.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



Re: [VOTE] Release Lucene/Solr 7.3.1 RC1

2018-05-08 Thread Đạt Cao Mạnh
This release needs to spin because of SOLR-12316.

On Thu, May 3, 2018 at 6:31 PM Ahmet Arslan 
wrote:

> +1
>
> SUCCESS! [1:15:16.705804]
>
> Ahmet
>
>
> On Wednesday, May 2, 2018, 9:55:04 PM GMT+3, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
>
>
>
>
> +1
> SUCCESS! [1:04:51.914445]
>
> On Wed, May 2, 2018 at 12:32 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
> > +1
> >
> > SUCCESS! [0:49:04.927108]
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Wed, May 2, 2018 at 6:40 AM, Đạt Cao Mạnh 
> wrote:
> >> Please vote for release candidate 1 for Lucene/Solr 7.3.1
> >>
> >> The artifacts can be downloaded from:
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.3.1-RC1-rev8fa7687413558b3bc65cbbbeb722a21314187e6a
> >>
> >> Here's my +1
> >> SUCCESS! [0:52:14.381028]
> >>
> >
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+5) - Build # 21979 - Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21979/
Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.MaxSizeAutoCommitTest.deleteTest

Error Message:
Tlog size exceeds the max size bound. Tlog path: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.update.MaxSizeAutoCommitTest_988AEB31DED7DE72-001/init-core-data-001/tlog/tlog.003,
 tlog size: 1302

Stack Trace:
java.lang.AssertionError: Tlog size exceeds the max size bound. Tlog path: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.update.MaxSizeAutoCommitTest_988AEB31DED7DE72-001/init-core-data-001/tlog/tlog.003,
 tlog size: 1302
at 
__randomizedtesting.SeedInfo.seed([988AEB31DED7DE72:88C40ECEA579E783]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.update.MaxSizeAutoCommitTest.getTlogFileSizes(MaxSizeAutoCommitTest.java:379)
at 
org.apache.solr.update.MaxSizeAutoCommitTest.deleteTest(MaxSizeAutoCommitTest.java:200)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 606 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/606/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.CustomHighlightComponentTest

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:51982 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:51982 within 3 ms
at __randomizedtesting.SeedInfo.seed([75239061DA7DDA88]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:183)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:120)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:102)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForAllNodes(MiniSolrCloudCluster.java:269)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:263)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.build(SolrCloudTestCase.java:198)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
at 
org.apache.solr.handler.component.CustomHighlightComponentTest.setupCluster(CustomHighlightComponentTest.java:119)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:51982 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:232)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:175)
... 32 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.CustomHighlightComponentTest

Error Message:
ObjectTracker found 6 object(s) that were not released!!! [InternalHttpClient, 
InternalHttpClient, InternalHttpClient, InternalHttpClient, InternalHttpClient, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:319)
  at 
org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:212)
  at 
org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:47)
  at 

[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-7960:
--

All good points.

I made the min/max parameters required on the factory because the constructor 
without any size parameters is deprecated.  Is this something you don't like at 
all, or something you would only want to see in master?  You're right that 
there is some backcompat confusion in that.  I wasn't completely sure it was a 
good idea, decided to proceed, with the probability of not making that change 
in the backport to 7x.

If we do need to keep default values, the current defaults (1 and 2 for ngram, 
1 and 1 for edgengram) really kinda suck.  But changing them is another 
backcompat break.  Seems better to completely get rid of defaults in master, 
and unless I misunderstood you, that seems to be your position as well.

I would need to review the patch to be sure, but I think that the cosmetic 
style changes you mentioned were made by the contributor before I started 
working on it.  The changes to the inner workings of the filter looked like 
they were doing more than the issue requires, but I don't understand token 
handling code well enough to grasp what the changes were actually doing.  Tests 
pass, so if there's a problem there, it's not being caught by test coverage.  
Please feel free to adjust or make suggestions!

I'm done in for the night, and will poke at it again tomorrow.  If you could 
summarize everything that you'd like to see in a new patch, that would help me.

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-Tests-7.x - Build # 600 - Still Unstable

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/600/

4 tests failed.
FAILED:  org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState

Error Message:
Collection not found: deleteFromClusterState_false

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: 
deleteFromClusterState_false
at 
__randomizedtesting.SeedInfo.seed([4B4137FF3E44AD3F:A5D89C92017AD688]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:853)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:187)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaFromClusterState(DeleteReplicaTest.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1850 - Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1850/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

10 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
number of ops expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: number of ops expected:<2> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([A2730678EE614E6E:C1B830FA77AE3D43]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack 

[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7960:
-

Also for the full ctor that allows a range, i really still think it needs some 
wording, a warning of sorts, that a big range is really the same 
(space/time-wise) as indexing the content N different ways. It may be also good 
to include the fact that if you pass {{true}} for preserveOriginal, its like 
indexing the content yet another time.

The ctor that just takes a fixed "n" for the n-gram doesn't need such warnings, 
its pretty safe.

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7960:
-

The patch has a little confusion about back compat (e.g. breaks back compat 
with the factories by requiring parameters that were optional before, but 
leaves back compat in the tokenfilters), so I'm not sure if its geared at the 
master branch or not. Sometimes its easiest to make the patch with all the 
back-compat, commit it to master and merge it back, then make a separate commit 
to just master to remove the cruft, maybe its good in this case.

There are some cosmetic style changes such as moving attribute initialization 
into the ctor instead of inline, that is different than the style of all our 
other tokenfilters. It makes it hard to review the logic changes (have not 
looked at this, just the apis and docs).

As far as docs, I think there are easy wins. Lets take EdgeNGramTokenFilter 
just as an example.

For the ctor with all the parameters, it doesn't need to have documentation on 
what the other ctors do: they can have their own. It should only document the 
behavior and parameters like it does, so we can just remove its last line about 
that.

For the other ctors which are shortcuts/sugar, we can add a line such as this:
{code}
   * 
   * Behaves the same as {@link #EdgeNGramTokenFilter(TokenStream, int, int, 
boolean) 
   * EdgeNGramTokenFilter(input, minGram, maxGram, 
false)}
{code}

This helps make it clear what the shortcut/sugar is really doing with a 
clickable link, and it also helps the deprecated case, if someone has to 
transition their code.

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey updated LUCENE-7960:
-
Attachment: LUCENE-7960.patch

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-7960:
--

Uploading new patch.  [~iwesp], please make sure I haven't broken anything, 
including test coverage.  Tests and precommit do pass.  [~rcmuir], can you look 
it over too?


> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12292) Make it easier to configure Solr with CORS

2018-05-08 Thread JIRA

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

Jan Høydahl commented on SOLR-12292:


If we make it easy enough to configure CORS origins, we don't need to have it 
open for all origins by default, we can pre-configure for all nodes in same 
cluster to enable Admin UI access.

Perhaps this could be a new clusterProp {{corsOrigins}}, taking a comma 
separated list of valid origins? Then we already have the infrastructure to 
edit the list, through the CLUSTERPROP API and zkcli.sh. We could add an 
AdminUI edit screen too if we want.

> Make it easier to configure Solr with CORS
> --
>
> Key: SOLR-12292
> URL: https://issues.apache.org/jira/browse/SOLR-12292
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Reporter: Jan Høydahl
>Priority: Major
>
> While working on SOLR-8207 I wanted to collect info from other SolrCloud 
> nodes from the AdminUI. However this is blocked by 
> [CORS|https://en.wikipedia.org/wiki/Cross-origin_resource_sharing] policy. In 
> that Jira I instead did the fan-out on the Solr server side for the two 
> handler I needed.
> It would be nice if all nodes in a SolrCloud cluster could automatically 
> accept any other node as a legal origin, and make it easy for users to add 
> other origins by config.
> If we use the [Jetty CORS 
> filter|http://www.eclipse.org/jetty/documentation/9.4.9.v20180320/cross-origin-filter.html]
>  in web.xml, perhaps we could parse a env.var from solr.in.xx and inject into 
> the {{allowedOrigins}} property of that filter? There is also SOLR-6059 which 
> tries to implement CORS inside of Solr handlers and not in Jetty. Don't know 
> pros/cons of those.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12055) Enable asynch logging by default

2018-05-08 Thread JIRA

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

Jan Høydahl commented on SOLR-12055:


Linking SOLR-12120 which deals with an audit logging framework completely 
separate from Log4j. That framework has support for both synchronous and async 
audit logger implementations.

> Enable asynch logging by default
> 
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change 
> to the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

2018-05-08 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev commented on SOLR-12298:
-

bq. I'm proposing removing explicit SolrInputField._childDocuments in favor of 
having fields contains child document values.
[~dsmiley], I've found some by considerations by [~hossman] 
[here|https://issues.apache.org/jira/browse/SOLR-3535?focusedCommentId=13295189=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13295189].
 Personally I don't have strong opinion. 

> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 215 - Still Failing

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/215/

No tests ran.

Build Log:
[...truncated 24220 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2194 links (1751 relative) to 2949 anchors in 228 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.4.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:

[jira] [Updated] (SOLR-12330) Referencing non existing parameter in JSON Facet "filter" either reported too little and even might be ignored

2018-05-08 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev updated SOLR-12330:

Description: 
Just encounter such weird behaviour, will recheck and followup. 
{{"filter":["\{!v=$bogus}"]}} responds back with just NPE which makes 
impossible to guess the reason.
It might be even worse, since {{"filter":[\{"param":"bogus"}]}} seems like just 
silently ignored.
Once agin, I'll double check. 

  was:
Just encounter such weird behaviour, will recheck and followup. 
{{ "filter":["{!v=$bogus}"]}} responds back with just NPE which makes 
impossible to guess the reason.
It might be even worse, since {{"filter":[{"param":"bogus"}]}} seems like just 
silently ignored.
Once agin, I'll double check. 


> Referencing non existing parameter in JSON Facet "filter" either reported too 
> little and even might be ignored 
> ---
>
> Key: SOLR-12330
> URL: https://issues.apache.org/jira/browse/SOLR-12330
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
>
> Just encounter such weird behaviour, will recheck and followup. 
> {{"filter":["\{!v=$bogus}"]}} responds back with just NPE which makes 
> impossible to guess the reason.
> It might be even worse, since {{"filter":[\{"param":"bogus"}]}} seems like 
> just silently ignored.
> Once agin, I'll double check. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12330) Referencing non existing parameter in JSON Facet "filter" either reported too little and even might be ignored

2018-05-08 Thread Mikhail Khludnev (JIRA)
Mikhail Khludnev created SOLR-12330:
---

 Summary: Referencing non existing parameter in JSON Facet "filter" 
either reported too little and even might be ignored 
 Key: SOLR-12330
 URL: https://issues.apache.org/jira/browse/SOLR-12330
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev


Just encounter such weird behaviour, will recheck and followup. 
{{ "filter":["{!v=$bogus}"]}} responds back with just NPE which makes 
impossible to guess the reason.
It might be even worse, since {{"filter":[{"param":"bogus"}]}} seems like just 
silently ignored.
Once agin, I'll double check. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7960:
-

then it would behave like you expect an n-gram filter to behave? min=max=4 or 
whatever. The two ints is really crazy/expert and doesn't match anyone's 
expectations about what n-grams are. Its also mega trappy as i mentioned above, 
it needs javadoc warnings.

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on LUCENE-7960:
--

What would happen when there's only one int in the constructor?

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11934) Visit Solr logging, it's too noisy.

2018-05-08 Thread Mark Miller (JIRA)

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

Mark Miller commented on SOLR-11934:


I think if we turn this off by default and document how to easily turn it back 
on, we don't have a problem. We never have promised back compat with our 
logging. What's more scary in SOLR-12055 is that you may think things are 
working as you expect for what can be a very sensitive function when they are 
not. If you actually count on certain logging from an issue like this though, 
when you upgrade you have to understand what logging exists for that version 
and how your tools work with what you expect - but at least you can count on 
the logging you as you would expect to if you see it in testing.

> Visit Solr logging, it's too noisy.
> ---
>
> Key: SOLR-11934
> URL: https://issues.apache.org/jira/browse/SOLR-11934
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I think we have way too much INFO level logging. Or, perhaps more correctly, 
> Solr logging needs to be examined and messages logged at an appropriate level.
> We log every update at an INFO level for instance. But I think we log LIR at 
> INFO as well. As a sysadmin I don't care to have my logs polluted with a 
> message for every update, but if I'm trying to keep my system healthy I want 
> to see LIR messages and try to understand why.
> Plus, in large installations logging at INFO level is creating a _LOT_ of 
> files.
> What I want to discuss on this JIRA is
> 1> What kinds of messages do we want log at WARN, INFO, DEBUG, and TRACE 
> levels?
> 2> Who's the audience at each level? For a running system that's functioning, 
> sysops folks would really like WARN messages that mean something need 
> attention for instance. If I'm troubleshooting should I turn on INFO? DEBUG? 
> TRACE?
> So let's say we get some kind of agreement as to the above. Then I propose 
> three things
> 1> Someone (and probably me but all help gratefully accepted) needs to go 
> through our logging and assign appropriate levels. This will take quite a 
> while, I intend to work on it in small chunks.
> 2> Actually answer whether unnecessary objects are created when something 
> like log.info("whatever {}", someObjectOrMethodCall); is invoked. Is this 
> independent on the logging implementation used? The SLF4J and log4j seem a 
> bit contradictory.
> 3> Maybe regularize log, logger, LOG as variable names, but that's a nit.
> As a tactical approach, I suggest we tag each LoggerFactory.getLogger in 
> files we work on with //SOLR-(whatever number is assigned when I create 
> this). We can remove them all later, but since I expect to approach this 
> piecemeal it'd be nice to keep track of which files have been done already.
> Finally, I really really really don't want to do this all at once. There are 
> 5-6 thousand log messages. Even at 1,000 a week that's 6 weeks, even starting 
> now it would probably span the 7.3 release.
> This will probably be an umbrella issue so we can keep all the commits 
> straight and people can volunteer to "fix the files in core" as a separate 
> piece of work (hint).
> There are several existing JIRAs about logging in general, let's link them in 
> here as well.
> Let the discussion begin!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk-10) - Build # 46 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/46/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC

9 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:50527/y_wi/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:50527/y_wi/collection1
at 
__randomizedtesting.SeedInfo.seed([E43B0CB9AA054732:6C6F336304F92ACA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1591)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:212)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-12321) Use of builtin java serialization for admin response breaks 7.3 compatibility

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12321:
-

This has been reported before -- SOLR-7055  and comes up again when 
SolrResponse changes.

> Use of builtin java serialization for admin response breaks 7.3 compatibility
> -
>
> Key: SOLR-12321
> URL: https://issues.apache.org/jira/browse/SOLR-12321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, 7.3.1
>Reporter: Will Currie
>Priority: Minor
>
> Premise: During an upgrade I should be able to run a 7.3 pull replica against 
> a 7.2 tlog leader. Or vice versa.
>  
> Adding a new method[1] to SolrResponse has broken binary compatibility. When 
> I try to register a new pull replica using the admin api[2] I get an HTTP 500 
> responseI see this error logged: java.io.InvalidClassException: 
> org.apache.solr.client.solrj.SolrResponse; local class incompatible: stream 
> classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -793110010336024264
>  
> The replica actually seems to register ok it just can't read the response 
> because the bytes from the 7.2 leader include a different serialVersionUID. 
>  
> Should SolrResponse include a serialVersionIUID? All subclasses too.
> [~markrmil...@gmail.com]'s advice is that the project should never use 
> builtin java serialization.
>  
> It looks like stock java serialization is only used for these admin 
> responses. Query responses use JavaBinCodec instead..
>  
> Full(ish) stack trace:
> {noformat}
> ERROR HttpSolrCall null:org.apache.solr.common.SolrException: 
> java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse; 
> local class incompatible: st
> ream classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -7931100103360242645
>     at 
> org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:73)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.sendToOCPQueue(CollectionsHandler.java:348)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:256)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>     at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
>     at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>  {noformat}
>  
> [1] 
> [https://github.com/apache/lucene-solr/commit/5ce83237e804ac1130eaf5cf793955667793fee0#diff-b809fa594f93aa6805381029a188e4e2R46]
> [2] 
> [http://localhost:8983/solr/admin/collections?action=ADDREPLICA=blah=shard1=blah=pull]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-7960:
-

Yes, I think we should deprecate. It helps ppl upgrade and shouldn't be too bad 
in this case.

If we currently have 1-arg (TokenStream) and 3-arg (TokenStream, int, int), and 
we want to end up at 2-arg (TokenStream, int) and 4-arg (TokenStream, int, int, 
boolean) then 7.x can temporarily have 4 constructors: the existing two of 
which are deprecated and forward to the new ones. Their javadoc can even 
explain what the forwarding is doing. master would just have the two new ones 
with no cruft.


> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12243) Edismax missing phrase queries when phrases contain multiterm synonyms

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-12243:
-

See SOLR-12028.  This issue refers to another one that was deleted for some 
reason -- SOLR-12016.  I can see all the history for that issue in my mail 
archive, but it's not on the Internet any more unless you want to delve into 
things like the web archive.

There is also an extensive discussion on the dev list, and a number of status 
messages from [~erickerickson] detailing the work he's doing on an ongoing 
basis.


> Edismax missing phrase queries when phrases contain multiterm synonyms
> --
>
> Key: SOLR-12243
> URL: https://issues.apache.org/jira/browse/SOLR-12243
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.1
> Environment: RHEL, MacOS X
> Do not believe this is environment-specific.
>Reporter: Elizabeth Haubert
>Priority: Major
> Attachments: SOLR-12243.patch, SOLR-12243.patch, SOLR-12243.patch, 
> SOLR-12243.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> synonyms.txt:
> allergic, hypersensitive
> aspirin, acetylsalicylic acid
> dog, canine, canis familiris, k 9
> rat, rattus
> request handler:
> 
>  
> 
>  edismax
>   0.4
>  title^100
>  title~20^5000
>  title~11
>  title~22^1000
>  text
>  
>  3-1 6-3 930%
>  *:*
>  25
> 
>  
> Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin"  against the 
> above list will not be generated.
> "allergic reaction dog" will generate pf2: "allergic reaction", but not 
> pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction 
> dog"
> "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin 
> dose" or pf3:"aspirin dose ?"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8296) PendingDeletes shouldn't write to live docs that it shared

2018-05-08 Thread Adrien Grand (JIRA)

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

Adrien Grand commented on LUCENE-8296:
--

bq. I think we should have a very very simple base class that FixedBitSet can 
extend that knows how to read from the array.

Because of LUCENE-4892 I'm interested in giving codecs a way to turn mutable 
bits into a read-only instance. The live docs impl in LUCENE-4892 wraps a hash 
set that is upgraded to a bit set when deleted docs become dense, so this would 
help return the wrapped bits and remove an unnecessary layer. I believe it 
could help not expose mutable bits with the default codec too.

bq. One thing that I am feel is missing is an explicit test that the returned 
bits don't change in subsequent modifications.

The changes to TestPendingDeletes test this. This test deletes a document, 
checks that the previously retrieved live docs show the doc as live, then 
retrieves live docs again and make sure it is deleted.

> PendingDeletes shouldn't write to live docs that it shared
> --
>
> Key: LUCENE-8296
> URL: https://issues.apache.org/jira/browse/LUCENE-8296
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-8296.patch
>
>
> PendingDeletes has a markAsShared mechanism that allow to make sure that the 
> latest livedocs are not going to receive more updates. But it is not always 
> used, and I was able to verify that in some cases we end up with readers 
> whose live docs disagree with the number of deletes. Even though this might 
> not be causing bugs, it feels dangerous to me so I think we should consider 
> always marking live docs as shared in #getLiveDocs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley resolved SOLR-12258.
-
   Resolution: Fixed
 Assignee: David Smiley
Fix Version/s: 7.4

> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12258:


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

SOLR-12258: A V2 request referencing a collection or alias may fail to resolve 
it if it was just recently created.
Now we sync with ZooKeeper and try one more time.  V1 partially did this but 
only for aliases; now it does both.

(cherry picked from commit c3d28a5)


> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12258:


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

SOLR-12258: A V2 request referencing a collection or alias may fail to resolve 
it if it was just recently created.
Now we sync with ZooKeeper and try one more time.  V1 partially did this but 
only for aliases; now it does both.


> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.4) - Build # 7307 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7307/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

51 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180508224920835, index.20180508224921105, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180508224920835, 
index.20180508224921105, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([31E23FFD4D05FC02:EA493F3B482D95B1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)

2018-05-08 Thread Gus Heck (JIRA)

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

Gus Heck commented on SOLR-12258:
-

Yeah I like that. I wasn't a fan of the secondTry arg either, except I'm not 
sure if we can put the aliasManager.update() in the same try bloack as 
.forceUpdateCollection() since we probably still want to force update the 
collection even if aliases update isn't happy... either that or we don't want 
to ignore the exception after all.

> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that 
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry 
> the request as if anew (in collaboration with SolrDispatchFilter).  If it 
> fails to resolve again we stop there and return an error; it doesn't go on 
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism.  It'll return 
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that 
> will at least help the odds of a newly made collection from being known to 
> this Solr node.  It'd be nice if this was more explicit – i.e. if there was a 
> mechanism similar to AliasesManager.update() but for a collection.  I'm not 
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of 
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to 
> issue a V2 based request to change the configuration of a collection that was 
> created immediately before it.  It's pretty mysterious.  I am aware of 
> SolrCloudTestCase.waitForState which is maybe something that needs to be 
> called?  But if that were true then *every* SolrCloud test would need to use 
> it; it just seems wrong to me that we ought to use this method commonly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12055) Enable asynch logging by default

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-12055:
---

Shawn:

That'd be great, but it'll probably be a week or more before I get back to this 
(going on vacation) so I'll circle back around at that point.


> Enable asynch logging by default
> 
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change 
> to the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12243) Edismax missing phrase queries when phrases contain multiterm synonyms

2018-05-08 Thread Alessandro Benedetti (JIRA)

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

Alessandro Benedetti commented on SOLR-12243:
-

Thanks [~elyograg], the code changes were minimal ( 1 line changed + 1 test 
added) but I agree with you about the inconsistency of the current testing 
framework.
I have another 3 patches pending, all of them with random tests failures ( very 
unlikely to be related the change itself).
You mentioned Erick is working on that, is there any Jira issue tracking that ?
Any way we could help ?
Thanks

> Edismax missing phrase queries when phrases contain multiterm synonyms
> --
>
> Key: SOLR-12243
> URL: https://issues.apache.org/jira/browse/SOLR-12243
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 7.1
> Environment: RHEL, MacOS X
> Do not believe this is environment-specific.
>Reporter: Elizabeth Haubert
>Priority: Major
> Attachments: SOLR-12243.patch, SOLR-12243.patch, SOLR-12243.patch, 
> SOLR-12243.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> synonyms.txt:
> allergic, hypersensitive
> aspirin, acetylsalicylic acid
> dog, canine, canis familiris, k 9
> rat, rattus
> request handler:
> 
>  
> 
>  edismax
>   0.4
>  title^100
>  title~20^5000
>  title~11
>  title~22^1000
>  text
>  
>  3-1 6-3 930%
>  *:*
>  25
> 
>  
> Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin"  against the 
> above list will not be generated.
> "allergic reaction dog" will generate pf2: "allergic reaction", but not 
> pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction 
> dog"
> "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin 
> dose" or pf3:"aspirin dose ?"
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12192) Error when ulimit is unlimited

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson resolved SOLR-12192.
---
Resolution: Fixed

Thanks Martijn!

> Error when ulimit is unlimited
> --
>
> Key: SOLR-12192
> URL: https://issues.apache.org/jira/browse/SOLR-12192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.3
>Reporter: Martijn Koster
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
>
> I noticed:
> {noformat}
> solr@fd8031538f4b:/opt/solr$  ulimit -u
> unlimited
> solr@fd8031538f4b:/opt/solr$  bin/solr
> /opt/solr/bin/solr: line 1452: [: unlimited: integer expression expected
> {noformat}
> The solr start script should check for "unlimited" and not print that error.
> Patch on https://github.com/apache/lucene-solr/pull/352



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12192) Error when ulimit is unlimited

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12192:


Commit 4cab3eba9c751b6364bf89f6d4dcd604985edba2 in lucene-solr's branch 
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4cab3eb ]

SOLR-12192: Error when ulimit is unlimited

(cherry picked from commit abb57c5)


> Error when ulimit is unlimited
> --
>
> Key: SOLR-12192
> URL: https://issues.apache.org/jira/browse/SOLR-12192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.3
>Reporter: Martijn Koster
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
>
> I noticed:
> {noformat}
> solr@fd8031538f4b:/opt/solr$  ulimit -u
> unlimited
> solr@fd8031538f4b:/opt/solr$  bin/solr
> /opt/solr/bin/solr: line 1452: [: unlimited: integer expression expected
> {noformat}
> The solr start script should check for "unlimited" and not print that error.
> Patch on https://github.com/apache/lucene-solr/pull/352



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12192) Error when ulimit is unlimited

2018-05-08 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on SOLR-12192:


Commit abb57c5c8166b25e8e26e3bde714d80f00b5cf27 in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=abb57c5 ]

SOLR-12192: Error when ulimit is unlimited


> Error when ulimit is unlimited
> --
>
> Key: SOLR-12192
> URL: https://issues.apache.org/jira/browse/SOLR-12192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.3
>Reporter: Martijn Koster
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
>
> I noticed:
> {noformat}
> solr@fd8031538f4b:/opt/solr$  ulimit -u
> unlimited
> solr@fd8031538f4b:/opt/solr$  bin/solr
> /opt/solr/bin/solr: line 1452: [: unlimited: integer expression expected
> {noformat}
> The solr start script should check for "unlimited" and not print that error.
> Patch on https://github.com/apache/lucene-solr/pull/352



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 605 - Still unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/605/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.AliasIntegrationTest.testDeleteOneOfTwoCollectionsAliased

Error Message:
Expected collection_one to be created with 2 shards and 1 replica null Live 
Nodes: [127.0.0.1:43127_solr, 127.0.0.1:52952_solr] Last available state: null

Stack Trace:
java.lang.AssertionError: Expected collection_one to be created with 2 shards 
and 1 replica
null
Live Nodes: [127.0.0.1:43127_solr, 127.0.0.1:52952_solr]
Last available state: null
at 
__randomizedtesting.SeedInfo.seed([8D2DE6B3BC0FDE62:A02A231D033A74B8]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:278)
at 
org.apache.solr.cloud.AliasIntegrationTest.testDeleteOneOfTwoCollectionsAliased(AliasIntegrationTest.java:405)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 52 - Still Unstable

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/52/

10 tests failed.
FAILED:  
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored_idx

Error Message:
java.lang.RuntimeException: Could not load collection from ZK: test_col

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Could not 
load collection from ZK: test_col
at 
__randomizedtesting.SeedInfo.seed([AE7DF151F4704847:A45AA0718B06EB10]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:288)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored_idx(TestStressCloudBlindAtomicUpdates.java:221)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Could not 

[jira] [Commented] (SOLR-12055) Enable asynch logging by default

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-12055:
-

I'm happy to provide you with some rather large logs from a 6.6.3 server that 
gets mostly updates and very few queries beyond load balancer health checks.  I 
also have 4.x servers that DO get queries and also produce large logs.  Since 
they're older versions, they will not have the improvements we've already made 
to reduce logging verbosity, but would hopefully provide insight for further 
verbosity reduction.


> Enable asynch logging by default
> 
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change 
> to the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-08 Thread Shawn Heisey (JIRA)

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

Shawn Heisey commented on SOLR-7767:


ZK 3.4.11 has ZOOKEEPER-2960 as a problem.  In that version, dataDir and 
dataLogDir are switched.  The project removed 3.4.11 from their mirrors and 
released 3.4.12 to fix the problem.


> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-error.png, zk-status-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-08 Thread Michael McCandless (JIRA)

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

Michael McCandless commented on LUCENE-8298:


+1, very cool!  My favorite part of the patch is:
{quote}just don't do it!{quote}
:)

Curiously, Lucene long ago had the ability to undelete a document!  It was a 
method on {{IndexReader}} to undelete all documents (that had not been 
reclaimed by merges yet), and now we get that ability back, but in the right 
place ({{IndexWriter}}) and with control over which doc to un-soft-delete.

 

> Allow DocValues updates to reset a value
> 
>
> Key: LUCENE-8298
> URL: https://issues.apache.org/jira/browse/LUCENE-8298
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8298.patch, LUCENE-8298.patch
>
>
>  Today once a document has a value in a certain DV field this values
> can only be changed but not removed. While resetting / removing a value
> from a field is certainly a corner case it can be used to undelete a
> soft-deleted document unless it's merged away.
> This allows to rollback changes without rolling back to another 
> commitpoint
> or trashing all uncommitted changes. In certain cenarios it can be used to
> "repair" history of documents in distributed systems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley commented on LUCENE-7960:
--

A new preserveOriginal will be nice, and also consistent with other filters 
that have this.
I agree with Rob about the defaults; users should explicitly state the gram 
length(s).

> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Priority: Major
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Assigned] (SOLR-12192) Error when ulimit is unlimited

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson reassigned SOLR-12192:
-

Assignee: Erick Erickson

> Error when ulimit is unlimited
> --
>
> Key: SOLR-12192
> URL: https://issues.apache.org/jira/browse/SOLR-12192
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCLI
>Affects Versions: 7.3
>Reporter: Martijn Koster
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
>
> I noticed:
> {noformat}
> solr@fd8031538f4b:/opt/solr$  ulimit -u
> unlimited
> solr@fd8031538f4b:/opt/solr$  bin/solr
> /opt/solr/bin/solr: line 1452: [: unlimited: integer expression expected
> {noformat}
> The solr start script should check for "unlimited" and not print that error.
> Patch on https://github.com/apache/lucene-solr/pull/352



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12112) NPE in QueryComponent

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson updated SOLR-12112:
--
Fix Version/s: (was: 7.4)
   (was: master (8.0))

> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2 
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>   
> 
>   explicit
>   10
> 
>   
>   
>   
> 
>   score desc,id asc
>   none
> 
>   
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12112) NPE in QueryComponent

2018-05-08 Thread Markus Jelsma (JIRA)

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

Markus Jelsma commented on SOLR-12112:
--

Hello [~sarkaramr...@gmail.com],

Unfortunately it is not fixed in 7.3

{code}
null:java.lang.NullPointerException
at 
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at 
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
{code}

> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2 
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>   
> 
>   explicit
>   10
> 
>   
>   
>   
> 
>   score desc,id asc
>   none
> 
>   
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12112) NPE in QueryComponent

2018-05-08 Thread Markus Jelsma (JIRA)

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

Markus Jelsma commented on SOLR-12112:
--

Hello [~sarkaramr...@gmail.com],

I finally had the opportunity to test, but unfortunately, it is not fixed in 
7.3. The stack trace is now slightly different:

{code}
2018-05-08 15:35:18.843 ERROR (qtp2137589296-17) [c:search s:shard2 
r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
null:java.lang.NullPointerException
at 
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at 
io.openindex.lunar.handler.component.DeduplicatingQueryComponent.mergeIds(DeduplicatingQueryComponent.java:302)
at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
{code}

> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2 
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>   
> 
>   explicit
>   10
> 
>   
>   
>   
> 
>   score desc,id asc
>   none
> 
>   
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Issue Comment Deleted] (SOLR-12112) NPE in QueryComponent

2018-05-08 Thread Markus Jelsma (JIRA)

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

Markus Jelsma updated SOLR-12112:
-
Comment: was deleted

(was: Hello [~sarkaramr...@gmail.com],

I finally had the opportunity to test, but unfortunately, it is not fixed in 
7.3. The stack trace is now slightly different:

{code}
2018-05-08 15:35:18.843 ERROR (qtp2137589296-17) [c:search s:shard2 
r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
null:java.lang.NullPointerException
at 
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at 
io.openindex.lunar.handler.component.DeduplicatingQueryComponent.mergeIds(DeduplicatingQueryComponent.java:302)
at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
{code})

> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2 
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>   
> 
>   explicit
>   10
> 
>   
>   
>   
> 
>   score desc,id asc
>   none
> 
>   
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12298:
-

[~moshebla] I think your suggestion of having a JSON child object represent a 
singular child document to the parent is fine but would be another issue.  
You'd need to propose what params would enable the JSON loader to know this.  
Perhaps it's simply the split?

> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (SOLR-12324) handling numeric fields in uniqueBlock(id) aggregation for JSON Facet

2018-05-08 Thread Andrey Kudryavtsev (JIRA)

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

Andrey Kudryavtsev updated SOLR-12324:
--
Attachment: SOLR-12324.patch

> handling numeric fields in uniqueBlock(id) aggregation for JSON Facet
> -
>
> Key: SOLR-12324
> URL: https://issues.apache.org/jira/browse/SOLR-12324
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.4
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-12324.patch
>
>
> Now it trows exception. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Comment Edited] (SOLR-12324) handling numeric fields in uniqueBlock(id) aggregation for JSON Facet

2018-05-08 Thread Andrey Kudryavtsev (JIRA)

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

Andrey Kudryavtsev edited comment on SOLR-12324 at 5/8/18 3:13 PM:
---

Have this lovely  [^SOLR-12324.patch]  for SOLR-12324 and SOLR-12325 with a 
simple idea - "ord" value for block in case of numeric id is a numeric value 
itself, for "parent filter" - global lucene id of parent. 

Honestly speaking not sure about distributed stuff even if 
{{BlockJoinFacetDistribTest}} seems to be fine. {{getValue()}} method for 
{{SlotAcc}} which is unaware about "shrads" - is it OK in general?  


was (Author: werder):
Have this lovely patch for SOLR-12324 and SOLR-12325 with a simple idea - "ord" 
value for block in case of numeric id is a numeric value itself, for "parent 
filter" - global lucene id of parent. 

Honestly speaking not sure about distributed stuff even if 
{{BlockJoinFacetDistribTest}} seems to be fine. {{getValue()}} method for 
{{SlotAcc}} which is unaware about "shrads" - is it OK in general?  

> handling numeric fields in uniqueBlock(id) aggregation for JSON Facet
> -
>
> Key: SOLR-12324
> URL: https://issues.apache.org/jira/browse/SOLR-12324
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.4
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-12324.patch
>
>
> Now it trows exception. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12324) handling numeric fields in uniqueBlock(id) aggregation for JSON Facet

2018-05-08 Thread Andrey Kudryavtsev (JIRA)

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

Andrey Kudryavtsev commented on SOLR-12324:
---

Have this lovely patch for SOLR-12324 and SOLR-12325 with a simple idea - "ord" 
value for block in case of numeric id is a numeric value itself, for "parent 
filter" - global lucene id of parent. 

Honestly speaking not sure about distributed stuff even if 
{{BlockJoinFacetDistribTest}} seems to be fine. {{getValue()}} method for 
{{SlotAcc}} which is unaware about "shrads" - is it OK in general?  

> handling numeric fields in uniqueBlock(id) aggregation for JSON Facet
> -
>
> Key: SOLR-12324
> URL: https://issues.apache.org/jira/browse/SOLR-12324
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.4
>Reporter: Mikhail Khludnev
>Priority: Minor
>
> Now it trows exception. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12096) Inconsistent response format in subquery transform

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12096:
-

I was looking at the response writing while looking at another issue.  It seems 
to me that the condition to check for a List yet not a SolrDocumentList is 
completely unnecessary; it can be simplified.  See the patch  
[^remove_needless_JSON_response_writing_special_case_for_List.patch] which 
passes.  This condition is pretty old Solr code; perhaps it was once necessary. 
 writeVal will detect SolrDocumentList before List.  WDYT?

> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch, 
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch, 
> remove_needless_JSON_response_writing_special_case_for_List.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared 
> to single-shard
> h1. Single Shard collection
> Request 
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> 

[jira] [Updated] (SOLR-12096) Inconsistent response format in subquery transform

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley updated SOLR-12096:

Attachment: 
remove_needless_JSON_response_writing_special_case_for_List.patch

> Inconsistent response format in subquery transform
> --
>
> Key: SOLR-12096
> URL: https://issues.apache.org/jira/browse/SOLR-12096
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.patch, 
> SOLR-12096.patch, SOLR-12096.patch, SOLR-12096.testsubquery.patch, 
> remove_needless_JSON_response_writing_special_case_for_List.patch
>
>
> Solr version - 6.6.2
> The response of subquery transform is inconsistent with multi-shard compared 
> to single-shard
> h1. Single Shard collection
> Request 
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response for above request
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 0,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 1,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10001677",
> "score": 0.5,
> "_children_": {
> "numFound": 9,
> "start": 0,
> "docs": [
> {
> "uniqueId": "100016771",
> "score": 0.5
> },
> {
> "uniqueId": "100016772",
> "score": 0.5
> },
> {
> "uniqueId": "100016773",
> "score": 0.5
> }
> ]
> }
> }
> ]
> }
> }
> {code}
> Here, *_children_* suquery response is as expected (Based on documentation)
> h1. Multi Shard collection(2)
> Request
> {code:java}
> localhost:8983/solr/k_test_2/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> Response
> {code:json}
> {
> "responseHeader": {
> "zkConnected": true,
> "status": 0,
> "QTime": 11,
> "params": {
> "fl": [
> "uniqueId",
> "score",
> "_children_:[subquery]",
> "uniqueId"
> ],
> "origQuery": "false",
> "q.op": "AND",
> "_children_.rows": "3",
> "sort": "score desc,uniqueId desc",
> "rows": "1",
> "q": "{!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})",
> "qf": "parent_field",
> "spellcheck": "false",
> "_children_.q": "{!edismax qf=parentId v=$row.uniqueId}",
> "_children_.fl": [
> "uniqueId",
> "score"
> ],
> "wt": "json",
> "facet": "false"
> }
> },
> "response": {
> "numFound": 5,
> "start": 0,
> "maxScore": 0.5,
> "docs": [
> {
> "uniqueId": "10006197",
> "_children_": [
> {

[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)

2018-05-08 Thread David Smiley (JIRA)

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

David Smiley commented on SOLR-12298:
-

I think I'm liking more and more getting rid of SolrInputDocument's 
\_childDocuments list.  I think it would simplify some special-casing logic in 
some places, and it would add more semantic information on the relationships.  
There aren't _that_ many non-test accessors of getChildDocuments() + 
addChildDocument() + addChildDocuments().  Some of those locations would melt 
away if hypothetically anonymous children were added under the field key 
{{\_childDocuments\_}}.  [~mkhludnev] you work with block joins a lot; what do 
you think of this refactoring proposal?  I'm proposing removing explicit 
SolrInputField._childDocuments in favor of having fields contains child 
document values.

If this all sounds good, lets create a sub-task about this refactoring.

Just an idea: imagine a new dummy FieldType called "ChildDocument".  In this 
way the schema could explicitly capture the information that child docs exist 
at what name, and wether it's single or multiValued.  This needn't come to pass 
until it's of use.  AddSchemaFieldsUpdateProcessorFactory and 
AddUpdateCommand.flatten/recUnwrap need to navigate the child documents without 
knowing at what names they will exist.  Perhaps it's reasonably efficient to 
just iterate all fields in the document to look, but if the schema declared 
which fields have child relationships, then it'd be faster.


> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing 
> the original document hierarchy.
>  Currently the client has to index the child document's full path and level 
> to manually reconstruct the original document structure, since the children 
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the 
> required fields while providing a document transformer to rebuild the 
> original document's hierarchy.
>  
> This issue is an umbrella issue for the particular tasks that will make it 
> all happen – either subtasks or issue linking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12055) Enable asynch logging by default

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-12055:
---

[~markrmil...@gmail.com] I'm changing my tune a bit on this, I'm less inclined 
to make it the default. On the issue of auditing, would that also apply to 
logging summary stats rather than individual messages in some cases?

In particular, depending on the resolution to SOLR-11934 and the like, we might 
dramatically reduce the number of log messages. 

So here's what I'm thinking makes the most sense here:

1> as part of the process we'll take a bunch of customer log files and figure 
out where the most frequent messages come from. The log file I looked at wasn't 
particularly representative so we need a better sample.

2> where it makes sense, publish summary stats at INFO (?) level or change the 
level

3> provide examples of how to turn on async logging (probably just 
commented-out sections of the log4j2.xml files) for those who want it. They can 
turn on async logging if they want, we should just make it easy rather than the 
default.

WDYT?

> Enable asynch logging by default
> 
>
> Key: SOLR-12055
> URL: https://issues.apache.org/jira/browse/SOLR-12055
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> When SOLR-7887 is done, switching to asynch logging will be a simple change 
> to the config files for log4j2. This will reduce contention and increase 
> throughput generally and logging in particular.
> There's a discussion of the pros/cons here: 
> https://logging.apache.org/log4j/2.0/manual/async.html
> An alternative is to put a note in the Ref Guide about how to enable async 
> logging.
> I guess even if we enable async by default the ref guide still needs a note 
> about how to _disable_ it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-08 Thread JIRA

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

Jan Høydahl commented on SOLR-7767:
---

Interesting find about datalog and data, this is an ensemble based on the 
default ZK docker image, so it's probably a bug there :)

I think perhaps two lines are swapped in 
[https://github.com/apache/zookeeper/blob/722ba9409a44a35d287aac803813f508cff2420a/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L212]
 

I'll come up with a suggestion for short list...

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-error.png, zk-status-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-11934) Visit Solr logging, it's too noisy.

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-11934:
---

[~markrmil...@gmail.com] Your comment on SOLR-12055 got me to wondering. Do we 
have to accommodate audit logging in this too? If so, I think it'd be a 
documentation issue, as you say in 12055 announce LOUDLY.

Plus, that informs the question about what level we log individual messages 
at...

> Visit Solr logging, it's too noisy.
> ---
>
> Key: SOLR-11934
> URL: https://issues.apache.org/jira/browse/SOLR-11934
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I think we have way too much INFO level logging. Or, perhaps more correctly, 
> Solr logging needs to be examined and messages logged at an appropriate level.
> We log every update at an INFO level for instance. But I think we log LIR at 
> INFO as well. As a sysadmin I don't care to have my logs polluted with a 
> message for every update, but if I'm trying to keep my system healthy I want 
> to see LIR messages and try to understand why.
> Plus, in large installations logging at INFO level is creating a _LOT_ of 
> files.
> What I want to discuss on this JIRA is
> 1> What kinds of messages do we want log at WARN, INFO, DEBUG, and TRACE 
> levels?
> 2> Who's the audience at each level? For a running system that's functioning, 
> sysops folks would really like WARN messages that mean something need 
> attention for instance. If I'm troubleshooting should I turn on INFO? DEBUG? 
> TRACE?
> So let's say we get some kind of agreement as to the above. Then I propose 
> three things
> 1> Someone (and probably me but all help gratefully accepted) needs to go 
> through our logging and assign appropriate levels. This will take quite a 
> while, I intend to work on it in small chunks.
> 2> Actually answer whether unnecessary objects are created when something 
> like log.info("whatever {}", someObjectOrMethodCall); is invoked. Is this 
> independent on the logging implementation used? The SLF4J and log4j seem a 
> bit contradictory.
> 3> Maybe regularize log, logger, LOG as variable names, but that's a nit.
> As a tactical approach, I suggest we tag each LoggerFactory.getLogger in 
> files we work on with //SOLR-(whatever number is assigned when I create 
> this). We can remove them all later, but since I expect to approach this 
> piecemeal it'd be nice to keep track of which files have been done already.
> Finally, I really really really don't want to do this all at once. There are 
> 5-6 thousand log messages. Even at 1,000 a week that's 6 weeks, even starting 
> now it would probably span the 7.3 release.
> This will probably be an umbrella issue so we can keep all the commits 
> straight and people can volunteer to "fix the files in core" as a separate 
> piece of work (hint).
> There are several existing JIRAs about logging in general, let's link them in 
> here as well.
> Let the discussion begin!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Resolved] (SOLR-12329) Default Analyzer for known and unknown fields

2018-05-08 Thread Erick Erickson (JIRA)

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

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

This issue tracker is not a support portal. Please raise this question on the 
user's list at solr-u...@lucene.apache.org, see: 
(http://lucene.apache.org/solr/community.html#mailing-lists-irc) there are a 
_lot_ more people watching that list who may be able to help and you'll 
probably get responses much more quickly.

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

> Default Analyzer for known and unknown fields
> -
>
> Key: SOLR-12329
> URL: https://issues.apache.org/jira/browse/SOLR-12329
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Reporter: Zyan
>Priority: Major
>
> Hi
> Is there any way I can set the Tokenizer to Keyword Tokenizer instead of 
> StandardTokenizer by default for all known fields as well as unknown fileds ( 
> In schema less mode ).  Basically I don't want Solr to break the terms I 
> index into multiple terms. It also affects faceting. when I try to facet on a 
> term CPU in an example Data Set ( CPU="Quad 2 Core" , CPU=Intel I3 ) , i get 
> 5 facets ( Quad , 2, Core , Intel and I3 ) which is not the behavior I'm 
> expecting. I'm expecting only 2 facets.
> Can it be made configurable too. For example can a user define the Analyzers 
> for all the unknown fields through a wildcard syntax or something
>  
> Thanks
> Zyan



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

2018-05-08 Thread Erick Erickson (JIRA)

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

Erick Erickson commented on SOLR-7767:
--

BTW, I haven't chimed in about all this but +1,000 for doing the work!

I'd vote to add "zk_version", "clientPort", "serverId"  as things we
need to leave in if you decide trim the list down, as those are things
people often get wrong and it'd be nice to have those up-front.

WDYT about the data dirs? I do note that your dataDir points to
/dataLog and dataLogDir points to /data ;)

Or maybe just list the most important ones first?

Totally up to you of course.

Erick



> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-error.png, zk-status-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (SOLR-12329) Default Analyzer for known and unknown fields

2018-05-08 Thread Zyan (JIRA)
Zyan created SOLR-12329:
---

 Summary: Default Analyzer for known and unknown fields
 Key: SOLR-12329
 URL: https://issues.apache.org/jira/browse/SOLR-12329
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Reporter: Zyan


Hi

Is there any way I can set the Tokenizer to Keyword Tokenizer instead of 
StandardTokenizer by default for all known fields as well as unknown fileds ( 
In schema less mode ).  Basically I don't want Solr to break the terms I index 
into multiple terms. It also affects faceting. when I try to facet on a term 
CPU in an example Data Set ( CPU="Quad 2 Core" , CPU=Intel I3 ) , i get 5 
facets ( Quad , 2, Core , Intel and I3 ) which is not the behavior I'm 
expecting. I'm expecting only 2 facets.

Can it be made configurable too. For example can a user define the Analyzers 
for all the unknown fields through a wildcard syntax or something

 

Thanks

Zyan



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1020 - Still Failing

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1020/

No tests ran.

Build Log:
[...truncated 24176 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2206 links (1762 relative) to 3066 anchors in 244 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

[jira] [Updated] (LUCENE-8299) Geo3D: Change factory method for polygons

2018-05-08 Thread Ignacio Vera (JIRA)

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

Ignacio Vera updated LUCENE-8299:
-
Attachment: LUCENE-8299.patch

> Geo3D: Change factory method for polygons
> -
>
> Key: LUCENE-8299
> URL: https://issues.apache.org/jira/browse/LUCENE-8299
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-8299.patch
>
>
> In LUCENE-8220 it was introduced a new factory method that chooses the best 
> technology for the provided polygon. In particular, this factory provides a 
> better support when creating a polygon with a list of points > 100 and in 
> some situations when tiling of the polygon is not possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Created] (LUCENE-8299) Geo3D: Change factory method for polygons

2018-05-08 Thread Ignacio Vera (JIRA)
Ignacio Vera created LUCENE-8299:


 Summary: Geo3D: Change factory method for polygons
 Key: LUCENE-8299
 URL: https://issues.apache.org/jira/browse/LUCENE-8299
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ignacio Vera


In LUCENE-8220 it was introduced a new factory method that chooses the best 
technology for the provided polygon. In particular, this factory provides a 
better support when creating a polygon with a list of points > 100 and in some 
situations when tiling of the polygon is not possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 624 - Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/624/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseG1GC

8 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([8366498D1F3F8EFF:D0DF0B3DFD2E1B05]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger

Error Message:
number of ops expected:<2> but was:<1>

Stack Trace:
java.lang.AssertionError: number of ops expected:<2> but was:<1>
at 

[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter

2018-05-08 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-8273:
-

For the new TermExclusionFilterFactory:

{code}
public static final String EXCLUDED_TOKENS = "excludeFile";
{code}

KeywordMarkerFilterFactory currently uses a different parameter name: 
"protected". So does WordDelimiterFilterFactory (which I think was the one that 
inspired this JIRA issue). Maybe we want it to be consistent, to support 
migrating away from that stuff?

> Add a ConditionalTokenFilter
> 
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, 
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265.  It would be useful to be able to wrap a TokenFilter 
> in such a way that it could optionally be bypassed based on the current state 
> of the TokenStream.  This could be used to, for example, only apply 
> WordDelimiterFilter to terms that contain hyphens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12321) Use of builtin java serialization for admin response breaks 7.3 compatibility

2018-05-08 Thread JIRA

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

Jan Høydahl commented on SOLR-12321:


Something to add to invalid API checks?

Hmm, this is what we have {{version}} request parameter for, isn't it?
{noformat}
(org.apache.solr.common.params.CommonParams)
/** version parameter to check request-response compatibility */
String VERSION ="version";{noformat}
What if we bump request version from 2.2 to 2.3 in a bugfix 7.3.2 release which 
also switches to JavaBin serialization. Then we have a mechanism for server to 
serve different response to a 2.3 client than a 2.2 client.

After that we could release a 7.2.2 release with ability to serve either Java 
or Javabin serialised SolrResponse depending on version param. In case of 
serialised object stored in Blob/ZK, the version may be lost so a fallback 
parsing may be necessary?

> Use of builtin java serialization for admin response breaks 7.3 compatibility
> -
>
> Key: SOLR-12321
> URL: https://issues.apache.org/jira/browse/SOLR-12321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3, 7.3.1
>Reporter: Will Currie
>Priority: Minor
>
> Premise: During an upgrade I should be able to run a 7.3 pull replica against 
> a 7.2 tlog leader. Or vice versa.
>  
> Adding a new method[1] to SolrResponse has broken binary compatibility. When 
> I try to register a new pull replica using the admin api[2] I get an HTTP 500 
> responseI see this error logged: java.io.InvalidClassException: 
> org.apache.solr.client.solrj.SolrResponse; local class incompatible: stream 
> classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -793110010336024264
>  
> The replica actually seems to register ok it just can't read the response 
> because the bytes from the 7.2 leader include a different serialVersionUID. 
>  
> Should SolrResponse include a serialVersionIUID? All subclasses too.
> [~markrmil...@gmail.com]'s advice is that the project should never use 
> builtin java serialization.
>  
> It looks like stock java serialization is only used for these admin 
> responses. Query responses use JavaBinCodec instead..
>  
> Full(ish) stack trace:
> {noformat}
> ERROR HttpSolrCall null:org.apache.solr.common.SolrException: 
> java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse; 
> local class incompatible: st
> ream classdesc serialVersionUID = 3945300637328478755, local class 
> serialVersionUID = -7931100103360242645
>     at 
> org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:73)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.sendToOCPQueue(CollectionsHandler.java:348)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:256)
>     at 
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)
>     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>     at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
>     at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
>     at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>     at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>  {noformat}
>  
> [1] 
> [https://github.com/apache/lucene-solr/commit/5ce83237e804ac1130eaf5cf793955667793fee0#diff-b809fa594f93aa6805381029a188e4e2R46]
> [2] 
> [http://localhost:8983/solr/admin/collections?action=ADDREPLICA=blah=shard1=blah=pull]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter

2018-05-08 Thread Alan Woodward (JIRA)

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

Alan Woodward commented on LUCENE-8273:
---

Thanks David, I'll do that.  Will commit later on if nobody else has any 
comments.

> Add a ConditionalTokenFilter
> 
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, 
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265.  It would be useful to be able to wrap a TokenFilter 
> in such a way that it could optionally be bypassed based on the current state 
> of the TokenStream.  This could be used to, for example, only apply 
> WordDelimiterFilter to terms that contain hyphens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request

2018-05-08 Thread Munendra S N (JIRA)

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

Munendra S N commented on SOLR-12303:
-

[~mkhludnev]
I concur with you, it is not a good idea to introduce change without 
completeness.
As you suggested, documentation should be changed to mention, 
{noformat}
subquery would use /select by default and search handler can be changed for 
subquery using subquery's qt parameter
{noformat}


> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request 
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should 
> be an option to override this behavior. (option to override is already 
> available by specifying *qt*)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4614 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4614/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([AC5AFF4A67DBE383:FFE3BDFA85CA7679]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 

[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request

2018-05-08 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev commented on SOLR-12303:
-

he-he. */get* is an example of search handler which has no sense for inheriting 
in \[subquery]. It makes me thick that it's better to keep existing code as-is 
and just mention this trap and workaround it the refguide. 

> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, 
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId 
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax 
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
>  qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request 
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should 
> be an option to override this behavior. (option to override is already 
> available by specifying *qt*)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-repro - Build # 592 - Still unstable

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-repro/592/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/215/consoleText

[repro] Revision: b72af046c5bd04eec4e84700a2ee20ab5a833e39

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=SearchRateTriggerTest 
-Dtests.method=testTrigger -Dtests.seed=2BF31B11BE1CE9D -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH -Dtests.timezone=Australia/Hobart -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
85c00e77efdf53f30da6eaffd38c2b016a7805bc
[repro] git fetch
[repro] git checkout b72af046c5bd04eec4e84700a2ee20ab5a833e39

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   SearchRateTriggerTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.SearchRateTriggerTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=2BF31B11BE1CE9D -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH -Dtests.timezone=Australia/Hobart -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 7247 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest

[repro] Re-testing 100% failures at the tip of branch_7x
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   SearchRateTriggerTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.SearchRateTriggerTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=2BF31B11BE1CE9D -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH -Dtests.timezone=Australia/Hobart -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 7215 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of branch_7x:
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest

[repro] Re-testing 100% failures at the tip of branch_7x without a seed
[repro] ant clean

[...truncated 8 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   SearchRateTriggerTest
[repro] ant compile-test

[...truncated 3316 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.SearchRateTriggerTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH -Dtests.timezone=Australia/Hobart -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 7135 lines...]
[repro] Setting last failure code to 256

[repro] Failures at the tip of branch_7x without a seed:
[repro]   5/5 failed: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest
[repro] git checkout 85c00e77efdf53f30da6eaffd38c2b016a7805bc

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Comment Edited] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface

2018-05-08 Thread JIRA

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

Jan Høydahl edited comment on SOLR-4052 at 5/8/18 10:30 AM:


We already have APIs for most things you need to do in ZK on a daily basis:
 * Upload config sets
 * Modify schema and config
 * Modify security settings (perhaps except the initial upload of security.json)

I think it is acceptable that typical install actions such as changing 
urlScheme or bootstrapping {{security.json}} must happen directly to ZK.

Question is whether we want Admin UI support for uploading config sets?

I'd rather see improved support for managed components so you never need to 
upload {{elevate.xml}}, {{currencies.xml}} etc and thus can create a collection 
with a default config set and start configuring through APIs. What if we 
compile list of components that today require some text file in config-set, and 
then create JIRAs for each of them to make a Managed counterpart, and finally 
deprecate the non managed ones?

Or is the Config API / Schema API (which are newer than the Managed REST APIs) 
a better way of configuring these components? What if an Authentication Plugin 
requires a huge config file, should it just be embedded in security.json?


was (Author: janhoy):
I think I'll close this JIRA, as we already have APIs for most things you need 
to do in ZK on a daily basis:
 * Upload config sets
 * Modify schema and config
 * Modify security settings (perhaps except the initial upload of security.json)

I think it is acceptable that typical install actions such as changing 
urlScheme or bootstrapping security.json must happen directly to ZK.

> Upload files to ZooKeeper from Solr Admin interface
> ---
>
> Key: SOLR-4052
> URL: https://issues.apache.org/jira/browse/SOLR-4052
> Project: Solr
>  Issue Type: Improvement
>Reporter: Eric Pugh
>Priority: Major
> Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch
>
>
> It would be nice if you could add files to ZooKeeper through the solr admin 
> tool instead of having to use the zkCli.  Steffan and I talked about this at 
> ApacheCon Euro, and he suggested that if I put the java code in place, he'll 
> put in the pretty GUI aspects!  This patch is based around using a tool like 
> http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet.  I 
> hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't 
> have a better sense of where it should go.   A *very* annoying thing is that 
> it seems like from the browser side you can't select a directory of files and 
> upload it, which would make loading a new solr core configuration split 
> across many directory VERY annoying.   Also, this doesn't really feel like a 
> solid solution to just pulling up a file in the ZK tree browser webpage, 
> editing it (maybe via a big text box) and then posting the contents back.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface

2018-05-08 Thread JIRA

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

Jan Høydahl commented on SOLR-4052:
---

I think I'll close this JIRA, as we already have APIs for most things you need 
to do in ZK on a daily basis:
 * Upload config sets
 * Modify schema and config
 * Modify security settings (perhaps except the initial upload of security.json)

I think it is acceptable that typical install actions such as changing 
urlScheme or bootstrapping security.json must happen directly to ZK.

> Upload files to ZooKeeper from Solr Admin interface
> ---
>
> Key: SOLR-4052
> URL: https://issues.apache.org/jira/browse/SOLR-4052
> Project: Solr
>  Issue Type: Improvement
>Reporter: Eric Pugh
>Priority: Major
> Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch
>
>
> It would be nice if you could add files to ZooKeeper through the solr admin 
> tool instead of having to use the zkCli.  Steffan and I talked about this at 
> ApacheCon Euro, and he suggested that if I put the java code in place, he'll 
> put in the pretty GUI aspects!  This patch is based around using a tool like 
> http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet.  I 
> hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't 
> have a better sense of where it should go.   A *very* annoying thing is that 
> it seems like from the browser side you can't select a directory of files and 
> upload it, which would make loading a new solr core configuration split 
> across many directory VERY annoying.   Also, this doesn't really feel like a 
> solid solution to just pulling up a file in the ZK tree browser webpage, 
> editing it (maybe via a big text box) and then posting the contents back.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[JENKINS] Lucene-Solr-Tests-7.3 - Build # 65 - Still Unstable

2018-05-08 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.3/65/

5 tests failed.
FAILED:  org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:43732/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:41589/solr/MoveReplicaHDFSTest_failed_coll_true]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:43732/solr/MoveReplicaHDFSTest_failed_coll_true, 
http://127.0.0.1:41589/solr/MoveReplicaHDFSTest_failed_coll_true]
at 
__randomizedtesting.SeedInfo.seed([AABFB03BF3F1394C:7263C94422EC9C]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1105)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:885)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:992)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:818)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:307)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 581 - Still Unstable!

2018-05-08 Thread Policeman Jenkins Server
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/581/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

23 tests failed.
FAILED:  
org.apache.solr.handler.component.SpellCheckComponentTest.testMaximumResultsForSuggest

Error Message:
Directory 
(SimpleFSDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.SpellCheckComponentTest_3FA68BEE23DFADDF-002\init-core-data-001\spellchecker1
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@2796f8) still has 
pending deleted files; cannot initialize IndexWriter

Stack Trace:
java.lang.IllegalArgumentException: Directory 
(SimpleFSDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.SpellCheckComponentTest_3FA68BEE23DFADDF-002\init-core-data-001\spellchecker1
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@2796f8) still has 
pending deleted files; cannot initialize IndexWriter
at 
__randomizedtesting.SeedInfo.seed([3FA68BEE23DFADDF:B3AB0B2DEDF3F292]:0)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:699)
at 
org.apache.lucene.search.spell.SpellChecker.clearIndex(SpellChecker.java:455)
at 
org.apache.solr.spelling.IndexBasedSpellChecker.build(IndexBasedSpellChecker.java:87)
at 
org.apache.solr.handler.component.SpellCheckComponent.prepare(SpellCheckComponent.java:128)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:269)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2510)
at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:982)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:951)
at 
org.apache.solr.handler.component.SpellCheckComponentTest.testMaximumResultsForSuggest(SpellCheckComponentTest.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-08 Thread Simon Willnauer (JIRA)

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

Simon Willnauer commented on LUCENE-8298:
-

new patch with added javadocs, API cleanups and more tests

> Allow DocValues updates to reset a value
> 
>
> Key: LUCENE-8298
> URL: https://issues.apache.org/jira/browse/LUCENE-8298
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8298.patch, LUCENE-8298.patch
>
>
>  Today once a document has a value in a certain DV field this values
> can only be changed but not removed. While resetting / removing a value
> from a field is certainly a corner case it can be used to undelete a
> soft-deleted document unless it's merged away.
> This allows to rollback changes without rolling back to another 
> commitpoint
> or trashing all uncommitted changes. In certain cenarios it can be used to
> "repair" history of documents in distributed systems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



[jira] [Updated] (LUCENE-8298) Allow DocValues updates to reset a value

2018-05-08 Thread Simon Willnauer (JIRA)

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

Simon Willnauer updated LUCENE-8298:

Attachment: LUCENE-8298.patch

> Allow DocValues updates to reset a value
> 
>
> Key: LUCENE-8298
> URL: https://issues.apache.org/jira/browse/LUCENE-8298
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8298.patch, LUCENE-8298.patch
>
>
>  Today once a document has a value in a certain DV field this values
> can only be changed but not removed. While resetting / removing a value
> from a field is certainly a corner case it can be used to undelete a
> soft-deleted document unless it's merged away.
> This allows to rollback changes without rolling back to another 
> commitpoint
> or trashing all uncommitted changes. In certain cenarios it can be used to
> "repair" history of documents in distributed systems.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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



  1   2   >