[jira] [Commented] (SOLR-7154) Wildcard query matches special characters

[Arun Rangarajan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335452#comment-14335452
 ] 

Arun Rangarajan commented on SOLR-7154:
---

Right, that seems to be the issue. I added another document with Latin small 
letter with acute and that document does not match the wild-card query. So I 
think this needs to be fixed in my data source itself.

 Wildcard query matches special characters
 -

 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor

 I have a string field raw_name defined like this:
 {code}
 fieldType name=string class=solr.StrField sortMissingLast=true 
 omitNorms=true/
 ...
 field name=raw_name type=string indexed=true stored=true /
 {code}
 I have a document like this:
 {code}
 {raw_name: beyoncé}
 {code}
 Notice that the last character is a special character (accented e).
 When I issue this wildcard query:
 {code}
 q=raw_name:beyonce*
 {code}
 i.e. with the last character simply being the ASCII 'e', Solr returns me the 
 above document.
 Exact query:
 {code}
 /select?q=raw_name:beyonce*wt=jsonfl=raw_name
 {code}
 Response:
 {code}
 {
   responseHeader: {
 status: 0,
 QTime: 0,
 params: {
   fl: raw_name,
   q: raw_name:beyonce*,
   wt: json
 }
   },
   response: {
 numFound: 2,
 start: 0,
 docs: [
   {
 raw_name: beyoncé
   },
   {
 raw_name: beyoncé
   }
 ]
   }
 }
 {code}
 I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
 this:
 Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
 Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]
 So when you look at the bytes, it seems to explain why beyonce* might match 
 beyoncé.



--
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-7155) Add an optional 'collection' parameter to all SolrClient methods

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-7155:
---

 Summary: Add an optional 'collection' parameter to all SolrClient 
methods
 Key: SOLR-7155
 URL: https://issues.apache.org/jira/browse/SOLR-7155
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
 Fix For: 5.1


As discussed on SOLR-7127.



--
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-7154) Wildcard query matches special characters

[Toke Eskildsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335381#comment-14335381
 ] 

Toke Eskildsen commented on SOLR-7154:
--

To quote Steve Jobs: You are holding it wrong: Your Beyoncé should be 
Beyoncé.

The difference between the two e's is that the first one has the ping added 
with the unicode Combining acute accent 
(http://www.fileformat.info/info/unicode/char/0301/index.htm), while the second 
one is a Latin small letter with acute 
(http://www.fileformat.info/info/unicode/char/e9/index.htm).

A proper normalizer would convert é and é into the same character, but you are 
using the raw string, so you do not have that luxury. If you use a text field, 
you can avoid this by normalising into letters with build-in diacritics (as 
opposed to letters followed with combining diacritics). Unfortunately that does 
not work well if the user query contains a truncation with combining 
diacritics, as truncated queries are not normalized (which I think they should, 
but that is a matter for another JIRA).

 Wildcard query matches special characters
 -

 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor

 I have a string field raw_name defined like this:
 {code}
 fieldType name=string class=solr.StrField sortMissingLast=true 
 omitNorms=true/
 ...
 field name=raw_name type=string indexed=true stored=true /
 {code}
 I have a document like this:
 {code}
 {raw_name: beyoncé}
 {code}
 Notice that the last character is a special character (accented e).
 When I issue this wildcard query:
 {code}
 q=raw_name:beyonce*
 {code}
 i.e. with the last character simply being the ASCII 'e', Solr returns me the 
 above document.
 Exact query:
 {code}
 /select?q=raw_name:beyonce*wt=jsonfl=raw_name
 {code}
 Response:
 {code}
 {
   responseHeader: {
 status: 0,
 QTime: 0,
 params: {
   fl: raw_name,
   q: raw_name:beyonce*,
   wt: json
 }
   },
   response: {
 numFound: 2,
 start: 0,
 docs: [
   {
 raw_name: beyoncé
   },
   {
 raw_name: beyoncé
   }
 ]
   }
 }
 {code}
 I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
 this:
 Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
 Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]
 So when you look at the bytes, it seems to explain why beyonce* might match 
 beyoncé.



--
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-6291) Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335377#comment-14335377
 ] 

Ryan Ernst commented on LUCENE-6291:


+1

 Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator
 ---

 Key: LUCENE-6291
 URL: https://issues.apache.org/jira/browse/LUCENE-6291
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1


 TwoPhaseDocIdSetIterator is a bit long to type while TwoPhaseIterator already 
 accurately describes what this class does?



--
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-6285) test seeds are not reproducing.

[Dawid Weiss (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335414#comment-14335414
 ] 

Dawid Weiss commented on LUCENE-6285:
-

I'm currently on vacation but if you can provide more context perhaps I'll be 
able to figure it out when I'm back.

The simplest way to check what's going on would be to add a sysout with 
nextInt() at certain checkpoints; they should be consistent for the same 
starting seed.

 test seeds are not reproducing.
 ---

 Key: LUCENE-6285
 URL: https://issues.apache.org/jira/browse/LUCENE-6285
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 even for very simple tests.



--
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-6287) Corrupt index (missing .si file) on first 4.x commit to a 3.x index

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335348#comment-14335348
 ] 

Robert Muir commented on LUCENE-6287:
-

looks good. Thanks for tracking this down!

 Corrupt index (missing .si file) on first 4.x commit to a 3.x index
 ---

 Key: LUCENE-6287
 URL: https://issues.apache.org/jira/browse/LUCENE-6287
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Blocker
 Fix For: 4.10.4

 Attachments: LUCENE-6287.patch, LUCENE-6287.patch


 If you have a 3.x index, and you open it with a 4.x IndexWriter for
 the first time, and you do something that kicks of merges while
 concurrently committing, it's possible the index will corrupt itself
 with exceptions like this:
 {noformat}
 java.nio.file.NoSuchFileException: 
 /l/tmp/reruns.TestBackwardsCompatibility3x.testMergeDuringUpgrade.t2/lucene.index.TestBackwardsCompatibility3x-71F31CCCEF6853A-001/manysegments.362-006/_0.si
   at 
 sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
   at 
 sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
   at java.nio.channels.FileChannel.open(FileChannel.java:287)
   at java.nio.channels.FileChannel.open(FileChannel.java:334)
   at 
 org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
   at 
 org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80)
   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.read(Lucene3xSegmentInfoReader.java:106)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:358)
   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:454)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:906)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:752)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:457)
   at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:414)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:196)
   at 
 org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
   at 
 org.apache.lucene.index.TestBackwardsCompatibility3x.testMergeDuringUpgrade(TestBackwardsCompatibility3x.java:1035)
 {noformat}
 Back compat tests in Elasticsearch hit this, and at first I thought maybe 
 LUCENE-6279 was the cause (I still think we should fix that) but after 
 further debugging there is a different concurrency bug lurking here.
 I have a test case which after substantial beasting is able to reproduce the 
 bug, but I don't yet have a fix.  I think IW is missing a checkpoint after 
 writing a new commit...



--
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-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335427#comment-14335427
 ] 

Darren Hardy commented on SOLR-7153:


We need all our field data marked stored=true to use the Atomic Update feature, 
which requires everything to be stored so it can reconstruct the document to 
re-index. My understanding here is tenuous but my workaround just specifies the 
__minX, __minY, etc. fields because of the ERROR exception not recognizing 
them. 

Ideally I want the original configuration that's on the wiki only changing it 
so that *_bbox is a dynamic field that's stored, rather than a declared field 
for abcd_bbox.

 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
 {noformat}
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 {noformat}
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 {noformat}
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 

[jira] [Commented] (LUCENE-6287) Corrupt index (missing .si file) on first 4.x commit to a 3.x index

[Simon Willnauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335512#comment-14335512
 ] 

Simon Willnauer commented on LUCENE-6287:
-

LGTM +1 to commit

 Corrupt index (missing .si file) on first 4.x commit to a 3.x index
 ---

 Key: LUCENE-6287
 URL: https://issues.apache.org/jira/browse/LUCENE-6287
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Blocker
 Fix For: 4.10.4

 Attachments: LUCENE-6287.patch, LUCENE-6287.patch


 If you have a 3.x index, and you open it with a 4.x IndexWriter for
 the first time, and you do something that kicks of merges while
 concurrently committing, it's possible the index will corrupt itself
 with exceptions like this:
 {noformat}
 java.nio.file.NoSuchFileException: 
 /l/tmp/reruns.TestBackwardsCompatibility3x.testMergeDuringUpgrade.t2/lucene.index.TestBackwardsCompatibility3x-71F31CCCEF6853A-001/manysegments.362-006/_0.si
   at 
 sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
   at 
 sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
   at java.nio.channels.FileChannel.open(FileChannel.java:287)
   at java.nio.channels.FileChannel.open(FileChannel.java:334)
   at 
 org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
   at 
 org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80)
   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.read(Lucene3xSegmentInfoReader.java:106)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:358)
   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:454)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:906)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:752)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:457)
   at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:414)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:196)
   at 
 org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
   at 
 org.apache.lucene.index.TestBackwardsCompatibility3x.testMergeDuringUpgrade(TestBackwardsCompatibility3x.java:1035)
 {noformat}
 Back compat tests in Elasticsearch hit this, and at first I thought maybe 
 LUCENE-6279 was the cause (I still think we should fix that) but after 
 further debugging there is a different concurrency bug lurking here.
 I have a test case which after substantial beasting is able to reproduce the 
 bug, but I don't yet have a fix.  I think IW is missing a checkpoint after 
 writing a new commit...



--
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] Lucene-Solr-SmokeRelease-5.0 - Build # 39 - Still Failing

[Robert Muir]

I disabled this job because it is testing the 5.0 branch.

On Tue, Feb 24, 2015 at 2:31 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.0/39/

 No tests ran.

 Build Log:
 [...truncated 51662 lines...]
 prepare-release-no-sign:
 [mkdir] Created dir: 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist
  [copy] Copying 446 files to 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/lucene
  [copy] Copying 245 files to 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/solr
[smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
[smoker] NOTE: output encoding is US-ASCII
[smoker]
[smoker] Load release URL 
 file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/...
[smoker]
[smoker] Test Lucene...
[smoker]   test basics...
[smoker]   get KEYS
[smoker] 0.1 MB in 0.01 sec (14.6 MB/sec)
[smoker]   check changes HTML...
[smoker]   download lucene-5.0.0-src.tgz...
[smoker] 27.9 MB in 0.04 sec (713.6 MB/sec)
[smoker] verify md5/sha1 digests
[smoker]   download lucene-5.0.0.tgz...
[smoker] 64.0 MB in 0.09 sec (730.3 MB/sec)
[smoker] verify md5/sha1 digests
[smoker]   download lucene-5.0.0.zip...
[smoker] 73.6 MB in 0.07 sec (998.1 MB/sec)
[smoker] verify md5/sha1 digests
[smoker]   unpack lucene-5.0.0.tgz...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker]   got 5647 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker]   unpack lucene-5.0.0.zip...
[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
[smoker] test demo with 1.7...
[smoker]   got 5647 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] check Lucene's javadoc JAR
[smoker]   unpack lucene-5.0.0-src.tgz...
[smoker] make sure no JARs/WARs in src dist...
[smoker] run ant validate
[smoker] run tests w/ Java 7 and 
 testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1 
 -Dtests.slow=false'...
[smoker] test demo with 1.7...
[smoker]   got 210 hits for query lucene
[smoker] checkindex with 1.7...
[smoker] generate javadocs w/ Java 7...
[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] Releases that don't seem to be tested:
[smoker]   5.0.0
[smoker] Traceback (most recent call last):
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 1535, in module
[smoker] main()
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 1480, in main
[smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
 c.is_signed, ' '.join(c.test_args))
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 1518, in smokeTest
[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
 version, svnRevision, version, testArgs, baseURL)
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 628, in unpackAndVerify
[smoker] verifyUnpacked(java, project, artifact, unpackPath, 
 svnRevision, version, testArgs, tmpDir, baseURL)
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 809, in verifyUnpacked
[smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
[smoker]   File 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
  line 1473, in confirmAllReleasesAreTestedForBackCompat
[smoker] raise RuntimeError('some releases are not tested by 
 TestBackwardsCompatibility?')
[smoker] RuntimeError: some releases are not tested by 
 TestBackwardsCompatibility?

 BUILD FAILED
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/build.xml:414:
  exec returned: 1

 Total time: 43 minutes 5 seconds
 Build step 'Invoke Ant' marked build as failure
 Email was triggered for: Failure
 Sending email for trigger: Failure




 -
 To 

Re: [JENKINS] Lucene-Solr-SmokeRelease-5.0 - Build # 39 - Still Failing

[Anshum Gupta]

Thanks Robert!

On Tue, Feb 24, 2015 at 11:40 AM, Robert Muir rcm...@gmail.com wrote:

 I disabled this job because it is testing the 5.0 branch.

 On Tue, Feb 24, 2015 at 2:31 PM, Apache Jenkins Server
 jenk...@builds.apache.org wrote:
  Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.0/39/
 
  No tests ran.
 
  Build Log:
  [...truncated 51662 lines...]
  prepare-release-no-sign:
  [mkdir] Created dir:
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist
   [copy] Copying 446 files to
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/lucene
   [copy] Copying 245 files to
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/solr
 [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
 [smoker] NOTE: output encoding is US-ASCII
 [smoker]
 [smoker] Load release URL
 file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/...
 [smoker]
 [smoker] Test Lucene...
 [smoker]   test basics...
 [smoker]   get KEYS
 [smoker] 0.1 MB in 0.01 sec (14.6 MB/sec)
 [smoker]   check changes HTML...
 [smoker]   download lucene-5.0.0-src.tgz...
 [smoker] 27.9 MB in 0.04 sec (713.6 MB/sec)
 [smoker] verify md5/sha1 digests
 [smoker]   download lucene-5.0.0.tgz...
 [smoker] 64.0 MB in 0.09 sec (730.3 MB/sec)
 [smoker] verify md5/sha1 digests
 [smoker]   download lucene-5.0.0.zip...
 [smoker] 73.6 MB in 0.07 sec (998.1 MB/sec)
 [smoker] verify md5/sha1 digests
 [smoker]   unpack lucene-5.0.0.tgz...
 [smoker] verify JAR metadata/identity/no javax.* or java.*
 classes...
 [smoker] test demo with 1.7...
 [smoker]   got 5647 hits for query lucene
 [smoker] checkindex with 1.7...
 [smoker] check Lucene's javadoc JAR
 [smoker]   unpack lucene-5.0.0.zip...
 [smoker] verify JAR metadata/identity/no javax.* or java.*
 classes...
 [smoker] test demo with 1.7...
 [smoker]   got 5647 hits for query lucene
 [smoker] checkindex with 1.7...
 [smoker] check Lucene's javadoc JAR
 [smoker]   unpack lucene-5.0.0-src.tgz...
 [smoker] make sure no JARs/WARs in src dist...
 [smoker] run ant validate
 [smoker] run tests w/ Java 7 and
 testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1
 -Dtests.slow=false'...
 [smoker] test demo with 1.7...
 [smoker]   got 210 hits for query lucene
 [smoker] checkindex with 1.7...
 [smoker] generate javadocs w/ Java 7...
 [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] Releases that don't seem to be tested:
 [smoker]   5.0.0
 [smoker] Traceback (most recent call last):
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1535, in module
 [smoker] main()
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1480, in main
 [smoker] smokeTest(c.java, c.url, c.revision, c.version,
 c.tmp_dir, c.is_signed, ' '.join(c.test_args))
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1518, in smokeTest
 [smoker] unpackAndVerify(java, 'lucene', tmpDir,
 'lucene-%s-src.tgz' % version, svnRevision, version, testArgs, baseURL)
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 628, in unpackAndVerify
 [smoker] verifyUnpacked(java, project, artifact, unpackPath,
 svnRevision, version, testArgs, tmpDir, baseURL)
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 809, in verifyUnpacked
 [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
 [smoker]   File
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1473, in confirmAllReleasesAreTestedForBackCompat
 [smoker] raise RuntimeError('some releases are not tested by
 TestBackwardsCompatibility?')
 [smoker] RuntimeError: some releases are not tested by
 TestBackwardsCompatibility?
 
  BUILD FAILED
 
 /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/build.xml:414:
 exec returned: 1
 
  Total time: 43 minutes 5 seconds
  Build step 'Invoke Ant' marked build as failure
  Email 

[jira] [Commented] (SOLR-6581) Efficient DocValues support and numeric collapse field implementations for Collapse and Expand

[Dallan Quass (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335405#comment-14335405
 ] 

Dallan Quass commented on SOLR-6581:


Any ideas how much slower numeric collapse/expand implementation is than string 
collapse/expand with the top_fc hint? I'm trying to decide if I should re-index 
my int collapse field as a string. (I don't care about real-time performance.)

 Efficient DocValues support and numeric collapse field implementations for 
 Collapse and Expand
 --

 Key: SOLR-6581
 URL: https://issues.apache.org/jira/browse/SOLR-6581
 Project: Solr
  Issue Type: Bug
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
 SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
 SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
 SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, SOLR-6581.patch, 
 renames.diff


 The 4x implementation of the CollapsingQParserPlugin and the ExpandComponent 
 are optimized to work with a top level FieldCache. Top level FieldCaches have 
 a very fast docID to top-level ordinal lookup. Fast access to the top-level 
 ordinals allows for very high performance field collapsing on high 
 cardinality fields. 
 LUCENE-5666 unified the DocValues and FieldCache api's so that the top level 
 FieldCache is no longer in regular use. Instead all top level caches are 
 accessed through MultiDocValues. 
 This ticket does the following:
 1) Optimizes Collapse and Expand to use MultiDocValues and makes this the 
 default approach when collapsing on String fields
 2) Provides an option to use a top level FieldCache if the performance of 
 MultiDocValues is a blocker. The mechanism for switching to the FieldCache is 
 a new hint parameter. If the hint parameter is set to top_fc then the 
 top-level FieldCache would be used for both Collapse and Expand.
 Example syntax:
 {code}
 fq={!collapse field=x hint=TOP_FC}
 {code}
 3)  Adds numeric collapse field implementations.
 4) Resolves issue SOLR-6066
  



--
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-7153) BBoxField with dynamic fields yield error

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335430#comment-14335430
 ] 

David Smiley commented on SOLR-7153:


Have you tried an atomic-update of a BBoxField that is stored (but it's 
coordinate values aren't)?  I haven't tried that before but I venture to guess 
it would work because the FieldType handles this mapping of it's stored value 
to these sub-fields, and the atomic update feature I think works above that.

 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
 {noformat}
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 {noformat}
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 {noformat}
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
   at 
 

[jira] [Commented] (SOLR-7154) Wildcard query matches special characters

[Arun Rangarajan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335436#comment-14335436
 ] 

Arun Rangarajan commented on SOLR-7154:
---

I had initially done this on Solr 4.2.1. After seeing your comment, I tried the 
same on Solr 5.0.0 and it gives the same results.

 Wildcard query matches special characters
 -

 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor

 I have a string field raw_name defined like this:
 {code}
 fieldType name=string class=solr.StrField sortMissingLast=true 
 omitNorms=true/
 ...
 field name=raw_name type=string indexed=true stored=true /
 {code}
 I have a document like this:
 {code}
 {raw_name: beyoncé}
 {code}
 Notice that the last character is a special character (accented e).
 When I issue this wildcard query:
 {code}
 q=raw_name:beyonce*
 {code}
 i.e. with the last character simply being the ASCII 'e', Solr returns me the 
 above document.
 Exact query:
 {code}
 /select?q=raw_name:beyonce*wt=jsonfl=raw_name
 {code}
 Response:
 {code}
 {
   responseHeader: {
 status: 0,
 QTime: 0,
 params: {
   fl: raw_name,
   q: raw_name:beyonce*,
   wt: json
 }
   },
   response: {
 numFound: 2,
 start: 0,
 docs: [
   {
 raw_name: beyoncé
   },
   {
 raw_name: beyoncé
   }
 ]
   }
 }
 {code}
 I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
 this:
 Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
 Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]
 So when you look at the bytes, it seems to explain why beyonce* might match 
 beyoncé.



--
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-6287) Corrupt index (missing .si file) on first 4.x commit to a 3.x index

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6287:
---
Attachment: LUCENE-6287.patch

Patch w/ a simple fix ... I'm beasting the test and so far so good ... I'll 
leave it running.

IW already holds an incRef'd set of files that are in-flight for commit, so I 
just fixed it to re-compute that set after SIS.prepareCommit (which may write 
the .si/marker files) and incRef the new set with IFD.  This protects them 
while the commit runs, and then when the commit finishes we incRef them with 
IFD again and they are permanent after that.


 Corrupt index (missing .si file) on first 4.x commit to a 3.x index
 ---

 Key: LUCENE-6287
 URL: https://issues.apache.org/jira/browse/LUCENE-6287
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Blocker
 Fix For: 4.10.4

 Attachments: LUCENE-6287.patch, LUCENE-6287.patch


 If you have a 3.x index, and you open it with a 4.x IndexWriter for
 the first time, and you do something that kicks of merges while
 concurrently committing, it's possible the index will corrupt itself
 with exceptions like this:
 {noformat}
 java.nio.file.NoSuchFileException: 
 /l/tmp/reruns.TestBackwardsCompatibility3x.testMergeDuringUpgrade.t2/lucene.index.TestBackwardsCompatibility3x-71F31CCCEF6853A-001/manysegments.362-006/_0.si
   at 
 sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
   at 
 sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
   at java.nio.channels.FileChannel.open(FileChannel.java:287)
   at java.nio.channels.FileChannel.open(FileChannel.java:334)
   at 
 org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
   at 
 org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80)
   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.read(Lucene3xSegmentInfoReader.java:106)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:358)
   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:454)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:906)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:752)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:457)
   at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:414)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:196)
   at 
 org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
   at 
 org.apache.lucene.index.TestBackwardsCompatibility3x.testMergeDuringUpgrade(TestBackwardsCompatibility3x.java:1035)
 {noformat}
 Back compat tests in Elasticsearch hit this, and at first I thought maybe 
 LUCENE-6279 was the cause (I still think we should fix that) but after 
 further debugging there is a different concurrency bug lurking here.
 I have a test case which after substantial beasting is able to reproduce the 
 bug, but I don't yet have a fix.  I think IW is missing a checkpoint after 
 writing a new commit...



--
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-7153) BBoxField with dynamic fields yield error

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335338#comment-14335338
 ] 

David Smiley commented on SOLR-7153:


This looks like a bug (the exception).  Although the part about _bbox_coord 
having its stored=true part being ignored, if I recall my thinking at the time, 
is by design. That's not a big deal though; it could be changed. Why do you 
want the underlying coordinates separated vs. marking the bbox field as stored? 
 It's redundant.

 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
 {noformat}
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 {noformat}
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 {noformat}
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
   at 
 

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b47) - Build # 11870 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11870/
Java: 64bit/jdk1.9.0-ea-b47 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest

Error Message:
{responseHeader={status=0, QTime=1}, response={numFound=0, start=0, docs=[]}}

Stack Trace:
java.lang.AssertionError: {responseHeader={status=0, QTime=1}, 
response={numFound=0, start=0, docs=[]}}
at 
__randomizedtesting.SeedInfo.seed([D3FAA081C09DB7D0:333B82D37B71C122]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestBlobHandler.doBlobHandlerTest(TestBlobHandler.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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 

[jira] [Commented] (LUCENE-6285) test seeds are not reproducing.

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335459#comment-14335459
 ] 

Robert Muir commented on LUCENE-6285:
-

Sorry, the problem that caused me to open it was 
http://svn.apache.org/viewvc?view=revisionrevision=1661945

These tests are pretty basic, single-threaded, and it was frustrating that it 
didn't reproduce. 

The bug in the test was around LUCENE-6265, and it wouldnt surprise me if that 
code is causing the issue.

 test seeds are not reproducing.
 ---

 Key: LUCENE-6285
 URL: https://issues.apache.org/jira/browse/LUCENE-6285
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir

 even for very simple tests.



--
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-7154) Wildcard query matches special characters

[Alexandre Rafalovitch (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335460#comment-14335460
 ] 

Alexandre Rafalovitch commented on SOLR-7154:
-

Either in data source itself or by switching to a text analyzer with 
KeywordTokenizer and ICU normalization in the pipeline. Still need to be 
careful with multi-word expansion, you may need to define *multiterm* chain 
explicitly as well (needs to be tested).

Regards,
  Alex.

 Wildcard query matches special characters
 -

 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor

 I have a string field raw_name defined like this:
 {code}
 fieldType name=string class=solr.StrField sortMissingLast=true 
 omitNorms=true/
 ...
 field name=raw_name type=string indexed=true stored=true /
 {code}
 I have a document like this:
 {code}
 {raw_name: beyoncé}
 {code}
 Notice that the last character is a special character (accented e).
 When I issue this wildcard query:
 {code}
 q=raw_name:beyonce*
 {code}
 i.e. with the last character simply being the ASCII 'e', Solr returns me the 
 above document.
 Exact query:
 {code}
 /select?q=raw_name:beyonce*wt=jsonfl=raw_name
 {code}
 Response:
 {code}
 {
   responseHeader: {
 status: 0,
 QTime: 0,
 params: {
   fl: raw_name,
   q: raw_name:beyonce*,
   wt: json
 }
   },
   response: {
 numFound: 2,
 start: 0,
 docs: [
   {
 raw_name: beyoncé
   },
   {
 raw_name: beyoncé
   }
 ]
   }
 }
 {code}
 I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
 this:
 Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
 Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]
 So when you look at the bytes, it seems to explain why beyonce* might match 
 beyoncé.



--
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-7154) Wildcard query matches special characters

[Arun Rangarajan (JIRA)]

Arun Rangarajan created SOLR-7154:
-

 Summary: Wildcard query matches special characters
 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor


I have a string field raw_name defined like this:

{code}
fieldType name=string class=solr.StrField sortMissingLast=true 
omitNorms=true/
...
field name=raw_name type=string indexed=true stored=true /
{code}

I have a document like this:
{code}
{raw_name: beyoncé}
{code}
Notice that the last character is a special character (accented e).

When I issue this wildcard query:
{code}
q=raw_name:beyonce*
{code}
i.e. with the last character simply being the ASCII 'e', Solr returns me the 
above document.

Exact query:
{code}
/select?q=raw_name:beyonce*wt=jsonfl=raw_name
{code}

Response:

{code}
{
  responseHeader: {
status: 0,
QTime: 0,
params: {
  fl: raw_name,
  q: raw_name:beyonce*,
  wt: json
}
  },
  response: {
numFound: 2,
start: 0,
docs: [
  {
raw_name: beyoncé
  },
  {
raw_name: beyoncé
  }
]
  }
}
{code}

I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
this:

Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]

So when you look at the bytes, it seems to explain why beyonce* might match 
beyoncé.




--
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-7155) Add an optional 'collection' parameter to all SolrClient methods

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-7155:

Attachment: SOLR-7155.patch

Patch.  Requires the patches from SOLR-7145 and SOLR-7151 to be applied first.

This just adds the capability to select a collection at query time to 
CloudSolrClient.  For HttpSolrClient it's a no-op, although that should be easy 
enough to add in a follow up issue.  I've also added better javadocs to 
SolrClient, and moved some methods that were only in HttpSolrClient up to the 
base class.

All tests pass.

 Add an optional 'collection' parameter to all SolrClient methods
 

 Key: SOLR-7155
 URL: https://issues.apache.org/jira/browse/SOLR-7155
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
 Fix For: 5.1

 Attachments: SOLR-7155.patch


 As discussed on SOLR-7127.



--
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-Tests-5.x-Java7 - Build # 2670 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2670/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:41851/u_uj/kp/c8n_1x2_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:41851/u_uj/kp/c8n_1x2_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([A9CDA0A098B4B564:21999F7A3648D89C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:597)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:906)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:809)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 

[jira] [Commented] (SOLR-7154) Wildcard query matches special characters

[Alexandre Rafalovitch (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335379#comment-14335379
 ] 

Alexandre Rafalovitch commented on SOLR-7154:
-

Which version of Solr is this against. This needs to be tested against version 
5 or at least 4.10.3 to be actionable.

Also, the definition of the bug seems simple enough to build a simple complete 
use case. Would be useful to have that.

 Wildcard query matches special characters
 -

 Key: SOLR-7154
 URL: https://issues.apache.org/jira/browse/SOLR-7154
 Project: Solr
  Issue Type: Bug
Reporter: Arun Rangarajan
Priority: Minor

 I have a string field raw_name defined like this:
 {code}
 fieldType name=string class=solr.StrField sortMissingLast=true 
 omitNorms=true/
 ...
 field name=raw_name type=string indexed=true stored=true /
 {code}
 I have a document like this:
 {code}
 {raw_name: beyoncé}
 {code}
 Notice that the last character is a special character (accented e).
 When I issue this wildcard query:
 {code}
 q=raw_name:beyonce*
 {code}
 i.e. with the last character simply being the ASCII 'e', Solr returns me the 
 above document.
 Exact query:
 {code}
 /select?q=raw_name:beyonce*wt=jsonfl=raw_name
 {code}
 Response:
 {code}
 {
   responseHeader: {
 status: 0,
 QTime: 0,
 params: {
   fl: raw_name,
   q: raw_name:beyonce*,
   wt: json
 }
   },
   response: {
 numFound: 2,
 start: 0,
 docs: [
   {
 raw_name: beyoncé
   },
   {
 raw_name: beyoncé
   }
 ]
   }
 }
 {code}
 I used the analysis tool in Solr admin (with Jetty). The raw bytes look like 
 this:
 Raw bytes for beyonce: [62 65 79 6f 6e 63 65]
 Raw bytes for beyoncé: [62 65 79 6f 6e 63 65 cc 81]
 So when you look at the bytes, it seems to explain why beyonce* might match 
 beyoncé.



--
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-7150) Make LRUStatsCache size configurable

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-7150:
---

 Summary: Make LRUStatsCache size configurable
 Key: SOLR-7150
 URL: https://issues.apache.org/jira/browse/SOLR-7150
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Shalin Shekhar Mangar
Priority: Trivial
 Fix For: Trunk, 5.1


LRUStatsCache size is hard-coded to 100 with a todo in the code to make it 
configurable. Let's make it so.



--
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.x-Linux (32bit/jdk1.7.0_76) - Build # 11703 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11703/
Java: 32bit/jdk1.7.0_76 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.codecs.lucene40.TestLucene40CompoundFormat.testAppend

Error Message:
expected:1 but was:2

Stack Trace:
java.lang.AssertionError: expected:1 but was:2
at 
__randomizedtesting.SeedInfo.seed([D0E561340A0D5FBD:3831D5E01FB425CB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.lucene.codecs.lucene40.TestLucene40CompoundFormat.testAppend(TestLucene40CompoundFormat.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 4293 lines...]
   [junit4] Suite: org.apache.lucene.codecs.lucene40.TestLucene40CompoundFormat
   [junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestLucene40CompoundFormat -Dtests.method=testAppend 
-Dtests.seed=D0E561340A0D5FBD -Dtests.multiplier=3 -Dtests.slow=true 

[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #854: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/854/

No tests ran.

Build Log:
[...truncated 37076 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-test-framework:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-parent:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-common:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:5.1.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-kuromoji:5.1.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:5.1.0-SNAPSHOT: checking for 
updates from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-analyzers-phonetic:5.1.0-SNAPSHOT: checking for 
updates from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:5.1.0-SNAPSHOT: checking for updates 
from maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-backward-codecs:5.1.0-SNAPSHOT: checking for updates 
from releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-expressions:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-grouping:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-highlighter:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-join:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-memory:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-misc:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queries:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:5.1.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:5.1.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2667 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2667/

6 tests failed.
REGRESSION:  org.apache.solr.handler.component.DistributedMLTComponentTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:16217/yh_u/jk/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:16217/yh_u/jk/collection1
at 
__randomizedtesting.SeedInfo.seed([CE89C483692AD59B:46DDFB59C7D6B863]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:568)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:309)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:538)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:586)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:568)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:547)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b22) - Build # 11866 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11866/
Java: 64bit/jdk1.8.0_40-ea-b22 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
commitWithin did not work on node: http://127.0.0.1:46408/v_fry/eq/collection1 
expected:68 but was:67

Stack Trace:
java.lang.AssertionError: commitWithin did not work on node: 
http://127.0.0.1:46408/v_fry/eq/collection1 expected:68 but was:67
at 
__randomizedtesting.SeedInfo.seed([CA15EC54DE23A8E3:4241D38E70DFC51B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:343)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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 

Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_76) - Build # 11700 - Still Failing!

[Adrien Grand]

Thanks Robert!

On Tue, Feb 24, 2015 at 4:28 AM, Robert Muir rcm...@gmail.com wrote:
 I committed a fix.

 On Mon, Feb 23, 2015 at 10:16 PM, Policeman Jenkins Server
 jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11700/
 Java: 32bit/jdk1.7.0_76 -server -XX:+UseConcMarkSweepGC

 1 tests failed.
 FAILED:  junit.framework.TestSuite.org.apache.lucene.queries.TermsQueryTest

 Error Message:
 Resource in scope SUITE failed to close. Resource was registered from thread 
 Thread[id=32, name=TEST-TermsQueryTest.testDuel-seed#[5946B5ADCC899A7C], 
 state=RUNNABLE, group=TGRP-TermsQueryTest], registration stack trace below.

 Stack Trace:
 com.carrotsearch.randomizedtesting.ResourceDisposalError: Resource in scope 
 SUITE failed to close. Resource was registered from thread Thread[id=32, 
 name=TEST-TermsQueryTest.testDuel-seed#[5946B5ADCC899A7C], state=RUNNABLE, 
 group=TGRP-TermsQueryTest], registration stack trace below.
 at __randomizedtesting.SeedInfo.seed([5946B5ADCC899A7C]:0)
 at java.lang.Thread.getStackTrace(Thread.java:1589)
 at 
 com.carrotsearch.randomizedtesting.RandomizedContext.closeAtEnd(RandomizedContext.java:166)
 at 
 org.apache.lucene.util.LuceneTestCase.closeAfterSuite(LuceneTestCase.java:718)
 at 
 org.apache.lucene.util.LuceneTestCase.wrapDirectory(LuceneTestCase.java:1328)
 at 
 org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1225)
 at 
 org.apache.lucene.util.LuceneTestCase.newDirectory(LuceneTestCase.java:1217)
 at 
 org.apache.lucene.queries.TermsQueryTest.testDuel(TermsQueryTest.java:63)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 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:365)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 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 
 

[jira] [Updated] (SOLR-7145) Make SolrRequest parametrized by its response type

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-7145:

Attachment: SOLR-7145.patch

New patch, removing the SolrClient API change, which I'll break into its own 
issue.  I think this should be uncontroversial?

 Make SolrRequest parametrized by its response type
 --

 Key: SOLR-7145
 URL: https://issues.apache.org/jira/browse/SOLR-7145
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 5.1

 Attachments: SOLR-7145.patch, SOLR-7145.patch


 We currently repeat a whole bunch of code in the process() method of every 
 single SolrRequest-derived class.  We should make SolrRequest parametrized by 
 its response type, and consolidate into the base class.



--
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-4242) A better spatial query parser

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-4242:
---
Attachment: SOLR-4242.patch

Updated the patch with some more refactorings, as per David's suggestions. 
Updated the review request as well.

 A better spatial query parser
 -

 Key: SOLR-4242
 URL: https://issues.apache.org/jira/browse/SOLR-4242
 Project: Solr
  Issue Type: New Feature
  Components: spatial
Reporter: David Smiley
 Fix For: 4.9, Trunk

 Attachments: SOLR-4242.patch, SOLR-4242.patch, SOLR-4242.patch


 I've been thinking about how spatial support is exposed to Solr users. 
 Presently there's the older Solr 3 stuff, most prominently seen via 
 \{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the 
 Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks 
 like mygeofield:Intersects(Circle(1 2 d=3)) What's inside the outer 
 parenthesis is parsed by Spatial4j as a shape, and it has a special 
 (non-standard) syntax for points, rects, and circles, and then there's WKT.  
 I believe this scheme was devised by [~ryantxu].
 I'd like to devise something that is both comprehensive and is aligned with 
 standards to the extent that it's prudent.  The old Solr 3 stuff is not 
 comprehensive and not standardized.  The newer stuff is comprehensive but 
 only a little based on standards. And I think it'd be nicer to implement it 
 as a Solr query parser.  I'll say more in the comments.



--
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-7136) Add an AutoPhrasing TokenFilter

[Ted Sullivan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14333833#comment-14333833
 ] 

Ted Sullivan edited comment on SOLR-7136 at 2/24/15 12:59 PM:
--

Yes Ahmet - that is correct, this patch includes a QParserPlugin as a 
workaround for LUCENE-2605 also mentioned in SOLR-5379. 
(AutophrasingQParserPlugin) The Query Parser solution published by Nolan Lawson 
and submitted as SOLR-4381 is a good solution too.  In fact, the Solr guys 
don't give a flying F comment on HN was in response to the fact that SOLR-4381 
which was filed over 2 years ago is still not committed. 

Note however that the AutoPhrasing parser first solves a problem of tokenizing 
phrases that represent single entities as single tokens - making the Lucene 
docID lookup cleaner.  Solutions like SOLR-5379 solve this indirectly and may 
have different edge cases because not all phrases are meant to represent single 
entities. For example, generalized phrase processing paradigms like mm or ps 
may not deal as precisely with phrases that include a multi-term entity with 
something else like New York City restaurants. Since it is part of an 
analysis pipeline, the AutophrasingTokenFilter can be used in conjunction with 
the SynonymTokenFilter to solve the multi-term synonym problem but that is an 
architectural solution. In other words this TokenFilter was not written to 
solve the multi-term synonym problem - that is a side benefit of what it does, 
given the nature of Lucene analysis chains.

 It has other benefits as well just by forcing exact-match semantics on phrases 
that should be treated as semantic or linguistic entities. It does have the 
downside of requiring autophrase lists, but so then does synonym processing.


was (Author: tedsullivan):
Yes Ahmet - that is correct, this patch includes a QParserPlugin as a 
workaround for LUCENE-2605 also mentioned in SOLR-5379. 
(AutophrasingQParserPlugin) The Query Parser solution published by Nolan Lawson 
and submitted as SOLR-4381 is a good solution too.  In fact, the Solr guys 
don't give a flying F comment on HN was in response to the fact that SOLR-4381 
which was filed over 2 years ago is still not committed. Note however that the 
AutoPhrasing parser first solves a problem of tokenizing phrases that represent 
single entities as single tokens - making the Lucene docID lookup cleaner.  
Solutions like SOLR-5379 solve this indirectly and may have different edge 
cases because not all phrases are meant to represent single entities. For 
example, generalized phrase processing paradigms like mm or ps may not deal as 
precisely with phrases that include a multi-term entity with something else 
like New York City restaurants. Since it is part of an analysis pipeline, the 
AutophrasingTokenFilter can be used in conjunction with the SynonymTokenFilter 
to solve the multi-term synonym problem but that is an architectural solution. 
In other words this TokenFilter was not written to solve the multi-term synonym 
problem - that is a side benefit of what it does, given the nature of Lucene 
analysis chains. It has other benefits as well just by forcing exact-match 
semantics on phrases that should be treated as semantic or linguistic entities. 
It does have the downside of requiring autophrase lists, but so then does 
synonym processing.

 Add an AutoPhrasing TokenFilter
 ---

 Key: SOLR-7136
 URL: https://issues.apache.org/jira/browse/SOLR-7136
 Project: Solr
  Issue Type: New Feature
Reporter: Ted Sullivan
 Attachments: SOLR-7136.patch


 Adds an 'autophrasing' token filter which is designed to enable noun phrases 
 that represent a single entity to be tokenized in a singular fashion. Adds 
 support for ManagedResources and Query parser auto-phrasing support given 
 Lucene-2605.
 The rationale for this Token Filter and its use in solving the long standing 
 multi-term synonym problem in Lucene Solr has been documented online. 
 http://lucidworks.com/blog/automatic-phrase-tokenization-improving-lucene-search-precision-by-more-precise-linguistic-analysis/
 https://lucidworks.com/blog/solution-for-multi-term-synonyms-in-lucenesolr-using-the-auto-phrasing-tokenfilter/



--
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-Tests-5.x-Java7 - Build # 2668 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2668/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:30499/c8n_1x2_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:30499/c8n_1x2_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([829A346BC0234715:ACE0BB16EDF2AED]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:597)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:906)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:809)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: Welcome Varun Thacker as Lucene/Solr committer

[Simon Willnauer]

welcome! It's been a while since GSoC :)

simon

On Tue, Feb 24, 2015 at 12:39 PM, Erik Hatcher erik.hatc...@gmail.com wrote:
 Congrats, Varun!   Well deserved.




 —
 Erik Hatcher, Senior Solutions Architect
 http://www.lucidworks.com




 On Feb 23, 2015, at 12:51 PM, Grant Ingersoll gsing...@apache.org wrote:

 Hi All,

 Please join me in welcoming Varun Thacker as the latest committer on Lucene
 and Solr.

 Varun, tradition is for you to provide a brief bio about yourself.

 Welcome aboard!

 -Grant





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

Re: Welcome Varun Thacker as Lucene/Solr committer

[Varun Thacker]

Thank you everyone for the kind welcome!  Right from the days I was a
student contributing as part of GSoC, It's been an honour to be part of
this community. I'm looking forward to committing to the project.

I am currently working for Lucidworks. I like to base a lot of my work
around the issues users face with Lucene/Solr.

Before Lucidworks I was part of a startup called Unbxd. I worked on
building their search platform tailored for eCommerce.

Looking forward to seeing everyone at future conferences.

Hi All,

Please join me in welcoming Varun Thacker as the latest committer on Lucene
and Solr.

Varun, tradition is for you to provide a brief bio about yourself.

Welcome aboard!

-Grant

Re: Welcome Varun Thacker as Lucene/Solr committer

[Erik Hatcher]

Congrats, Varun!   Well deserved. 




—
Erik Hatcher, Senior Solutions Architect
http://www.lucidworks.com http://www.lucidworks.com/




 On Feb 23, 2015, at 12:51 PM, Grant Ingersoll gsing...@apache.org wrote:
 
 Hi All,
 
 Please join me in welcoming Varun Thacker as the latest committer on Lucene 
 and Solr.
 
 Varun, tradition is for you to provide a brief bio about yourself.
 
 Welcome aboard!
 
 -Grant
 
 
 

[jira] [Created] (SOLR-7151) SolrClient.query() methods should throw IOException

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-7151:
---

 Summary: SolrClient.query() methods should throw IOException
 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1


All the methods on SolrClient are declared as throwing SolrServerException 
(thrown if there's an error somewhere on the server), and IOException (thrown 
if there's a communication error), except for the QueryRequest methods.  These 
swallow up IOException and repackage them in a SolrServerException.

I think these are useful distinctions to make (you might want to retry on an 
IOException, but not on a SolrServerException), and we should make the query 
methods fall in line with the others.

I'm not sure if this should go into 5.x as well as trunk, as it's a 
backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
useful API change that it's worth the break, but I'm not going to insist on it.



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

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

[jira] [Updated] (SOLR-7151) SolrClient.query() methods should throw IOException

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-7151:

Attachment: SOLR-7151.patch

Patch, building on top of the patch on SOLR-7145.

 SolrClient.query() methods should throw IOException
 ---

 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7151.patch


 All the methods on SolrClient are declared as throwing SolrServerException 
 (thrown if there's an error somewhere on the server), and IOException (thrown 
 if there's a communication error), except for the QueryRequest methods.  
 These swallow up IOException and repackage them in a SolrServerException.
 I think these are useful distinctions to make (you might want to retry on an 
 IOException, but not on a SolrServerException), and we should make the query 
 methods fall in line with the others.
 I'm not sure if this should go into 5.x as well as trunk, as it's a 
 backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
 useful API change that it's worth the break, but I'm not going to insist on 
 it.



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

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

[jira] [Commented] (SOLR-7151) SolrClient.query() methods should throw IOException

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334957#comment-14334957
 ] 

Mark Miller commented on SOLR-7151:
---

I think the tradeoffs have to be weighed pretty carefully. We want to get to 
the point that you can do rolling upgrades and such, and back compat breaks, 
while sometimes necessary, especially in the early days of APIs, need to become 
more and more rare for point releases I think.

I'd like to start a new trend of annotating what API's can be counted on and 
what not before long. We are great about http, but anything java is a mine 
field. And soon we would like to support rolling upgrades to some degree. 

In this case, I'm not sure the win is worth the break myself. But it also of 
the type we have let slide before.

 SolrClient.query() methods should throw IOException
 ---

 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7151.patch


 All the methods on SolrClient are declared as throwing SolrServerException 
 (thrown if there's an error somewhere on the server), and IOException (thrown 
 if there's a communication error), except for the QueryRequest methods.  
 These swallow up IOException and repackage them in a SolrServerException.
 I think these are useful distinctions to make (you might want to retry on an 
 IOException, but not on a SolrServerException), and we should make the query 
 methods fall in line with the others.
 I'm not sure if this should go into 5.x as well as trunk, as it's a 
 backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
 useful API change that it's worth the break, but I'm not going to insist on 
 it.



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

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

[jira] [Commented] (LUCENE-6286) Remove Filter from IndexSearcher APIs

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334960#comment-14334960
 ] 

Robert Muir commented on LUCENE-6286:
-

Does it cause ambiguity (null is used often here) if we add the new methods and 
deprecated the old ones in 5.1?

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6229) Remove Scorer.getChildren?

[Terry Smith (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335022#comment-14335022
 ] 

Terry Smith commented on LUCENE-6229:
-

Understood.

If you end up keeping getChildren(), how do you feel about making it well 
defined by capturing these constraints in the Javadoc?



 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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-6287) Corrupt index (missing .si file) on first 4.x commit to a 3.x index

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6287:
---
Attachment: LUCENE-6287.patch

Patch w/ test case that fails if you beast it for long enough.

I just created a simple 3.x index with many segments, and in the test case 
provoke merging and run a concurrent commit.  MDW.close then runs check index 
which detects the corruption.

Next I'll try to fix the bug ...

 Corrupt index (missing .si file) on first 4.x commit to a 3.x index
 ---

 Key: LUCENE-6287
 URL: https://issues.apache.org/jira/browse/LUCENE-6287
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Blocker
 Fix For: 4.10.4

 Attachments: LUCENE-6287.patch


 If you have a 3.x index, and you open it with a 4.x IndexWriter for
 the first time, and you do something that kicks of merges while
 concurrently committing, it's possible the index will corrupt itself
 with exceptions like this:
 {noformat}
 java.nio.file.NoSuchFileException: 
 /l/tmp/reruns.TestBackwardsCompatibility3x.testMergeDuringUpgrade.t2/lucene.index.TestBackwardsCompatibility3x-71F31CCCEF6853A-001/manysegments.362-006/_0.si
   at 
 sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
   at 
 sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
   at java.nio.channels.FileChannel.open(FileChannel.java:287)
   at java.nio.channels.FileChannel.open(FileChannel.java:334)
   at 
 org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
   at 
 org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80)
   at 
 org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.read(Lucene3xSegmentInfoReader.java:106)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:358)
   at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:454)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:906)
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:752)
   at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:457)
   at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:414)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
   at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:196)
   at 
 org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
   at 
 org.apache.lucene.index.TestBackwardsCompatibility3x.testMergeDuringUpgrade(TestBackwardsCompatibility3x.java:1035)
 {noformat}
 Back compat tests in Elasticsearch hit this, and at first I thought maybe 
 LUCENE-6279 was the cause (I still think we should fix that) but after 
 further debugging there is a different concurrency bug lurking here.
 I have a test case which after substantial beasting is able to reproduce the 
 bug, but I don't yet have a fix.  I think IW is missing a checkpoint after 
 writing a new commit...



--
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-6229) Remove Scorer.getChildren?

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334956#comment-14334956
 ] 

Robert Muir commented on LUCENE-6229:
-

{quote}
Can I position the returned scorers on the current document by calling freq(), 
score() or something else?
{quote}

No: this positioning is the whole problem here!

 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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-6286) Remove Filter from IndexSearcher APIs

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335003#comment-14335003
 ] 

Adrien Grand commented on LUCENE-6286:
--

No, there will be no ambiguity.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6286) Remove Filter from IndexSearcher APIs

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335008#comment-14335008
 ] 

Robert Muir commented on LUCENE-6286:
-

+1 to the patch and also to make the deprecated methods final.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6287) Corrupt index (missing .si file) on first 4.x commit to a 3.x index

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6287:
--

 Summary: Corrupt index (missing .si file) on first 4.x commit to a 
3.x index
 Key: LUCENE-6287
 URL: https://issues.apache.org/jira/browse/LUCENE-6287
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Blocker
 Fix For: 4.10.4


If you have a 3.x index, and you open it with a 4.x IndexWriter for
the first time, and you do something that kicks of merges while
concurrently committing, it's possible the index will corrupt itself
with exceptions like this:

{noformat}
java.nio.file.NoSuchFileException: 
/l/tmp/reruns.TestBackwardsCompatibility3x.testMergeDuringUpgrade.t2/lucene.index.TestBackwardsCompatibility3x-71F31CCCEF6853A-001/manysegments.362-006/_0.si
at 
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at 
sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
at java.nio.channels.FileChannel.open(FileChannel.java:287)
at java.nio.channels.FileChannel.open(FileChannel.java:334)
at 
org.apache.lucene.store.NIOFSDirectory.openInput(NIOFSDirectory.java:81)
at 
org.apache.lucene.store.FilterDirectory.openInput(FilterDirectory.java:80)
at 
org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.read(Lucene3xSegmentInfoReader.java:106)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:358)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:454)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:906)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:752)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:457)
at org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:414)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:207)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:196)
at 
org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
at 
org.apache.lucene.index.TestBackwardsCompatibility3x.testMergeDuringUpgrade(TestBackwardsCompatibility3x.java:1035)
{noformat}

Back compat tests in Elasticsearch hit this, and at first I thought maybe 
LUCENE-6279 was the cause (I still think we should fix that) but after further 
debugging there is a different concurrency bug lurking here.

I have a test case which after substantial beasting is able to reproduce the 
bug, but I don't yet have a fix.  I think IW is missing a checkpoint after 
writing a new commit...



--
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-7151) SolrClient.query() methods should throw IOException

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334980#comment-14334980
 ] 

Alan Woodward commented on SOLR-7151:
-

bq. We are great about http, but anything java is a mine field. And soon we 
would like to support rolling upgrades to some degree.

Agreed!  I don't think this will effect rolling upgrades, though?  This just 
changes how the client handles exceptions - you can still talk to a 5.1 server 
using a 4.10 client, and vice versa.

 SolrClient.query() methods should throw IOException
 ---

 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7151.patch


 All the methods on SolrClient are declared as throwing SolrServerException 
 (thrown if there's an error somewhere on the server), and IOException (thrown 
 if there's a communication error), except for the QueryRequest methods.  
 These swallow up IOException and repackage them in a SolrServerException.
 I think these are useful distinctions to make (you might want to retry on an 
 IOException, but not on a SolrServerException), and we should make the query 
 methods fall in line with the others.
 I'm not sure if this should go into 5.x as well as trunk, as it's a 
 backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
 useful API change that it's worth the break, but I'm not going to insist on 
 it.



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

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

[jira] [Comment Edited] (SOLR-7151) SolrClient.query() methods should throw IOException

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334881#comment-14334881
 ] 

Shawn Heisey edited comment on SOLR-7151 at 2/24/15 1:58 PM:
-

bq. I'm not sure if this should go into 5.x as well as trunk, as it's a 
backwards-breaking change. I'm leaning towards yes, as it's a sufficiently 
useful API change that it's worth the break, but I'm not going to insist on it.

+1 to 5x.  I have no idea whether I'm in the minority here.  I fully expect 
that anytime I update a library (like SolrJ) that my program uses, I may need 
to fix my code, and at the very least I will need to recompile my programs.  If 
the change is documented in whatever the package has for a CHANGES file, that's 
even better.

So far I've been extraordinarily lucky in that I've only needed to make changes 
to take advantage of new features, the code has always compiled successfully on 
SolrJ updates.  It's a bonus that I did not expect; I'm OK with minor changes 
in the API.  Large scale refactorings in a minor version update might bother 
me, but only if they do not come with a major advancement in the library's 
usability or capability.

To put it another way: If CHANGES.txt informs me that I may not be able to do a 
drop-in jar replacement with that minor update, that's enough notice for me ... 
although I would have assumed that anyway.


was (Author: elyograg):
bq. I'm not sure if this should go into 5.x as well as trunk, as it's a 
backwards-breaking change. I'm leaning towards yes, as it's a sufficiently 
useful API change that it's worth the break, but I'm not going to insist on it.

+1 to 5x.  I have no idea whether I'm in the minority here.  I fully expect 
that anytime I update a library (like SolrJ) that my program uses, I may need 
to fix my code, and at the very least I will need to recompile my programs.  If 
the change is documented in whatever the package has for a CHANGES file, that's 
even better.

So far I've been extraordinarily lucky in that I've only needed to make changes 
to take advantage of new features, the code has always compiled successfully on 
SolrJ updates.  It's a bonus that I did not expect; I'm OK with minor changes 
in the API.  Large scale refactorings in a minor version update might bother 
me, but only if they do not come with a major advancement in the library's 
usability or capability.


 SolrClient.query() methods should throw IOException
 ---

 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7151.patch


 All the methods on SolrClient are declared as throwing SolrServerException 
 (thrown if there's an error somewhere on the server), and IOException (thrown 
 if there's a communication error), except for the QueryRequest methods.  
 These swallow up IOException and repackage them in a SolrServerException.
 I think these are useful distinctions to make (you might want to retry on an 
 IOException, but not on a SolrServerException), and we should make the query 
 methods fall in line with the others.
 I'm not sure if this should go into 5.x as well as trunk, as it's a 
 backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
 useful API change that it's worth the break, but I'm not going to insist on 
 it.



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

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

[jira] [Commented] (LUCENE-6286) Remove Filter from IndexSearcher APIs

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334934#comment-14334934
 ] 

Robert Muir commented on LUCENE-6286:
-

It is a little strange that now the regular search methods call searchAfter

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6285) test seeds are not reproducing.

[Robert Muir (JIRA)]

Robert Muir created LUCENE-6285:
---

 Summary: test seeds are not reproducing.
 Key: LUCENE-6285
 URL: https://issues.apache.org/jira/browse/LUCENE-6285
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


even for very simple tests.



--
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-7151) SolrClient.query() methods should throw IOException

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334881#comment-14334881
 ] 

Shawn Heisey commented on SOLR-7151:


bq. I'm not sure if this should go into 5.x as well as trunk, as it's a 
backwards-breaking change. I'm leaning towards yes, as it's a sufficiently 
useful API change that it's worth the break, but I'm not going to insist on it.

+1 to 5x.  I have no idea whether I'm in the minority here.  I fully expect 
that anytime I update a library (like SolrJ) that my program uses, I may need 
to fix my code, and at the very least I will need to recompile my programs.  If 
the change is documented in whatever the package has for a CHANGES file, that's 
even better.

So far I've been extraordinarily lucky in that I've only needed to make changes 
to take advantage of new features, the code has always compiled successfully on 
SolrJ updates.  It's a bonus that I did not expect; I'm OK with minor changes 
in the API.  Large scale refactorings in a minor version update might bother 
me, but only if they do not come with a major advancement in the library's 
usability or capability.


 SolrClient.query() methods should throw IOException
 ---

 Key: SOLR-7151
 URL: https://issues.apache.org/jira/browse/SOLR-7151
 Project: Solr
  Issue Type: Bug
  Components: SolrJ
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-7151.patch


 All the methods on SolrClient are declared as throwing SolrServerException 
 (thrown if there's an error somewhere on the server), and IOException (thrown 
 if there's a communication error), except for the QueryRequest methods.  
 These swallow up IOException and repackage them in a SolrServerException.
 I think these are useful distinctions to make (you might want to retry on an 
 IOException, but not on a SolrServerException), and we should make the query 
 methods fall in line with the others.
 I'm not sure if this should go into 5.x as well as trunk, as it's a 
 backwards-breaking change.  I'm leaning towards yes, as it's a sufficiently 
 useful API change that it's worth the break, but I'm not going to insist on 
 it.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b47) - Build # 11868 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11868/
Java: 64bit/jdk1.9.0-ea-b47 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
{   responseHeader:{ status:404, QTime:3},   error:{ 
msg:no such blob or version available: test/1, code:404}}

Stack Trace:
java.lang.AssertionError: {
  responseHeader:{
status:404,
QTime:3},
  error:{
msg:no such blob or version available: test/1,
code:404}}
at 
__randomizedtesting.SeedInfo.seed([B636FBB21548C75E:6E7BD6E5E29562FE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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 

[jira] [Commented] (SOLR-7144) Suggester dictionary does not set origFreq

[James Dyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334914#comment-14334914
 ] 

James Dyer commented on SOLR-7144:
--

Charles,

Here is what I believe how the correctlySpelled flag is supposed to work 
today:

1. If spellcheck.maxResultsForSuggest is *not* specified
- If any query term has a frequency of zero, correctlySpelled is false.  
Otherwise it is true.

2. If  spellcheck.maxResultsForSuggest is specified
- If the query returns fewer results than specified for 
spellcheck.maxResultsForSuggest, correctlySpelled is false.  Otherwise it 
is true.

Were you seeing behavior different from this, or under which cases do you feel 
correctlySpelled is incorrect that you'd like to change?

Personally, I do not like that correctlySpelled even exists.  This is a 
subjective judgement and the client can decide this based on # results returned 
and the contents of the spell check response.  My approach with this, whenever 
making changes to the spell check component, is to try and keep the behavior 
consistent so nobody upgrades and all of a sudden their app is broken.  That 
doesn't mean we can't improve this though, especially if you've found a case in 
which its broken.

 Suggester dictionary does not set origFreq
 --

 Key: SOLR-7144
 URL: https://issues.apache.org/jira/browse/SOLR-7144
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 4.10.3
 Environment: Linux, Windows
Reporter: Charles Reitzel
Priority: Minor
 Attachments: SOLR-7144.patch


 Although it sets term frequency for corrections, 
 org.apache.solr.spelling.suggest.Suggester never sets the frequency for the 
 original term.   Thus, the spellcheck component will never format extended 
 results.
 There is a related issue with SpellCheckComponent: it may mark a query as 
 correctly spelled, even if zero frequency terms exist in the original 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] [Commented] (LUCENE-6229) Remove Scorer.getChildren?

[Terry Smith (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334937#comment-14334937
 ] 

Terry Smith commented on LUCENE-6229:
-

[~rcmuir] Sorry for excluding that scenario, it wasn't intentional.

If you all decide to keep getChildren(), then I'd love to get the contract 
described so people know what to expect.

I think these statements are correct:

# Scorer.getChildren() returns the immediate child scorers
# A returned scorer may be 
## unpositioned (never had next() or advance() called on it)
## positioned on a valid document that is before, on, or after the current 
document
## exhausted and thus positioned at NO_MORE_DOCS
# You MUST NOT call next() or advance() on the returned scorers yourself

And have these questions:

# Can I walk the returned scorers to get to all non-null leaf scorers?
# Can I position the returned scorers on the current document by calling 
freq(), score() or something else?




 Remove Scorer.getChildren?
 --

 Key: LUCENE-6229
 URL: https://issues.apache.org/jira/browse/LUCENE-6229
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor

 This API is used in a single place in our code base: 
 ToParentBlockJoinCollector. In addition, the usage is a bit buggy given that 
 using this API from a collector only works if setScorer is called with an 
 actual Scorer (and not eg. FakeScorer or BooleanScorer like you would get in 
 disjunctions) so it needs a custom IndexSearcher that does not use the 
 BulkScorer API.



--
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: Welcome Varun Thacker as Lucene/Solr committer

[Ryan Ernst]

Welcome!
On Feb 23, 2015 9:51 AM, Grant Ingersoll gsing...@apache.org wrote:

 Hi All,

 Please join me in welcoming Varun Thacker as the latest committer on
 Lucene and Solr.

 Varun, tradition is for you to provide a brief bio about yourself.

 Welcome aboard!

 -Grant

[jira] [Created] (LUCENE-6286) Remove Filter from IndexSearcher APIs

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6286:


 Summary: Remove Filter from IndexSearcher APIs
 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand


IndexSearcher has lots of methods that take a filter, and merge it with the 
query using a FilteredQuery when it is non null. I would like to remove these 
methods in favour of methods that only take a query and leave the 
responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause to 
the user.



--
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-6286) Remove Filter from IndexSearcher APIs

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14334948#comment-14334948
 ] 

Adrien Grand commented on LUCENE-6286:
--

This was changed in LUCENE-6220, but it was this way on 4.x too, the names just 
do not make it clear. Here is an excerpt from 4.10's IndexSearcher:

{noformat}
  /** Finds the top coden/code
   * hits for codequery/code, applying codefilter/code if non-null.
   *
   * @throws BooleanQuery.TooManyClauses If a query would exceed 
   * {@link BooleanQuery#getMaxClauseCount()} clauses.
   */
  public TopDocs search(Query query, Filter filter, int n)
throws IOException {
return search(createNormalizedWeight(wrapFilter(query, filter)), null, n);
  }
{noformat}

The object which is passed as null on the last line is the ScoreDoc after 
parameter.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_76) - Build # 11703 - Failure!

[Robert Muir]

I committed fixes... at least i think. seeds are not reproducing.

On Tue, Feb 24, 2015 at 4:55 AM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11703/
 Java: 32bit/jdk1.7.0_76 -client -XX:+UseSerialGC

 1 tests failed.
 FAILED:  
 org.apache.lucene.codecs.lucene40.TestLucene40CompoundFormat.testAppend

 Error Message:
 expected:1 but was:2

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:2
 at 
 __randomizedtesting.SeedInfo.seed([D0E561340A0D5FBD:3831D5E01FB425CB]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at org.junit.Assert.failNotEquals(Assert.java:647)
 at org.junit.Assert.assertEquals(Assert.java:128)
 at org.junit.Assert.assertEquals(Assert.java:472)
 at org.junit.Assert.assertEquals(Assert.java:456)
 at 
 org.apache.lucene.codecs.lucene40.TestLucene40CompoundFormat.testAppend(TestLucene40CompoundFormat.java:108)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 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:365)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 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:365)
 at java.lang.Thread.run(Thread.java:745)




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

[jira] [Updated] (SOLR-7147) Introduce new TrackingShardHandlerFactory for monitoring what requests are sent to shards during tests

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7147:

Attachment: SOLR-7147.patch

Here's a patch which implements the ideas that Hoss outlined:

TrackingShardHandlerFactory has the following API:
{code}
public synchronized void setTrackingQueue(QueueShardRequestAndParams queue) {
this.queue = queue;
  }

  public synchronized QueueShardRequestAndParams getTrackingQueue() {
return queue;
  }

  public synchronized boolean isTracking() {
return queue != null;
  }
{code}

Then there's a RequestTrackingQueue which has the following:
{code}
public ShardRequestAndParams getShardRequestByPurpose(ZkStateReader 
zkStateReader, String collectionName, String shardId, int purpose);

public ListShardRequestAndParams getShardRequests(ZkStateReader 
zkStateReader, String collectionName, String shardId);

public MapString, ListShardRequestAndParams getAllRequests();

public ListShardRequestAndParams getCollectionAdminRequests();

public ListShardRequestAndParams getCoreAdminRequests();
{code}

The getCollectionAdminRequests() and getCoreAdminRequests() methods are not 
implemented in this patch.

 Introduce new TrackingShardHandlerFactory for monitoring what requests are 
 sent to shards during tests
 --

 Key: SOLR-7147
 URL: https://issues.apache.org/jira/browse/SOLR-7147
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man
 Attachments: SOLR-7147.patch


 this is an idea shalin proposed as part of the testing for SOLR-7128...
 bq. I created a TrackingShardHandlerFactory which can record shard requests 
 sent from any node. There are a few helper methods to get requests by shard 
 and by purpose.
 ...
 bq. I will likely move the TrackingShardHandlerFactory into its own issue 
 because it is helpful for other distributed tests as well. I also need to 
 decouple it from the MiniSolrCloudCluster abstraction.



--
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-6286) Remove Filter from IndexSearcher APIs

[Adrien Grand (JIRA)]

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

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

Here is a patch. In most cases, callers were passing a null filter, and in the 
other cases calling code was changed to do the wrapping in a FilteredQuery 
explicitely.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-5984) Remove ChainedFilter

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335073#comment-14335073
 ] 

Adrien Grand commented on LUCENE-5984:
--

Hi Torsten, this change is documented in the 5.0 migration guide: 
https://lucene.apache.org/core/5_0_0/MIGRATE.html. 

 Remove ChainedFilter
 

 Key: LUCENE-5984
 URL: https://issues.apache.org/jira/browse/LUCENE-5984
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: LUCENE-5984.patch


 I would like to suggest removing ChainedFilter. It is currently only used in 
 Solr's CurrencyField but could easily be replaced with a BooleanFilter and my 
 understanding of this filter is that it can generally be replaced with a 
 BooleanFilter. So let's drop it and suggest using BooleanFilter instead?



--
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-NightlyTests-5.x - Build # 768 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/768/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:62143/c8n_1x2_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:62143/c8n_1x2_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([B59BF49184EAA6D8:3DCFCB4B2A16CB20]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:597)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:906)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:809)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (LUCENE-5984) Remove ChainedFilter

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-5984:
-
Fix Version/s: 5.0
   Trunk

 Remove ChainedFilter
 

 Key: LUCENE-5984
 URL: https://issues.apache.org/jira/browse/LUCENE-5984
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: LUCENE-5984.patch


 I would like to suggest removing ChainedFilter. It is currently only used in 
 Solr's CurrencyField but could easily be replaced with a BooleanFilter and my 
 understanding of this filter is that it can generally be replaced with a 
 BooleanFilter. So let's drop it and suggest using BooleanFilter instead?



--
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-5984) Remove ChainedFilter

[Torsten Krah (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335037#comment-14335037
 ] 

Torsten Krah commented on LUCENE-5984:
--

From a user perspective it would be nice to document this change. Changelog 
misses this and there maybe other users which use this Filter, e.g. myself - 
it's not only used in Solr, it maybe used in users code too.
At least deprecating it in 4.x to know this would have been nice to know this 
is coming. Maybe you can add it to the Changes.txt for 5.0.x?

 Remove ChainedFilter
 

 Key: LUCENE-5984
 URL: https://issues.apache.org/jira/browse/LUCENE-5984
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Attachments: LUCENE-5984.patch


 I would like to suggest removing ChainedFilter. It is currently only used in 
 Solr's CurrencyField but could easily be replaced with a BooleanFilter and my 
 understanding of this filter is that it can generally be replaced with a 
 BooleanFilter. So let's drop it and suggest using BooleanFilter instead?



--
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-6290) Make the query - filter migration less performance trappy

[Adrien Grand (JIRA)]

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

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

Here is a patch:
 - QueryWrapperFilter rewrites to a ConstantScoreQuery with a boost of 0 in 
order to propagate approximations
 - FilteredQuery rewrites to a BooleanQuery when the filter is a 
QueryWrapperFilter in order to take advantage of approximations

 Make the query - filter migration less performance trappy
 --

 Key: LUCENE-6290
 URL: https://issues.apache.org/jira/browse/LUCENE-6290
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6290.patch


 The filter-query migration might be a bit trappy in terms of performance for 
 our users.
 For instance a FilteredQuery over a TermQuery and a DocValuesRangeFilter 
 should be migrated to a BooleanQuery with a MUST clause for the TermQuery and 
 a FILTER clause for the DocValuesRangeQuery. Performance will be similar 
 since in both case we would use the query to drive the iteration and the 
 filter would only be used to check documents that match the query (we would 
 NOT try to advance the filter iterator).
 However, if you only go half-way through the migration and end up with a 
 FilteredQuery over a TermQuery and a QueryWrapperFilter(DocValuesRangeQuery) 
 then performance will be terrible because this QueryWrapperFilter does not 
 support random-access (which is the way such filters were not too slow 
 before) and hides the approximation support from the DocValuesRangeQuery.



--
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-6286) Remove Filter from IndexSearcher APIs

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6286.
--
   Resolution: Fixed
Fix Version/s: 5.1
   Trunk

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6286) Remove Filter from IndexSearcher APIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335236#comment-14335236
 ] 

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

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

LUCENE-6286: Removed IndexSearcher methods that take a Filter object.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-6291) Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6291:


 Summary: Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator
 Key: LUCENE-6291
 URL: https://issues.apache.org/jira/browse/LUCENE-6291
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1


TwoPhaseDocIdSetIterator is a bit long to type while TwoPhaseIterator already 
accurately describes what this class does?



--
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-7147) Introduce new TrackingShardHandlerFactory for monitoring what requests are sent to shards during tests

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7147:

Attachment: SOLR-7147.patch

Patch which adds following static helper methods in TrackingShardHandlerFactory 
to enable tracking on all nodes:
{code}
public static void setTrackingQueue(MiniSolrCloudCluster cluster, 
QueueShardRequestAndParams queue);

public static void setTrackingQueue(ListJettySolrRunner runners, 
QueueShardRequestAndParams queue);
{code}

I removed the proposed methods for tracking core admin and collection APIs. We 
can't track them with a shard handler factory and it is out of scope for this 
issue.

I'm working on a test.


 Introduce new TrackingShardHandlerFactory for monitoring what requests are 
 sent to shards during tests
 --

 Key: SOLR-7147
 URL: https://issues.apache.org/jira/browse/SOLR-7147
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man
 Attachments: SOLR-7147.patch, SOLR-7147.patch


 this is an idea shalin proposed as part of the testing for SOLR-7128...
 bq. I created a TrackingShardHandlerFactory which can record shard requests 
 sent from any node. There are a few helper methods to get requests by shard 
 and by purpose.
 ...
 bq. I will likely move the TrackingShardHandlerFactory into its own issue 
 because it is helpful for other distributed tests as well. I also need to 
 decouple it from the MiniSolrCloudCluster abstraction.



--
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-7134) Replication can still cause index corruption.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-7134:
--
Attachment: SOLR-7134.patch

First patch. Includes SOLR-7141.

I've been mostly testing this on our Cloudera search branch so far (4.4 with 
lots of backports, especially around SolrCloud). It has resolved all of the 
most worrisome trouble spots I could find with HdfsChaosMonkeySafeLeader with 
thousands and thousands of runs so far.

 Replication can still cause index corruption.
 -

 Key: SOLR-7134
 URL: https://issues.apache.org/jira/browse/SOLR-7134
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Critical
 Fix For: Trunk, 5.1

 Attachments: SOLR-7134.patch


 While we have plugged most of these holes, there appears to be another that 
 is fairly rare.
 I've seen it play out a couple ways in tests, but it looks like part of the 
 problem is that even if we decide we need a file and download it, we don't 
 care if we then cannot move it into place if it already exists.
 I'm working with a fix that does two things:
 * Fail a replication attempt if we cannot move a file into place because it 
 already exists.
 * If a replication attempt during recovery fails, on the next attempt force a 
 full replication to a new directory.



--
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-6279) 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335083#comment-14335083
 ] 

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

Commit 1662024 from [~mikemccand] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1662024 ]

LUCENE-6279: don't let a leftover _N_upgraded.si file corrupt a 3.x index on 
first kiss from 4.x

 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file
 

 Key: LUCENE-6279
 URL: https://issues.apache.org/jira/browse/LUCENE-6279
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 4.10.x

 Attachments: LUCENE-6279.patch, LUCENE-6279.patch


 Today when you do the first IW.commit to a 3.x index from Lucene 4.x, we go
 through a per-segment upgrade process when writing the next segments_N
 file, writing .si files for each segment if we didn't already do so.
 However, this process can be fooled by a leftover _N_upgraded.si
 file, in case the app above Lucene wasn't careful and reused a
 directory that had leftover files... I think we can make this more
 robust.



--
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-5984) Remove ChainedFilter

[Torsten Krah (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335081#comment-14335081
 ] 

Torsten Krah commented on LUCENE-5984:
--

Thanks for the hint - btw while i am looking at it - i am searching the 
{{FieldCacheRangeFilter}} too - its not in the MIGRATE.html document and not 
mentioned in the Changes - where is this one and how to migrate this.

 Remove ChainedFilter
 

 Key: LUCENE-5984
 URL: https://issues.apache.org/jira/browse/LUCENE-5984
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: LUCENE-5984.patch


 I would like to suggest removing ChainedFilter. It is currently only used in 
 Solr's CurrencyField but could easily be replaced with a BooleanFilter and my 
 understanding of this filter is that it can generally be replaced with a 
 BooleanFilter. So let's drop it and suggest using BooleanFilter instead?



--
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-6289) Replace DocValuesTermsFilter with a new DocValuesTermsQuery

[Adrien Grand (JIRA)]

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

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

Here is a patch. The change is similar to what was done with 
DocValuesRangeFilter.

 Replace DocValuesTermsFilter with a new DocValuesTermsQuery
 ---

 Key: LUCENE-6289
 URL: https://issues.apache.org/jira/browse/LUCENE-6289
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6289.patch


 Similarly to what we did with other filters. Additionally, 
 DocValuesTermsQuery could support approximations.



--
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-6290) Make the query - filter migration less performance trappy

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6290:


 Summary: Make the query - filter migration less performance trappy
 Key: LUCENE-6290
 URL: https://issues.apache.org/jira/browse/LUCENE-6290
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1


The filter-query migration might be a bit trappy in terms of performance for 
our users.

For instance a FilteredQuery over a TermQuery and a DocValuesRangeFilter should 
be migrated to a BooleanQuery with a MUST clause for the TermQuery and a FILTER 
clause for the DocValuesRangeQuery. Performance will be similar since in both 
case we would use the query to drive the iteration and the filter would only be 
used to check documents that match the query (we would NOT try to advance the 
filter iterator).

However, if you only go half-way through the migration and end up with a 
FilteredQuery over a TermQuery and a QueryWrapperFilter(DocValuesRangeQuery) 
then performance will be terrible because this QueryWrapperFilter does not 
support random-access (which is the way such filters were not too slow before) 
and hides the approximation support from the DocValuesRangeQuery.



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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1355/

No tests ran.

Build Log:
[...truncated 37051 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] snapshot 
org.apache.lucene:lucene-queries:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-queryparser:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:6.0.0-SNAPSHOT: checking for updates from 
maven-restlet
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-spatial:6.0.0-SNAPSHOT: checking for updates from 
releases.cloudera.com
[artifact:dependencies] 

[jira] [Comment Edited] (LUCENE-5984) Remove ChainedFilter

[Torsten Krah (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335081#comment-14335081
 ] 

Torsten Krah edited comment on LUCENE-5984 at 2/24/15 5:09 PM:
---

Thanks for the hint - missed this document, open another ticket for the other 
filter question to omit hijacking this one.


was (Author: tkrah):
Thanks for the hint - btw while i am looking at it - i am searching the 
{{FieldCacheRangeFilter}} too - its not in the MIGRATE.html document and not 
mentioned in the Changes - where is this one and how to migrate this.

 Remove ChainedFilter
 

 Key: LUCENE-5984
 URL: https://issues.apache.org/jira/browse/LUCENE-5984
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Fix For: 5.0, Trunk

 Attachments: LUCENE-5984.patch


 I would like to suggest removing ChainedFilter. It is currently only used in 
 Solr's CurrencyField but could easily be replaced with a BooleanFilter and my 
 understanding of this filter is that it can generally be replaced with a 
 BooleanFilter. So let's drop it and suggest using BooleanFilter instead?



--
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-6288) FieldCacheRangeFilter missing from MIGRATE.html

[Torsten Krah (JIRA)]

Torsten Krah created LUCENE-6288:


 Summary: FieldCacheRangeFilter missing from MIGRATE.html
 Key: LUCENE-6288
 URL: https://issues.apache.org/jira/browse/LUCENE-6288
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/other
Affects Versions: 5.0
Reporter: Torsten Krah


Hi,

i am searching the {{FieldCacheRangeFilter}} - its not mentioned in the 
{{https://lucene.apache.org/core/5_0_0/MIGRATE.html}} document and not 
mentioned in the Changelog  - where to find this one and if it is gone, is it 
possible to mention this in the migration guide please and how to cope with it 
in 5.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] (LUCENE-6286) Remove Filter from IndexSearcher APIs

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335143#comment-14335143
 ] 

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

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

LUCENE-6286: Removed IndexSearcher methods that take a Filter object.

 Remove Filter from IndexSearcher APIs
 -

 Key: LUCENE-6286
 URL: https://issues.apache.org/jira/browse/LUCENE-6286
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Attachments: LUCENE-6286.patch


 IndexSearcher has lots of methods that take a filter, and merge it with the 
 query using a FilteredQuery when it is non null. I would like to remove these 
 methods in favour of methods that only take a query and leave the 
 responsibility to build a FilteredQuery or a BooleanQuery with FILTER clause 
 to the user.



--
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-Windows (32bit/jdk1.8.0_31) - Build # 4503 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4503/
Java: 32bit/jdk1.8.0_31 -server -XX:+UseG1GC

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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001\tempDir-002: java.nio.file.AccessDeniedException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001\tempDir-002
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001\tempDir-002: java.nio.file.AccessDeniedException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001\tempDir-002
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.BasicDistributedZk2Test
 DF5E91835E81E951-001

at __randomizedtesting.SeedInfo.seed([DF5E91835E81E951]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:286)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:200)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: 
http://127.0.0.1:59020/jgd/vh/repfacttest_c8n_1x3_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: 
http://127.0.0.1:59020/jgd/vh/repfacttest_c8n_1x3_shard1_replica1
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:597)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:906)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:809)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:752)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:284)
at 
org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 

[jira] [Reopened] (LUCENE-6279) 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file

[Michael McCandless (JIRA)]

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

Michael McCandless reopened LUCENE-6279:


 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file
 

 Key: LUCENE-6279
 URL: https://issues.apache.org/jira/browse/LUCENE-6279
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 4.10.x

 Attachments: LUCENE-6279.patch, LUCENE-6279.patch


 Today when you do the first IW.commit to a 3.x index from Lucene 4.x, we go
 through a per-segment upgrade process when writing the next segments_N
 file, writing .si files for each segment if we didn't already do so.
 However, this process can be fooled by a leftover _N_upgraded.si
 file, in case the app above Lucene wasn't careful and reused a
 directory that had leftover files... I think we can make this more
 robust.



--
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-6279) 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6279.

Resolution: Fixed

 3.x - 4.x .si upgrade should not be tricked by leftover upgrade marker file
 

 Key: LUCENE-6279
 URL: https://issues.apache.org/jira/browse/LUCENE-6279
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 4.10.x

 Attachments: LUCENE-6279.patch, LUCENE-6279.patch


 Today when you do the first IW.commit to a 3.x index from Lucene 4.x, we go
 through a per-segment upgrade process when writing the next segments_N
 file, writing .si files for each segment if we didn't already do so.
 However, this process can be fooled by a leftover _N_upgraded.si
 file, in case the app above Lucene wasn't careful and reused a
 directory that had leftover files... I think we can make this more
 robust.



--
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-6289) Replace DocValuesTermsFilter with a new DocValuesTermsQuery

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6289:


 Summary: Replace DocValuesTermsFilter with a new 
DocValuesTermsQuery
 Key: LUCENE-6289
 URL: https://issues.apache.org/jira/browse/LUCENE-6289
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1


Similarly to what we did with other filters. Additionally, DocValuesTermsQuery 
could support approximations.



--
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-6289) Replace DocValuesTermsFilter with a new DocValuesTermsQuery

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335113#comment-14335113
 ] 

Adrien Grand commented on LUCENE-6289:
--

I forgot to mention: I extracted some logic to oal.search.ConstantScoreWeight 
for these queries that return a constant score.

 Replace DocValuesTermsFilter with a new DocValuesTermsQuery
 ---

 Key: LUCENE-6289
 URL: https://issues.apache.org/jira/browse/LUCENE-6289
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6289.patch


 Similarly to what we did with other filters. Additionally, 
 DocValuesTermsQuery could support approximations.



--
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-6290) Make the query - filter migration less performance trappy

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335138#comment-14335138
 ] 

Robert Muir commented on LUCENE-6290:
-

I think if QWF can somehow pass thru appoximation support of the wrapped 
query, that would be fantastic.

 Make the query - filter migration less performance trappy
 --

 Key: LUCENE-6290
 URL: https://issues.apache.org/jira/browse/LUCENE-6290
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1


 The filter-query migration might be a bit trappy in terms of performance for 
 our users.
 For instance a FilteredQuery over a TermQuery and a DocValuesRangeFilter 
 should be migrated to a BooleanQuery with a MUST clause for the TermQuery and 
 a FILTER clause for the DocValuesRangeQuery. Performance will be similar 
 since in both case we would use the query to drive the iteration and the 
 filter would only be used to check documents that match the query (we would 
 NOT try to advance the filter iterator).
 However, if you only go half-way through the migration and end up with a 
 FilteredQuery over a TermQuery and a QueryWrapperFilter(DocValuesRangeQuery) 
 then performance will be terrible because this QueryWrapperFilter does not 
 support random-access (which is the way such filters were not too slow 
 before) and hides the approximation support from the DocValuesRangeQuery.



--
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-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

Darren Hardy created SOLR-7153:
--

 Summary: BBoxField with dynamic fields yield error
 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy


Can you provide an example for dynamic fields for BBoxField that use stored 
values? That is, this configuration:

 dynamicField name=*_bbox type=bbox stored=true indexed=true/
 fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
numberType=_bbox_coord/
 fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
docValues=true stored=true/

This example configuration yields the following error in 4.10.3 when sending in 
data for field abcd_bbox... 

ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
 at 
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
at 
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
at 
org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 

[jira] [Updated] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

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

Darren Hardy updated SOLR-7153:
---
Description: 
Can you provide an example for dynamic fields for BBoxField that use stored 
values? That is, this configuration:

{noformat}
 dynamicField name=*_bbox type=bbox stored=true indexed=true/
 fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
numberType=_bbox_coord/
 fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
docValues=true stored=true/
 fieldType name=double class=solr.TrieDoubleField  precisionStep=8 
positionIncrementGap=0/
{noformat}

This example configuration yields the following error in 4.10.3 when sending in 
data for field abcd_bbox... 

{noformat}
ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
 at 
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
at 
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
at 
org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2669 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2669/

6 tests failed.
REGRESSION:  org.apache.solr.handler.component.DistributedMLTComponentTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:31516//collection1
at 
__randomizedtesting.SeedInfo.seed([9F54451702B37316:17007ACDAC4F1EEE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:568)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:309)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:538)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:586)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:568)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:547)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 

[jira] [Created] (SOLR-7152) Cannot override default rq with no rankquery

[Ryan Josal (JIRA)]

Ryan Josal created SOLR-7152:


 Summary: Cannot override default rq with no rankquery
 Key: SOLR-7152
 URL: https://issues.apache.org/jira/browse/SOLR-7152
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.10.2
Reporter: Ryan Josal
Priority: Minor


In your update handler, if you put a default parameter for rq=, you cannot 
override it with no rankquery.  You can try passing rq=, which will override 
the default value to an empty string, but the QueryComponent will complain that 
it isn't a valid RankQuery.  Looks like a simple fix to not only check for null 
but also isEmpty.

Possible workaround for now:
Check for empty rq string in the prepare method of an earlier search component 
and remove it.  This isn't a workable solution though if your rankquery param 
uses a {!switch ...} that can set to empty in a default case for example.



--
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-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335189#comment-14335189
 ] 

Darren Hardy commented on SOLR-7153:


Note that the work-around I'm using is this:

dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/


 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
   at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
   at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
   at 
 

[jira] [Comment Edited] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335189#comment-14335189
 ] 

Darren Hardy edited comment on SOLR-7153 at 2/24/15 6:27 PM:
-

Note that the work-around I'm using is this:

{noformat}
dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/
{noformat}


was (Author: drh):
Note that the work-around I'm using is this:

dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/


 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
   at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
   at 
 

[jira] [Updated] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

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

Darren Hardy updated SOLR-7153:
---
Description: 
Can you provide an example for dynamic fields for BBoxField that use stored 
values? That is, this configuration:

{noformat}
 dynamicField name=*_bbox type=bbox stored=true indexed=true/
 fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
numberType=_bbox_coord/
 fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
docValues=true stored=true/
{noformat}

This example configuration yields the following error in 4.10.3 when sending in 
data for field abcd_bbox... 

{noformat}
ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
 at 
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
at 
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
at 
org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at 

[jira] [Comment Edited] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335189#comment-14335189
 ] 

Darren Hardy edited comment on SOLR-7153 at 2/24/15 6:32 PM:
-

Note that the work-around I'm using is this:

{noformat}
dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/
fieldType name=double class=solr.TrieDoubleField  precisionStep=8 
positionIncrementGap=0/
{noformat}


was (Author: drh):
Note that the work-around I'm using is this:

{noformat}
dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/
{noformat}

 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
 {noformat}
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 {noformat}
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 {noformat}
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
   at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
   at 
 

[jira] [Updated] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

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

Darren Hardy updated SOLR-7153:
---
Description: 
Can you provide an example for dynamic fields for BBoxField that use stored 
values? That is, this configuration:

{noformat}
 dynamicField name=*_bbox type=bbox stored=true indexed=true/
 fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
numberType=_bbox_coord/
 fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
docValues=true stored=true/
{noformat}

This example configuration yields the following error in 4.10.3 when sending in 
data for field abcd_bbox... 

{noformat}
ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
 at 
org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
at 
org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
at 
org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at 

[jira] [Comment Edited] (SOLR-7153) BBoxField with dynamic fields yield error

[Darren Hardy (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335189#comment-14335189
 ] 

Darren Hardy edited comment on SOLR-7153 at 2/24/15 6:33 PM:
-

Note that the work-around I'm using is this:

{noformat}
dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/
fieldType name=double class=solr.TrieDoubleField  precisionStep=8 
positionIncrementGap=0/
fieldType name=bbox class=solr.BBoxField geo=true 
   units=degrees numberType=double
/
{noformat}


was (Author: drh):
Note that the work-around I'm using is this:

{noformat}
dynamicField name=*_bbox type=bbox stored=true 
indexed=true/
dynamicField name=*_bbox__minX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__minY type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxX type=double stored=true 
indexed=true/
dynamicField name=*_bbox__maxY type=double stored=true 
indexed=true/
fieldType name=double class=solr.TrieDoubleField  precisionStep=8 
positionIncrementGap=0/
{noformat}

 BBoxField with dynamic fields yield error
 -

 Key: SOLR-7153
 URL: https://issues.apache.org/jira/browse/SOLR-7153
 Project: Solr
  Issue Type: Bug
  Components: spatial
Affects Versions: 4.10.3
Reporter: Darren Hardy

 Can you provide an example for dynamic fields for BBoxField that use stored 
 values? That is, this configuration:
 {noformat}
  dynamicField name=*_bbox type=bbox stored=true indexed=true/
  fieldType name=bbox class=solr.BBoxField geo=true units=degrees 
 numberType=_bbox_coord/
  fieldType name=_bbox_coord class=solr.TrieDoubleField precisionStep=8 
 docValues=true stored=true/
 {noformat}
 This example configuration yields the following error in 4.10.3 when sending 
 in data for field abcd_bbox... 
 {noformat}
 ERROR - 2015-02-24 10:13:46.780; org.apache.solr.common.SolrException; 
 org.apache.solr.common.SolrException: undefined field abcd_bbox__minX
  at 
 org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1269)
   at 
 org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.getWrappedAnalyzer(IndexSchema.java:413)
   at 
 org.apache.lucene.analysis.AnalyzerWrapper.getPositionIncrementGap(AnalyzerWrapper.java:118)
   at 
 org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:699)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:359)
   at 
 org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:318)
   at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:457)
   at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1511)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:240)
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:164)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:952)
   at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:692)
   at 
 org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:100)
   at 
 org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:247)
   at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:174)
   at 
 org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:99)
   at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
   at 
 

[jira] [Commented] (LUCENE-6290) Make the query - filter migration less performance trappy

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335267#comment-14335267
 ] 

Robert Muir commented on LUCENE-6290:
-

+1

 Make the query - filter migration less performance trappy
 --

 Key: LUCENE-6290
 URL: https://issues.apache.org/jira/browse/LUCENE-6290
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
 Fix For: Trunk, 5.1

 Attachments: LUCENE-6290.patch


 The filter-query migration might be a bit trappy in terms of performance for 
 our users.
 For instance a FilteredQuery over a TermQuery and a DocValuesRangeFilter 
 should be migrated to a BooleanQuery with a MUST clause for the TermQuery and 
 a FILTER clause for the DocValuesRangeQuery. Performance will be similar 
 since in both case we would use the query to drive the iteration and the 
 filter would only be used to check documents that match the query (we would 
 NOT try to advance the filter iterator).
 However, if you only go half-way through the migration and end up with a 
 FilteredQuery over a TermQuery and a QueryWrapperFilter(DocValuesRangeQuery) 
 then performance will be terrible because this QueryWrapperFilter does not 
 support random-access (which is the way such filters were not too slow 
 before) and hides the approximation support from the DocValuesRangeQuery.



--
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-6291) Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14335268#comment-14335268
 ] 

Robert Muir commented on LUCENE-6291:
-

+1

 Rename TwoPhaseDocIdSetIterator to TwoPhaseIterator
 ---

 Key: LUCENE-6291
 URL: https://issues.apache.org/jira/browse/LUCENE-6291
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: Trunk, 5.1


 TwoPhaseDocIdSetIterator is a bit long to type while TwoPhaseIterator already 
 accurately describes what this class does?



--
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.x-Windows (32bit/jdk1.7.0_76) - Build # 4395 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4395/
Java: 32bit/jdk1.7.0_76 -client -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf\params.json: The process 
cannot access the file because it is being used by another process. 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf\params.json: The process 
cannot access the file because it is being used by another process.

   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1\conf
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010\collection1
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001\tempDir-010
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 F98497695EB8889B-001: java.nio.file.DirectoryNotEmptyException: 

[JENKINS] Lucene-Solr-SmokeRelease-5.0 - Build # 39 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.0/39/

No tests ran.

Build Log:
[...truncated 51662 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker] 
   [smoker] Load release URL 
file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build/smokeTestRelease/dist/...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (14.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.0.0-src.tgz...
   [smoker] 27.9 MB in 0.04 sec (713.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.0.0.tgz...
   [smoker] 64.0 MB in 0.09 sec (730.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.0.0.zip...
   [smoker] 73.6 MB in 0.07 sec (998.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5647 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5647 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run ant validate
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket 
-Dtests.multiplier=1 -Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 210 hits for query lucene
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [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] Releases that don't seem to be tested:
   [smoker]   5.0.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1535, in module
   [smoker] main()
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1480, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1518, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 628, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 809, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/dev-tools/scripts/smokeTestRelease.py,
 line 1473, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/build.xml:414:
 exec returned: 1

Total time: 43 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (LUCENE-6238) minimize tests.policy

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6238:

Attachment: LUCENE-6238.patch

Here is a patch:
* removes read and execute permission for whole filesystem
* removes unnecessary network permissions
* adds only runtimepermissions actually needed

This found a few test bugs.

 minimize tests.policy
 -

 Key: LUCENE-6238
 URL: https://issues.apache.org/jira/browse/LUCENE-6238
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6238.patch


 This is overly permissive:
 {noformat}
   // Basic permissions needed for Lucene to work:
   permission java.util.PropertyPermission *, read,write;
   permission java.lang.reflect.ReflectPermission *;
   permission java.lang.RuntimePermission *;
 {noformat}
 Because of various BS like unsafe-hacks (only mmap seems to do it properly), 
 this means effectively you cannot use lucene with SM today, without allowing 
 SM itself to just be disabled with reflection. 
 This is easy to fix.



--
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-7156) Fix test failures on Windows

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-7156:
---
Attachment: SOLR-7156.patch

Attaching a patch fixing test failures due to Backup functionality, affecting 
TestReplicationHandlerBackup and BasicDistributedZk2Test.

 Fix test failures on Windows
 

 Key: SOLR-7156
 URL: https://issues.apache.org/jira/browse/SOLR-7156
 Project: Solr
  Issue Type: Bug
Reporter: Ishan Chattopadhyaya
 Attachments: SOLR-7156.patch


 There are failures on Jenkins (Windows), latest one being: 
 http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4504/
 It looks like there are some problems during cleanup of certain files, even 
 after the tests have passed.



--
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-7156) Fix test failures on Windows

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-7156:
---
Attachment: SOLR-7156.patch

Thanks Shalin for the pointer to try-with-resources. I've updated the patch.

 Fix test failures on Windows
 

 Key: SOLR-7156
 URL: https://issues.apache.org/jira/browse/SOLR-7156
 Project: Solr
  Issue Type: Bug
Reporter: Ishan Chattopadhyaya
Assignee: Shalin Shekhar Mangar
 Attachments: SOLR-7156.patch, SOLR-7156.patch


 There are failures on Jenkins (Windows), latest one being: 
 http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4504/
 It looks like there are some problems during cleanup of certain files, even 
 after the tests have passed.



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