Re: A 5.4 release?

[Shalin Shekhar Mangar]

I closed LUCENE-6722 as a 'won't fix'

On Wed, Nov 25, 2015 at 7:35 PM, Upayavira  wrote:
> I shall shortly create the 5.4 release branch. From this moment, the feature
> freeze starts.
>
> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> suspect we won't be able to fix all 71 in one week, so I expect that the
> majority will be pushed, after this release, to 5.5.
>
> Looking for blockers or critical tickets, I see five tickets:
>
> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>   "Adding read restriction to BasicAuth + RuleBased authorization causes
> issue with replication"
>
>   Anusham/Noble - any thoughts on how to resolve this before the release?
>
> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>   "Move solr/webapp to solr/server/solr-webapp"
>
>   This one I know isn't a blocker in any sense.
>
> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>   "Add tests for bin/post"
>
>   Again, this one does not seem to be something worthy of holding back a
> release
>
> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>
>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>
> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
>   "Java 8 as the minimum supported JVM version for branch_5x"
>
>   Looking at the discussion, there was no consensus here, so I will not
> consider this a blocker either.
>
>   - o -
>
> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. Anyone
> have comments/observations here?
>
> I will create the branch shortly.
>
> Upayavira



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (SOLR-8330) Remove unintentionally shared loggers.

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8330:


I think it definitely is worthy of mention in CHANGES.txt, if only for the 
sheer size of the patch.  It's probably worth mentioning in the "upgrading 
from" section as well as the issue list, with a paragraph similar to this:

{code}
* Logger declarations in most source files have changed to code that
  no longer needs to explicitly state the class name.  This fixes situations
  where a logger for a different class was incorrectly used. See SOLR-8324
  and its sub-issues for details.
{code}

On SOLR-8324, Uwe mentioned a way of doing the declaration without imports -- 
fully qualified class names in the code.  I wonder if that's the way we should 
do this.  I have no strong opinion on the matter.


> Remove unintentionally shared loggers.
> --
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Issue Type: Bug  (was: Improvement)

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6722) Java 8 as the minimum supported JVM version for branch_5x

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved LUCENE-6722.
---
   Resolution: Won't Fix
Fix Version/s: (was: 5.4)

The consensus is that Java 8 will be the minimum requirement for 6.0 and not 
5.x so I am closing this issue as a 'won't fix'.

> Java 8 as the minimum supported JVM version for branch_5x
> -
>
> Key: LUCENE-6722
> URL: https://issues.apache.org/jira/browse/LUCENE-6722
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Shalin Shekhar Mangar
>Priority: Blocker
>
> Require Java 8 as the minimum supported JVM version for branch_5x.
> # Java 7 is already EOL'ed
> # Trunk is already at Java8
> # Important Solr components such as Jetty 9.3.x already require Java 8
> # Nashorn Javascript engine available in Java 8 is just so much faster and we 
> may see more usage of JS inside Solr (SOLR-7576 etc.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-6905:


thanks [~mikemccand]. I went ahead and added the jenkins failure as an explicit 
test. I'll commit shortly. 

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8035) Move solr/webapp to solr/server/solr-webapp

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-8035:
---
Priority: Minor  (was: Critical)

> Move solr/webapp to solr/server/solr-webapp
> ---
>
> Key: SOLR-8035
> URL: https://issues.apache.org/jira/browse/SOLR-8035
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: Trunk, 5.5, 6.0
>
> Attachments: SOLR-8035.patch
>
>
> Let's move solr/webapp *source* files to their final actual distro 
> destination.  This facilitates folks editing the UI in real-time (save 
> change, refresh in browser) rather than having to "stop, ant server, restart" 
> to see a change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8035) Move solr/webapp to solr/server/solr-webapp

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-8035:
---
Fix Version/s: (was: 5.4)
   6.0
   5.5

> Move solr/webapp to solr/server/solr-webapp
> ---
>
> Key: SOLR-8035
> URL: https://issues.apache.org/jira/browse/SOLR-8035
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: Trunk, 5.5, 6.0
>
> Attachments: SOLR-8035.patch
>
>
> Let's move solr/webapp *source* files to their final actual distro 
> destination.  This facilitates folks editing the UI in real-time (save 
> change, refresh in browser) rather than having to "stop, ant server, restart" 
> to see a change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6994) Implement Windows version of bin/post

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-6994:
---
Fix Version/s: (was: 5.4)

> Implement Windows version of bin/post
> -
>
> Key: SOLR-6994
> URL: https://issues.apache.org/jira/browse/SOLR-6994
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: Trunk
>
>
> SOLR-6900 added a Unix bin/post tool.  A Windows equivalent would be nice to 
> have as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716465 from [~nknize] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716465 ]

LUCENE-6905: Unwrap center longitude for dateline crossing 
GeoPointDistanceQuery.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8073) Solr fails to start on Windows with obscure errors when using relative path

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-8073.
-
   Resolution: Fixed
Fix Version/s: Trunk
   5.4

Thanks Alexandre and Ishan!

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8073.patch
>
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {quote}
> Possibly related to SOLR-8068? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6909) Improve concurrency for FacetsConfig

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6909.

   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> Improve concurrency for FacetsConfig
> 
>
> Key: LUCENE-6909
> URL: https://issues.apache.org/jira/browse/LUCENE-6909
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.3
>Reporter: Sanne Grinovero
>Priority: Trivial
> Fix For: Trunk, 5.5
>
> Attachments: 
> 0001-LUCENE-6909-Allow-efficient-concurrent-usage-of-a-Fa.patch
>
>
> The design of {{org.apache.lucene.facet.FacetsConfig}} encourages reuse of a 
> single instance across multiple threads, yet the current synchronization 
> model is too strict as it doesn't allow for concurrent read operations.
> I'll attach a trivial patch which removes the contention point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8335:
-

SOLR-6737 is already solved since 5.3.

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> ... 7 more
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer 

[jira] [Updated] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-5868:
-
Fix Version/s: 5.5

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-6905.

Resolution: Fixed

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716486 from [~nknize] in branch 'dev/trunk'
[ https://svn.apache.org/r1716486 ]

LUCENE-6905: updating change log.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Should schema API allow deleting uniqueKey?

[Upayavira]

On Wed, Nov 25, 2015, at 05:09 PM, Alexandre Rafalovitch wrote:
> I am testing 5.4 branch and was enjoying new UI for adding/removing
> fields in the schema.
> 
> So, for a test of an error message, I decided to delete the ID field.
> And it let me. And then I indexed some files and the ID got recreated
> as a generic field.
> 
> Should this be allowed or should delete field API check that we are
> not deleting the uniqueKey? I can kind of see it both ways.

There's much damage can be done with the "delete field" button :-)

I think it makes sense to add a "are you sure you want to delete your
unique key?" warning to the UI, in 5.5.

We could actually add a check to see if the field has content, and warn
them before deleting a field with content. Those would both make lots of
sense.

Upayavira

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

Fixing differences in solr/CHANGES.txt between 5x and trunk

[Shawn Heisey]

I ran into some large differences in solr/CHANGES.txt between 5x and
trunk that made it difficult to patch 5x with a diff from trunk.  I
compared them several days ago, and found a rather large number of
differences, particularly in the 5.4.0 section, but there were other
differences in sections further down.

The differences that I found previously in the 5.4.0 section are no
longer present.  Thank you to whoever cleaned those up, because it
eliminates most of the potential impact to ongoing work from what I'm
proposing:

I'd like to review the differences I found, make sure that 5x file is
correct, then completely replace everything after the 6.0 section in the
trunk file with the 5x file.

I'm thinking this change doesn't need an issue, but I'd like some guidance.

Here's a patch file showing what differences (other than the 6.0
section) currently exist:

https://www.dropbox.com/s/458k4xzkkli4rhj/solr-changes.patch?dl=0

Thanks,
Shawn


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

Re: Fixing differences in solr/CHANGES.txt between 5x and trunk

[Upayavira]

This will undoubtedly help with making release notes, but please do
track it in a ticket.

Thanks!

On Wed, Nov 25, 2015, at 03:25 PM, Shawn Heisey wrote:
> I ran into some large differences in solr/CHANGES.txt between 5x and
> trunk that made it difficult to patch 5x with a diff from trunk.  I
> compared them several days ago, and found a rather large number of
> differences, particularly in the 5.4.0 section, but there were other
> differences in sections further down.
> 
> The differences that I found previously in the 5.4.0 section are no
> longer present.  Thank you to whoever cleaned those up, because it
> eliminates most of the potential impact to ongoing work from what I'm
> proposing:
> 
> I'd like to review the differences I found, make sure that 5x file is
> correct, then completely replace everything after the 6.0 section in the
> trunk file with the 5x file.
> 
> I'm thinking this change doesn't need an issue, but I'd like some
> guidance.
> 
> Here's a patch file showing what differences (other than the 6.0
> section) currently exist:
> 
> https://www.dropbox.com/s/458k4xzkkli4rhj/solr-changes.patch?dl=0
> 
> Thanks,
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8335:
---

Ah, ok.  I'd have to look closer. 

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> ... 7 more
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports 

[jira] [Updated] (SOLR-8326) Adding read restriction to BasicAuth + RuleBased authorization causes issue with replication

[Noble Paul (JIRA)]

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

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

> Adding read restriction to BasicAuth + RuleBased authorization causes issue 
> with replication
> 
>
> Key: SOLR-8326
> URL: https://issues.apache.org/jira/browse/SOLR-8326
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 5.4
>
> Attachments: SOLR-8326.patch, SOLR-8326.patch
>
>
> This was reported on the mailing list:
> https://www.mail-archive.com/solr-user@lucene.apache.org/msg115921.html
> I tested it out as follows to confirm that adding a 'read' rule causes 
> replication to break. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8073) Solr fails to start on Windows with obscure errors when using relative path

[ASF subversion and git services (JIRA)]

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

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

Commit 1716448 from sha...@apache.org in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716448 ]

SOLR-8073: Solr fails to start on Windows with obscure errors when using 
relative path

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Attachments: SOLR-8073.patch
>
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {quote}
> Possibly related to SOLR-8068? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716462 from [~nknize] in branch 'dev/trunk'
[ https://svn.apache.org/r1716462 ]

LUCENE-6905: Unwrap center longitude for dateline crossing 
GeoPointDistanceQuery.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6909) Improve concurrency for FacetsConfig

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6909:


Thanks [~sanne], I'll put the first part back and commit the 2nd part!

> Improve concurrency for FacetsConfig
> 
>
> Key: LUCENE-6909
> URL: https://issues.apache.org/jira/browse/LUCENE-6909
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.3
>Reporter: Sanne Grinovero
>Priority: Trivial
> Attachments: 
> 0001-LUCENE-6909-Allow-efficient-concurrent-usage-of-a-Fa.patch
>
>
> The design of {{org.apache.lucene.facet.FacetsConfig}} encourages reuse of a 
> single instance across multiple threads, yet the current synchronization 
> model is too strict as it doesn't allow for concurrent read operations.
> I'll attach a trivial patch which removes the contention point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6909) Improve concurrency for FacetsConfig

[ASF subversion and git services (JIRA)]

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

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

Commit 1716477 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716477 ]

LUCENE-6909: remove unnecessary synchronized keyword

> Improve concurrency for FacetsConfig
> 
>
> Key: LUCENE-6909
> URL: https://issues.apache.org/jira/browse/LUCENE-6909
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.3
>Reporter: Sanne Grinovero
>Priority: Trivial
> Attachments: 
> 0001-LUCENE-6909-Allow-efficient-concurrent-usage-of-a-Fa.patch
>
>
> The design of {{org.apache.lucene.facet.FacetsConfig}} encourages reuse of a 
> single instance across multiple threads, yet the current synchronization 
> model is too strict as it doesn't allow for concurrent read operations.
> I'll attach a trivial patch which removes the contention point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716488 from [~nknize] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716488 ]

LUCENE-6905: updating change log.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[ANNOUNCE] CFP open for ApacheCon North America 2016

[Rich Bowen]

Community growth starts by talking with those interested in your
project. ApacheCon North America is coming, are you?

We are delighted to announce that the Call For Presentations (CFP) is
now open for ApacheCon North America. You can submit your proposed
sessions at
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
for big data talks and
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
for all other topics.

ApacheCon North America will be held in Vancouver, Canada, May 9-13th
2016. ApacheCon has been running every year since 2000, and is the place
to build your project communities.

While we will consider individual talks we prefer to see related
sessions that are likely to draw users and community members. When
submitting your talk work with your project community and with related
communities to come up with a full program that will walk attendees
through the basics and on into mastery of your project in example use
cases. Content that introduces what's new in your latest release is also
of particular interest, especially when it builds upon existing well
know application models. The goal should be to showcase your project in
ways that will attract participants and encourage engagement in your
community, Please remember to involve your whole project community (user
and dev lists) when building content. This is your chance to create a
project specific event within the broader ApacheCon conference.

Content at ApacheCon North America will be cross-promoted as
mini-conferences, such as ApacheCon Big Data, and ApacheCon Mobile, so
be sure to indicate which larger category your proposed sessions fit into.

Finally, please plan to attend ApacheCon, even if you're not proposing a
talk. The biggest value of the event is community building, and we count
on you to make it a place where your project community is likely to
congregate, not just for the technical content in sessions, but for
hackathons, project summits, and good old fashioned face-to-face networking.

-- 
rbo...@apache.org
http://apache.org/

[ANNOUNCE] CFP open for ApacheCon North America 2016

[Rich Bowen]

Community growth starts by talking with those interested in your
project. ApacheCon North America is coming, are you?

We are delighted to announce that the Call For Presentations (CFP) is
now open for ApacheCon North America. You can submit your proposed
sessions at
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
for big data talks and
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
for all other topics.

ApacheCon North America will be held in Vancouver, Canada, May 9-13th
2016. ApacheCon has been running every year since 2000, and is the place
to build your project communities.

While we will consider individual talks we prefer to see related
sessions that are likely to draw users and community members. When
submitting your talk work with your project community and with related
communities to come up with a full program that will walk attendees
through the basics and on into mastery of your project in example use
cases. Content that introduces what's new in your latest release is also
of particular interest, especially when it builds upon existing well
know application models. The goal should be to showcase your project in
ways that will attract participants and encourage engagement in your
community, Please remember to involve your whole project community (user
and dev lists) when building content. This is your chance to create a
project specific event within the broader ApacheCon conference.

Content at ApacheCon North America will be cross-promoted as
mini-conferences, such as ApacheCon Big Data, and ApacheCon Mobile, so
be sure to indicate which larger category your proposed sessions fit into.

Finally, please plan to attend ApacheCon, even if you're not proposing a
talk. The biggest value of the event is community building, and we count
on you to make it a place where your project community is likely to
congregate, not just for the technical content in sessions, but for
hackathons, project summits, and good old fashioned face-to-face networking.

-- 
rbo...@apache.org
http://apache.org/

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

[jira] [Commented] (LUCENE-6909) Improve concurrency for FacetsConfig

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on LUCENE-6909:
-

Hi [~mikemccand]! Thanks for checking.
Yes, of course that first changed line is not required. I just felt it was 
useful to make it explicit to the reader that these are concurrent maps. Just a 
matter of style, feel free to revert that if it doesn't fit the Lucene style? 
Or should I provide an alternative patch?

> Improve concurrency for FacetsConfig
> 
>
> Key: LUCENE-6909
> URL: https://issues.apache.org/jira/browse/LUCENE-6909
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.3
>Reporter: Sanne Grinovero
>Priority: Trivial
> Attachments: 
> 0001-LUCENE-6909-Allow-efficient-concurrent-usage-of-a-Fa.patch
>
>
> The design of {{org.apache.lucene.facet.FacetsConfig}} encourages reuse of a 
> single instance across multiple threads, yet the current synchronization 
> model is too strict as it doesn't allow for concurrent read operations.
> I'll attach a trivial patch which removes the contention point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-8073) Solr fails to start on Windows with obscure errors when using relative path

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-8073:
---

Assignee: Shalin Shekhar Mangar

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Attachments: SOLR-8073.patch
>
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {quote}
> Possibly related to SOLR-8068? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: A 5.4 release?

[Shalin Shekhar Mangar]

I'll take it up, Ishan.

On Wed, Nov 25, 2015 at 9:11 PM, Ishan Chattopadhyaya
 wrote:
>> SOLR-8073 should be marked as resolved for 5.4
>
> Can someone please review and commit this?
>
> On Wed, Nov 25, 2015 at 9:09 PM, Shalin Shekhar Mangar
>  wrote:
>>
>> I closed LUCENE-6722 as a 'won't fix'
>>
>> On Wed, Nov 25, 2015 at 7:35 PM, Upayavira  wrote:
>> > I shall shortly create the 5.4 release branch. From this moment, the
>> > feature
>> > freeze starts.
>> >
>> > Looking through JIRA, I see some 71 tickets assigned to fix version 5.4.
>> > I
>> > suspect we won't be able to fix all 71 in one week, so I expect that the
>> > majority will be pushed, after this release, to 5.5.
>> >
>> > Looking for blockers or critical tickets, I see five tickets:
>> >
>> > https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>> >   "Adding read restriction to BasicAuth + RuleBased authorization causes
>> > issue with replication"
>> >
>> >   Anusham/Noble - any thoughts on how to resolve this before the
>> > release?
>> >
>> > https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>> >   "Move solr/webapp to solr/server/solr-webapp"
>> >
>> >   This one I know isn't a blocker in any sense.
>> >
>> > https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>> >   "Add tests for bin/post"
>> >
>> >   Again, this one does not seem to be something worthy of holding back a
>> > release
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>> >   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>> >
>> >   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others),
>> > blocker
>> >   "Java 8 as the minimum supported JVM version for branch_5x"
>> >
>> >   Looking at the discussion, there was no consensus here, so I will not
>> > consider this a blocker either.
>> >
>> >   - o -
>> >
>> > So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention.
>> > Anyone
>> > have comments/observations here?
>> >
>> > I will create the branch shortly.
>> >
>> > Upayavira
>>
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch

Updated patch:
* moves unwrapping into {{GeoPointDistanceQuery}}
* removes 7% tolerance - will be addressed by LUCENE-6908



> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8330) Remove unintentionally shared loggers.

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8330:
---

OK, ill add a note in CHANGES.Txt when I get back to a computer.

I don't see a ton of value in getting rid of Logger imports, but I'm happy to 
add that if people want to see it added.

> Remove unintentionally shared loggers.
> --
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8326) PKIAuthenticationPlugin doesn't report any errors in case of stale or wrong keys and returns garbage

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8326:
---
Summary: PKIAuthenticationPlugin doesn't report any errors in case of stale 
or wrong keys and returns garbage  (was: Adding read restriction to BasicAuth + 
RuleBased authorization causes issue with replication)

> PKIAuthenticationPlugin doesn't report any errors in case of stale or wrong 
> keys and returns garbage
> 
>
> Key: SOLR-8326
> URL: https://issues.apache.org/jira/browse/SOLR-8326
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 5.4
>
> Attachments: SOLR-8326.patch, SOLR-8326.patch
>
>
> This was reported on the mailing list:
> https://www.mail-archive.com/solr-user@lucene.apache.org/msg115921.html
> I tested it out as follows to confirm that adding a 'read' rule causes 
> replication to break. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: A 5.4 release?

[Ishan Chattopadhyaya]

> SOLR-8073 should be marked as resolved for 5.4

Can someone please review and commit this?

On Wed, Nov 25, 2015 at 9:09 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> I closed LUCENE-6722 as a 'won't fix'
>
> On Wed, Nov 25, 2015 at 7:35 PM, Upayavira  wrote:
> > I shall shortly create the 5.4 release branch. From this moment, the
> feature
> > freeze starts.
> >
> > Looking through JIRA, I see some 71 tickets assigned to fix version 5.4.
> I
> > suspect we won't be able to fix all 71 in one week, so I expect that the
> > majority will be pushed, after this release, to 5.5.
> >
> > Looking for blockers or critical tickets, I see five tickets:
> >
> > https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
> >   "Adding read restriction to BasicAuth + RuleBased authorization causes
> > issue with replication"
> >
> >   Anusham/Noble - any thoughts on how to resolve this before the release?
> >
> > https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
> >   "Move solr/webapp to solr/server/solr-webapp"
> >
> >   This one I know isn't a blocker in any sense.
> >
> > https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
> >   "Add tests for bin/post"
> >
> >   Again, this one does not seem to be something worthy of holding back a
> > release
> >
> > https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
> >   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
> >
> >   Uwe, I presume as this relates to Java 9, it isn't a blocker?
> >
> > https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others),
> blocker
> >   "Java 8 as the minimum supported JVM version for branch_5x"
> >
> >   Looking at the discussion, there was no consensus here, so I will not
> > consider this a blocker either.
> >
> >   - o -
> >
> > So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention.
> Anyone
> > have comments/observations here?
> >
> > I will create the branch shortly.
> >
> > Upayavira
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Attachment: (was: LUCENE-6905.patch)

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6905:
---
Attachment: LUCENE-6905.patch

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: pointers to subtle Lucene bugs

[Eslam Elnikety]

Thanks a lot, Robert. This is the kind of bugs I am after.

Mike, thanks for the pointer (interesting bug!). You are right. By "subtle"
I mean their impact could have been overlooked (no crash/exception). If
Lucene was able to search despite a missing segment --it seems to me that
Lucene will always throw an exception, right?--, then that bug would
qualify.

On Wed, Nov 25, 2015 at 3:49 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I like this one:
>
> https://issues.apache.org/jira/browse/LUCENE-5904
>
> As far as I know, it was not hit by user(s), but it was a real
> vulnerability when Lucene operates in a hostile environment where an
> adversarial virus checker can hold certain files open a "bad times"
> for Lucene.
>
> In such cases it could cause Lucene to delete files that would the
> corrupt its index, sort of a DOS attack.
>
> But I'm not sure this bug qualifies?  It seems like you are looking
> for bugs that are much more subtle in their impact?
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Nov 25, 2015 at 9:21 AM, Robert Muir  wrote:
> > I like this one (never released)
> > https://issues.apache.org/jira/browse/LUCENE-3575
> >
> > the basics are that fields in lucene have numbers, but if code mixes
> > these up (e.g. in an optimization), then data can "move" to different
> > field.
> >
> > Maybe there were other real corruption bugs along the same lines with
> > bulk merge.
> >
> > On Wed, Nov 25, 2015 at 9:08 AM, Eslam Elnikety
> >  wrote:
> >> Hi everyone,
> >>
> >> This is a question about your experience with bugs that silently make
> the
> >> application produce wrong results.
> >>
> >> I am developing a tool that prevents search engines from leaking
> sensitive
> >> information when they start misbehaving due to bugs/misconfigurations.
> I am
> >> trying to get better understanding of these bugs. If you recall bugs
> (e.g.,
> >> wrong/corrupt index, incorrect query parsing, ..) that result in wrong
> >> results or another strange silent behavior, it will be great if you
> share
> >> them with me. This will be extremely helpful.
> >>
> >> Here is an example of the kind of bugs I am looking for:
> >> https://issues.apache.org/jira/browse/LUCENE-2756
> >>
> >> Thanks!
> >>
> >> -- Eslam
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-7555) Display total space and available space in Admin

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7555:
---
Fix Version/s: (was: 5.4)
   5.5

[~epugh] been a long night :)  pushing to post-5.4

> Display total space and available space in Admin
> 
>
> Key: SOLR-7555
> URL: https://issues.apache.org/jira/browse/SOLR-7555
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.1
>Reporter: Eric Pugh
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.5
>
> Attachments: DiskSpaceAwareDirectory.java, 
> SOLR-7555-display_disk_space.patch, SOLR-7555-display_disk_space_v2.patch, 
> SOLR-7555-display_disk_space_v3.patch, SOLR-7555-display_disk_space_v4.patch, 
> SOLR-7555-display_disk_space_v5.patch, SOLR-7555.patch, SOLR-7555.patch, 
> SOLR-7555.patch
>
>
> Frequently I have access to the Solr Admin console, but not the underlying 
> server, and I'm curious how much space remains available.   This little patch 
> exposes total Volume size as well as the usable space remaining:
> !https://monosnap.com/file/VqlReekCFwpK6utI3lP18fbPqrGI4b.png!
> I'm not sure if this is the best place to put this, as every shard will share 
> the same data, so maybe it should be on the top level Dashboard?  Also not 
> sure what to call the fields! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-1280) Fields used update processor

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-1280:
---
Fix Version/s: (was: 5.4)

> Fields used update processor
> 
>
> Key: SOLR-1280
> URL: https://issues.apache.org/jira/browse/SOLR-1280
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: Trunk
>
> Attachments: FieldsUsedUpdateProcessorFactory.java, 
> FieldsUsedUpdateProcessorFactory.java, SOLR-1280.patch
>
>
> When dealing with highly heterogeneous documents with different fields per 
> document, it can be very useful to know what fields are present on the result 
> documents from a search.  For example, this could be used to determine which 
> fields make the best facets for a given query.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-6737) Remove unlockOnStartup option

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-6737.
-
Resolution: Duplicate
  Assignee: Uwe Schindler

Fixed already through LUCENE-6508 and SOLR-7942.

> Remove unlockOnStartup option
> -
>
> Key: SOLR-6737
> URL: https://issues.apache.org/jira/browse/SOLR-6737
> Project: Solr
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Uwe Schindler
>
> In LUCENE-6060 we removed IndexWriter.unlock: the method is dangerous, and we 
> needed because of buggy locking implementations which we think are now fixed 
> ... but I left Solr's unlockOnStartup option in that issue (wasn't sure what 
> to do).  I think Solr should also remove it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6909) Improve concurrency for FacetsConfig

[ASF subversion and git services (JIRA)]

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

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

Commit 1716476 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1716476 ]

LUCENE-6909: remove unnecessary synchronized keyword

> Improve concurrency for FacetsConfig
> 
>
> Key: LUCENE-6909
> URL: https://issues.apache.org/jira/browse/LUCENE-6909
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 5.3
>Reporter: Sanne Grinovero
>Priority: Trivial
> Attachments: 
> 0001-LUCENE-6909-Allow-efficient-concurrent-usage-of-a-Fa.patch
>
>
> The design of {{org.apache.lucene.facet.FacetsConfig}} encourages reuse of a 
> single instance across multiple threads, yet the current synchronization 
> model is too strict as it doesn't allow for concurrent read operations.
> I'll attach a trivial patch which removes the contention point.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Should schema API allow deleting uniqueKey?

[Alexandre Rafalovitch]

I am testing 5.4 branch and was enjoying new UI for adding/removing
fields in the schema.

So, for a test of an error message, I decided to delete the ID field.
And it let me. And then I indexed some files and the ID got recreated
as a generic field.

Should this be allowed or should delete field API check that we are
not deleting the uniqueKey? I can kind of see it both ways.

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/

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

[jira] [Commented] (SOLR-8073) Solr fails to start on Windows with obscure errors when using relative path

[ASF subversion and git services (JIRA)]

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

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

Commit 1716447 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716447 ]

SOLR-8073: Solr fails to start on Windows with obscure errors when using 
relative path

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Attachments: SOLR-8073.patch
>
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {quote}
> Possibly related to SOLR-8068? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716483 from [~nknize] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716483 ]

LUCENE-6905: updating change log.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: A 5.4 release?

[Timothy Potter]

I would like to put SOLR-7169 (also fixes 8267) and SOLR-8101 into
5.4. I'll commit to trunk and 5x today ... let me know if there are
any objections to also including in 5.4 branch

Tim

On Wed, Nov 25, 2015 at 6:05 AM, Upayavira  wrote:
> I shall shortly create the 5.4 release branch. From this moment, the feature
> freeze starts.
>
> Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> suspect we won't be able to fix all 71 in one week, so I expect that the
> majority will be pushed, after this release, to 5.5.
>
> Looking for blockers or critical tickets, I see five tickets:
>
> https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>   "Adding read restriction to BasicAuth + RuleBased authorization causes
> issue with replication"
>
>   Anusham/Noble - any thoughts on how to resolve this before the release?
>
> https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>   "Move solr/webapp to solr/server/solr-webapp"
>
>   This one I know isn't a blocker in any sense.
>
> https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>   "Add tests for bin/post"
>
>   Again, this one does not seem to be something worthy of holding back a
> release
>
> https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>
>   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>
> https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
>   "Java 8 as the minimum supported JVM version for branch_5x"
>
>   Looking at the discussion, there was no consensus here, so I will not
> consider this a blocker either.
>
>   - o -
>
> So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. Anyone
> have comments/observations here?
>
> I will create the branch shortly.
>
> Upayavira

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

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6905:


+1, thanks [~nknize], patch looks great, but can we add a test case showing the 
bug and then showing that we fixed it?  (Just capture the jenkins failures)

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8073) Solr fails to start on Windows with obscure errors when using relative path

[ASF subversion and git services (JIRA)]

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

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

Commit 1716446 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1716446 ]

SOLR-8073: Solr fails to start on Windows with obscure errors when using 
relative path

> Solr fails to start on Windows with obscure errors when using relative path
> ---
>
> Key: SOLR-8073
> URL: https://issues.apache.org/jira/browse/SOLR-8073
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
> Environment: Windows 7
>Reporter: Alexandre Rafalovitch
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Attachments: SOLR-8073.patch
>
>
> Clean 5.3  (and 5.3.1 RC3) on Windows:
> * bin\solr start -e techproducts
> * Visit Admin UI - all works
> * bin\solr stop -all
> * bin\solr start -s example\techproducts\solr
> * ERROR: Solr at http://localhost:8983/solr did not come online within 30 
> seconds!
> * Visit Admin UI - get an error:
> {quote}
> HTTP ERROR 500
> Problem accessing /solr/. Reason:
> Server Error
> Caused by:
> java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.authenticateRequest(SolrDispatchFilter.java:237)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:186)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:499)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Thread.java:745)
> {quote}
> Possibly related to SOLR-8068? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8335:
-

This was just broken behaviour in 4.x. The lock file should not have a prefix, 
because this would have no effect at all. Every Solr node would produce a new 
lock file name so locking would have no effect :-)

I was expecting that you had the 4.x deprecated setting to forcefully remove 
the lock file on startup, which is no longer supported in 5.x. You have to 
delete the file on your own.

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks 

[jira] [Commented] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query

[ASF subversion and git services (JIRA)]

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

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

Commit 1716478 from [~nknize] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716478 ]

LUCENE-6905: Unwrap center longitude for dateline crossing 
GeoPointDistanceQuery.

> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> ---
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch, 
> LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum 
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean 
> SHOULD. PostFiltering is accomplished by calculating the distance from the 
> center point to the candidate point field. Unfortunately the center point is 
> wrapped such that calculating the closest point on the "circle" from an 
> eastern point to a western MBR provides incorrect results thus causing false 
> negatives in the range creation. This was caught by a jenkins failure and 
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-8326) PKIAuthenticationPlugin doesn't report any errors in case of stale or wrong keys and returns garbage

[Anshum Gupta (JIRA)]

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

Anshum Gupta edited comment on SOLR-8326 at 11/25/15 5:40 PM:
--

PKIAuthenticationPlugin doesn't report errors in case the key provided is 
invalid and instead just returns garbage. This causes the authorization to 
break as well.

Original text:

Here are the list of steps that you'd need to run to see that things are fine 
for you without the read permission:
* Untar and setup Solr, don't start it yet
* Start clean zookeeper
* Put the security.json in zk, without anything other than a security-edit 
permission. Find the content of the file below. Upload it using your own zk 
client or through the solr script:
> solr-5.3.1/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd 
> putfile /security.json ~/security.json

security.json:
{"authentication":{"class":"solr.BasicAuthPlugin","credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}},"authorization":{"class":"solr.RuleBasedAuthorizationPlugin","user-role":{"solr":["admin"]},"permissions":[{"name":"security-edit","role":"admin"}]}}

* Start solr: 
> solr-5.3.1/bin/solr start -e cloud -z localhost:2181

You would need to key in a few things e.g. #nodes and ports, leave them at the 
default values of 2 nodes and 8983/7574, unless you want to run Solr on a 
different port. Then let it create a default collection to just make sure that 
everything works fine.

* Add the collection-admin-edit command:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : 
> {"name":"collection-admin-edit", "role":"admin"}}'

At this point, everything should be working fine. Restarting the nodes  should 
also work fine. You can try 2 things at this point:
1. Create a new collection with 1 shard and 1 replica and then try adding a 
replica, here's how:
> curl --user solr:SolrRocks 
> http://localhost:8983/solr/admin/collections?action=CREATE=testcollection=gettingstarted=1

> curl --user solr:SolrRocks 
> http://localhost:8983/solr/admin/collections?action=ADDREPLICA=testcollection=shard1

This should work fine.

2. After this, try restarting the solr cluster. Here's how you can do so, 
assuming you didn't change any of the defaults and you are running zk on 
localhost:2181. If not, just change those values below:
> bin/solr stop -all

After this, check that Solr was actually stopped. I'd also suggest you tail the 
logs on both nodes when they are coming up to see any errors, if any. The logs 
would be here: example/cloud/node1/logs/solr.log and 
example/cloud/node2/logs/solr.log

> bin/solr start -c -p 8983 -s "example/cloud/node1/solr" -z localhost:2181
> bin/solr start -c -p 7574 -s "example/cloud/node2/solr" -z localhost:2181

If you get to this checkpoint fine, try adding a read permission.
Add a permission:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
> 'Content-type:application/json' -d '{"set-permission" : {"name":"read", 
> "role":"read"}}'

Add a user:
> curl --user solr:SolrRocks http://localhost:8983/solr/admin/authentication -H 
> 'Content-type:application/json' -d '{"set-user" : {"solrread":"solrRocks"}}'

Assign a role to the user:
>curl --user solr:SolrRocks http://localhost:8983/solr/admin/authorization -H 
>'Content-type:application/json' -d '{"set-user-role" : {"solrread":["read"]}}'

After this, you should start having issues with ADDREPLICA.
Also, as you would at this point have a collection with a shard that has a 
replication factor > 1 (remember the ADDREPLICA we did earlier), you would have 
issues when you restart the cluster again using the steps I mentioned above.


was (Author: anshumg):
Here are the list of steps that you'd need to run to see that things are fine 
for you without the read permission:
* Untar and setup Solr, don't start it yet
* Start clean zookeeper
* Put the security.json in zk, without anything other than a security-edit 
permission. Find the content of the file below. Upload it using your own zk 
client or through the solr script:
> solr-5.3.1/server/scripts/cloud-scripts/zkcli.sh -zkhost localhost:2181 -cmd 
> putfile /security.json ~/security.json

security.json:
{"authentication":{"class":"solr.BasicAuthPlugin","credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0=
 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}},"authorization":{"class":"solr.RuleBasedAuthorizationPlugin","user-role":{"solr":["admin"]},"permissions":[{"name":"security-edit","role":"admin"}]}}

* Start solr: 
> solr-5.3.1/bin/solr start -e cloud -z localhost:2181

You would need to key in a few things e.g. #nodes and ports, leave them at the 
default values of 2 nodes and 8983/7574, unless you want to run Solr on a 
different port. Then let 

[jira] [Updated] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Alexey Zelin (JIRA)]

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

Alexey Zelin updated LUCENE-5868:
-
Attachment: LUCENE-5868.patch

Added long values support as well as multi value fields support.

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7901) Add tests for bin/post

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7901:
---
Priority: Minor  (was: Critical)

> Add tests for bin/post
> --
>
> Key: SOLR-7901
> URL: https://issues.apache.org/jira/browse/SOLR-7901
> Project: Solr
>  Issue Type: Test
>  Components: scripts and tools
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: Trunk
>
>
> bin/post relies on SimplePostTool, which has tests, but bin/post itself needs 
> a tests.  SOLR-7859 shows an example where a test would have caught a problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7042) Enhance bin/post's JSON handling

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7042:
---
Fix Version/s: (was: 5.4)

> Enhance bin/post's JSON handling
> 
>
> Key: SOLR-7042
> URL: https://issues.apache.org/jira/browse/SOLR-7042
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: Trunk
>
>
> The current (5.0) version of bin/post assumes JSON (and XML) are in *Solr* 
> command format, eg. {{bin/post -c collection1 data.json}} and that the URL to 
> post to is /update.  
> This issue is to improve/evolve bin/post so that it can post to /update when 
> the data is in *Solr* XML or JSON format and to /update/json/docs for 
> arbitrary JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7901) Add tests for bin/post

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7901:
---
Fix Version/s: (was: 5.4)
   Trunk

> Add tests for bin/post
> --
>
> Key: SOLR-7901
> URL: https://issues.apache.org/jira/browse/SOLR-7901
> Project: Solr
>  Issue Type: Test
>  Components: scripts and tools
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Critical
> Fix For: Trunk
>
>
> bin/post relies on SimplePostTool, which has tests, but bin/post itself needs 
> a tests.  SOLR-7859 shows an example where a test would have caught a problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8330) Remove unintentionally shared loggers.

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8330:


Wow that's a good 400kb patch! I'd like to change the CHANGES.txt entry to say 
"Standardize and fix logger creation and usage so that they are't shared across 
java class files"
 or something. It's certainly would be good to call it out explicitly that we 
want to move forward with this as more or less the standard, so that no one 
needs to revisit this and fix it again.

+1 from my end. If others are fine, I can commit this today/tomorrow so that it 
makes it to 5.4.

> Remove unintentionally shared loggers.
> --
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330.patch, SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7893) Enable SSL to ZooKeeper by default

[JIRA]

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

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

Added a link to the ZK SSL docs in the RefGuide: [Setting Up an External 
ZooKeeper 
Ensemble|https://cwiki.apache.org/confluence/display/solr/Setting+Up+an+External+ZooKeeper+Ensemble]

I'm not certain how we could enable "SSL by default" as the title suggests, as 
there is no "default" external ZooKeeper shipped with Solr that we could 
pre-configure.

I'll go ahead and rename this JIRA as a documentation jira and resolve it. 
Created two new spinoffs: SOLR-8342 for {{bin/solr}} and SOLR-8343 {{zkcli.sh}}.

> Enable SSL to ZooKeeper by default
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8343) zkcli.sh support for SSL enabled ZK communication

[JIRA]

Jan Høydahl created SOLR-8343:
-

 Summary: zkcli.sh support for SSL enabled ZK communication
 Key: SOLR-8343
 URL: https://issues.apache.org/jira/browse/SOLR-8343
 Project: Solr
  Issue Type: Sub-task
  Components: scripts and tools
Reporter: Jan Høydahl


If communicating with a secured ZooKeeper, {{zkcli.sh}} script should have 
native support for specifying the needed configurations, ref 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-8335.
-
Resolution: Won't Fix

The current behaviour is expected and one has to manually remove the lock file 
if the JVM stops abruptly . SOLR-8169 aims to solve that problem for HDFS users 
by exploring the option of the lock being in ZooKeeper.

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at 

[jira] [Updated] (SOLR-8337) Add ReduceOperation and wire it into the ReducerStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8337:
-
Summary: Add ReduceOperation and wire it into the ReducerStream  (was: Add 
ReduceOperation and wire into the ReducerStream)

> Add ReduceOperation and wire it into the ReducerStream
> --
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-8318) SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-8318:


Assignee: Erick Erickson

> SimpleQueryParser doesn't use MultiTermAnalysis for Fuzzy Queries
> -
>
> Key: SOLR-8318
> URL: https://issues.apache.org/jira/browse/SOLR-8318
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.3
>Reporter: Tom Hill
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: sqp_fuzzy_multiterm.patch
>
>
> Fuzzy queries in SimpleQParserPlugin don't seem to use the multi-term 
> analysis chain. Prefix queries do, and SolrQueryParser does use multi-term 
> analysis for fuzzy queries, so it seems like SimpleQParserPlugin should as 
> well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8330) Remove unintentionally shared loggers.

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-8330:
--
Attachment: SOLR-8330.patch

This patch includes a note in CHANGES.txt.  Shawn, I used your paragraph 
verbatim for the "upgrading from" section.  Well worded; thanks!

> Remove unintentionally shared loggers.
> --
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>  Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330.patch, SOLR-8330.patch
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are 
> unintentionally shared between classes.  Many instances of this are caused by 
> overzealous copy-paste.  This can make debugging tougher, as messages appear 
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate 
> reasons for sharing loggers between classes.  Where any ambiguity exists, 
> these instances shouldn't be touched.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7893) Enable SSL to ZooKeeper by default

[JIRA]

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

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

ZooKeeper now support SSL from clients if ZooKeeper is tarted with the Netty 
transport. See ZOOKEEPER-2125.

According to documentation 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide 
Solr users should already be able to connect to ZK securely simply by setting 
some Java Properties.

This issue will handle Solr start script support for enabling this, and update 
RefGuide accordingly.


> Enable SSL to ZooKeeper by default
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8342) Easy setup of ZooKeeper SSL in bin/solr

[JIRA]

Jan Høydahl created SOLR-8342:
-

 Summary: Easy setup of ZooKeeper SSL in bin/solr
 Key: SOLR-8342
 URL: https://issues.apache.org/jira/browse/SOLR-8342
 Project: Solr
  Issue Type: Sub-task
  Components: scripts and tools
Reporter: Jan Høydahl


Start scripts should support configuring ZooKeeper SSL. See 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-7893) Document ZooKeeper SSL support

[JIRA]

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

Jan Høydahl reassigned SOLR-7893:
-

Assignee: Jan Høydahl

> Document ZooKeeper SSL support
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7893) Document ZooKeeper SSL support

[JIRA]

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

Jan Høydahl resolved SOLR-7893.
---
Resolution: Fixed

> Document ZooKeeper SSL support
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7893) Document ZooKeeper SSL support

[JIRA]

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

Jan Høydahl edited comment on SOLR-7893 at 11/26/15 12:47 AM:
--

ZooKeeper now support SSL from clients if ZooKeeper is tarted with the Netty 
transport. See ZOOKEEPER-2125.

According to documentation 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide 
Solr users should already be able to connect to ZK securely simply by setting 
some Java Properties.


was (Author: janhoy):
ZooKeeper now support SSL from clients if ZooKeeper is tarted with the Netty 
transport. See ZOOKEEPER-2125.

According to documentation 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide 
Solr users should already be able to connect to ZK securely simply by setting 
some Java Properties.

This issue will handle Solr start script support for enabling this, and update 
RefGuide accordingly.


> Document ZooKeeper SSL support
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7893) Document ZooKeeper SSL support

[JIRA]

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

Jan Høydahl updated SOLR-7893:
--
Summary: Document ZooKeeper SSL support  (was: Enable SSL to ZooKeeper by 
default)

> Document ZooKeeper SSL support
> --
>
> Key: SOLR-7893
> URL: https://issues.apache.org/jira/browse/SOLR-7893
> Project: Solr
>  Issue Type: Sub-task
>  Components: security
>Reporter: Jan Høydahl
>  Labels: ssl, zookeeper
> Fix For: Trunk
>
>
> Once ZooKeeper supports SSL properly, Solr should start using it for all 
> communication. See comments in 
> https://cwiki.apache.org/confluence/display/solr/Enabling+SSL
> {quote}
> ZooKeeper does not support encrypted communication with clients like Solr.  
> There are several related JIRA tickets where SSL support is being 
> planned/worked on: ZOOKEEPER-235; ZOOKEEPER-236; ZOOKEEPER-733; and  
> ZOOKEEPER-1000.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-8337) Add ReduceOperation and wire into the ReducerStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8337 at 11/25/15 6:08 PM:


First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  
 search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
 by="a_s",
 group(sort="a_f asc", n="20"))
{code}  


was (Author: joel.bernstein):
First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  
 search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
by="a_s",
group(sort="a_f asc", n="20"))
{code}  

> Add ReduceOperation and wire into the ReducerStream
> ---
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8267) Status exit code

[Timothy Potter (JIRA)]

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

Timothy Potter resolved SOLR-8267.
--
   Resolution: Duplicate
Fix Version/s: 5.4

> Status exit code
> 
>
> Key: SOLR-8267
> URL: https://issues.apache.org/jira/browse/SOLR-8267
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Affects Versions: 5.2.1, 5.3
> Environment: ALL
>Reporter: Gauthier FRANCOIS
>Assignee: Timothy Potter
>Priority: Minor
>  Labels: easyfix
> Fix For: 5.4
>
>
> When /etc/init.d/solr status is called and solr service is not running, the 
> return exit code is 0 instead 3.
> I made some modifications in the /opt/solr/bin/solr file to correct this 
> issue:
>  - after line 446: add "exit 3"
>  - after line 466: add "exit 3"
> This issue appeared with an industrialisation configuration tool (puppet in 
> my case) which check if service is running.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7169) init.d status command has incorrect return value

[ASF subversion and git services (JIRA)]

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

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

Commit 1716518 from [~thelabdude] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716518 ]

SOLR-7169: bin/solr status should return exit code 3 no Solr is running instead 
of 0

> init.d status command has incorrect return value
> 
>
> Key: SOLR-7169
> URL: https://issues.apache.org/jira/browse/SOLR-7169
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
> Environment: Debian stable
>Reporter: Martin Skøtt
>Assignee: Timothy Potter
> Fix For: 5.4
>
>
> {{/etc/init.d/solr status}} returns 0 if Solr is not running, but according 
> to the LSB 0 means that the service is running 
> (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> In my situation this causes problems when managing the service with Puppet 
> which uses the status command to determine if a service should be started. 
> Puppet simply doesn't start the service because it thinks its already 
> running. Any other script depending on the result of the status command will 
> suffer similar problems.
> Workaround for other Puppet users:
> Setting {{hasstatus => false}} and {{pattern => "solr.solr.home"}} in the 
> service definition works for me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[ASF subversion and git services (JIRA)]

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

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

Commit 1716523 from [~yo...@apache.org] in branch 'dev/trunk'
[ https://svn.apache.org/r1716523 ]

SOLR-8341: fix parsing of domain:{excludeTags:mytag}

> domain:{excludeTags:mytag} doesn't work
> ---
>
> Key: SOLR-8341
> URL: https://issues.apache.org/jira/browse/SOLR-8341
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
>
> Generic domain switching keywords were all moved to
> the "domain" object, but it doesn't work for excludeTags.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[ASF subversion and git services (JIRA)]

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

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

Commit 1716527 from [~yo...@apache.org] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716527 ]

SOLR-8341: fix parsing of domain:{excludeTags:mytag}

> domain:{excludeTags:mytag} doesn't work
> ---
>
> Key: SOLR-8341
> URL: https://issues.apache.org/jira/browse/SOLR-8341
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
>
> Generic domain switching keywords were all moved to
> the "domain" object, but it doesn't work for excludeTags.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8101) Installation script permission issues and other scripts fixes

[ASF subversion and git services (JIRA)]

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

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

Commit 1716507 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716507 ]

SOLR-8101: Improve Linux service installation script

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: SOLR-8101.patch, solr-5.3.1.patch, 
> solr-scripts-v2.patch, solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
> may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8101) Installation script permission issues and other scripts fixes

[ASF subversion and git services (JIRA)]

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

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

Commit 1716506 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1716506 ]

SOLR-8101: Improve Linux service installation script

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: SOLR-8101.patch, solr-5.3.1.patch, 
> solr-scripts-v2.patch, solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
> may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-8101) Installation script permission issues and other scripts fixes

[Timothy Potter (JIRA)]

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

Timothy Potter resolved SOLR-8101.
--
   Resolution: Fixed
Fix Version/s: 5.4

Thanks Sergey!

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Fix For: 5.4
>
> Attachments: SOLR-8101.patch, solr-5.3.1.patch, 
> solr-scripts-v2.patch, solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
> may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6853) solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding - Not able to delete Synonyms/Stopwords with special characters

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-6853:
-
Assignee: (was: Timothy Potter)

> solr.ManagedSynonymFilterFactory/ManagedStopwordFilterFactory: URLEncoding - 
> Not able to delete Synonyms/Stopwords with special characters
> --
>
> Key: SOLR-6853
> URL: https://issues.apache.org/jira/browse/SOLR-6853
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 4.10.2
> Environment: Solr 4.10.2 running @ Win7
>Reporter: Tomasz Sulkowski
>  Labels: ManagedStopwordFilterFactory, 
> ManagedSynonymFilterFactory, REST, SOLR
> Attachments: SOLR-6853.patch
>
>
> Hi Guys,
> We're using the SOLR Rest API in order to manage synonyms and stopwords with 
> solr.Managed*FilterFactory.
> {_emphasis_}The same applies to stopwords. I am going to explain the synonym 
> case only from this point on.{_emphasis_}
> Let us consider the following _schema_analysis_synonyms_en.json managedMap: {
> "xxx#xxx":["xxx#xxx"],
> "xxx%xxx":["xxx%xxx"],
> "xxx/xxx":["xxx/xxx"],
> "xxx:xxx":["xxx:xxx"],
> "xxx;xxx":["xxx;xxx"],
> "xx ":["xx "]
> }
> I can add such synonym to keyword relations using REST API. The problem is 
> that I cannot remove/list them as 
> http://localhost:8983/solr/collection1/schema/analysis/synonyms/en/
>  where  is one of the map's key throws 404, or 500 (in case of 
> xxx%25xxx):
> java.lang.NullPointerException at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:367)
>  at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>  at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
>  at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) 
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
>  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) 
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
>  at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
>  at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) 
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
>  at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
>  at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
>  at org.eclipse.jetty.server.Server.handle(Server.java:368) at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
>  at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
>  at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
>  at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
>  at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at 
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
>  at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
>  at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
>  at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
>  at java.lang.Thread.run(Unknown Source)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5938) ConcurrentUpdateSolrServer don't parser the response while response status code isn't 200

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-5938:
-
Assignee: (was: Timothy Potter)

> ConcurrentUpdateSolrServer don't parser the response while response status 
> code isn't 200
> -
>
> Key: SOLR-5938
> URL: https://issues.apache.org/jira/browse/SOLR-5938
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.6.1
> Environment: one cloud has two server, one shard, one leader one 
> replica, send the index into replica server, replica server forward leader 
> server.
>Reporter: Raintung Li
>  Labels: SolrCloud, difficulty-easy, impact-low, solrj
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-5938.txt
>
>
> ConcurrentUpdateSolrServer only give back the error that don't parser the 
> response body, you can't get the error reason from remote server. 
> EX.
> You send the index request to one solr server, this server forward the other 
> leader server. forward case invoke the ConcurrentUpdateSolrServer.java, you 
> can't get the right error message only check it in the leader server if 
> happen error. Actually leader server had sent the error message to the 
> forwarding server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-8341:
--

Assignee: Yonik Seeley

> domain:{excludeTags:mytag} doesn't work
> ---
>
> Key: SOLR-8341
> URL: https://issues.apache.org/jira/browse/SOLR-8341
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
>
> Generic domain switching keywords were all moved to
> the "domain" object, but it doesn't work for excludeTags.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: A 5.4 release?

[Timothy Potter]

Ok, those fixes are in 5.4 now, thanks!

On Wed, Nov 25, 2015 at 9:49 AM, Upayavira  wrote:
> I'm for one am okay with these going into 5.4.
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 05:28 PM, Timothy Potter wrote:
>> I would like to put SOLR-7169 (also fixes 8267) and SOLR-8101 into
>> 5.4. I'll commit to trunk and 5x today ... let me know if there are
>> any objections to also including in 5.4 branch
>>
>> Tim
>>
>> On Wed, Nov 25, 2015 at 6:05 AM, Upayavira  wrote:
>> > I shall shortly create the 5.4 release branch. From this moment, the 
>> > feature
>> > freeze starts.
>> >
>> > Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
>> > suspect we won't be able to fix all 71 in one week, so I expect that the
>> > majority will be pushed, after this release, to 5.5.
>> >
>> > Looking for blockers or critical tickets, I see five tickets:
>> >
>> > https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
>> >   "Adding read restriction to BasicAuth + RuleBased authorization causes
>> > issue with replication"
>> >
>> >   Anusham/Noble - any thoughts on how to resolve this before the release?
>> >
>> > https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
>> >   "Move solr/webapp to solr/server/solr-webapp"
>> >
>> >   This one I know isn't a blocker in any sense.
>> >
>> > https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
>> >   "Add tests for bin/post"
>> >
>> >   Again, this one does not seem to be something worthy of holding back a
>> > release
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
>> >   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
>> >
>> >   Uwe, I presume as this relates to Java 9, it isn't a blocker?
>> >
>> > https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
>> >   "Java 8 as the minimum supported JVM version for branch_5x"
>> >
>> >   Looking at the discussion, there was no consensus here, so I will not
>> > consider this a blocker either.
>> >
>> >   - o -
>> >
>> > So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. 
>> > Anyone
>> > have comments/observations here?
>> >
>> > I will create the branch shortly.
>> >
>> > Upayavira
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Resolved] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-8341.

Resolution: Fixed

> domain:{excludeTags:mytag} doesn't work
> ---
>
> Key: SOLR-8341
> URL: https://issues.apache.org/jira/browse/SOLR-8341
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
>
> Generic domain switching keywords were all moved to
> the "domain" object, but it doesn't work for excludeTags.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7169) init.d status command has incorrect return value

[Dominik Siebel (JIRA)]

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

Dominik Siebel commented on SOLR-7169:
--

Thanks for merging this, Timothy.
This will then be fixed with 5.4.0 I assume?
Will there be another 5.3.x before that?

> init.d status command has incorrect return value
> 
>
> Key: SOLR-7169
> URL: https://issues.apache.org/jira/browse/SOLR-7169
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
> Environment: Debian stable
>Reporter: Martin Skøtt
>Assignee: Timothy Potter
> Fix For: 5.4
>
>
> {{/etc/init.d/solr status}} returns 0 if Solr is not running, but according 
> to the LSB 0 means that the service is running 
> (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> In my situation this causes problems when managing the service with Puppet 
> which uses the status command to determine if a service should be started. 
> Puppet simply doesn't start the service because it thinks its already 
> running. Any other script depending on the result of the status command will 
> suffer similar problems.
> Workaround for other Puppet users:
> Setting {{hasstatus => false}} and {{pattern => "solr.solr.home"}} in the 
> service definition works for me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: A 5.4 release?

[Upayavira]

I'm for one am okay with these going into 5.4.

Upayavira

On Wed, Nov 25, 2015, at 05:28 PM, Timothy Potter wrote:
> I would like to put SOLR-7169 (also fixes 8267) and SOLR-8101 into
> 5.4. I'll commit to trunk and 5x today ... let me know if there are
> any objections to also including in 5.4 branch
> 
> Tim
> 
> On Wed, Nov 25, 2015 at 6:05 AM, Upayavira  wrote:
> > I shall shortly create the 5.4 release branch. From this moment, the feature
> > freeze starts.
> >
> > Looking through JIRA, I see some 71 tickets assigned to fix version 5.4. I
> > suspect we won't be able to fix all 71 in one week, so I expect that the
> > majority will be pushed, after this release, to 5.5.
> >
> > Looking for blockers or critical tickets, I see five tickets:
> >
> > https://issues.apache.org/jira/browse/SOLR-8326 (Anusham, Noble) blocker
> >   "Adding read restriction to BasicAuth + RuleBased authorization causes
> > issue with replication"
> >
> >   Anusham/Noble - any thoughts on how to resolve this before the release?
> >
> > https://issues.apache.org/jira/browse/SOLR-8035 (Erik) critical
> >   "Move solr/webapp to solr/server/solr-webapp"
> >
> >   This one I know isn't a blocker in any sense.
> >
> > https://issues.apache.org/jira/browse/SOLR-7901 (Erik) critical
> >   "Add tests for bin/post"
> >
> >   Again, this one does not seem to be something worthy of holding back a
> > release
> >
> > https://issues.apache.org/jira/browse/LUCENE-6723 (Uwe) critical
> >   "Date field problems using ExtractingRequestHandler and java 9 (b71)"
> >
> >   Uwe, I presume as this relates to Java 9, it isn't a blocker?
> >
> > https://issues.apache.org/jira/browse/LUCENE-6722 (Shalin, others), blocker
> >   "Java 8 as the minimum supported JVM version for branch_5x"
> >
> >   Looking at the discussion, there was no consensus here, so I will not
> > consider this a blocker either.
> >
> >   - o -
> >
> > So SOLR-8326 and LUCENE-6723 seem to be the ones worthy of attention. Anyone
> > have comments/observations here?
> >
> > I will create the branch shortly.
> >
> > Upayavira
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Updated] (SOLR-8326) PKIAuthenticationPlugin doesn't report any errors in case of stale or wrong keys and returns garbage

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8326:
---
Attachment: SOLR-8326.patch

Thanks for the patch Noble. I've changed log levels and reduced visibility of 
methods where I could. I've also made a few things final in this patch where I 
thought it made sense.
The rest looks good to me.

I tested this out with:
* Start a 2 node cluster with external zk and security.json in place
* Try creating a collection and adding a replica - positive
* Add collection-admin-edit rule and make sure that credentials are required - 
positive
* Restart one of the nodes and see there are no errors - positive
* Add read user and permission, then create a collection - positive
* Add a replica on the new collection - positive
* Restart one of the nodes and make sure there are no errors and the replicas 
are healthy once the node is up - positive

It'd be good to add a test here so that we don't regress. It could be a PKI 
test or a Chaos monkey test perhaps, but then we'll need to figure a way to get 
Chaos monkey to work with MiniSolrCloudCluster so we could upload the security 
conf etc. 
For now, I think we should commit this as I'm not sure how long would the test 
itself take considering we're close to cutting the 5.4 branch and this is a 
blocker.

> PKIAuthenticationPlugin doesn't report any errors in case of stale or wrong 
> keys and returns garbage
> 
>
> Key: SOLR-8326
> URL: https://issues.apache.org/jira/browse/SOLR-8326
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3, 5.3.1
>Reporter: Anshum Gupta
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 5.4
>
> Attachments: SOLR-8326.patch, SOLR-8326.patch, SOLR-8326.patch
>
>
> This was reported on the mailing list:
> https://www.mail-archive.com/solr-user@lucene.apache.org/msg115921.html
> I tested it out as follows to confirm that adding a 'read' rule causes 
> replication to break. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7043) Refactor SolrCLI, bin\solr, bin\solr.cmd to be more unit-testable and less OS specific

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-7043:
-
Assignee: (was: Timothy Potter)

> Refactor SolrCLI, bin\solr, bin\solr.cmd to be more unit-testable and less OS 
> specific
> --
>
> Key: SOLR-7043
> URL: https://issues.apache.org/jira/browse/SOLR-7043
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Timothy Potter
>
> With the 5.0 release, we've reached critical mass with the bin/solr script 
> interface, but we've picked up some cruft along the way. Specifically, 
> there's too much OS-specific constructs in the scripts and they are quite 
> complex overall. They also require extensive manual testing. Moreover, 
> SolrCLI (provides support for the scripts) needs to be refactored to use the 
> Collections API support added to SolrJ instead of using low-level JSON / HTTP 
> constructs. SolrCLI is also in desperate need of a unit test. The overall 
> goal of this ticket is to move as much as possible out of the shell scripts 
> and into SolrCLI, thus increasing test coverage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[ASF subversion and git services (JIRA)]

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

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

Commit 1716524 from [~yo...@apache.org] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716524 ]

SOLR-8341: fix parsing of domain:{excludeTags:mytag}

> domain:{excludeTags:mytag} doesn't work
> ---
>
> Key: SOLR-8341
> URL: https://issues.apache.org/jira/browse/SOLR-8341
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
>
> Generic domain switching keywords were all moved to
> the "domain" object, but it doesn't work for excludeTags.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-8337) Add ReduceOperation Interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8337 at 11/25/15 6:05 PM:


First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
by="a_s",
group(sort="a_f asc", n="20"))
{code}  


was (Author: joel.bernstein):
First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
by="a_s",
group(sort="a_f asc"))
{code}  

> Add ReduceOperation Interface
> -
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8337) Add ReduceOperation Interface

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8337:
-
Attachment: SOLR-8337.patch

Added the GroupOperation. Now we just need some tests.

> Add ReduceOperation Interface
> -
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8101) Installation script permission issues and other scripts fixes

[ASF subversion and git services (JIRA)]

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

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

Commit 1716509 from [~thelabdude] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716509 ]

SOLR-8101: Improve Linux service installation script

> Installation script permission issues and other scripts fixes
> -
>
> Key: SOLR-8101
> URL: https://issues.apache.org/jira/browse/SOLR-8101
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.3.1
>Reporter: Sergey Urushkin
>Assignee: Timothy Potter
>  Labels: patch, security
> Attachments: SOLR-8101.patch, solr-5.3.1.patch, 
> solr-scripts-v2.patch, solr-scripts-v3.patch
>
>
> Until [https://issues.apache.org/jira/browse/SOLR-7871] is fixed, I suggest 
> to improve current shell scripts. Provided patch:
>   *  changes {{$SOLR_ENV}} default to {{/etc/default/$SOLR_SERVICE.in.sh}} . 
> This is *security* issue. If {{solr.in.sh}} is placed in directory which is 
> writable by {{$SOLR_USER}}, solr process is able to write to it, and than it 
> will be run by root on start/shutdown.
>   * changes permissions. {{$SOLR_USER}} should only be able to write to 
> {{$SOLR_VAR_DIR}}. This directory should not be readable by other users as it 
> may contain personal information.
>   * sets {{$SOLR_USER}} home directory to {{$SOLR_VAR_DIR}} . As I can see 
> there is no need in {{/home/solr}} directory.
>   * adds {{-f}} option to {{install_solr_service.sh}}. It should be used to 
> safely upgrade Solr.
>   * adds quotes to unquoted variables
>   * adds leading zero to chmod commands
>   * removes group from chown commands (uses ":")
> Tested on ubuntu 14.04 amd64, but changes are pretty system-independent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7615) Slow update requests not logged at WARN due to how LogUpdateProcessor's are created

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-7615:
-
Assignee: (was: Timothy Potter)

> Slow update requests not logged at WARN due to how LogUpdateProcessor's are 
> created
> ---
>
> Key: SOLR-7615
> URL: https://issues.apache.org/jira/browse/SOLR-7615
> Project: Solr
>  Issue Type: Bug
>Reporter: Timothy Potter
>Priority: Minor
>
> In SOLR-6650, we introduced the ability to only have slow update and query 
> requests get logged as warnings. However, when tracking down the cause of 
> SOLR-7603, we discovered that the LogUpdateProcessor is only included in the 
> chain if the log has INFO enabled, thus rendering the solution provided by 
> SOLR-6650 useless for update requests (queries still work though).
> Thus, we need to fix how LogUpdateProcessor is created if the user has 
> configured slowUpdateThresholdMillis > 0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8239) Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and remove DefaultSimilarityFactory in trunk

[ASF subversion and git services (JIRA)]

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

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

Commit 1716502 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1716502 ]

SOLR-8239: CHANGES typo (merge r1716501)

> Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and 
> remove DefaultSimilarityFactory in trunk
> --
>
> Key: SOLR-8239
> URL: https://issues.apache.org/jira/browse/SOLR-8239
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8239.patch
>
>
> As outlined in parent issue...
> * clone DefaultSimilarityFactory -> ClassicSimilarityFactory
> * prune DefaultSimilarityFactory down to a trivial subclass of 
> ClassicSimilarityFactory
> ** make it log a warning on init
> * change default behavior of IndexSchema to use ClassicSimilarityFactory 
> directly
> * mark DefaultSimilarityFactory as deprecated in 5.x, remove from trunk/6.0
> This should put us in a better position moving forward of having the facotry 
> names directly map to the underlying implementation, leaving less ambiguity 
> when an explicit factory is specified in the schema.xml (either as the main 
> similarity, or as a per field similarity)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8239) Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and remove DefaultSimilarityFactory in trunk

[ASF subversion and git services (JIRA)]

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

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

Commit 1716501 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1716501 ]

SOLR-8239: CHANGES typo

> Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and 
> remove DefaultSimilarityFactory in trunk
> --
>
> Key: SOLR-8239
> URL: https://issues.apache.org/jira/browse/SOLR-8239
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8239.patch
>
>
> As outlined in parent issue...
> * clone DefaultSimilarityFactory -> ClassicSimilarityFactory
> * prune DefaultSimilarityFactory down to a trivial subclass of 
> ClassicSimilarityFactory
> ** make it log a warning on init
> * change default behavior of IndexSchema to use ClassicSimilarityFactory 
> directly
> * mark DefaultSimilarityFactory as deprecated in 5.x, remove from trunk/6.0
> This should put us in a better position moving forward of having the facotry 
> names directly map to the underlying implementation, leaving less ambiguity 
> when an explicit factory is specified in the schema.xml (either as the main 
> similarity, or as a per field similarity)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8239) Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and remove DefaultSimilarityFactory in trunk

[ASF subversion and git services (JIRA)]

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

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

Commit 1716503 from hoss...@apache.org in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1716503 ]

SOLR-8239: CHANGES typo (merge r1716501)

> Deprecate/rename DefaultSimilarityFactory to ClassicSimilarityFactory and 
> remove DefaultSimilarityFactory in trunk
> --
>
> Key: SOLR-8239
> URL: https://issues.apache.org/jira/browse/SOLR-8239
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8239.patch
>
>
> As outlined in parent issue...
> * clone DefaultSimilarityFactory -> ClassicSimilarityFactory
> * prune DefaultSimilarityFactory down to a trivial subclass of 
> ClassicSimilarityFactory
> ** make it log a warning on init
> * change default behavior of IndexSchema to use ClassicSimilarityFactory 
> directly
> * mark DefaultSimilarityFactory as deprecated in 5.x, remove from trunk/6.0
> This should put us in a better position moving forward of having the facotry 
> names directly map to the underlying implementation, leaving less ambiguity 
> when an explicit factory is specified in the schema.xml (either as the main 
> similarity, or as a per field similarity)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8337) Add ReduceOperation and wire into the ReducerStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8337:
-
Summary: Add ReduceOperation and wire into the ReducerStream  (was: Add 
ReduceOperation Interface)

> Add ReduceOperation and wire into the ReducerStream
> ---
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-8337) Add ReduceOperation and wire into the ReducerStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8337 at 11/25/15 6:08 PM:


First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  
 search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
by="a_s",
group(sort="a_f asc", n="20"))
{code}  


was (Author: joel.bernstein):
First crack at adding the ReduceOperation to the ReducerStream.

I'll create a GroupOperation that will emit a single Tuple with a list of all 
the Tuples in a group.

{code}
reduce(  search(collection1, 
  q="*:*",
  qt="/export", 
  fl="id,a_s,a_i,a_f", 
  sort="a_s asc, a_f asc"),
by="a_s",
group(sort="a_f asc", n="20"))
{code}  

> Add ReduceOperation and wire into the ReducerStream
> ---
>
> Key: SOLR-8337
> URL: https://issues.apache.org/jira/browse/SOLR-8337
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-8337.patch, SOLR-8337.patch, SOLR-8337.patch
>
>
> This is a very simple ticket to create new interface that extends the 
> StreamOperation. The interface will be called the ReduceOperation.
> In the near future the ReducerStream will be changed to accept a 
> ReduceOperation. This will allow users to pass in the specific reduce 
> algorithm to the ReducerStream, making the ReducerStream much more powerful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8335) HdfsLockFactory does not allow core to come up after a node was killed

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8335:
-

bq. Every Solr node would produce a new lock file name so locking would have no 
effect

That explains it ;)

I am marking this ticket as 'Won't Fix' then.

> HdfsLockFactory does not allow core to come up after a node was killed
> --
>
> Key: SOLR-8335
> URL: https://issues.apache.org/jira/browse/SOLR-8335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1
>Reporter: Varun Thacker
>
> When using HdfsLockFactory if a node gets killed instead of a graceful 
> shutdown the write.lock file remains in HDFS . The next time you start the 
> node the core doesn't load up because of LockObtainFailedException .
> I was able to reproduce this in all 5.x versions of Solr . The problem wasn't 
> there when I tested it in 4.10.4
> Steps to reproduce this on 5.x
> 1. Create directory in HDFS : {{bin/hdfs dfs -mkdir /solr}}
> 2. Start Solr: {{bin/solr start -Dsolr.directoryFactory=HdfsDirectoryFactory 
> -Dsolr.lock.type=hdfs -Dsolr.data.dir=hdfs://localhost:9000/solr 
> -Dsolr.updatelog=hdfs://localhost:9000/solr}}
> 3. Create core: {{./bin/solr create -c test -n data_driven}}
> 4. Kill solr
> 5. The lock file is there in HDFS and is called {{write.lock}}
> 6. Start Solr again and you get a stack trace like this:
> {code}
> 2015-11-23 13:28:04.287 ERROR (coreLoadExecutor-6-thread-1) [   x:test] 
> o.a.s.c.CoreContainer Error creating core [test]: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> org.apache.solr.common.SolrException: Index locked for write for core 'test'. 
> Solr now longer supports forceful unlocking via 'unlockOnStartup'. Please 
> verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.lucene.store.LockObtainFailedException: Index locked 
> for write for core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.initIndex(SolrCore.java:528)
> at org.apache.solr.core.SolrCore.(SolrCore.java:761)
> ... 9 more
> 2015-11-23 13:28:04.289 ERROR (coreContainerWorkExecutor-2-thread-1) [   ] 
> o.a.s.c.CoreContainer Error waiting for SolrCore to be created
> java.util.concurrent.ExecutionException: 
> org.apache.solr.common.SolrException: Unable to create core [test]
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at org.apache.solr.core.CoreContainer$2.run(CoreContainer.java:472)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.common.SolrException: Unable to create core [test]
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:737)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:443)
> at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:434)
> ... 5 more
> Caused by: org.apache.solr.common.SolrException: Index locked for write for 
> core 'test'. Solr now longer supports forceful unlocking via 
> 'unlockOnStartup'. Please verify locks manually!
> at org.apache.solr.core.SolrCore.(SolrCore.java:820)
> at org.apache.solr.core.SolrCore.(SolrCore.java:659)
> at org.apache.solr.core.CoreContainer.create(CoreContainer.java:723)
> ... 7 more
> Caused 

[jira] [Commented] (SOLR-7672) introduce implicit _parent_:true

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7672:


Hmmm, \_parent\_:true wouldn't seem to work that well for multi-level 
hierarchies (remember, we're not limited to a single parent-child level).

Seems like something more general is desirable.  It feels like indexing 
\_path\_ would be both general and very useful.  The top-level parents would 
have a zero length _path_:""   Unfortunately, "/" is used by regex in the 
lucene query parser, so we could use "." as a path separator instead.

This fits in well with (future) auto-mapping from JSON structure to nested 
documents.

Example:
{code}
{
  id:x,
  work_address: {
state:NY,
street:"my work street"
  },
  home_address:{
state:NJ,
street:"my_home street"
  },
  cars:[
{
  make: Toyota,
  model: Highlander
},
{
  make: Honda,
  model: Accord
}
  ]  
}
{code}

_path_ would be "" for the root, then "home_address", "street_address", and 
"cars" for the other nested documents.

Note: I'm not asking that all this be *done* in this issue, just that we think 
about the end-game for nested documents (where we want to go), and make 
whatever we do fit in with that scheme.  For this specific JIRA issue, all that 
would need to be done is use a more generic \_path\_:"" 

Hmmm, perhaps \_type\_ would be a better name, since we aren't including id 
values or anything, we're just deriving a type name from the path.


> introduce implicit _parent_:true  
> --
>
> Key: SOLR-7672
> URL: https://issues.apache.org/jira/browse/SOLR-7672
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers, update
>Affects Versions: 5.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: 5.4, Trunk
>
>
> Solr provides block join support in non-invasive manner. It turns out, it 
> gives a chance to shoot a leg. As it was advised by [~thetaphi] at SOLR-7606, 
> let AddUpdateCommand add _parent_:true field to the document (not to 
> children). Do it *always* no matter whether it has children or not.
> Also, introduce default values for for block join qparsers \{!parent 
> *which=\_parent\_:true*} \{!child *of=\_parent\_:true*} (sometimes, I rather 
> want to hide them from the user, because they are misunderstood quite often). 
>  
> Please share your concerns and vote.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8341) domain:{excludeTags:mytag} doesn't work

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-8341:
--

 Summary: domain:{excludeTags:mytag} doesn't work
 Key: SOLR-8341
 URL: https://issues.apache.org/jira/browse/SOLR-8341
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3
Reporter: Yonik Seeley
 Fix For: 5.4


Generic domain switching keywords were all moved to
the "domain" object, but it doesn't work for excludeTags.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7169) init.d status command has incorrect return value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-7169:
--

Github user dsiebel commented on the pull request:

https://github.com/apache/lucene-solr/pull/212#issuecomment-159714390
  
Changes merged via JIRA/SVN:
* trunk: https://svn.apache.org/viewvc?view=revision=r1716516
* branch_5x: https://svn.apache.org/viewvc?view=revision=r1716517
* lucene_solr_5_4: 
https://svn.apache.org/viewvc?view=revision=r1716518


> init.d status command has incorrect return value
> 
>
> Key: SOLR-7169
> URL: https://issues.apache.org/jira/browse/SOLR-7169
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
> Environment: Debian stable
>Reporter: Martin Skøtt
>Assignee: Timothy Potter
> Fix For: 5.4
>
>
> {{/etc/init.d/solr status}} returns 0 if Solr is not running, but according 
> to the LSB 0 means that the service is running 
> (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> In my situation this causes problems when managing the service with Puppet 
> which uses the status command to determine if a service should be started. 
> Puppet simply doesn't start the service because it thinks its already 
> running. Any other script depending on the result of the status command will 
> suffer similar problems.
> Workaround for other Puppet users:
> Setting {{hasstatus => false}} and {{pattern => "solr.solr.home"}} in the 
> service definition works for me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7169) init.d status command has incorrect return value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-7169:
--

Github user dsiebel closed the pull request at:

https://github.com/apache/lucene-solr/pull/212


> init.d status command has incorrect return value
> 
>
> Key: SOLR-7169
> URL: https://issues.apache.org/jira/browse/SOLR-7169
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
> Environment: Debian stable
>Reporter: Martin Skøtt
>Assignee: Timothy Potter
> Fix For: 5.4
>
>
> {{/etc/init.d/solr status}} returns 0 if Solr is not running, but according 
> to the LSB 0 means that the service is running 
> (http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html).
> In my situation this causes problems when managing the service with Puppet 
> which uses the status command to determine if a service should be started. 
> Puppet simply doesn't start the service because it thinks its already 
> running. Any other script depending on the result of the status command will 
> suffer similar problems.
> Workaround for other Puppet users:
> Setting {{hasstatus => false}} and {{pattern => "solr.solr.home"}} in the 
> service definition works for me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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