[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

[Greg Pendlebury (JIRA)]

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

Greg Pendlebury commented on SOLR-2649:
---

I just ran it against out test system (patched Solr 5.1.0): (A OR B OR C) "D E"

1) Using mm=100%, q.op=AND and searching just the fulltext field. RAW debug:
{code}
(+(+(DisjunctionMaxQuery((fulltext:a)) DisjunctionMaxQuery((fulltext:b)) 
DisjunctionMaxQuery((fulltext:c))) +DisjunctionMaxQuery((fulltext:\"d e\"
{code}
I read that as:
{code}
+(a b c) +("d e")
{code}
which looks correct

2) switching to q.op=OR. RAW debug:
{code}
(+(((DisjunctionMaxQuery((fulltext:a)) DisjunctionMaxQuery((fulltext:b)) 
DisjunctionMaxQuery((fulltext:c))) DisjunctionMaxQuery((fulltext:\"d e\")))~2))
{code}
I read that as:
{code}
((a b c) "d e")~2
{code}
Which again looks correct... but we don't generally use OR, so I could be wrong

3) Finally, lowered mm to 50%, again with q.op=OR. RAW debug:
{code}
(+(((DisjunctionMaxQuery((fulltext:a)) DisjunctionMaxQuery((fulltext:b)) 
DisjunctionMaxQuery((fulltext:c))) DisjunctionMaxQuery((fulltext:\"d e\")))~1))
{code}
I read that as:
{code}
((a b c) "d e")~1
{code}
Still looks good.


> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-5211) updating parent as childless makes old children orphans

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-5211 at 12/4/15 7:34 AM:
-

I want to address this. Thus, we have to assign identifier spans across whole 
block. However it makes  semantics odd. Even if you send a single 
document, it _moves_ {{uniqueKey}} field value into {{\_root_}} field (as-is). 
Otherwise, we can propagate {{uniqueKey}} to whole block, but it would seem 
contradictionary. 
Which way would you like?


was (Author: mkhludnev):
I want to address this. Thus, we have to assign identifier spans across whole 
block. However it makes  semantics odd. Even if you send a single 
document, it _moves_ {{uniqueKey}} field value into {{_root_}} field (as-is). 
Otherwise, we can propagate {{uniqueKey}} to whole block, but it would seem 
contradictionary. 
Which way would you like?

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, Trunk
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[ASF subversion and git services (JIRA)]

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

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

Commit 1717898 from [~varunthacker] in branch 'dev/trunk'
[ https://svn.apache.org/r1717898 ]

SOLR-8363: Fix luceneMatchVersion check and update in build scripts

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch, SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[ASF subversion and git services (JIRA)]

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

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

Commit 1717905 from [~varunthacker] in branch 'dev/branches/lucene_solr_5_4'
[ https://svn.apache.org/r1717905 ]

SOLR-8363: Fix luceneMatchVersion check and update in build scripts

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch, SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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-8169) Need LockFactory impl that uses ZooKeeper as replacement for HdfsLockFactory

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8169:
-

This lock factory will also be useful for NFS users who use the simple lock 
factory since that also suffers from the same limitation currently.

> Need LockFactory impl that uses ZooKeeper as replacement for HdfsLockFactory
> 
>
> Key: SOLR-8169
> URL: https://issues.apache.org/jira/browse/SOLR-8169
> Project: Solr
>  Issue Type: New Feature
>  Components: Hadoop Integration
>Reporter: Timothy Potter
>
> It would be good to have an option to use a ZooKeeper backed LockFactory 
> implementation as a replacement for the HdfsLockFactory. FWIW - I've seen 
> instances in Solr on YARN environments where the lock file doesn't get 
> cleaned up correctly, which prevents using the index w/o some manual 
> intervention.



--
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

[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 232 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/232/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([27E8919E3801C711:9D3AFEE6BB2F2904]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:749)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:742)
... 40 more




Build Log:
[...truncated 10334 lines...]
   [junit4] Suite: 

[jira] [Created] (SOLR-8369) Increase value of "maxEdits" in spellchecker component

[Chintan V. Patel (JIRA)]

Chintan V. Patel created SOLR-8369:
--

 Summary: Increase value of "maxEdits" in spellchecker component
 Key: SOLR-8369
 URL: https://issues.apache.org/jira/browse/SOLR-8369
 Project: Solr
  Issue Type: Improvement
Reporter: Chintan V. Patel
Priority: Minor


Right now we have available value for "maxEdits" in spellchecker is 1 or 2
It's not sufficient so to improve we should have more value for maxEdits.

Here is example 
populr or popul - it gives "popular" as result
popu - no result ( because the difference is 6 )



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Varun Thacker (JIRA)]

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

Varun Thacker resolved SOLR-8363.
-
   Resolution: Fixed
 Assignee: Varun Thacker
Fix Version/s: Trunk
   5.4

Thanks Ryan!

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Blocker
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8363.patch, SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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?

[Varun Thacker]

Hi Upayavira,

I have committed a fix for SOLR-8363 . You should be good to go.

On Thu, Dec 3, 2015 at 8:00 PM, Upayavira  wrote:

> Agreed. Waiting on SOLR-8363 right now.
>
> On Thu, Dec 3, 2015, at 02:14 PM, Shalin Shekhar Mangar wrote:
> > Agreed, what's done is done but in future, let's avoid shoving
> > anything other than critical bug fixes into release branches.
> >
> > On Thu, Dec 3, 2015 at 7:42 PM, Robert Muir  wrote:
> > > A really strong reason would be to not shove last minute changes right
> > > before releases.
> > >
> > > On Thu, Dec 3, 2015 at 9:08 AM, Anshum Gupta 
> wrote:
> > >> I'll admit I committed it thinking it was safe and didn't bring any
> > >> flakiness into the system but it's not something critical. I'll let
> the
> > >> release manager decide if it's fine being released with 5.4. If he
> thinks
> > >> otherwise (or someone else has a really strong reason) we can roll
> this
> > >> back, though I don't really see a reason unless we see broken builds
> due to
> > >> this commit.
> > >>
> > >> On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand 
> wrote:
> > >>>
> > >>> SOLR-8330 is not critical so I don't think it should have been
> committed
> > >>> to the 5.4 branch. This gives CI too little time to find problems
> before
> > >>> Upayavira cuts a release candidate.
> > >>>
> > >>> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta 
> a écrit
> > >>> :
> > 
> >  Hi,
> > 
> >  I'd like to get SOLR-8330 in for 5.4. I'm currently merging and
> running
> >  tests so let me know if I shouldn't be merging this in.
> > 
> > 
> >  On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
> > >
> > > Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
> > > pointing at the 5.4 branch.
> > >
> > > Upayavira
> > >
> > > On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
> > > > thx :-)
> > > >
> > > > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
> > > > > OK . So I need to commit my fixes there. I missed the branch
> > > > > creation
> > > > > mail
> > > > >
> > > > >
> > > > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul <
> noble.p...@gmail.com>
> > > > > wrote:
> > > > > > @Upayavira is there a branch created for 5.4 already. I see
> one
> > > > > > already
> > > > > >
> > > > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson
> > > > > >  wrote:
> > > > > >> Do note that this is the Thanksgiving holiday here in the
> US,
> > > > > >> lots of
> > > > > >> people are out for the week. Mostly FYI, just don't be
> surprised
> > > > > >> if
> > > > > >> you get more traffic on this starting next week ;)
> > > > > >>
> > > > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter
> > > > > >>  wrote:
> > > > > >>> 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 <
> u...@odoko.co.uk>
> > > > > > 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?
> > > > > > >
> > > > > > > 

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2858 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2858/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([C0CC3620413ADA5C]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestAuthenticationFramework

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([C0CC3620413ADA5C]:0)




Build Log:
[...truncated 11054 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestAuthenticationFramework
   [junit4]   2> 344140 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 344140 INFO  (Thread-657) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 344140 INFO  (Thread-657) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 344241 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.ZkTestServer start zk server on port:60331
   [junit4]   2> 344241 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 344242 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 344251 INFO  (zkCallback-1901-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@29c98b90 
name:ZooKeeperConnection Watcher:127.0.0.1:60331 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 344251 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 344252 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 344252 INFO  
(TEST-TestAuthenticationFramework.testErrorsInStartup-seed#[C0CC3620413ADA5C]) 
[] o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 344273 INFO  (jetty-launcher-1900-thread-1) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 344274 INFO  (jetty-launcher-1900-thread-3) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 344280 INFO  (jetty-launcher-1900-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@5834393a{/solr,null,AVAILABLE}
   [junit4]   2> 344280 INFO  (jetty-launcher-1900-thread-1) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@2db687ad{HTTP/1.1}{127.0.0.1:60333}
   [junit4]   2> 344280 INFO  (jetty-launcher-1900-thread-3) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@6216bc17{/solr,null,AVAILABLE}
   [junit4]   2> 344280 INFO  (jetty-launcher-1900-thread-1) [] 
o.e.j.s.Server Started @349501ms
   [junit4]   2> 344280 INFO  (jetty-launcher-1900-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostPort=60333, 
hostContext=/solr}
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-3) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@36254a57{HTTP/1.1}{127.0.0.1:60334}
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-3) [] 
o.e.j.s.Server Started @349502ms
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-1) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@7b3cb2c6
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-3) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostPort=60334, 
hostContext=/solr}
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-1) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 
'/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.TestAuthenticationFramework_C0CC3620413ADA5C-001/tempDir-001/node1'
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-1) [] 
o.a.s.c.SolrResourceLoader JNDI not configured for solr (NoInitialContextEx)
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-1) [] 
o.a.s.c.SolrResourceLoader solr home defaulted to 'solr/' (could not find 
system property or JNDI)
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-3) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@7b3cb2c6
   [junit4]   2> 344281 INFO  (jetty-launcher-1900-thread-3) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_66) - Build # 15107 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15107/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseConcMarkSweepGC

56 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.DistributedVersionInfoTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([F6D4FD50D7345608]:0)


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

Error Message:
IOException occured when talking to server at: http://127.0.0.1:47906/_/oh

Stack Trace:
java.lang.AssertionError: IOException occured when talking to server at: 
http://127.0.0.1:47906/_/oh
at 
__randomizedtesting.SeedInfo.seed([F6D4FD50D7345608:7E80C28A79C83BF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.testNodeWithoutCollectionForwarding(BasicDistributedZk2Test.java:162)
at 
org.apache.solr.cloud.BasicDistributedZk2Test.test(BasicDistributedZk2Test.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 

[jira] [Comment Edited] (SOLR-2649) MM ignored in edismax queries with operators

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-2649 at 12/4/15 5:29 AM:
---

[~gpendleb] OK, we're using the same patch which was what  I wanted to be sure 
of. Sorry for the mis-attribution.

Regardless of what we call it, my questions are:

1> Are we going to include this change in 5.4.x? I have no intention of doing 
so, that ship has already sailed.

2> Does this change behavior that we've supported in the past? 

2a> If "yes", then we need to concern ourselves with back-compat and it's 
arguable whether this should be put in 5.x. It seems that it's better behavior 
than it was before, so perhaps documentation will be sufficient.

2b> If "no", then we're free to put this in both trunk and 5x (5.5 if one comes 
out) if we think the behavior is better with this patch. Still add a note to 
CHANGES.txt, along with the issue...

I'm tending at this point to put it in the 5x code line and make a point of 
this change in CHANGES.txt as I think it's a change that'll be seen as 
positive. I'm not wedded to the idea though.


was (Author: erickerickson):
[~gpendleb] OK, we're using the same patch which was what  I wanted to be sure 
of. Sorry for the mis-attribution.

Regardless of what we call it, my questions are:

1> Are we going to include this change in a point release, i.e. 5.4.x? I have 
no intention of doing so, that ship has already sailed.

2> Does this change behavior that we've supported in the past? 

2a> If "yes", then we need to concern ourselves with back-compat and it's 
arguable whether this should be put in 5.x. It seems that it's better behavior 
than it was before, so perhaps documentation will be sufficient.

2b> If "no", then we're free to put this in both trunk and 5x (5.5 if one comes 
out) if we think the behavior is better with this patch. Still add a note to 
CHANGES.txt, along with the issue...

I'm tending at this point to put it in the 5x code line and make a point of 
this change in CHANGES.txt as I think it's a change that'll be seen as 
positive. I'm not wedded to the idea though.

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-2649) MM ignored in edismax queries with operators

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-2649:
--

[~gpendleb] OK, we're using the same patch which was what  I wanted to be sure 
of. Sorry for the mis-attribution.

Regardless of what we call it, my questions are:

1> Are we going to include this change in a point release, i.e. 5.4.x? I have 
no intention of doing so, that ship has already sailed.

2> Does this change behavior that we've supported in the past? 

2a> If "yes", then we need to concern ourselves with back-compat and it's 
arguable whether this should be put in 5.x. It seems that it's better behavior 
than it was before, so perhaps documentation will be sufficient.

2b> If "no", then we're free to put this in both trunk and 5x (5.5 if one comes 
out) if we think the behavior is better with this patch. Still add a note to 
CHANGES.txt, along with the issue...

I'm tending at this point to put it in the 5x code line and make a point of 
this change in CHANGES.txt as I think it's a change that'll be seen as 
positive. I'm not wedded to the idea though.

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-7672) introduce implicit _parent_:true

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-7672 at 12/4/15 7:32 AM:
-

[~ysee...@gmail.com]
my turn: {{\_type_:_root_}} and spin off a jira about  
{{\_type_:\_root_.home_address}} or  {{\_type_:home_address}} 
Do you like it?


was (Author: mkhludnev):
[~ysee...@gmail.com]
my turn: {{_type_:_root_}} and spin off a jira about  
{{_type_:_root_.home_address}} or  {{_type_:home_address}} 
Do you like it?

> 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] [Commented] (SOLR-5211) updating parent as childless makes old children orphans

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-5211:


I want to emphasize two things: multilevel nesting is out of scope so far, just 
because we can't deal with the simplest single level parent/child case yet; I 
don't think we can afford to complicate update flow, ie. add {{deleteBy\*}} or 
check are there children (btw, they can be commited yet). 
We need to come up with universal routine which can handle all cases below via 
the single API entry point  [IW.updateDocuments(delTerm, 
docs)|https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/index/IndexWriter.java#L1299]
 or establish the new one: 
- add with/without children
- update (overwrite) with/without children
- let to omit uniquKey in schema, it this case it won't overwrite itself

just to remind, now it work as {{delTerm=$uniqueKey:get($uniqueKey)}} for 
childless, and  {{delTerm=\_root_:get($uniqueKey)}}. here is the problem.

IMHO, if we just allow $uniqueKey to span across a whole block (q=id:33 returns 
a block of several docs), it would be nobrainer, which solves everything. 

What I'm missing? 

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, Trunk
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
> Fix For: Trunk, 5.5
>
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
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-2649) MM ignored in edismax queries with operators

[Brian Carver (JIRA)]

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

Brian Carver commented on SOLR-2649:


This all began, years ago, with this query (assume whitespace=AND and mm=100%):

(A or B or C) "D E"

Will the currently proposed patch interpret such a query as:

(A or B or C) AND "D E"

or in some other way? 

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-7183) SaslZkACLProviderTest reproducible failures due to poor locale blacklisting

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7183:
-

I think we should add a link from this issue to the HadoopMiniKDC issue (if it 
exists) and then set this issue to state "pending" or like that.

> SaslZkACLProviderTest reproducible failures due to poor locale blacklisting
> ---
>
> Key: SOLR-7183
> URL: https://issues.apache.org/jira/browse/SOLR-7183
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Gregory Chanan
> Fix For: 5.2
>
> Attachments: SOLR-7183.patch
>
>
> SaslZkACLProviderTest has this blacklist of locales...
> {code}
>   // These Locales don't generate dates that are compatibile with Hadoop 
> MiniKdc.
>   protected final static List brokenLocales =
> Arrays.asList(
>   "th_TH_TH_#u-nu-thai",
>   "ja_JP_JP_#u-ca-japanese",
>   "hi_IN");
> {code}
> ..but this list is incomplete -- notably because it only focuses on one 
> specific Thai variant, and then does a string Locale.toString() comparison.  
> so at a minimum {{-Dtests.locale=th_TH}} also fails - i suspect there are 
> other variants that will fail as well
> * if there is a bug in "Hadoop MiniKdc" then that bug should be filed in 
> jira, and there should be Solr jira that refers to it -- the Solr jira URL 
> needs to be included her in the test case so developers in the future can 
> understand the context and have some idea of if/when the third-party lib bug 
> is fixed
> * if we need to work around some Locales because of this bug, then Locale 
> comparisons need be based on whatever aspects of the Locale are actually 
> problematic
> see for example SOLR-6387 & this commit: 
> https://svn.apache.org/viewvc/lucene/dev/branches/branch_4x/solr/contrib/morphlines-core/src/test/org/apache/solr/morphlines/solr/AbstractSolrMorphlineZkTestBase.java?r1=1618676=1618675=1618676
> Or SOLR-6991 + TIKA-1526 & this commit: 
> https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_5_0/solr/contrib/extraction/src/test/org/apache/solr/handler/extraction/ExtractingRequestHandlerTest.java?r1=1653708=1653707=1653708



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8363:
---

 Summary: luceneMatchVerision in solrconfigs under the example 
directory don't get updated
 Key: SOLR-8363
 URL: https://issues.apache.org/jira/browse/SOLR-8363
 Project: Solr
  Issue Type: Bug
Reporter: Varun Thacker
Priority: Blocker


The solrconfig.xml files under the example/ directory don't get updated on a 
new release.

example/files/conf/solrconfig still shows 5.0 
-https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
 

Similarly all configs under example/example-DIH/solr/ show 5.2



--
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) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8330:


The MethodHandles.lookup() creates an extra object for the Lookup inner class 
of MethodHandles. 

Isn't it memory/gc wise expensive, esp. given that some of the shortlived, 
often created objects (like AtomicUpdateDocumentMerger, 
DistributedUpdateProcessor etc.), would be creating their own logger, thus 
implying many extra MethodHandles.Lookup objects for every request? Is that a 
significant problem, or am I over estimating the problem?

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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] [Comment Edited] (SOLR-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8330 at 12/3/15 10:13 AM:
--

The MethodHandles.lookup() creates an extra object for the Lookup inner class 
of MethodHandles [0]. 

Isn't it memory/gc wise expensive, esp. given that some of the shortlived, 
often created objects (like AtomicUpdateDocumentMerger, 
DistributedUpdateProcessor etc.), would be creating their own logger, thus 
implying many extra MethodHandles.Lookup objects for every request? Is that a 
significant problem, or am I over estimating the problem?

[0] - 
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/java/lang/invoke/MethodHandles.java#MethodHandles.lookup%28%29


was (Author: ichattopadhyaya):
The MethodHandles.lookup() creates an extra object for the Lookup inner class 
of MethodHandles. 

Isn't it memory/gc wise expensive, esp. given that some of the shortlived, 
often created objects (like AtomicUpdateDocumentMerger, 
DistributedUpdateProcessor etc.), would be creating their own logger, thus 
implying many extra MethodHandles.Lookup objects for every request? Is that a 
significant problem, or am I over estimating the problem?

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8330:
-

The loggers are static, so created once.

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8330:


Ah, I was missing the static part; indeed no per-request cost. Good to learn 
about the escape analysis; thanks!

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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] [Updated] (LUCENE-6918) LRUQueryCache.onDocIdSetEviction should not be called when nothing is evicted

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6918:
-
Attachment: LUCENE-6918.patch

Here is a patch.

> LRUQueryCache.onDocIdSetEviction should not be called when nothing is evicted
> -
>
> Key: LUCENE-6918
> URL: https://issues.apache.org/jira/browse/LUCENE-6918
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-6918.patch
>
>
> This method is confusing because it states it will be called "when one or 
> more DocIdSets are removed from this cache" but may actually be called with 
> zero docidsets when evicting a per-segment cache that did not contain any 
> entries.



--
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-6918) LRUQueryCache.onDocIdSetEviction should not be called when nothing is evicted

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6918:
-
Description: This method is confusing because it states it will be called 
"when one or more DocIdSets are removed from this cache" but may actually be 
called with zero docidsets when evicting a per-segment cache that did not 
contain any entries.  (was: This method is confusing because it states it will 
be called "when one or more {@link DocIdSet}s are removed from this cache" but 
may actually be called with zero docidsets when evicting a per-segment cache 
that did not contain any entries.)

> LRUQueryCache.onDocIdSetEviction should not be called when nothing is evicted
> -
>
> Key: LUCENE-6918
> URL: https://issues.apache.org/jira/browse/LUCENE-6918
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.5
>
>
> This method is confusing because it states it will be called "when one or 
> more DocIdSets are removed from this cache" but may actually be called with 
> zero docidsets when evicting a per-segment cache that did not contain any 
> entries.



--
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

[JENKINS] Lucene-Solr-5.4-Linux (32bit/jdk1.8.0_66) - Build # 307 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/307/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([F27CA03146FB186A:8442BF4207CCB545]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:321)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:366)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:407)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:357)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:421)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 74226 - Failure!

[Michael McCandless]

Does not repro for me, even with the same JVM args (-server
-XX:+UseSerialGC -XX:-UseCompressedOops) ... maybe this is the elusive
https://issues.apache.org/jira/browse/LUCENE-6629 ... I'll add a comment.

Mike McCandless

On Thu, Dec 3, 2015 at 12:32 AM,  wrote:

> *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/74226/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDK8,network,heap[1024m],-server
> +UseSerialGC -UseCompressedOops,sec manager on Date of build:Thu, 03 Dec
> 2015 04:27:21 +0100 Build duration:2 hr 5 min
> *CHANGES* No Changes
> *BUILD ARTIFACTS*
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J0-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J1-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J2-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J3-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J4-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J5-20151203_043208_434.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J6-20151203_043208_435.events
> 
> -
> checkout/lucene/build/backward-codecs/test/temp/junit4-J7-20151203_043208_436.events
> 
> *FAILED JUNIT TESTS* Name: junit.framework Failed: 1 test(s), Passed: 0
> test(s), Skipped: 0 test(s), Total: 1 test(s)
> *- Failed:
> junit.framework.TestSuite.org.apache.lucene.codecs.lucene41.TestLucene41StoredFieldsFormat
> * Name: org.apache.lucene.codecs.lucene41 Failed: 1 test(s), Passed: 7
> test(s), Skipped: 0 test(s), Total: 8 test(s)
> *- Failed:
> org.apache.lucene.codecs.lucene41.TestLucene41StoredFieldsFormat.testMergeLargeDocuments
> *
> *CONSOLE OUTPUT* [...truncated 5743 lines...] [junit4] [junit4] [junit4]
> JVM J0: 0.77 .. 36.13 = 35.36s [junit4] JVM J1: 1.01 .. 43.63 = 42.62s 
> [junit4]
> JVM J2: 0.75 .. 50.83 = 50.09s [junit4] JVM J3: 0.62 .. 7245.27 = 7244.65s 
> [junit4]
> JVM J4: 0.81 .. 30.15 = 29.34s [junit4] JVM J5: 0.75 .. 36.32 = 35.58s 
> [junit4]
> JVM J6: 0.50 .. 55.80 = 55.30s [junit4] JVM J7: 0.57 .. 30.17 = 29.60s 
> [junit4]
> Execution time total: 2 hours 45 seconds [junit4] Tests summary: 30
> suites, 815 tests, 1 suite-level error, 1 error, 92 ignored (92 assumptions) 
> BUILD
> FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:471:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2248:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1452:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1006:
> There were test failures: 30 suites, 815 tests, 1 suite-level error, 1
> error, 92 ignored (92 assumptions) [seed: 1B32743AE8AA0DDD] Total time:
> 125 minutes 18 seconds Build step 'Invoke Ant' marked build as failure 
> Archiving
> artifacts Recording test results [description-setter] Description set:
> JDK8,network,heap[1024m],-server +UseSerialGC -UseCompressedOops,sec
> manager on Email was triggered for: Failure - 1st Trigger Failure - Any
> was overridden by another trigger and will not send an 

[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6629:


Maybe another one? 
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/74226/

{noformat}
  [junit4] Suite: 
org.apache.lucene.codecs.lucene41.TestLucene41StoredFieldsFormat
   [junit4]   2> gru 03, 2015 12:32:30 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.lucene41.TestLucene41StoredFieldsFormat
   [junit4]   2>1) Thread[id=70, 
name=SUITE-TestLucene41StoredFieldsFormat-seed#[1B32743AE8AA0DDD], 
state=RUNNABLE, group=TGRP-TestLucene41StoredFieldsFormat]
   [junit4]   2> at java.lang.Thread.getStackTrace(Thread.java:1552)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:688)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:685)
   [junit4]   2> at java.security.AccessController.doPrivileged(Native 
Method)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getStackTrace(ThreadLeakControl.java:685)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getThreadsWithTraces(ThreadLeakControl.java:701)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.formatThreadStacksFull(ThreadLeakControl.java:681)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.access$1000(ThreadLeakControl.java:64)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:414)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:681)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:140)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:591)
   [junit4]   2>2) Thread[id=10, name=JUnit4-serializer-daemon, 
state=TIMED_WAITING, group=main]
   [junit4]   2> at java.lang.Thread.sleep(Native Method)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$1.run(Serializer.java:47)
   [junit4]   2>3) Thread[id=1, name=main, state=WAITING, group=main]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1245)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1319)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:601)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:450)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:244)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:10)
   [junit4]   2>4) Thread[id=71, 
name=TEST-TestLucene41StoredFieldsFormat.testMergeLargeDocuments-seed#[1B32743AE8AA0DDD],
 state=RUNNABLE, group=TGRP-TestLucene41StoredFieldsFormat]
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.CompressionMode$LZ4FastCompressor.compress(CompressionMode.java:164)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene41.Lucene41StoredFieldsWriter.flush(Lucene41StoredFieldsWriter.java:218)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene41.Lucene41StoredFieldsWriter.finishDocument(Lucene41StoredFieldsWriter.java:151)
   [junit4]   2> at 
org.apache.lucene.index.DefaultIndexingChain.finishStoredFields(DefaultIndexingChain.java:270)
   [junit4]   2> at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:311)
   [junit4]   2> at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:234)
   [junit4]   2> at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:450)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1477)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1256)
   [junit4]   2> at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:170)
   [junit4]   2> at 
org.apache.lucene.codecs.lucene41.TestLucene41StoredFieldsFormat.testMergeLargeDocuments(TestLucene41StoredFieldsFormat.java:70)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b93) - Build # 15102 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15102/
Java: 32bit/jdk1.9.0-ea-b93 -client -XX:+UseSerialGC -XX:-CompactStrings

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

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=5620, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=5623, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)3) Thread[id=5624, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=5621, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)5) Thread[id=5622, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at 
jdk.internal.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=5620, name=apacheds, state=WAITING, 
group=TGRP-SaslZkACLProviderTest]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=5623, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at 

[jira] [Updated] (SOLR-8131) Make ManagedIndexSchemaFactory as the default in Solr

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8131:

Attachment: SOLR-8131.patch

Updated patch. The one additional change in behaviour with this patch is that 
mutable=true for ManagedSchema by default. This was there in my first patch but 
slipped out in the subsequent ones.

This also fixes the test failure which Shalin pointed out. Additionally there 
were some SolrJ tests failing because I had missed out some solrconfig files to 
add the schema factory to. Those have been fixed as well.

If everything is looking fine then I'll run the tests one final time with 
nightly tests to make sure everything is okay and then commit it tomorrow ( 
Friday )

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



--
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-8292) TransactionLog.next() does not honor contract and return null for EOF

[Renaud Delbru (JIRA)]

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

Renaud Delbru commented on SOLR-8292:
-

Perhaps related to SOLR-4116 ?

> TransactionLog.next() does not honor contract and return null for EOF
> -
>
> Key: SOLR-8292
> URL: https://issues.apache.org/jira/browse/SOLR-8292
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>
> This came to light in CDCR testing, which stresses this code a lot, there's a 
> stack trace showing this line (641 trunk) throwing an EOF exception:
> o = codec.readVal(fis);
> At first I thought to just wrap reading fis in a try/catch and return null, 
> but looking at the code a bit more I'm not so sure, that seems like it'd mask 
> what looks at first glance like a bug in the logic.
> A few lines earlier (633-4) there's these lines:
> // shouldn't currently happen - header and first record are currently written 
> at the same time
> if (fis.position() >= fos.size()) {
> Why are we comparing the the input file position against the size of the 
> output file? Maybe because the 'i' key is right next to the 'o' key? The 
> comment hints that it's checking for the ability to read the first record in 
> input stream along with the header. And perhaps there's a different issue 
> here because the expectation clearly is that the first record should be there 
> if the header is.
> So what's the right thing to do? Wrap in a try/catch and return null for EOF? 
> Change the test? Do both?
> I can take care of either, but wanted a clue whether the comparison of fis to 
> fos is intended.



--
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-6915) SaslZkACLProvider and Kerberos Test Using MiniKdc

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-6915:


Maybe we should move this discussion to SOLR-7183, where I added a way to black 
list the known bad locales in the util class?

> SaslZkACLProvider and Kerberos Test Using MiniKdc
> -
>
> Key: SOLR-6915
> URL: https://issues.apache.org/jira/browse/SOLR-6915
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6915.patch, SOLR-6915.patch, fail.log, fail.log, 
> tests-failures.txt
>
>
> We should provide a ZkACLProvider that requires SASL authentication.  This 
> provider will be useful for administration in a kerberos environment.   In 
> such an environment, the administrator wants solr to authenticate to 
> zookeeper using SASL, since this is only way to authenticate with zookeeper 
> via kerberos.
> The authorization model in such a setup can vary, e.g. you can imagine a 
> scenario where solr owns (is the only writer of) the non-config znodes, but 
> some set of trusted users are allowed to modify the configs.  It's hard to 
> predict all the possibilities here, but one model that seems generally useful 
> is to have a model where solr itself owns all the znodes and all actions that 
> require changing the znodes are routed to Solr APIs.  That seems simple and 
> reasonable as a first version.
> As for testing, I noticed while working on SOLR-6625 that we don't really 
> have any infrastructure for testing kerberos integration in unit tests.  
> Internally, I've been testing using kerberos-enabled VM clusters, but this 
> isn't great since we won't notice any breakages until someone actually spins 
> up a VM.  So part of this JIRA is to provide some infrastructure for testing 
> kerberos at the unit test level (using Hadoop's MiniKdc, HADOOP-9848).



--
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] (LUCENE-6918) LRUQueryCache.onDocIdSetEviction should not be called when nothing is evicted

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6918:


 Summary: LRUQueryCache.onDocIdSetEviction should not be called 
when nothing is evicted
 Key: LUCENE-6918
 URL: https://issues.apache.org/jira/browse/LUCENE-6918
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.5


This method is confusing because it states it will be called "when one or more 
{@link DocIdSet}s are removed from this cache" but may actually be called with 
zero docidsets when evicting a per-segment cache that did not contain any 
entries.



--
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-8131) Make ManagedIndexSchemaFactory as the default in Solr

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8131:
-

Thanks Varun, there's one reproducible test failure with your patch applied:

{code}
  [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSolrCLIRunExample -Dtests.method=testInteractiveSolrCloudExample 
-Dtests.seed=B06DF3AE906F4D27 -Dtests.slow=true -Dtests.locale=es_PY 
-Dtests.timezone=Pacific/Easter -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] ERROR   5.32s J1 | 
TestSolrCLIRunExample.testInteractiveSolrCloudExample <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://localhost:54786/solr/testCloudExamplePrompt_shard1_replica2: 
This IndexSchema is not mutable.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B06DF3AE906F4D27:6B1C1364A71A8841]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:633)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:982)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:174)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:139)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:153)
   [junit4]>at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:445)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 
http://localhost:54786/solr/testCloudExamplePrompt_shard1_replica2: This 
IndexSchema is not mutable.
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient$2.call(CloudSolrClient.java:608)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient$2.call(CloudSolrClient.java:605)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:232)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>... 1 more

{code}

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



--
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?

[Varun Thacker]

Hi Everyone,

I think we should try to fix SOLR-8363 before the RC?

Seems like this problem has been there for a while since the
luceneMatchVersion hasn't updated in a while. So if others feel this isn't
worth the delay then I'll remove it from being a blocker.

On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand  wrote:

> SOLR-8330 is not critical so I don't think it should have been committed
> to the 5.4 branch. This gives CI too little time to find problems before
> Upayavira cuts a release candidate.
>
> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a
> écrit :
>
>> Hi,
>>
>> I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
>> tests so let me know if I shouldn't be merging this in.
>>
>>
>> On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
>>
>>> Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
>>> pointing at the 5.4 branch.
>>>
>>> Upayavira
>>>
>>> On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
>>> > thx :-)
>>> >
>>> > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
>>> > > OK . So I need to commit my fixes there. I missed the branch creation
>>> > > mail
>>> > >
>>> > >
>>> > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
>>> wrote:
>>> > > > @Upayavira is there a branch created for 5.4 already. I see one
>>> already
>>> > > >
>>> > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson <
>>> erickerick...@gmail.com> wrote:
>>> > > >> Do note that this is the Thanksgiving holiday here in the US,
>>> lots of
>>> > > >> people are out for the week. Mostly FYI, just don't be surprised
>>> if
>>> > > >> you get more traffic on this starting next week ;)
>>> > > >>
>>> > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter <
>>> thelabd...@gmail.com> wrote:
>>> > > >>> 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: 

[jira] [Commented] (SOLR-6915) SaslZkACLProvider and Kerberos Test Using MiniKdc

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-6915:


bq. best solution is to fix MiniKDC
+1, but seems like longer term.

> SaslZkACLProvider and Kerberos Test Using MiniKdc
> -
>
> Key: SOLR-6915
> URL: https://issues.apache.org/jira/browse/SOLR-6915
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6915.patch, SOLR-6915.patch, fail.log, fail.log, 
> tests-failures.txt
>
>
> We should provide a ZkACLProvider that requires SASL authentication.  This 
> provider will be useful for administration in a kerberos environment.   In 
> such an environment, the administrator wants solr to authenticate to 
> zookeeper using SASL, since this is only way to authenticate with zookeeper 
> via kerberos.
> The authorization model in such a setup can vary, e.g. you can imagine a 
> scenario where solr owns (is the only writer of) the non-config znodes, but 
> some set of trusted users are allowed to modify the configs.  It's hard to 
> predict all the possibilities here, but one model that seems generally useful 
> is to have a model where solr itself owns all the znodes and all actions that 
> require changing the znodes are routed to Solr APIs.  That seems simple and 
> reasonable as a first version.
> As for testing, I noticed while working on SOLR-6625 that we don't really 
> have any infrastructure for testing kerberos integration in unit tests.  
> Internally, I've been testing using kerberos-enabled VM clusters, but this 
> isn't great since we won't notice any breakages until someone actually spins 
> up a VM.  So part of this JIRA is to provide some infrastructure for testing 
> kerberos at the unit test level (using Hadoop's MiniKdc, HADOOP-9848).



--
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-8330) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8330 at 12/3/15 10:29 AM:
---

The loggers are static, so created once. There is no per-request cost!

In addition, the Lookup objects are never created on heap, because they never 
escape the declaration, so they are optimized away by hotspot, see [escape 
analysis|http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis].


was (Author: thetaphi):
The loggers are static, so created once.

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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

Re: A 5.4 release?

[Adrien Grand]

SOLR-8330 is not critical so I don't think it should have been committed to
the 5.4 branch. This gives CI too little time to find problems before
Upayavira cuts a release candidate.

Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a écrit :

> Hi,
>
> I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
> tests so let me know if I shouldn't be merging this in.
>
>
> On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
>
>> Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
>> pointing at the 5.4 branch.
>>
>> Upayavira
>>
>> On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
>> > thx :-)
>> >
>> > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
>> > > OK . So I need to commit my fixes there. I missed the branch creation
>> > > mail
>> > >
>> > >
>> > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
>> wrote:
>> > > > @Upayavira is there a branch created for 5.4 already. I see one
>> already
>> > > >
>> > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson <
>> erickerick...@gmail.com> wrote:
>> > > >> Do note that this is the Thanksgiving holiday here in the US, lots
>> of
>> > > >> people are out for the week. Mostly FYI, just don't be surprised if
>> > > >> you get more traffic on this starting next week ;)
>> > > >>
>> > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter <
>> thelabd...@gmail.com> wrote:
>> > > >>> 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: 

RE: A 5.4 release?

[Uwe Schindler]

Hi,

 

I agree: it brings no new functionality. On the other hand it is unlikely to 
break, so if Jenkins passes one time it will pass everytime (unless there is a 
still broken test that parses log output in a random way).!

 

So I would leave it open to release manager to merge it and press the “commit” 
button.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Adrien Grand [mailto:jpou...@gmail.com] 
Sent: Thursday, December 03, 2015 10:37 AM
To: dev@lucene.apache.org
Subject: Re: A 5.4 release?

 

SOLR-8330 is not critical so I don't think it should have been committed to the 
5.4 branch. This gives CI too little time to find problems before Upayavira 
cuts a release candidate.

 

Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  > a écrit :

Hi,

 

I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running tests 
so let me know if I shouldn't be merging this in.

 

 

On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  > wrote:

Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
pointing at the 5.4 branch.

Upayavira


On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
> thx :-)
>
> On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
> > OK . So I need to commit my fixes there. I missed the branch creation
> > mail
> >
> >
> > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul  >  > wrote:
> > > @Upayavira is there a branch created for 5.4 already. I see one already
> > >
> > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson  > >  > wrote:
> > >> Do note that this is the Thanksgiving holiday here in the US, lots of
> > >> people are out for the week. Mostly FYI, just don't be surprised if
> > >> you get more traffic on this starting next week ;)
> > >>
> > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter  > >>  > wrote:
> > >>> 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 

[jira] [Commented] (SOLR-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Ryan Ernst (JIRA)]

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

Ryan Ernst commented on SOLR-8363:
--

See {{update_example_solrconfigs}} in {{dev-tools/scripts/addVersion.py}}. The 
current directory it traverses underneath to find solrconfigs is 
{{solr/server/solr/configsets}}. This was originally using {{solr/example}}, 
but was changed in SOLR-7487.

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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) Restrict logger visibility throughout the codebase to private so that only the file that declares it can use it

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8330:
-

bq. Good to learn about the escape analysis; thanks!

This is one of the most important Hotspot optimizations, especially for Java 8! 
Lambdas and the fluent stream API based on collections would be slow  without 
escape analysis. Fluent APIs like {{int evenSquareSum = 
Arrays.stream(intArray).filter(i -> i % 2 == 0).map(i -> i * i).sum();}} make 
profit from that because those APIs return new instances of Stream subclasses 
all the time. Same applies for java.time API. Those never escape the method.

> Restrict logger visibility throughout the codebase to private so that only 
> the file that declares it can use it
> ---
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
>  Issue Type: Sub-task
>Affects Versions: Trunk
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>  Labels: logging
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8330-combined.patch, SOLR-8330-detector.patch, 
> SOLR-8330-detector.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, 
> SOLR-8330.patch, SOLR-8330.patch, 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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[ASF subversion and git services (JIRA)]

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

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

Commit 1717904 from [~varunthacker] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717904 ]

SOLR-8363: Fix luceneMatchVersion check and update in build scripts

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch, SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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-6889) BooleanQuery.rewrite could easily optimize some simple cases

[ASF subversion and git services (JIRA)]

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

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

Commit 1717757 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1717757 ]

LUCENE-6889: Add some basic rewrite rules to BooleanQuery that can make it run 
significantly faster in some cases.

> BooleanQuery.rewrite could easily optimize some simple cases
> 
>
> Key: LUCENE-6889
> URL: https://issues.apache.org/jira/browse/LUCENE-6889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6889.patch, LUCENE-6889.patch
>
>
> Follow-up of SOLR-8251: APIs and user interfaces sometimes encourage to write 
> BooleanQuery instances that are not optimal, for instance a typical case that 
> happens often with Solr/Elasticsearch is to send a request that has a 
> MatchAllDocsQuery as a query and some filter, which could be executed more 
> efficiently by directly wrapping the filter into a ConstantScoreQuery.
> Here are some ideas of rewrite operations that BooleanQuery could perform:
>  - remove FILTER clauses when they are also a MUST clause
>  - rewrite queries of the form "+*:* #filter" to a ConstantScoreQuery(filter)
>  - rewrite to a MatchNoDocsQuery when a clause that is a MUST or FILTER 
> clause is also a MUST_NOT clause



--
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-8347) Asynchronous searcher for custom component

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8347:
-

[~bogandy] I'd suggest you ask this question on the Solr user list. This does 
not strike me, at present, as a bug in Solr. It most certainly isn't a blocker 
for the project. If, after discussion on the Solr user list, you find an 
enhancement to Solr that would help, or find a specific bug, that would be the 
time to open a ticket here.

> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Blocker
>
> I'm trying to write a custom component for fuzzy searches. 
> After solr calls my component, I create a Thread and give it the 
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was 
> closed 
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be 
> used anymore as one of its child readers was closed
> at 
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at 
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at 
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at 
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other 
> threads? 



--
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-6910) fix 2 interesting and 2 trivial issues found by "Coverity scan results of Lucene"

[ASF subversion and git services (JIRA)]

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

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

Commit 1717772 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717772 ]

LUCENE-6910: remove line.length(); statement in TrecContentSource.java 
(https://scan.coverity.com/projects/5620 CID 120628) (merge in revision 1717756 
from trunk)

> fix 2 interesting and 2 trivial issues found by "Coverity scan results of 
> Lucene"
> -
>
> Key: LUCENE-6910
> URL: https://issues.apache.org/jira/browse/LUCENE-6910
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6910.patch, LUCENE-6910.patch
>
>
> https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> * coverity CID 119973
> * coverity CID 120040
> * coverity CID 120081
> * coverity CID 120628



--
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-6910) fix 2 interesting and 2 trivial issues found by "Coverity scan results of Lucene"

[ASF subversion and git services (JIRA)]

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

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

Commit 1717756 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1717756 ]

LUCENE-6910: remove line.length(); statement in TrecContentSource.java 
(https://scan.coverity.com/projects/5620 CID 120628)

> fix 2 interesting and 2 trivial issues found by "Coverity scan results of 
> Lucene"
> -
>
> Key: LUCENE-6910
> URL: https://issues.apache.org/jira/browse/LUCENE-6910
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6910.patch, LUCENE-6910.patch
>
>
> https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> * coverity CID 119973
> * coverity CID 120040
> * coverity CID 120081
> * coverity CID 120628



--
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-8347) Asynchronous searcher for custom component

[Bogdan Marinescu (JIRA)]

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

Bogdan Marinescu updated SOLR-8347:
---
Priority: Blocker  (was: Major)

Would be cool if someone answered...

> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Blocker
>
> I'm trying to write a custom component for fuzzy searches. 
> After solr calls my component, I create a Thread and give it the 
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was 
> closed 
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be 
> used anymore as one of its child readers was closed
> at 
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at 
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at 
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at 
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other 
> threads? 



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8363:
-

[~upayavira] The branch is taking a while to download and have to step out for 
a 3-4 hours. I can come back, test and commit it.

Please feel free to commit if you get to it earlier.

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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?

[Robert Muir]

A really strong reason would be to not shove last minute changes right
before releases.

On Thu, Dec 3, 2015 at 9:08 AM, Anshum Gupta  wrote:
> I'll admit I committed it thinking it was safe and didn't bring any
> flakiness into the system but it's not something critical. I'll let the
> release manager decide if it's fine being released with 5.4. If he thinks
> otherwise (or someone else has a really strong reason) we can roll this
> back, though I don't really see a reason unless we see broken builds due to
> this commit.
>
> On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand  wrote:
>>
>> SOLR-8330 is not critical so I don't think it should have been committed
>> to the 5.4 branch. This gives CI too little time to find problems before
>> Upayavira cuts a release candidate.
>>
>> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a écrit
>> :
>>>
>>> Hi,
>>>
>>> I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
>>> tests so let me know if I shouldn't be merging this in.
>>>
>>>
>>> On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:

 Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
 pointing at the 5.4 branch.

 Upayavira

 On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
 > thx :-)
 >
 > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
 > > OK . So I need to commit my fixes there. I missed the branch
 > > creation
 > > mail
 > >
 > >
 > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
 > > wrote:
 > > > @Upayavira is there a branch created for 5.4 already. I see one
 > > > already
 > > >
 > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson
 > > >  wrote:
 > > >> Do note that this is the Thanksgiving holiday here in the US,
 > > >> lots of
 > > >> people are out for the week. Mostly FYI, just don't be surprised
 > > >> if
 > > >> you get more traffic on this starting next week ;)
 > > >>
 > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter
 > > >>  wrote:
 > > >>> 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 

[jira] [Commented] (SOLR-8347) Asynchronous searcher for custom component

[Bogdan Marinescu (JIRA)]

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

Bogdan Marinescu commented on SOLR-8347:


I made it a blocker because nobody was answering. It's not a blocker but it is 
I believe an issue because if I want to do some asynchronous work in a custom 
component I cannot access the SolrIndexSearcher anymore.. mainly because after 
the solr call is over someone/something closes the searcher (probably due to a 
commit). I was wondering if what I was trying to do was possible (to lock the 
searcher somehow until my component releases it) but I'll take your advice and 
ask in the solr user list

> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> I'm trying to write a custom component for fuzzy searches. 
> After solr calls my component, I create a Thread and give it the 
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was 
> closed 
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be 
> used anymore as one of its child readers was closed
> at 
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at 
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at 
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at 
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other 
> threads? 



--
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-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8363:

Attachment: SOLR-8363.patch

I had the variable names messed up in the previous patch

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch, SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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've just generated the first RC, but haven't posted it. How long do you
expect it to take to get this bug resolved? It does seem worth doing.

Upayavira

On Thu, Dec 3, 2015, at 09:51 AM, Varun Thacker wrote:
> Hi Everyone,
>
> I think we should try to fix SOLR-8363 before the RC?
>
> Seems like this problem has been there for a while since the
> luceneMatchVersion hasn't updated in a while. So if others feel this
> isn't worth the delay then I'll remove it from being a blocker.
>
> On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand
>  wrote:
>> SOLR-8330 is not critical so I don't think it should have been
>> committed to the 5.4 branch. This gives CI too little time to find
>> problems before Upayavira cuts a release candidate.
>>
>> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a
>> écrit :
>>> Hi,
>>>
>>> I'd like to get SOLR-8330 in for 5.4. I'm currently merging and
>>> running tests so let me know if I shouldn't be merging this in.
>>>
>>>
>>>
>>> On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
 Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins

pointing at the 5.4 branch.


Upayavira


On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:

> thx :-)

>

> On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:

> > OK . So I need to commit my fixes there. I missed the branch
> > creation

> > mail

> >

> >

> > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
> > wrote:

> > > @Upayavira is there a branch created for 5.4 already. I see one
> > > already

> > >

> > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson
> > >  wrote:

> > >> Do note that this is the Thanksgiving holiday here in the US,
> > >> lots of

> > >> people are out for the week. Mostly FYI, just don't be
> > >> surprised if

> > >> you get more traffic on this starting next week ;)

> > >>

> > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter
> > >>  wrote:

> > >>> 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 -

> > 

Re: A 5.4 release?

[Shalin Shekhar Mangar]

Agreed, what's done is done but in future, let's avoid shoving
anything other than critical bug fixes into release branches.

On Thu, Dec 3, 2015 at 7:42 PM, Robert Muir  wrote:
> A really strong reason would be to not shove last minute changes right
> before releases.
>
> On Thu, Dec 3, 2015 at 9:08 AM, Anshum Gupta  wrote:
>> I'll admit I committed it thinking it was safe and didn't bring any
>> flakiness into the system but it's not something critical. I'll let the
>> release manager decide if it's fine being released with 5.4. If he thinks
>> otherwise (or someone else has a really strong reason) we can roll this
>> back, though I don't really see a reason unless we see broken builds due to
>> this commit.
>>
>> On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand  wrote:
>>>
>>> SOLR-8330 is not critical so I don't think it should have been committed
>>> to the 5.4 branch. This gives CI too little time to find problems before
>>> Upayavira cuts a release candidate.
>>>
>>> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a écrit
>>> :

 Hi,

 I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
 tests so let me know if I shouldn't be merging this in.


 On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
>
> Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
> pointing at the 5.4 branch.
>
> Upayavira
>
> On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
> > thx :-)
> >
> > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
> > > OK . So I need to commit my fixes there. I missed the branch
> > > creation
> > > mail
> > >
> > >
> > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
> > > wrote:
> > > > @Upayavira is there a branch created for 5.4 already. I see one
> > > > already
> > > >
> > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson
> > > >  wrote:
> > > >> Do note that this is the Thanksgiving holiday here in the US,
> > > >> lots of
> > > >> people are out for the week. Mostly FYI, just don't be surprised
> > > >> if
> > > >> you get more traffic on this starting next week ;)
> > > >>
> > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter
> > > >>  wrote:
> > > >>> 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
> > > > 

[jira] [Updated] (SOLR-8363) luceneMatchVerision in solrconfigs under the example directory don't get updated

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8363:

Attachment: SOLR-8363.patch

Thanks [~rjernst] for pointing it out! That made it very simple to understand 
what changed.

[~upayavira] I am currently downloading the 5_4 branch to test out the patch. 
Could you also quickly try it out to see if it works?

> luceneMatchVerision in solrconfigs under the example directory don't get 
> updated
> 
>
> Key: SOLR-8363
> URL: https://issues.apache.org/jira/browse/SOLR-8363
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Priority: Blocker
> Attachments: SOLR-8363.patch
>
>
> The solrconfig.xml files under the example/ directory don't get updated on a 
> new release.
> example/files/conf/solrconfig still shows 5.0 
> -https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_5_4/solr/example/files/conf/solrconfig.xml
>  
> Similarly all configs under example/example-DIH/solr/ show 5.2



--
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]

Agreed. Waiting on SOLR-8363 right now.

On Thu, Dec 3, 2015, at 02:14 PM, Shalin Shekhar Mangar wrote:
> Agreed, what's done is done but in future, let's avoid shoving
> anything other than critical bug fixes into release branches.
> 
> On Thu, Dec 3, 2015 at 7:42 PM, Robert Muir  wrote:
> > A really strong reason would be to not shove last minute changes right
> > before releases.
> >
> > On Thu, Dec 3, 2015 at 9:08 AM, Anshum Gupta  wrote:
> >> I'll admit I committed it thinking it was safe and didn't bring any
> >> flakiness into the system but it's not something critical. I'll let the
> >> release manager decide if it's fine being released with 5.4. If he thinks
> >> otherwise (or someone else has a really strong reason) we can roll this
> >> back, though I don't really see a reason unless we see broken builds due to
> >> this commit.
> >>
> >> On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand  wrote:
> >>>
> >>> SOLR-8330 is not critical so I don't think it should have been committed
> >>> to the 5.4 branch. This gives CI too little time to find problems before
> >>> Upayavira cuts a release candidate.
> >>>
> >>> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a écrit
> >>> :
> 
>  Hi,
> 
>  I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
>  tests so let me know if I shouldn't be merging this in.
> 
> 
>  On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
> >
> > Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
> > pointing at the 5.4 branch.
> >
> > Upayavira
> >
> > On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
> > > thx :-)
> > >
> > > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
> > > > OK . So I need to commit my fixes there. I missed the branch
> > > > creation
> > > > mail
> > > >
> > > >
> > > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
> > > > wrote:
> > > > > @Upayavira is there a branch created for 5.4 already. I see one
> > > > > already
> > > > >
> > > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson
> > > > >  wrote:
> > > > >> Do note that this is the Thanksgiving holiday here in the US,
> > > > >> lots of
> > > > >> people are out for the week. Mostly FYI, just don't be surprised
> > > > >> if
> > > > >> you get more traffic on this starting next week ;)
> > > > >>
> > > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter
> > > > >>  wrote:
> > > > >>> 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"
> > > > > >
> > > > > 

[jira] [Commented] (SOLR-7339) Upgrade Jetty from 9.2 to 9.3

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7339: Remove http2-parent as a dependency because it is only a pom and 
thus fails our maven builds

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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-8131) Make ManagedIndexSchemaFactory as the default in Solr

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8131:
-

There are still some test failures, Varun

{code}
   [junit4] Tests with failures [seed: EF2ABB6034EFC3BC]:
   [junit4]   - org.apache.solr.analytics.facet.FieldFacetTest (suite)
   [junit4]   - org.apache.solr.analytics.expression.ExpressionTest (suite)
   [junit4]   - org.apache.solr.analytics.NoFacetTest (suite)
   [junit4]   - org.apache.solr.analytics.util.valuesource.FunctionTest (suite)
   [junit4]   - org.apache.solr.analytics.facet.RangeFacetTest (suite)
   [junit4]   - org.apache.solr.analytics.facet.FieldFacetExtrasTest (suite)
   [junit4]   - org.apache.solr.analytics.facet.QueryFacetTest (suite)
{code}

Most are of the form:
{code}
   [junit4] ERROR   0.00s J1 | QueryFacetTest (suite) <<<
   [junit4]> Throwable #1: java.security.AccessControlException: access 
denied ("java.io.FilePermission" 
"/home/shalin/work/oss/trunk/solr/contrib/analytics/src/test-files/solr/collection1/conf/managed-schema"
 "write")
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([EF2ABB6034EFC3BC]:0)
   [junit4]>at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.security.AccessController.checkPermission(AccessController.java:884)
   [junit4]>at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
   [junit4]>at 
java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
   [junit4]>at 
java.io.FileOutputStream.(FileOutputStream.java:200)
   [junit4]>at 
java.io.FileOutputStream.(FileOutputStream.java:162)
   [junit4]>at 
org.apache.solr.schema.ManagedIndexSchema.persistManagedSchema(ManagedIndexSchema.java:130)
   [junit4]>at 
org.apache.solr.schema.ManagedIndexSchemaFactory.upgradeToManagedSchema(ManagedIndexSchemaFactory.java:271)
   [junit4]>at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:186)
   [junit4]>at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:46)
   [junit4]>at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
   [junit4]>at 
org.apache.solr.util.TestHarness.(TestHarness.java:97)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:572)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:562)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:404)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:393)
   [junit4]>at 
org.apache.solr.analytics.facet.QueryFacetTest.beforeClass(QueryFacetTest.java:39)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{code}

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



--
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-7339) Upgrade Jetty from 9.2 to 9.3

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7339:
-

Thanks [~joakime]. I'll dig into why this is happening. As Ishan pointed out, 
adding a breakpoint in the test makes it pass so there's a subtle race 
condition somewhere.

> Upgrade Jetty from 9.2 to 9.3
> -
>
> Key: SOLR-7339
> URL: https://issues.apache.org/jira/browse/SOLR-7339
> Project: Solr
>  Issue Type: Improvement
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 6.0
>
> Attachments: SOLR-7339.patch, SOLR-7339.patch, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty92.pcapng, 
> SolrExampleStreamingBinaryTest.testUpdateField-jetty93.pcapng
>
>
> Jetty 9.3 offers support for HTTP/2. Interest in HTTP/2 or its predecessor 
> SPDY was shown in [SOLR-6699|https://issues.apache.org/jira/browse/SOLR-6699] 
> and [on the mailing list|http://markmail.org/message/jyhcmwexn65gbdsx].
> Among the HTTP/2 benefits over HTTP/1.1 relevant to Solr are:
> * multiplexing requests over a single TCP connection ("streams")
> * canceling a single request without closing the TCP connection
> * removing [head-of-line 
> blocking|https://http2.github.io/faq/#why-is-http2-multiplexed]
> * header compression
> Caveats:
> * Jetty 9.3 is at M2, not released.
> * Full Solr support for HTTP/2 would require more work than just upgrading 
> Jetty. The server configuration would need to change and a new HTTP client 
> ([Jetty's own 
> client|https://github.com/eclipse/jetty.project/tree/master/jetty-http2], 
> [Square's OkHttp|http://square.github.io/okhttp/], 
> [etc.|https://github.com/http2/http2-spec/wiki/Implementations]) would need 
> to be selected and wired up. Perhaps this is worthy of a branch?



--
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?

[Anshum Gupta]

I'll admit I committed it thinking it was safe and didn't bring any
flakiness into the system but it's not something critical. I'll let the
release manager decide if it's fine being released with 5.4. If he thinks
otherwise (or someone else has a really strong reason) we can roll this
back, though I don't really see a reason unless we see broken builds due to
this commit.

On Thu, Dec 3, 2015 at 3:07 PM, Adrien Grand  wrote:

> SOLR-8330 is not critical so I don't think it should have been committed
> to the 5.4 branch. This gives CI too little time to find problems before
> Upayavira cuts a release candidate.
>
> Le jeu. 3 déc. 2015 à 03:34, Anshum Gupta  a
> écrit :
>
>> Hi,
>>
>> I'd like to get SOLR-8330 in for 5.4. I'm currently merging and running
>> tests so let me know if I shouldn't be merging this in.
>>
>>
>> On Thu, Nov 26, 2015 at 11:00 PM, Upayavira  wrote:
>>
>>> Thanks to Steve and Uwe, we now have both ASF and Policeman Jenkins
>>> pointing at the 5.4 branch.
>>>
>>> Upayavira
>>>
>>> On Thu, Nov 26, 2015, at 04:10 PM, Upayavira wrote:
>>> > thx :-)
>>> >
>>> > On Thu, Nov 26, 2015, at 04:07 PM, Noble Paul wrote:
>>> > > OK . So I need to commit my fixes there. I missed the branch creation
>>> > > mail
>>> > >
>>> > >
>>> > > On Thu, Nov 26, 2015 at 9:34 PM, Noble Paul 
>>> wrote:
>>> > > > @Upayavira is there a branch created for 5.4 already. I see one
>>> already
>>> > > >
>>> > > > On Thu, Nov 26, 2015 at 2:08 AM, Erick Erickson <
>>> erickerick...@gmail.com> wrote:
>>> > > >> Do note that this is the Thanksgiving holiday here in the US,
>>> lots of
>>> > > >> people are out for the week. Mostly FYI, just don't be surprised
>>> if
>>> > > >> you get more traffic on this starting next week ;)
>>> > > >>
>>> > > >> On Wed, Nov 25, 2015 at 11:35 AM, Timothy Potter <
>>> thelabd...@gmail.com> wrote:
>>> > > >>> 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
>>> > > >
>>> > > >
>>> 

[jira] [Updated] (SOLR-8347) Asynchronous searcher for custom component

[Bogdan Marinescu (JIRA)]

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

Bogdan Marinescu updated SOLR-8347:
---
Priority: Critical  (was: Blocker)

> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> I'm trying to write a custom component for fuzzy searches. 
> After solr calls my component, I create a Thread and give it the 
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was 
> closed 
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be 
> used anymore as one of its child readers was closed
> at 
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at 
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at 
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at 
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other 
> threads? 



--
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: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1618: POMs out of sync

[Shalin Shekhar Mangar]

This should be fixed now. There was a pom dependency on http2-parent
which has no corresponding jar file which caused the maven build to
fail.

On Wed, Dec 2, 2015 at 12:55 AM, Shalin Shekhar Mangar
 wrote:
> I'll fix this. Why does ant nightly-smoke not catch this?
>
> On Wed, Dec 2, 2015 at 12:06 AM, Apache Jenkins Server
>  wrote:
>> Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1618/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 36891 lines...]
>> -validate-maven-dependencies:
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
>> from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-test-framework:6.0.0-SNAPSHOT: checking for updates 
>> from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
>> sonatype.releases
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-parent:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
>> updates from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-common:6.0.0-SNAPSHOT: checking for 
>> updates from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
>> updates from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-kuromoji:6.0.0-SNAPSHOT: checking for 
>> updates from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
>> updates from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-analyzers-phonetic:6.0.0-SNAPSHOT: checking for 
>> updates from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for 
>> updates from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-backward-codecs:6.0.0-SNAPSHOT: checking for 
>> updates from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-codecs:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-core:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
>> from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-expressions:6.0.0-SNAPSHOT: checking for updates 
>> from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-grouping:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
>> from maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-highlighter:6.0.0-SNAPSHOT: checking for updates 
>> from releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-join:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-memory:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-misc:6.0.0-SNAPSHOT: checking for updates from 
>> releases.cloudera.com
>> [artifact:dependencies] [INFO] snapshot 
>> org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
>> maven-restlet
>> [artifact:dependencies] [INFO] 

[jira] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks. Currently I am using 5.2.1.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Sorry for posting the same message more than one time. Some how the add button 
was not responding may be due to slow network which caused this.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-2649) MM ignored in edismax queries with operators

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan updated SOLR-2649:
---
Priority: Major  (was: Minor)

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back on the version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back to older version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks. Currently I am using 5.2.1.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back to older version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5205:
-

Y.  Will backport for all 5.x.  Is there any need to make the fix in 4.x?

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather commented on LUCENE-5205:


Thanks for the quick response. Currently I am using 5.2.1 and will not be going 
back to older version.

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back to older version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-6910) fix 2 interesting and 2 trivial issues found by "Coverity scan results of Lucene"

[ASF subversion and git services (JIRA)]

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

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

Commit 1717804 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1717804 ]

LUCENE-6910: remove no-op code in CheckIndex.java 
(https://scan.coverity.com/projects/5620 CID 120040)

> fix 2 interesting and 2 trivial issues found by "Coverity scan results of 
> Lucene"
> -
>
> Key: LUCENE-6910
> URL: https://issues.apache.org/jira/browse/LUCENE-6910
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6910.patch, LUCENE-6910.patch
>
>
> https://scan.coverity.com/projects/5620 mentioned on the dev mailing list 
> (http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3ccaftwexg51-jm_6mdeoz1reagn3xgkbetoz5ou_f+melboo1...@mail.gmail.com%3e)
>  in July 2015:
> * coverity CID 119973
> * coverity CID 120040
> * coverity CID 120081
> * coverity CID 120628



--
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-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4116:
---

[~markus17], if you see this again, could you dump the shutdown logs? 

> Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException
> -
>
> Key: SOLR-4116
> URL: https://issues.apache.org/jira/browse/SOLR-4116
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.1
> Environment: 5.0.0.2012.11.28.10.42.06
> Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
>Reporter: Markus Jelsma
> Fix For: 5.4, Trunk
>
>
> With SOLR-4032 fixed we see other issues when randomly taking down nodes 
> (nicely via tomcat restart) while indexing a few million web pages from 
> Hadoop. We do make sure that at least one node is up for a shard but due to 
> recovery issues it may not be live.
> {code}
> 2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : Starting log replay 
> tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
> refcount=2} active=false starting pos=0
> 2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : java.io.EOFException
> at 
> org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
> at 
> org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
> at 
> org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
> at 
> org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}



--
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-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-4116:
-

Yes of course! Btw, the last time i saw the error, we were already using Jetty 
(Solr 5.1).

> Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException
> -
>
> Key: SOLR-4116
> URL: https://issues.apache.org/jira/browse/SOLR-4116
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.1
> Environment: 5.0.0.2012.11.28.10.42.06
> Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
>Reporter: Markus Jelsma
> Fix For: 5.4, Trunk
>
>
> With SOLR-4032 fixed we see other issues when randomly taking down nodes 
> (nicely via tomcat restart) while indexing a few million web pages from 
> Hadoop. We do make sure that at least one node is up for a shard but due to 
> recovery issues it may not be live.
> {code}
> 2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : Starting log replay 
> tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
> refcount=2} active=false starting pos=0
> 2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : java.io.EOFException
> at 
> org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
> at 
> org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
> at 
> org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
> at 
> org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back to older version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back on the version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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] [Issue Comment Deleted] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Modassar Ather (JIRA)]

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

Modassar Ather updated LUCENE-5205:
---
Comment: was deleted

(was: Thanks for the quick response. Currently I am using 5.2.1 and will not be 
going back to older version.)

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-7744) CheckIndex integration

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-7744:


[~thetaphi] how's your trip? 

> CheckIndex integration
> --
>
> Key: SOLR-7744
> URL: https://issues.apache.org/jira/browse/SOLR-7744
> Project: Solr
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up of LUCENE-6589.
> It would be nice to integrate index consistency checking tools such as 
> CheckIndex into Solr, which verifies checksums and ensures that redundant 
> informations in the index are consistent.
> Having some way to run these slow verifications would also allow for 
> integrating LUCENE-6589 which proposes an extension to CheckIndex for block 
> joins.



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5205:
-

Definitely a bug.  Thank you for reporting.  I was trying to allow the legacy 
behavior of double quotes around a single term (as determined by whitespace), 
but I think I should back off and require the use of single quotes for the 
classic parser's double quotes around a single term.

The fix for this example is easy, but I'd like to clean up other items related 
to this and add more tests.  Should have fix by tomorrow afternoon EDT.  

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 352 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/352/

No tests ran.

Build Log:
[...truncated 53042 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.02 sec (9.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.3 MB in 0.04 sec (733.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 65.4 MB in 0.09 sec (733.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 75.9 MB in 0.10 sec (723.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5951 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5951 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 211 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (28.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.0.0-src.tgz...
   [smoker] 37.2 MB in 0.62 sec (59.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.tgz...
   [smoker] 132.1 MB in 1.66 sec (79.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.zip...
   [smoker] 140.3 MB in 1.84 sec (76.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]  

[jira] [Issue Comment Deleted] (SOLR-8361) Failed to create collection in Solrcloud

[mugeesh (JIRA)]

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

mugeesh updated SOLR-8361:
--
Comment: was deleted

(was: @Erick, yeah it was not bug, actually, there was some IP redirection of 
server.)

> Failed to create collection in Solrcloud
> 
>
> Key: SOLR-8361
> URL: https://issues.apache.org/jira/browse/SOLR-8361
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: mugeesh
> Fix For: 5.3
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Hi, 
> I am using 3 server ,solr1,solr2a sn solr3 
> I have setup 3 instance of zookeeper in server solr 2 
> when i try to create 1 shards and 2 replica, it work find. 
> while i am try to create core with 1 shards with 3 replication,using this 
> command bin/solr create -c abc  -n abcr -shards 1 -replicationFactor 3 
> I am getting below error, 
>  ERROR: Failed to create collection 'abc' due to: 
> org.apache.solr.client.solrj.SolrServerException:IOException occured when 
> talking to server at: http://xx.yyy.zz:8985/solr (server -solr 3) 
> solr 3:) i did start this server using this command bin/solr start -cloud -p 
> 8985 -s "example/cloud/node1/solr" -z solr2:2181,solr2:2182,solr3:2183 
> what is the issue i unable to solved it. 
> I thought it is a bug in solr 5.3



--
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] [Closed] (SOLR-8361) Failed to create collection in Solrcloud

[mugeesh (JIRA)]

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

mugeesh closed SOLR-8361.
-

@Erick, yeah it was not bug, actually, there was some IP redirection of server

> Failed to create collection in Solrcloud
> 
>
> Key: SOLR-8361
> URL: https://issues.apache.org/jira/browse/SOLR-8361
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: mugeesh
> Fix For: 5.3
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Hi, 
> I am using 3 server ,solr1,solr2a sn solr3 
> I have setup 3 instance of zookeeper in server solr 2 
> when i try to create 1 shards and 2 replica, it work find. 
> while i am try to create core with 1 shards with 3 replication,using this 
> command bin/solr create -c abc  -n abcr -shards 1 -replicationFactor 3 
> I am getting below error, 
>  ERROR: Failed to create collection 'abc' due to: 
> org.apache.solr.client.solrj.SolrServerException:IOException occured when 
> talking to server at: http://xx.yyy.zz:8985/solr (server -solr 3) 
> solr 3:) i did start this server using this command bin/solr start -cloud -p 
> 8985 -s "example/cloud/node1/solr" -z solr2:2181,solr2:2182,solr3:2183 
> what is the issue i unable to solved it. 
> I thought it is a bug in solr 5.3



--
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-8361) Failed to create collection in Solrcloud

[mugeesh (JIRA)]

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

mugeesh commented on SOLR-8361:
---

@Erick, yeah it was not bug, actually, there was some IP redirection of server.

> Failed to create collection in Solrcloud
> 
>
> Key: SOLR-8361
> URL: https://issues.apache.org/jira/browse/SOLR-8361
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: mugeesh
> Fix For: 5.3
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> Hi, 
> I am using 3 server ,solr1,solr2a sn solr3 
> I have setup 3 instance of zookeeper in server solr 2 
> when i try to create 1 shards and 2 replica, it work find. 
> while i am try to create core with 1 shards with 3 replication,using this 
> command bin/solr create -c abc  -n abcr -shards 1 -replicationFactor 3 
> I am getting below error, 
>  ERROR: Failed to create collection 'abc' due to: 
> org.apache.solr.client.solrj.SolrServerException:IOException occured when 
> talking to server at: http://xx.yyy.zz:8985/solr (server -solr 3) 
> solr 3:) i did start this server using this command bin/solr start -cloud -p 
> 8985 -s "example/cloud/node1/solr" -z solr2:2181,solr2:2182,solr3:2183 
> what is the issue i unable to solved it. 
> I thought it is a bug in solr 5.3



--
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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-8251:

Fix Version/s: 5.5

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3, 5.3.1
>Reporter: wei shen
> Fix For: 5.5
>
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*=+categoryIdsPath:1001=id=0=2=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular 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] [Created] (SOLR-8364) SpellCheckComponentTest occasionally fails

[James Dyer (JIRA)]

James Dyer created SOLR-8364:


 Summary: SpellCheckComponentTest occasionally fails
 Key: SOLR-8364
 URL: https://issues.apache.org/jira/browse/SOLR-8364
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 6.0
Reporter: James Dyer
Priority: Minor


This failure did not reproduce for me in Linux or Windows with the same seed.

{quote}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5439/
: Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
: 
: 1 tests failed.
: FAILED:  org.apache.solr.handler.component.SpellCheckComponentTest.test
: 
: Error Message:
: List size mismatch @ spellcheck/suggestions
: 
: Stack Trace:
: java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
{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] [Commented] (SOLR-2556) Spellcheck component not returned with numeric queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1717795 from jd...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1717795 ]

SOLR-2556: Fix SpellingQueryConverter to recognize terms consisting only of 
digits

> Spellcheck component not returned with numeric queries
> --
>
> Key: SOLR-2556
> URL: https://issues.apache.org/jira/browse/SOLR-2556
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.1
>Reporter: Markus Jelsma
>Assignee: James Dyer
> Attachments: SOLR-2556.patch, SOLR-2556.patch
>
>
> The spell check component's output is not written when sending queries that 
> consist of numbers only. Clients depending on the availability of the 
> spellcheck output need to check if the output is actually there.
> See also:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c201105301607.41956.markus.jel...@openindex.io%3E



--
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-8347) Asynchronous searcher for custom component

[Upayavira (JIRA)]

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

Upayavira resolved SOLR-8347.
-
Resolution: Not A Problem

As I said, please ask this question on the Solr user mailing list, where 
hopefully you will find the help you are looking for. I am not aware of any 
conscious attempt to support threading within a single search request, thus 
this is *not* an issue for Solr, so it cannot be considered a bug. Please 
discuss it on the user list, and only bring it here if the discussion concludes 
some development is needed. Marking this issue as resolved, for now.

> Asynchronous searcher for custom component
> --
>
> Key: SOLR-8347
> URL: https://issues.apache.org/jira/browse/SOLR-8347
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Bogdan Marinescu
>Priority: Critical
>
> I'm trying to write a custom component for fuzzy searches. 
> After solr calls my component, I create a Thread and give it the 
> SolrIndexSearcher and some params.
> Problem is after a few seconds I get an Exception that the indexreader was 
> closed 
> {code}
> org.apache.lucene.store.AlreadyClosedException: this IndexReader cannot be 
> used anymore as one of its child readers was closed
> at 
> org.apache.lucene.index.IndexReader.ensureOpen(IndexReader.java:279)
> at 
> org.apache.lucene.index.FilterLeafReader.getLiveDocs(FilterLeafReader.java:374)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:768)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:485)
> at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:202)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1666)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1485)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:561)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocList(SolrIndexSearcher.java:1350)
> at 
> awinta.mdm.solr.components.FuzzyLikeThisComponent$FLTHelper.getLikeThis(FuzzyLikeThisComponent.java:336)
> at 
> awinta.mdm.solr.components.FLTWorker.getLikeThese(FLTWorker.java:161)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:94)
> at awinta.mdm.solr.components.FLTWorker.call(FLTWorker.java:35)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> {code}
> Is there a way of locking the IndexReader so it doesn't get closed by other 
> threads? 



--
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-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4116:
---

Looks like with tomcat you have to crank the unloadDelay for the webapp context 
to be sure there is enough time for the final commit and the shutdown stuff 
that could take a while.

> Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException
> -
>
> Key: SOLR-4116
> URL: https://issues.apache.org/jira/browse/SOLR-4116
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.1
> Environment: 5.0.0.2012.11.28.10.42.06
> Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
>Reporter: Markus Jelsma
> Fix For: 5.4, Trunk
>
>
> With SOLR-4032 fixed we see other issues when randomly taking down nodes 
> (nicely via tomcat restart) while indexing a few million web pages from 
> Hadoop. We do make sure that at least one node is up for a shard but due to 
> recovery issues it may not be live.
> {code}
> 2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : Starting log replay 
> tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
> refcount=2} active=false starting pos=0
> 2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : java.io.EOFException
> at 
> org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
> at 
> org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
> at 
> org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
> at 
> org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}



--
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-2649) MM ignored in edismax queries with operators

[James Bown (JIRA)]

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

James Bown commented on SOLR-2649:
--

A high criticality bug for me too...

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
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-6889) BooleanQuery.rewrite could easily optimize some simple cases

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6889.
--
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> BooleanQuery.rewrite could easily optimize some simple cases
> 
>
> Key: LUCENE-6889
> URL: https://issues.apache.org/jira/browse/LUCENE-6889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: LUCENE-6889.patch, LUCENE-6889.patch
>
>
> Follow-up of SOLR-8251: APIs and user interfaces sometimes encourage to write 
> BooleanQuery instances that are not optimal, for instance a typical case that 
> happens often with Solr/Elasticsearch is to send a request that has a 
> MatchAllDocsQuery as a query and some filter, which could be executed more 
> efficiently by directly wrapping the filter into a ConstantScoreQuery.
> Here are some ideas of rewrite operations that BooleanQuery could perform:
>  - remove FILTER clauses when they are also a MUST clause
>  - rewrite queries of the form "+*:* #filter" to a ConstantScoreQuery(filter)
>  - rewrite to a MatchNoDocsQuery when a clause that is a MUST or FILTER 
> clause is also a MUST_NOT clause



--
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-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5205:
-

Plan b... you can also escape with {{\}}

{{"understanding \(span query\)"}}

or for a token {{sp'an}}:

{{"understanding \(sp\'an query\)"}}

Was this not working for you?

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
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-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-4116:
--

_May_ be related, adding link just in case.

> Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException
> -
>
> Key: SOLR-4116
> URL: https://issues.apache.org/jira/browse/SOLR-4116
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.1
> Environment: 5.0.0.2012.11.28.10.42.06
> Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
>Reporter: Markus Jelsma
> Fix For: 5.4, Trunk
>
>
> With SOLR-4032 fixed we see other issues when randomly taking down nodes 
> (nicely via tomcat restart) while indexing a few million web pages from 
> Hadoop. We do make sure that at least one node is up for a shard but due to 
> recovery issues it may not be live.
> {code}
> 2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : Starting log replay 
> tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
> refcount=2} active=false starting pos=0
> 2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : java.io.EOFException
> at 
> org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
> at 
> org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
> at 
> org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
> at 
> org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}



--
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-8364) SpellCheckComponentTest occasionally fails

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-8364:
--

: Date: Wed, 2 Dec 2015 16:20:52 -0600
: From: "Dyer, James" 
: Reply-To: dev@lucene.apache.org
: To: "dev@lucene.apache.org" 
: Subject: RE: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_66) - Build #
:  5439 - Failure!
: 
: I'm looking at this failure.  I cannot reproduce this on Linux using:
: 
: ant test -Dtests.class="*.SpellCheckComponentTest" 
-Dtests.seed=110D525A21D16B1:8944EAFF0CE17B49


James - not sure if you noticed but assertJQ logs the entire response when 
an assertion fails...

   [junit4]   2>  
expected=/spellcheck=={'suggestions':['documemt',{'numFound':1,'startOffset':0,'endOffset':8,'suggestion':['document']}]}
   [junit4]   2>  response = {
   [junit4]   2>   "responseHeader":{
   [junit4]   2> "status":0,
   [junit4]   2> "QTime":0},
   [junit4]   2>   "response":{"numFound":0,"start":0,"docs":[]
   [junit4]   2>   },
   [junit4]   2>   "spellcheck":{
   [junit4]   2> "suggestions":[]}}
   [junit4]   2>
   [junit4]   2>  request = 
q=documemt=spellCheckCompRH=true=xml

...I haven't dug into the code being tested, or even the logs from 
jenkins, but if it's rebuilding any spellcheck structures in a newSearcher 
listener, then maybe that's slowing down opening the searcher so that when 
the test is run the docs (and suggestions) aren't always visible yet?

maybe try adding a waitSearcher=true to the commit() calls?  or switch to 
some explicitly blocking client call to generate those spellcheck 
structures/indexes?


> SpellCheckComponentTest occasionally fails
> --
>
> Key: SOLR-8364
> URL: https://issues.apache.org/jira/browse/SOLR-8364
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 6.0
>Reporter: James Dyer
>Priority: Minor
>
> This failure did not reproduce for me in Linux or Windows with the same seed.
> {quote}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5439/
> : Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
> : 
> : 1 tests failed.
> : FAILED:  org.apache.solr.handler.component.SpellCheckComponentTest.test
> : 
> : Error Message:
> : List size mismatch @ spellcheck/suggestions
> : 
> : Stack Trace:
> : java.lang.RuntimeException: List size mismatch @ spellcheck/suggestions
> {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] [Commented] (SOLR-4116) Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-4116:
---

Hmm...that for how long a request can finish, but this stuff should be how long 
it allows for filter#destroy I think. Jetty has a setting for this if I recall 
correctly, but not finding tomcats version.

> Log Replay [recoveryExecutor-8-thread-1] - : java.io.EOFException
> -
>
> Key: SOLR-4116
> URL: https://issues.apache.org/jira/browse/SOLR-4116
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.1
> Environment: 5.0.0.2012.11.28.10.42.06
> Debian Squeeze, Tomcat 6, Sun Java 6, 10 nodes, 10 shards, rep. factor 2.
>Reporter: Markus Jelsma
> Fix For: 5.4, Trunk
>
>
> With SOLR-4032 fixed we see other issues when randomly taking down nodes 
> (nicely via tomcat restart) while indexing a few million web pages from 
> Hadoop. We do make sure that at least one node is up for a shard but due to 
> recovery issues it may not be live.
> {code}
> 2012-11-28 11:32:33,086 WARN [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : Starting log replay 
> tlog{file=/opt/solr/cores/openindex_e/data/tlog/tlog.028 
> refcount=2} active=false starting pos=0
> 2012-11-28 11:32:41,873 ERROR [solr.update.UpdateLog] - 
> [recoveryExecutor-8-thread-1] - : java.io.EOFException
> at 
> org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:151)
> at 
> org.apache.solr.common.util.JavaBinCodec.readStr(JavaBinCodec.java:479)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:176)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:374)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:225)
> at 
> org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:451)
> at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:182)
> at 
> org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:618)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1198)
> at 
> org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1143)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {code}



--
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-6889) BooleanQuery.rewrite could easily optimize some simple cases

[ASF subversion and git services (JIRA)]

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

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

Commit 1717782 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717782 ]

LUCENE-6889: Add some basic rewrite rules to BooleanQuery that can make it run 
significantly faster in some cases.

> BooleanQuery.rewrite could easily optimize some simple cases
> 
>
> Key: LUCENE-6889
> URL: https://issues.apache.org/jira/browse/LUCENE-6889
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6889.patch, LUCENE-6889.patch
>
>
> Follow-up of SOLR-8251: APIs and user interfaces sometimes encourage to write 
> BooleanQuery instances that are not optimal, for instance a typical case that 
> happens often with Solr/Elasticsearch is to send a request that has a 
> MatchAllDocsQuery as a query and some filter, which could be executed more 
> efficiently by directly wrapping the filter into a ConstantScoreQuery.
> Here are some ideas of rewrite operations that BooleanQuery could perform:
>  - remove FILTER clauses when they are also a MUST clause
>  - rewrite queries of the form "+*:* #filter" to a ConstantScoreQuery(filter)
>  - rewrite to a MatchNoDocsQuery when a clause that is a MUST or FILTER 
> clause is also a MUST_NOT clause



--
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-2556) Spellcheck component not returned with numeric queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1717796 from jd...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1717796 ]

SOLR-2556: Fix SpellingQueryConverter to recognize terms consisting only of 
digits

> Spellcheck component not returned with numeric queries
> --
>
> Key: SOLR-2556
> URL: https://issues.apache.org/jira/browse/SOLR-2556
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.1
>Reporter: Markus Jelsma
>Assignee: James Dyer
> Attachments: SOLR-2556.patch, SOLR-2556.patch
>
>
> The spell check component's output is not written when sending queries that 
> consist of numbers only. Clients depending on the availability of the 
> spellcheck output need to check if the output is actually there.
> See also:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201105.mbox/%3c201105301607.41956.markus.jel...@openindex.io%3E



--
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