[jira] [Updated] (SOLR-3887) Add support for arrays of operations to JSON Update Handler
[
https://issues.apache.org/jira/browse/SOLR-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Dubay updated SOLR-3887:
--
Attachment: SOLR-3887.patch
Add support for arrays of operations to JSON Update Handler
---
Key: SOLR-3887
URL: https://issues.apache.org/jira/browse/SOLR-3887
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 4.0-BETA
Reporter: Jesse Dubay
Priority: Minor
Labels: json, update
Fix For: 4.0
Attachments: SOLR-3887.patch
Currently, UpdateRequestHandler accepts a sequence of operations in JSON
format by specifying duplicate keys. While duplicate keys aren't forbidden by
the JSON spec, in practice, this makes the update handler difficult to use in
conjunction with JSON serialization libraries in clients.
This has been mitigated somewhat by adding special syntax to add and delete
in SOLR-2496 and SOLR-3508 respectively, but there's still no way to specify
operations in a particular sequence as you can with XML. Per the JSON spec,
the right way to do this is with an array, as objects are considered
unordered sets.
Using an array at the top level would obviate the need for such a key, but
that syntax was used in the fix for SOLR-2496 as a shortcut for adds, so...
The attached patch adds an operations key that can exist at the same level
as any other operation. The operations key's value is an array of objects,
each of which uses the same syntax as the root object:
{code}
{
operations: [
{add: {id: 1}},
{delete: {query: foo}},
{add: {id: 2}},
{commit: {}},
]
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3887) Add support for arrays of operations to JSON Update Handler
Jesse Dubay created SOLR-3887:
-
Summary: Add support for arrays of operations to JSON Update
Handler
Key: SOLR-3887
URL: https://issues.apache.org/jira/browse/SOLR-3887
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 4.0-BETA
Reporter: Jesse Dubay
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3887.patch
Currently, UpdateRequestHandler accepts a sequence of operations in JSON format
by specifying duplicate keys. While duplicate keys aren't forbidden by the JSON
spec, in practice, this makes the update handler difficult to use in
conjunction with JSON serialization libraries in clients.
This has been mitigated somewhat by adding special syntax to add and delete in
SOLR-2496 and SOLR-3508 respectively, but there's still no way to specify
operations in a particular sequence as you can with XML. Per the JSON spec, the
right way to do this is with an array, as objects are considered unordered sets.
Using an array at the top level would obviate the need for such a key, but that
syntax was used in the fix for SOLR-2496 as a shortcut for adds, so...
The attached patch adds an operations key that can exist at the same level as
any other operation. The operations key's value is an array of objects, each
of which uses the same syntax as the root object:
{code}
{
operations: [
{add: {id: 1}},
{delete: {query: foo}},
{add: {id: 2}},
{commit: {}},
]
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4411) Depth requested in a facetRequest is reset when Sampling is in effect
[ https://issues.apache.org/jira/browse/LUCENE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera resolved LUCENE-4411. Resolution: Fixed Fix Version/s: 4.0 3.6.2 5.0 4.1 Lucene Fields: New,Patch Available (was: New) Committed to 3.6.2, 4x, and trunk. I also committed to lucene_solr_4_0 just in case we'll have another 4.0 candidate. Thanks Gilad ! Depth requested in a facetRequest is reset when Sampling is in effect - Key: LUCENE-4411 URL: https://issues.apache.org/jira/browse/LUCENE-4411 Project: Lucene - Core Issue Type: Bug Components: modules/facet Affects Versions: 3.6.1, 5.0, 4.0 Reporter: Gilad Barkai Assignee: Shai Erera Fix For: 4.1, 5.0, 3.6.2, 4.0 Attachments: LUCENE-4411.patch, OversampleWithDepthTest.java, OversampleWithDepthTest.java FacetRequest can be set a Depth parameter, which controls the depth of the result tree to be returned. When Sampling is enabled (and actually used) the Depth parameter gets reset to its default (1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3880) /browse jEOE should be Cat instead
[
https://issues.apache.org/jira/browse/SOLR-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462538#comment-13462538
]
Erick Erickson commented on SOLR-3880:
--
Thanks Hoss!
/browse jEOE should be Cat instead
--
Key: SOLR-3880
URL: https://issues.apache.org/jira/browse/SOLR-3880
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Environment: This was spotted in the 4.0 (RC0) build
Reporter: Erik Hatcher
Assignee: Erick Erickson
Priority: Trivial
Fix For: 4.0, 4.1
Attachments: SOLR-3880.patch
The /browse UI, after indexing the example docs (java -jar post.jar *.xml),
shows:
{code}
In Stock: true
jEOE: software search
{code}
That jEOE is errant, originating from
example/solr/example/collection1/conf/velocity/product-doc.vm and should be
Cat or Category instead.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-4424) DocValues.java @see tags need help
[ https://issues.apache.org/jira/browse/LUCENE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer reassigned LUCENE-4424: --- Assignee: Simon Willnauer DocValues.java @see tags need help -- Key: LUCENE-4424 URL: https://issues.apache.org/jira/browse/LUCENE-4424 Project: Lucene - Core Issue Type: Task Components: general/javadocs Reporter: Robert Muir Assignee: Simon Willnauer https://builds.apache.org/job/Lucene-Artifacts-4.x/javadoc/core/org/apache/lucene/index/DocValues.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4424) DocValues.java @see tags need help
[ https://issues.apache.org/jira/browse/LUCENE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4424: Description: https://builds.apache.org/job/Lucene-Artifacts-4.x/javadoc/core/org/apache/lucene/index/DocValues.html (was: https://builds.apache.org/job/Lucene-Artifacts-4.x/javadoc/core/org/apache/lucene/index/DocValues.html) Affects Version/s: 4.0-BETA Fix Version/s: 5.0 4.1 DocValues.java @see tags need help -- Key: LUCENE-4424 URL: https://issues.apache.org/jira/browse/LUCENE-4424 Project: Lucene - Core Issue Type: Task Components: general/javadocs Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Simon Willnauer Fix For: 4.1, 5.0 https://builds.apache.org/job/Lucene-Artifacts-4.x/javadoc/core/org/apache/lucene/index/DocValues.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4424) DocValues.java @see tags need help
[ https://issues.apache.org/jira/browse/LUCENE-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462544#comment-13462544 ] Simon Willnauer commented on LUCENE-4424: - I commmitted a fix to trunk (r1389748) and branch_4x (r1389749). in the case of a respin feel free to merge this in before respinning. DocValues.java @see tags need help -- Key: LUCENE-4424 URL: https://issues.apache.org/jira/browse/LUCENE-4424 Project: Lucene - Core Issue Type: Task Components: general/javadocs Affects Versions: 4.0-BETA Reporter: Robert Muir Assignee: Simon Willnauer Fix For: 4.1, 5.0 https://builds.apache.org/job/Lucene-Artifacts-4.x/javadoc/core/org/apache/lucene/index/DocValues.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462568#comment-13462568
]
Thomas Egense commented on SOLR-3875:
-
Thank you for the fast response and fix! Great job.
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Assignee: Hoss Man
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b51) - Build # 1344 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1344/ Java: 32bit/jdk1.8.0-ea-b51 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 20907 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.8.0-ea [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 2 warnings BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 27 minutes 27 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.8.0-ea-b51 -client -XX:+UseG1GC 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
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 917 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/917/ Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 20995 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\java\org\apache\lucene\index\DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\docs\core\help-doc.html... [javadoc] 1 warning BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:338: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:622: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\core\build.xml:48: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1611: Javadocs warnings were found! Total time: 45 minutes 0 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC 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-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[
https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4423:
-
Attachment: LUCENE-4423.patch
This patch should fix the issue, although I am not sure whether it should be
the responsability of the {{StoredFieldVisitor}} or of the
{{StoredFieldsReader}} to make sure that the byte[] is a copy (this patch
assumes it it the responsability of {{StoredFieldVisitor}}).
Moreover, do you think this issue should be a blocker for {{4.0}}?
DocumentStoredFieldVisitor.binaryField ignores offset and length
Key: LUCENE-4423
URL: https://issues.apache.org/jira/browse/LUCENE-4423
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Adrien Grand
Attachments: LUCENE-4423.patch
This is no problem with SimpleText and Lucene40 since in their cases, offset
is always 0 and length the length of the byte[] array, but it might break
with custom codecs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-919) Cache and reuse the SolrConfig
[ https://issues.apache.org/jira/browse/SOLR-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462593#comment-13462593 ] Erick Erickson commented on SOLR-919: - Taking some _very_ rough timings on a 2012 Macbook pro, loading the config file takes something on the order of 300-400 ms, so for 1,000s of cores we need this. Cache and reuse the SolrConfig -- Key: SOLR-919 URL: https://issues.apache.org/jira/browse/SOLR-919 Project: Solr Issue Type: Improvement Components: multicore Reporter: Noble Paul Assignee: Noble Paul Fix For: 4.1 Attachments: SOLR-919.patch If there are 1000's of cores the no:of times we need to load and parse the solrconfig.xml is going to be very expensive. It is desirable to just create one instance of SolrConfig object and re-use it across cores -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b51) - Build # 1355 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1355/ Java: 32bit/jdk1.8.0-ea-b51 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 20968 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] warning: [options] bootstrap class path not set in conjunction with -source 1.7 [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.8.0-ea [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 2 warnings BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 24 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.8.0-ea-b51 -client -XX:+UseSerialGC 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
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_07) - Build # 919 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/919/ Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 20928 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\src\java\org\apache\lucene\index\DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\help-doc.html... [javadoc] 1 warning BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:338: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:622: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\build.xml:48: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1611: Javadocs warnings were found! Total time: 47 minutes 13 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC 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
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_35) - Build # 1345 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1345/ Java: 32bit/jdk1.6.0_35 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 20166 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_35 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/stylesheet.css... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 26 minutes 3 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -server -XX:+UseParallelGC 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
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 493 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/493/ All tests passed Build Log: [...truncated 20958 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_06 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:338: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:59: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/common-build.xml:622: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/core/build.xml:48: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 39 minutes 43 seconds Build step 'Invoke Ant' marked build as failure Recording test results 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
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_35) - Build # 1356 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1356/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 20248 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_35 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/stylesheet.css... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 25 minutes 48 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC 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
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_07) - Build # 918 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/918/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 20992 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\java\org\apache\lucene\index\DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\docs\core\help-doc.html... [javadoc] 1 warning BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:338: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:622: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\core\build.xml:48: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1611: Javadocs warnings were found! Total time: 43 minutes 7 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC 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
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 703 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/703/ All tests passed Build Log: [...truncated 20227 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/build/docs/core/stylesheet.css... [javadoc] 1 warning BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:338: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:59: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/common-build.xml:622: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/core/build.xml:48: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 36 minutes 56 seconds Build step 'Invoke Ant' marked build as failure Recording test results 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
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_07) - Build # 1346 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1346/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 20909 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 24 minutes 40 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -client -XX:+UseG1GC 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] [Commented] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[
https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462642#comment-13462642
]
Robert Muir commented on LUCENE-4423:
-
{quote}
although I am not sure whether it should be the responsability of the
StoredFieldVisitor or of the StoredFieldsReader to make sure that the byte[] is
a copy (this patch assumes it it the responsability of StoredFieldVisitor).
{quote}
Can we separate this? This is a different issue (there are TODOs about that). I
definitely dont want it mixed in with this bugfix.
DocumentStoredFieldVisitor.binaryField ignores offset and length
Key: LUCENE-4423
URL: https://issues.apache.org/jira/browse/LUCENE-4423
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Adrien Grand
Attachments: LUCENE-4423.patch
This is no problem with SimpleText and Lucene40 since in their cases, offset
is always 0 and length the length of the byte[] array, but it might break
with custom codecs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_07) - Build # 1357 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1357/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 20983 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 27 minutes 36 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC 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
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_35) - Build # 1356 - Still Failing!
I committed a fix. Mike McCandless http://blog.mikemccandless.com On Tue, Sep 25, 2012 at 6:27 AM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1356/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 20248 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_35 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/docs/core/stylesheet.css... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 25 minutes 48 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_07) - Build # 920 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/920/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 20913 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\src\java\org\apache\lucene\index\DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\docs\core\help-doc.html... [javadoc] 1 warning BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:338: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:59: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:622: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\core\build.xml:48: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:1611: Javadocs warnings were found! Total time: 42 minutes 44 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC 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] [Commented] (SOLR-3875) Document boost does not work correctly when using multi-valued fields
[
https://issues.apache.org/jira/browse/SOLR-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462661#comment-13462661
]
Michael McCandless commented on SOLR-3875:
--
Thanks Hoss.
Document boost does not work correctly when using multi-valued fields
-
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
Issue Type: Bug
Components: Schema and Analysis, update
Affects Versions: 4.0-BETA
Reporter: Toke Eskildsen
Assignee: Hoss Man
Priority: Critical
Fix For: 4.0, 4.1, 5.0
Attachments: SOLR-3875.patch
In Solr 4 BETA trunk, document boosts skews the ranking for documents with
multi value fields tremendously. A document boost of 5 combined with 15
values in a multi value field results in scores above 1,000,000,000, while a
boost of 0,5 results in scores below 0,001. The error is not present in Solr
3.6.
Thomas Egense and I have tracked it down to a change in Solr DocumentBuilder
committed 20110827 (@1162347) by Mike McCandless, as part of work done on
LUCENE-2308. The problem is that Lucene multiplies the boosts of multiple
instances of the same field when updating the index.
The old DocumentBuilder, used in Lucene 3.6, handled this by calculating the
score for the field (docBoost*fieldBoost) and assigning it to the first
instance of the field, then setting the boost to 1.0f and assigning that to
subsequent instances of the field. This effectively assigned
docBoost*fieldBoost to the field, regardless of the number of instances.
The updated DocumentBuilder (see
https://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_0/solr/core/src/java/org/apache/solr/update/DocumentBuilder.java?revision=1388778view=markup),
used in Lucene 4 BETA trunk, also assigns docBoost*fieldBoost to the first
instance of the field. Then it sets fieldBoost = docBoost and continues to
assign docBoost*fieldBoost to subsequent instances. Using the example
mentioned above, the generated IndexableFields will get assigned boosts of 5,
5*5, 5*5... 5*5. As Lucene multiplies all the values, 15 instances of the
same field will have a collective boost of 5*25^14.
This can be demonstrated with the Solr tutorial example by indexing the
sample documents and adding the document
{code:xml}
add
doc boost=5
field name=idInsane score Example. Score = 10E9 /field
field name=nameDocument boost broken for multivalued fields/field
field name=manuThomas Egense and Toke Eskildsen/field
field name=manu_id_sTest/field
field name=catbug/field
field name=featuresinsane_boost/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
field name=featuressomething else/field
/doc
/add
{code}
The _manu_ _features_-fields gets copied to _text_ and a search for
_thomas_ matches the _text_-field with query explanation
{code:xml}
str name=Insane score Example. Score = 10E10
2.44373361E10 = (MATCH) weight(text:thomas in 0) [DefaultSimilarity], result
of:
2.44373361E10 = fieldWeight in 0, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
3.2512918 = idf(docFreq=3, maxDocs=38)
7.5161928E9 = fieldNorm(doc=0)
/str
{code}
Thomas and I are too pressed for time to attempt a proper patch at the
moment, but we guess that a reversion to the old algorithm of assigning the
combined boost to the first instance and 1.0f to all subsequent instances
would work?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_07) - Build # 1347 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1347/ Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 20911 lines...] [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene... [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.analysis.tokenattributes... [javadoc] Loading source files for package org.apache.lucene.codecs... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40.values... [javadoc] Loading source files for package org.apache.lucene.codecs.perfield... [javadoc] Loading source files for package org.apache.lucene.document... [javadoc] Loading source files for package org.apache.lucene.index... [javadoc] Loading source files for package org.apache.lucene.search... [javadoc] Loading source files for package org.apache.lucene.search.payloads... [javadoc] Loading source files for package org.apache.lucene.search.similarities... [javadoc] Loading source files for package org.apache.lucene.search.spans... [javadoc] Loading source files for package org.apache.lucene.store... [javadoc] Loading source files for package org.apache.lucene.util... [javadoc] Loading source files for package org.apache.lucene.util.automaton... [javadoc] Loading source files for package org.apache.lucene.util.fst... [javadoc] Loading source files for package org.apache.lucene.util.mutable... [javadoc] Loading source files for package org.apache.lucene.util.packed... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_07 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/src/java/org/apache/lucene/index/DocValues.java:91: warning - Tag @link: reference not found: Field [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/core/help-doc.html... [javadoc] 1 warning BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:338: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:59: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:622: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/core/build.xml:48: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:1611: Javadocs warnings were found! Total time: 24 minutes 17 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseConcMarkSweepGC 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] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated SOLR-3884:
--
Attachment: java7.solr-example.log
java6.solr-example.log
{quote}
a short term way of addressing this in the smoke tester (if we don't have a
better fix for 4.0) would be to have hte smoke tester explicitly request a hard
commit before doing a shutdown of the server, or using a new clean directory
(w/o any tlog or previous docs) when running the example for the second time.
{quote}
I tried the clean directory approach - here's the smokeTestRelease.py patch:
{noformat}
Index: dev-tools/scripts/smokeTestRelease.py
===
--- dev-tools/scripts/smokeTestRelease.py (revision 1389823)
+++ dev-tools/scripts/smokeTestRelease.py (working copy)
@@ -533,11 +533,21 @@
if project == 'lucene':
testDemo(isSrc, version)
else:
+ print('copying unpacked distribution...')
+ java6UnpackPath = '%s-java6' %unpackPath
+ if os.path.exists(java6UnpackPath):
+shutil.rmtree(java6UnpackPath)
+ shutil.copytree(unpackPath, java6UnpackPath)
print('test solr example w/ Java 6...')
- testSolrExample(unpackPath, JAVA6_HOME, False)
+ testSolrExample(java6UnpackPath, JAVA6_HOME, False)
+ print('copying unpacked distribution...')
+ java7UnpackPath = '%s-java7' %unpackPath
+ if os.path.exists(java7UnpackPath):
+shutil.rmtree(java7UnpackPath)
+ shutil.copytree(unpackPath, java7UnpackPath)
print('test solr example w/ Java 7...')
- testSolrExample(unpackPath, JAVA7_HOME, False)
+ testSolrExample(java7UnpackPath, JAVA7_HOME, False)
testChangesText('.', version, project)
{noformat}
But this seemed to have no effect - the failure still happens:
{noformat}
Test Solr...
test basics...
get KEYS
0.1 MB
download apache-solr-4.0.0-src.tgz...
29.8 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
download apache-solr-4.0.0.tgz...
102.8 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
download apache-solr-4.0.0.zip...
107.0 MB
verify md5/sha1 digests
verify sig
GPG: gpg: WARNING: using insecure memory!
verify trust
GPG: gpg: WARNING: using insecure memory!
GPG: gpg: WARNING: This key is not certified with a trusted signature!
unpack apache-solr-4.0.0.tgz...
copying unpacked distribution...
test solr example w/ Java 6...
start Solr instance
(log=/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0-java6/solr-example.log)...
startup done
test utf8...
index example docs...
run query...
stop server (SIGINT)...
copying unpacked distribution...
test solr example w/ Java 7...
start Solr instance
(log=/home/sarowe/temp/tmpDir/unpack/apache-solr-4.0.0-java7/solr-example.log)...
startup done
test utf8...
index example docs...
run query...
FAILED: response is:
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint
name=QTime1/intlst name=paramsstr
name=qvideo/str/lst/lstresult name=response numFound=0
start=0/result
/response
stop server (SIGINT)...
Traceback (most recent call last):
File dev-tools/scripts/smokeTestRelease.py, line 1133, in module
File dev-tools/scripts/smokeTestRelease.py, line 1081, in main
File dev-tools/scripts/smokeTestRelease.py, line 1123, in smokeTest
File dev-tools/scripts/smokeTestRelease.py, line 424, in unpack
File dev-tools/scripts/smokeTestRelease.py, line 550, in verifyUnpacked
File dev-tools/scripts/smokeTestRelease.py, line 622, in testSolrExample
RuntimeError: query on solr example instance failed
{noformat}
Attaching the {{solr-example.log}} files from each directory.
possible bug in how commits are handled during recovery mode on startup?
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
[jira] [Created] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
Adrien Grand created LUCENE-4425:
Summary: Unclear documentation of StoredFieldVisitor.binaryValue
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused outside
of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}} with
a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462692#comment-13462692
]
Robert Muir commented on LUCENE-4425:
-
Currently the responsibility is on the codecs to always allocate new things in
this visitor API.
This keeps the API simple (like String.toCharArray doing a copy does).
We should proceed with caution: StoredFieldVisitor is essentially part of our
.document API
(despite its packaging, .index is wrong, sorry) and a parameter passed to
IndexReader.document.
I think making this api more complicated for no real gain would be the wrong
tradeoff.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[ https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-4423: - Attachment: LUCENE-4423.patch Minimal patch that leaves the responsability to make the copy on the codec side. I created LUCENE-4425 to address the documentation issue. DocumentStoredFieldVisitor.binaryField ignores offset and length Key: LUCENE-4423 URL: https://issues.apache.org/jira/browse/LUCENE-4423 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Adrien Grand Attachments: LUCENE-4423.patch, LUCENE-4423.patch This is no problem with SimpleText and Lucene40 since in their cases, offset is always 0 and length the length of the byte[] array, but it might break with custom codecs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462696#comment-13462696
]
Robert Muir commented on LUCENE-4425:
-
I would support removing offset and length here in the visitor. I think then it
would be more intuitive.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462699#comment-13462699
]
Adrien Grand commented on LUCENE-4425:
--
bq. I would support removing offset and length here in the visitor. I think
then it would be more intuitive.
+1 If the responsability is on the codec side, then we should remove offset and
length.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462702#comment-13462702
]
Robert Muir commented on LUCENE-4425:
-
If we change this API, one way is to do it trunk only, and we add docs for 4.1?
However StoredFieldsVisitor is an abstract class (not an interface), so maybe
its not the only option.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[ https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462707#comment-13462707 ] Robert Muir commented on LUCENE-4423: - +1 for the patch. Unrelated, its also bogus we have a Field(byte[], int, int) ctor but no Field(byte[], int, int) setter. I guess i don't like the inconsistency: but its all sugar for BytesRef anyway. DocumentStoredFieldVisitor.binaryField ignores offset and length Key: LUCENE-4423 URL: https://issues.apache.org/jira/browse/LUCENE-4423 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Adrien Grand Attachments: LUCENE-4423.patch, LUCENE-4423.patch This is no problem with SimpleText and Lucene40 since in their cases, offset is always 0 and length the length of the byte[] array, but it might break with custom codecs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[
https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462708#comment-13462708
]
Robert Muir commented on LUCENE-4423:
-
Its also possible to add a test for this issue: we could do it either in
AssertingCodec or AssertingAtomicReader,
have it copy the bytes to a new byte[] { BOGUS + original } and set the
offset/length.
This way we know if any visitors are broken. (even though the current offset
and length are superfluous imo,
we should ensure visitors respect the contract).
DocumentStoredFieldVisitor.binaryField ignores offset and length
Key: LUCENE-4423
URL: https://issues.apache.org/jira/browse/LUCENE-4423
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Adrien Grand
Attachments: LUCENE-4423.patch, LUCENE-4423.patch
This is no problem with SimpleText and Lucene40 since in their cases, offset
is always 0 and length the length of the byte[] array, but it might break
with custom codecs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462710#comment-13462710
]
Adrien Grand commented on LUCENE-4425:
--
bq. However StoredFieldsVisitor is an abstract class (not an interface), so
maybe its not the only option.
If everybody agrees that the copy is on the codec side, then I think we should
push it to 4.x given that this API is counter-intuitive and might lead to
hard-to-track bugs with custom codecs?
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462713#comment-13462713
]
Robert Muir commented on LUCENE-4425:
-
I agree Adrien. I guess i immediately jumped to splitting the api change from
the bugfix because
I didn't want one blocked on the other.
I think we can still do it this way, commit LUCENE-4423 and get the bug fixed
(ignore my comment
about testing). Then we can think about this issue.
In my opinion the api is buggy :)
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462727#comment-13462727
]
Adrien Grand commented on LUCENE-4425:
--
bq. commit LUCENE-4423 and get the bug fixed (ignore my comment about testing).
Then we can think about this issue.
I just committed. I'll wait for a couple of Jenkins builds and merge into 4.0.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: VOTE: release 4.0
On a separate box with Win7+Cygwin, I just now successfully ran the smoke tester (it even says so now: SUCCESS!). So I think it's not a problem with running the smoke tester on Windows. Also, on -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Monday, September 24, 2012 2:32 PM To: dev@lucene.apache.org Subject: Re: VOTE: release 4.0 On Mon, Sep 24, 2012 at 2:26 PM, Steven A Rowe sar...@syr.edu wrote: Running smokeTestRelease.py on Win7+Cygwin, I can't get past the Solr example test under Java7. I'm not really sure thats a reflection on this release candidate: I'm not sure the smoke tester works on windows. I think you may have to test manually. -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462737#comment-13462737 ] Steven Rowe commented on SOLR-3884: --- bq. I don't think it does happen every time - others seem to have run the smoke test and not seen it at all, steve saw it some runs, I see it every run on my really fast comp. So I'm guessing there is some timing involved. Mark, what OS are you running the smoke tester on? On another Win7+Cygwin box, the smoke tester succeeds for me. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462739#comment-13462739 ] Robert Muir commented on SOLR-3884: --- Strange too, I've run the smoketester over 100 times and not encountered this. and sometimes my computer is busy doing other things too. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462803#comment-13462803 ] Mark Miller commented on SOLR-3884: --- I'm running it on Ubuntu 12.04. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462809#comment-13462809 ] Robert Muir commented on SOLR-3884: --- Me too: Distributor ID: Ubuntu Description:Ubuntu 12.04 LTS Release:12.04 Codename: precise I run 'ant nightly-smoke' like this: ant -DJAVA7_HOME=/usr/local/jdk1.7.0_01 -DJAVA6_HOME=/usr/local/jdk1.6.0_27 nightly-smoke possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2255) local params are not parsed in facet.pivot parameter
[
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462845#comment-13462845
]
Michael McCandless commented on SOLR-2255:
--
bq. But more importantly I want to be very judicious about what goes into a
release branch.
+1
local params are not parsed in facet.pivot parameter
Key: SOLR-2255
URL: https://issues.apache.org/jira/browse/SOLR-2255
Project: Solr
Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
Fix For: 4.1
Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch,
SOLR-2255_local-param_support_for_pivot_faceting.patch
...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
generates the following error : undefined field {!ex=category}category_id
If you filter on subcategory_id, the facet.pivot result will contain only
results from this subcategory. It's a loss of function since you can't alter
this behavior with local params.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462859#comment-13462859
]
Michael McCandless commented on LUCENE-4425:
+1 to remove offset/length and make it clear that you can hold onto that byte[]
(caller will not reuse it).
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462860#comment-13462860
]
Hoss Man commented on SOLR-3884:
{quote}
I tried the clean directory approach - here's the smokeTestRelease.py patch:
...
But this seemed to have no effect - the failure still happens:
...
Attaching the solr-example.log files from each directory.
{quote}
If these logs you attached on 25/Sep/12 are what you got *with* the patch then
something _really_ weird is going on -- because using a clean example dir
there's no logical reason why it should have been doing tlog recovery in either
run.
possible bug in how commits are handled during recovery mode on startup?
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
I'm not certain, but looking at his logs, i think this suggests a bug in how
commits are handled when a newly started server is in recovery mode
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462862#comment-13462862
]
Michael McCandless commented on LUCENE-4425:
Maybe we should fix this for 4.0? It really is an API bug...
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462867#comment-13462867 ] Jim Musil commented on SOLR-3859: - I think this is occurring when two nodes are killed simultaneously. This happened on ec2, so it's not that uncommon to take multiple servers down at once. My theory is that when a leader goes down, a new leader is chosen, but if the new leader has also gone down, then the remaining nodes cannot recover properly. Then, if the node that failed to recover is elected leader, it stays in that same recovery failed state. SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Attachments: zkAdminScreen.PNG, zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462881#comment-13462881 ] Steven Rowe commented on SOLR-3884: --- bq. If these logs you attached on 25/Sep/12 are what you got with the patch then something really weird is going on – because using a clean example dir there's no logical reason why it should have been doing tlog recovery in either run. those two logs are *with* the patch. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3859: -- Fix Version/s: 5.0 4.1 SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Fix For: 4.1, 5.0 Attachments: zkAdminScreen.PNG, zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Smoke test instructions
What are the instructions for running the infamous “smoke test”?
Is there a specific release of python needed?
I tried the following:
python dev-tools/scripts/smokeTestRelease.py
But got this error:
File dev-tools/scripts/smokeTestRelease.py, line 684
print('get POM templates', end=' ')
^
SyntaxError: invalid syntax
(The caret was under the “=” after “end”.)
-- Jack Krupansky
[jira] [Commented] (SOLR-3887) Add support for arrays of operations to JSON Update Handler
[
https://issues.apache.org/jira/browse/SOLR-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462924#comment-13462924
]
Jesse Dubay commented on SOLR-3887:
---
Hoss, no problem. Thanks for taking a look at it!
Add support for arrays of operations to JSON Update Handler
---
Key: SOLR-3887
URL: https://issues.apache.org/jira/browse/SOLR-3887
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 4.0-BETA
Reporter: Jesse Dubay
Priority: Minor
Labels: json, update
Attachments: SOLR-3887.patch
Currently, UpdateRequestHandler accepts a sequence of operations in JSON
format by specifying duplicate keys. While duplicate keys aren't forbidden by
the JSON spec, in practice, this makes the update handler difficult to use in
conjunction with JSON serialization libraries in clients.
This has been mitigated somewhat by adding special syntax to add and delete
in SOLR-2496 and SOLR-3508 respectively, but there's still no way to specify
operations in a particular sequence as you can with XML. Per the JSON spec,
the right way to do this is with an array, as objects are considered
unordered sets.
Using an array at the top level would obviate the need for such a key, but
that syntax was used in the fix for SOLR-2496 as a shortcut for adds, so...
The attached patch adds an operations key that can exist at the same level
as any other operation. The operations key's value is an array of objects,
each of which uses the same syntax as the root object:
{code}
{
operations: [
{add: {id: 1}},
{delete: {query: foo}},
{add: {id: 2}},
{commit: {}},
]
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor
[
https://issues.apache.org/jira/browse/SOLR-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462943#comment-13462943
]
Rob Tulloh commented on SOLR-3881:
--
One possible solution is to limit the size of the string that is selected for
concatenation. I don't know if there is a good way to guess which part of the
string to select. Just picking the first 64K seems like a reasonable solution
with the lack of any heuristics to suggest otherwise. Thoughts?
In LanguageIdentifierUpdateProcessor.concatFields:
{noformat}
String fieldValue = (String) doc.getFieldValue(fieldName);
if (fieldValue != null fieldValue.length() 0) {
fieldValue =
fieldValue.substring(0,Math.min(65536,fieldValue.length()));
}
sb.append(fieldValue);
{noformat}
frequent OOM in LanguageIdentifierUpdateProcessor
-
Key: SOLR-3881
URL: https://issues.apache.org/jira/browse/SOLR-3881
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.0
Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
Reporter: Rob Tulloh
We are seeing frequent failures from Solr causing it to OOM. Here is the
stack trace we observe when this happens:
{noformat}
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuffer.append(StringBuffer.java:224)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
at
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
at
org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
at
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
at
org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
at
org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
at
org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
[jira] [Resolved] (SOLR-3560) Handle Logging Events in UI
[
https://issues.apache.org/jira/browse/SOLR-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-3560.
-
Resolution: Fixed
Committed revision 1389981. trunk
Committed revision 1389982. branch_4x
Handle Logging Events in UI
---
Key: SOLR-3560
URL: https://issues.apache.org/jira/browse/SOLR-3560
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.1
Attachments: SOLR-3560.patch
As follow up on SOLR-3367, we should try to handle all type of Exceptions -
the good ones as well as the bad ones:
{code}throw new RuntimeException( error +cause );{code}
{code}{
time: 2012-05-16T13:26:10.722Z,
level: SEVERE,
logger: org.apache.solr.core.SolrCore,
message: org.apache.solr.common.SolrException: Can not find:
schema.not [/opt/solr-trunk/solr/example/solr/./conf/schema.not]
at
org.apache.solr.handler.admin.ShowFileRequestHandler.showFromFileSystem(ShowFileRequestHandler.java:229)
at
org.apache.solr.handler.admin.ShowFileRequestHandler.handleRequestBody(ShowFileRequestHandler.java:122)
...
}{code}
and
{code}throw new RuntimeException( error message, cause );{code}
{code}{
time: 2012-05-16T13:25:03.679Z,
level: SEVERE,
logger: org.apache.solr.handler.admin.LoggingHandler,
message: error (with exception),
trace: java.lang.RuntimeException: test
at
org.apache.solr.handler.admin.LoggingHandler.handleRequestBody(LoggingHandler.java:75)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
...
}{code}
First Idea would be, to check for an existing {{trace}}-Index .. if the
record has none, we expect the whole Output to be stored in {{message}} - so
we split on the first Line-break, take the former part as new {{message}} and
use the latter as {{trace}}.
If that will not work (at least for specific cases) and you already know
about .. please speak up :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3734) Forever loop in schema browser
[ https://issues.apache.org/jira/browse/SOLR-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462956#comment-13462956 ] Stefan Matheis (steffkes) commented on SOLR-3734: - [~lancenorskog] would you mind having a look, if that works as expected? Forever loop in schema browser -- Key: SOLR-3734 URL: https://issues.apache.org/jira/browse/SOLR-3734 Project: Solr Issue Type: Bug Components: Schema and Analysis, web gui Reporter: Lance Norskog Assignee: Stefan Matheis (steffkes) Attachments: SOLR-3734.patch, SOLR-3734.patch, SOLR-3734_schema_browser_blocks_solr_conf_dir.zip When I start Solr with the attached conf directory, and hit the Schema Browser, the loading circle spins permanently. I don't know if the problem is in the UI or in Solr. The UI does not display the Ajax solr calls, and I don't have a debugging proxy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3788) core creation UI screen should redirect browser to details about newly created core
[ https://issues.apache.org/jira/browse/SOLR-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-3788. - Resolution: Fixed Fix Version/s: 4.1 Committed revision 1389984. trunk Committed revision 1389985. branch_4x core creation UI screen should redirect browser to details about newly created core --- Key: SOLR-3788 URL: https://issues.apache.org/jira/browse/SOLR-3788 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Hoss Man Assignee: Stefan Matheis (steffkes) Fix For: 4.1 Attachments: SOLR-3788.patch got confused while testing SOLR-3679 because when you create a new SolrCore using the Admin UI, the form goes away, and you are still looking at the core admin details page for whatever SolrCore you were on when you clicked the Add Core button -- it would be nice if the successful completion of hte Add Core form would redirect you to the sub-page for the core you just added. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4422) Don't rely on the computer locale to generate javadocs
[ https://issues.apache.org/jira/browse/LUCENE-4422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4422. - Resolution: Fixed Fix Version/s: 5.0 Thanks Adrien: nice catch! Don't rely on the computer locale to generate javadocs -- Key: LUCENE-4422 URL: https://issues.apache.org/jira/browse/LUCENE-4422 Project: Lucene - Core Issue Type: Bug Components: general/build, general/javadocs Affects Versions: 5.0, 4.0 Environment: locale=fr_FR Reporter: Adrien Grand Assignee: Robert Muir Priority: Minor Fix For: 5.0, 4.0 Attachments: LUCENE-4422.patch With the fr_FR locale, javadoc 1.6.0_26 fails to generate correct HTML output for the class-use files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3840) XML query response display is unreadable in Solr Admin Query UI
[ https://issues.apache.org/jira/browse/SOLR-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3840: Attachment: SOLR-3840.patch The point is exactly as Alexandre stated, the rendering does not work by default for content in iframes .. afaik the can be enabled as 'advanced setting', but this nothing i'd like to build on. first draft attached, which uses the same client-rendering as we do for schema/config. XML query response display is unreadable in Solr Admin Query UI --- Key: SOLR-3840 URL: https://issues.apache.org/jira/browse/SOLR-3840 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Environment: Google Chrome, Windows 7 - Firefox as well Reporter: Jack Krupansky Attachments: Query-UI-XML-unreadable.png, SOLR-3840.patch If I execute a query in the Solr Admin Query UI, the default XML writer displays only the raw text of the Solr response XML element values, but none of the XML syntax itself, rendering the response display on the Query page almost completely useless. JSON, Ruby, et al display very reasonably formatted output, but XML does not. You can click on the icon next to the generated query URL to display the response in a browser tab of its own and then it does display the XML very reasonably, but the framed display on the query page is simply not readable. My recollection is that the old UI had this same problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3637) The commit status of a core is allways as false at the core admin page
[
https://issues.apache.org/jira/browse/SOLR-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3637:
Attachment: SOLR-3637.patch
Thanks Uwe! On the Cores UI an undefined property {{optimized}} was used, i
changed this on, using the same logic as the Dashboard does.
The commit status of a core is allways as false at the core admin page
---
Key: SOLR-3637
URL: https://issues.apache.org/jira/browse/SOLR-3637
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0-ALPHA
Environment: Solaris11, Java7 and newly downloaded 4.0-Alpha (jetty)
Reporter: Uwe Reh
Priority: Trivial
Labels: admin, gui
Attachments: SOLR-3637.patch
Original Estimate: 2h
Remaining Estimate: 2h
Using the admin gui, the page 'Core Admin' (...solr/#/~cores/coreX) says
allways that the selected core isn't optimized. The main page of the core's
submenu (solr/#/coreX) shows the correct state.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3637) The commit status of a core is allways as false at the core admin page
[ https://issues.apache.org/jira/browse/SOLR-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) reassigned SOLR-3637: --- Assignee: Stefan Matheis (steffkes) The commit status of a core is allways as false at the core admin page --- Key: SOLR-3637 URL: https://issues.apache.org/jira/browse/SOLR-3637 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-ALPHA Environment: Solaris11, Java7 and newly downloaded 4.0-Alpha (jetty) Reporter: Uwe Reh Assignee: Stefan Matheis (steffkes) Priority: Trivial Labels: admin, gui Attachments: SOLR-3637.patch Original Estimate: 2h Remaining Estimate: 2h Using the admin gui, the page 'Core Admin' (...solr/#/~cores/coreX) says allways that the selected core isn't optimized. The main page of the core's submenu (solr/#/coreX) shows the correct state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4426) New ValueSource implementations that wrap DocValues
Adrien Grand created LUCENE-4426: Summary: New ValueSource implementations that wrap DocValues Key: LUCENE-4426 URL: https://issues.apache.org/jira/browse/LUCENE-4426 Project: Lucene - Core Issue Type: New Feature Components: modules/other Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.1, 5.0 We should have ValueSource implementations that wrap DocValues in lucene-queries so that DocValues can be used in function queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3861: -- Attachment: SOLR-3861.patch Here is a completed test. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-3861.patch, SOLR-3861.patch, SOLR-3861.patch SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462995#comment-13462995 ] Mark Miller edited comment on SOLR-3861 at 9/26/12 4:21 AM: Here is a completed patch. was (Author: markrmil...@gmail.com): Here is a completed test. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-3861.patch, SOLR-3861.patch, SOLR-3861.patch SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13462996#comment-13462996 ] Yonik Seeley commented on SOLR-3884: Something to watch out for on Windows/cygwin: I've noticed that ^C in cygwin no longer works to stop the JVM. Doing a kill -2 on the java process from a different window seems to immediately abort the JVM (no graceful shutdown that does a commit). The latter may be happening with the python script too? possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2058) Adds optional phrase slop to edismax pf2, pf3 and pf parameters with field~slop^boost syntax
[
https://issues.apache.org/jira/browse/SOLR-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463009#comment-13463009
]
Michael Dodsworth commented on SOLR-2058:
-
It looks like this change also altered the way phrase queries are merged into
the main query.
For the query: 'term1 term2' with pf2:[field1, field2, field3] we now get
(omitting the non phrase query section for clarity):
{code}
main query DisjunctionMaxQuery((field1:term1 term2^1.0)~0.1)
DisjunctionMaxQuery((field2:term1 term2^1.0)~0.1)
DisjunctionMaxQuery((field3:term1 term2^1.0)~0.1)
{code}
Prior to this change, we got:
{code}
main query DisjunctionMaxQuery((field1:term1 term2^1.0 | field2:term1
term2^1.0 | field3:term1 term2^1.0)~0.1)
{code}
The upshot being that if the phrase query term1 term2 appears in multiple
fields, it will get a significant boost over the previous implementation. The
presence of the dismax queries makes me think this behavioral change was not
intentional; if that's the case, let me know and I'll get a fix together.
Thanks.
Adds optional phrase slop to edismax pf2, pf3 and pf parameters with
field~slop^boost syntax
Key: SOLR-2058
URL: https://issues.apache.org/jira/browse/SOLR-2058
Project: Solr
Issue Type: Improvement
Components: query parsers
Environment: n/a
Reporter: Ron Mayer
Assignee: James Dyer
Priority: Minor
Fix For: 4.0-ALPHA
Attachments: edismax_pf_with_slop_v2.1.patch,
edismax_pf_with_slop_v2.patch, pf2_with_slop.patch,
SOLR-2058-and-3351-not-finished.patch, SOLR-2058.patch
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3c4c659119.2010...@0ape.com%3E
{quote}
From Ron Mayer r...@0ape.com
... my results might be even better if I had a couple different pf2s with
different ps's at the same time. In particular. One with ps=0 to put a
high boost on ones the have the right ordering of words. For example
insuring that [the query]:
red hat black jacket
boosts only documents with red hats and not black hats. And another
pf2 with a more modest boost with ps=5 or so to handle the query above also
boosting docs with
red baseball hat.
{quote}
[http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3caanlktimd+v3g6d_mnhp+jykkd+dej8fvmvf_1lqoi...@mail.gmail.com%3E]
{quote}
From Yonik Seeley yo...@lucidimagination.com
Perhaps fold it into the pf/pf2 syntax?
pf=text^2// current syntax... makes phrases with a boost of 2
pf=text~1^2 // proposed syntax... makes phrases with a slop of 1 and
a boost of 2
That actually seems pretty natural given the lucene query syntax - an
actual boosted sloppy phrase query already looks like
{{text:foo bar~1^2}}
-Yonik
{quote}
[http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3calpine.deb.1.10.1008161300510.6...@radix.cryptio.net%3E]
{quote}
From Chris Hostetter hossman_luc...@fucit.org
Big +1 to this idea ... the existing ps param can stick arround as the
default for any field that doesn't specify it's own slop in the pf/pf2/pf3
fields using the ~ syntax.
-Hoss
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4426) New ValueSource implementations that wrap DocValues
[
https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4426:
-
Attachment: LUCENE-4426.patch
This patch adds {{ValueSource}} implementations for ints, longs, floats,
doubles, dates and UTF8-encoded Strings.
New ValueSource implementations that wrap DocValues
---
Key: LUCENE-4426
URL: https://issues.apache.org/jira/browse/LUCENE-4426
Project: Lucene - Core
Issue Type: New Feature
Components: modules/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4426.patch
We should have ValueSource implementations that wrap DocValues in
lucene-queries so that DocValues can be used in function queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4423) DocumentStoredFieldVisitor.binaryField ignores offset and length
[ https://issues.apache.org/jira/browse/LUCENE-4423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-4423. -- Resolution: Fixed Fix Version/s: 4.0 Assignee: Adrien Grand Committed on trunk branch 4.x and branch 4.0. DocumentStoredFieldVisitor.binaryField ignores offset and length Key: LUCENE-4423 URL: https://issues.apache.org/jira/browse/LUCENE-4423 Project: Lucene - Core Issue Type: Bug Components: core/store Reporter: Adrien Grand Assignee: Adrien Grand Fix For: 4.0 Attachments: LUCENE-4423.patch, LUCENE-4423.patch This is no problem with SimpleText and Lucene40 since in their cases, offset is always 0 and length the length of the byte[] array, but it might break with custom codecs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4426) New ValueSource implementations that wrap DocValues
[ https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463016#comment-13463016 ] Robert Muir commented on LUCENE-4426: - How does this relate to NumericIndexDocValueSource? I am confused why the current one only handles 3 types? New ValueSource implementations that wrap DocValues --- Key: LUCENE-4426 URL: https://issues.apache.org/jira/browse/LUCENE-4426 Project: Lucene - Core Issue Type: New Feature Components: modules/other Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4426.patch We should have ValueSource implementations that wrap DocValues in lucene-queries so that DocValues can be used in function queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463018#comment-13463018
]
Hoss Man commented on SOLR-3884:
{quote}
Doing a kill -2 on the java process from a different window seems to
immediately abort the JVM (no graceful shutdown that does a commit).
The latter may be happening with the python script too?
{quote}
That could explain how a tlog would be left in the directory after calling the
testSolrExample() method, but it still leaves some open questions...
1) according to sarowe, he's seeing this problem (and his smoke test logs show
tlog recovery) even when using a pristine copy of the unpack dir - so why is
there a tlog in that case?
2) how should tlog recovery be fixed to better handle this situation (ie:
docs commits coming in during recovery) in a real world situation.
possible bug in how commits are handled during recovery mode on startup?
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
I'm not certain, but looking at his logs, i think this suggests a bug in how
commits are handled when a newly started server is in recovery mode
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463019#comment-13463019 ] Hoss Man commented on SOLR-3884: bq. 1) according to sarowe, he's seeing this problem (and his smoke test logs show tlog recovery) even when using a pristine copy of the unpack dir - so why is there a tlog in that case? Hmm.. talking with sarowe on IRC, i think there may be a bug in his patch ... he cloned the unpackDir he passes to testSolrExample, but i don't think testSolrExample actaully uses that unpack dir for anything, it appears to just run the example relative the CWD. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463030#comment-13463030 ] Yonik Seeley commented on SOLR-3884: bq. I've noticed that ^C in cygwin no longer works to stop the JVM. I think it might be this: http://cygwin.com/ml/cygwin/2012-07/msg00250.html The author does note that the Java shutdown hook is no longer called though. possible bug in how commits are handled during recovery mode on startup? -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463034#comment-13463034
]
Steven Rowe commented on SOLR-3884:
---
{quote}
Hmm.. talking with sarowe on IRC, i think there may be a bug in his patch ...
he cloned the unpackDir he passes to testSolrExample, but i don't think
testSolrExample actaully uses that unpack dir for anything, it appears to just
run the example relative the CWD.
{quote}
Yup, buggy patch, I didn't chdir to the unpacked copy, so it was still sharing
the original dir between the two runs. Here's the hopefully fixed patch:
{noformat}
Index: dev-tools/scripts/smokeTestRelease.py
===
--- dev-tools/scripts/smokeTestRelease.py (revision 1389823)
+++ dev-tools/scripts/smokeTestRelease.py (working copy)
@@ -533,12 +536,26 @@
if project == 'lucene':
testDemo(isSrc, version)
else:
+ print('copying unpacked distribution...')
+ java6UnpackPath = '%s-java6' %unpackPath
+ if os.path.exists(java6UnpackPath):
+shutil.rmtree(java6UnpackPath)
+ shutil.copytree(unpackPath, java6UnpackPath)
+ chdir(java6UnpackPath)
print('test solr example w/ Java 6...')
- testSolrExample(unpackPath, JAVA6_HOME, False)
+ testSolrExample(java6UnpackPath, JAVA6_HOME, False)
+ print('copying unpacked distribution...')
+ java7UnpackPath = '%s-java7' %unpackPath
+ if os.path.exists(java7UnpackPath):
+shutil.rmtree(java7UnpackPath)
+ shutil.copytree(unpackPath, java7UnpackPath)
+ chdir(java7UnpackPath)
print('test solr example w/ Java 7...')
- testSolrExample(unpackPath, JAVA7_HOME, False)
+ testSolrExample(java7UnpackPath, JAVA7_HOME, False)
+ chdir(unpackPath)
+
testChangesText('.', version, project)
{noformat}
possible bug in how commits are handled during recovery mode on startup?
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
I'm not certain, but looking at his logs, i think this suggests a bug in how
commits are handled when a newly started server is in recovery mode
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4426) New ValueSource implementations that wrap DocValues
[ https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463038#comment-13463038 ] Adrien Grand commented on LUCENE-4426: -- bq. How does this relate to NumericIndexDocValueSource? I didn't know about this class! Maybe the new classes of my patch could replace this one: * the objectVal method returns an object whose type matches the ValueSource name, * there is the StrDocValuesFieldSource to deal with DocValues.Type.BYTES* when they are UTF8-encoded Strings * they use a default source when the segment has no DocValues * they give the ability to load direct sources (My goal is to reuse them in SOLR-3855) bq. I am confused why the current one only handles 3 types? Right. Strange that it is able to deal with VAR_INTS but none of FIXED_INTS_*. New ValueSource implementations that wrap DocValues --- Key: LUCENE-4426 URL: https://issues.apache.org/jira/browse/LUCENE-4426 Project: Lucene - Core Issue Type: New Feature Components: modules/other Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4426.patch We should have ValueSource implementations that wrap DocValues in lucene-queries so that DocValues can be used in function queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463041#comment-13463041
]
Adrien Grand commented on LUCENE-4425:
--
bq. Maybe we should fix this for 4.0? It really is an API bug...
That would be great. Maybe we should first make sure that everyone agrees that
it is the codec responsability to make the copy.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-3884) possible bug in how commits are handled during recovery mode on startup?
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463034#comment-13463034
]
Steven Rowe edited comment on SOLR-3884 at 9/26/12 4:55 AM:
{quote}
Hmm.. talking with sarowe on IRC, i think there may be a bug in his patch ...
he cloned the unpackDir he passes to testSolrExample, but i don't think
testSolrExample actaully uses that unpack dir for anything, it appears to just
run the example relative the CWD.
{quote}
Yup, buggy patch, I didn't chdir to the unpacked copy, so it was still sharing
the original dir between the two runs. Here's the hopefully fixed patch:
*edit* {{chdir}} - {{os.chdir}}
{noformat}
Index: dev-tools/scripts/smokeTestRelease.py
===
--- dev-tools/scripts/smokeTestRelease.py (revision 1389823)
+++ dev-tools/scripts/smokeTestRelease.py (working copy)
@@ -533,12 +536,26 @@
if project == 'lucene':
testDemo(isSrc, version)
else:
+ print('copying unpacked distribution...')
+ java6UnpackPath = '%s-java6' %unpackPath
+ if os.path.exists(java6UnpackPath):
+shutil.rmtree(java6UnpackPath)
+ shutil.copytree(unpackPath, java6UnpackPath)
+ os.chdir(java6UnpackPath)
print('test solr example w/ Java 6...')
- testSolrExample(unpackPath, JAVA6_HOME, False)
+ testSolrExample(java6UnpackPath, JAVA6_HOME, False)
+ print('copying unpacked distribution...')
+ java7UnpackPath = '%s-java7' %unpackPath
+ if os.path.exists(java7UnpackPath):
+shutil.rmtree(java7UnpackPath)
+ shutil.copytree(unpackPath, java7UnpackPath)
+ os.chdir(java7UnpackPath)
print('test solr example w/ Java 7...')
- testSolrExample(unpackPath, JAVA7_HOME, False)
+ testSolrExample(java7UnpackPath, JAVA7_HOME, False)
+ os.chdir(unpackPath)
+
testChangesText('.', version, project)
{noformat}
was (Author: steve_rowe):
{quote}
Hmm.. talking with sarowe on IRC, i think there may be a bug in his patch ...
he cloned the unpackDir he passes to testSolrExample, but i don't think
testSolrExample actaully uses that unpack dir for anything, it appears to just
run the example relative the CWD.
{quote}
Yup, buggy patch, I didn't chdir to the unpacked copy, so it was still sharing
the original dir between the two runs. Here's the hopefully fixed patch:
{noformat}
Index: dev-tools/scripts/smokeTestRelease.py
===
--- dev-tools/scripts/smokeTestRelease.py (revision 1389823)
+++ dev-tools/scripts/smokeTestRelease.py (working copy)
@@ -533,12 +536,26 @@
if project == 'lucene':
testDemo(isSrc, version)
else:
+ print('copying unpacked distribution...')
+ java6UnpackPath = '%s-java6' %unpackPath
+ if os.path.exists(java6UnpackPath):
+shutil.rmtree(java6UnpackPath)
+ shutil.copytree(unpackPath, java6UnpackPath)
+ chdir(java6UnpackPath)
print('test solr example w/ Java 6...')
- testSolrExample(unpackPath, JAVA6_HOME, False)
+ testSolrExample(java6UnpackPath, JAVA6_HOME, False)
+ print('copying unpacked distribution...')
+ java7UnpackPath = '%s-java7' %unpackPath
+ if os.path.exists(java7UnpackPath):
+shutil.rmtree(java7UnpackPath)
+ shutil.copytree(unpackPath, java7UnpackPath)
+ chdir(java7UnpackPath)
print('test solr example w/ Java 7...')
- testSolrExample(unpackPath, JAVA7_HOME, False)
+ testSolrExample(java7UnpackPath, JAVA7_HOME, False)
+ chdir(unpackPath)
+
testChangesText('.', version, project)
{noformat}
possible bug in how commits are handled during recovery mode on startup?
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
I'm not certain, but looking at his logs, i think this suggests a bug in how
commits are handled when a newly started server is in recovery mode
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To
[jira] [Created] (SOLR-3888) need beter handling of external add/commit requests during tlog recovery
Hoss Man created SOLR-3888: -- Summary: need beter handling of external add/commit requests during tlog recovery Key: SOLR-3888 URL: https://issues.apache.org/jira/browse/SOLR-3888 Project: Solr Issue Type: Bug Affects Versions: 4.0 Reporter: Hoss Man Assignee: Yonik Seeley Fix For: 4.1 as noted in SOLR-3884: if Solr suffers an unclean-shutdown with documents in the tlog that have not been hard commited to the index, it is then possible that on the next startup tlog recovery will cause commits sent by external clients (ie: after indexing new documents) to be ignored. in general, we need to give more thought to edge causes of how updates during tlog recovery should be dealt with... * is there a non-solrcloud tlog recovery case we're handling poorly? * should all updates be blocked until tlog recovery finishes? * should tlog recovery be synchronized on UpdateHandler init so that solr isn't even listing on the port until it finishes? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4425:
Attachment: LUCENE-4425.patch
here's a patch (not tested) just to see what it would look like.
SolrIndexSearcher was ignoring offset and length too, if we dont fix this
issue, we should at least fix that.
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4425.patch
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4426) New ValueSource implementations that wrap DocValues
[ https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463060#comment-13463060 ] Robert Muir commented on LUCENE-4426: - I think the previous patch was done before additional fixed types were added. We could always deprecate the old one (probably should deprecate AND fix it if we do that). Your patch is better (e.g. checks hasArray, etc) from the implementation side. The only thing i dont get is if maybe it really should just be one class like the old one. I dont know why we need Int/Float versions of the classes when these implementations have things like intVal()/floatVal()/doubleVal()... New ValueSource implementations that wrap DocValues --- Key: LUCENE-4426 URL: https://issues.apache.org/jira/browse/LUCENE-4426 Project: Lucene - Core Issue Type: New Feature Components: modules/other Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.1, 5.0 Attachments: LUCENE-4426.patch We should have ValueSource implementations that wrap DocValues in lucene-queries so that DocValues can be used in function queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3884: --- Description: while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E The crux of the issue seems to be... * the same directory is reused for testing the example in java6 and then java7 * in some versions of cygwin, SIGINT does not do a clean shutdown of jetty+solr (with jvm close hooks that would do a hard commit) * when solr is shutdown uncleanly (the java6 run), the tlog is used on startup of the next (java7) run. * tlog recovery concurrent with rapid updates on startup can be problematic, commits may be ignored. The underlying questions about dealing with tlog recovery and concurrent updates from external clients have been spun off into SOLR-3888. this issue is focusing on changes that should be considered for the smoke tester. was: while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E I'm not certain, but looking at his logs, i think this suggests a bug in how commits are handled when a newly started server is in recovery mode Summary: smoke tester on cygwin fails when testing example due to tlog recovery (was: possible bug in how commits are handled during recovery mode on startup?) updated issue summary now that tlog questions have been spun off into SOLR-3888. For 4.0 we should focus on addressing the smoke tester to run the example in a more consistent way -- ie: not re-use the directory when running the example with diff jvms. We can always make the the smoke tester explicitly trigger tlog recoery and smoke test that as a distinct task (done in both jvms) as part of SOLR-3888 smoke tester on cygwin fails when testing example due to tlog recovery -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 4.0 Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E The crux of the issue seems to be... * the same directory is reused for testing the example in java6 and then java7 * in some versions of cygwin, SIGINT does not do a clean shutdown of jetty+solr (with jvm close hooks that would do a hard commit) * when solr is shutdown uncleanly (the java6 run), the tlog is used on startup of the next (java7) run. * tlog recovery concurrent with rapid updates on startup can be problematic, commits may be ignored. The underlying questions about dealing with tlog recovery and concurrent updates from external clients have been spun off into SOLR-3888. this issue is focusing on changes that should be considered for the smoke tester. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-3884: --- Fix Version/s: 4.0 smoke tester on cygwin fails when testing example due to tlog recovery -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 4.0 Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E The crux of the issue seems to be... * the same directory is reused for testing the example in java6 and then java7 * in some versions of cygwin, SIGINT does not do a clean shutdown of jetty+solr (with jvm close hooks that would do a hard commit) * when solr is shutdown uncleanly (the java6 run), the tlog is used on startup of the next (java7) run. * tlog recovery concurrent with rapid updates on startup can be problematic, commits may be ignored. The underlying questions about dealing with tlog recovery and concurrent updates from external clients have been spun off into SOLR-3888. this issue is focusing on changes that should be considered for the smoke tester. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463068#comment-13463068 ] Mark Miller commented on SOLR-3884: --- Yeah, it turns out my fail in the utf-8 test is a little different i noticed last night. Still don't know the root cause. Fails every time though. -- - Mark smoke tester on cygwin fails when testing example due to tlog recovery -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 4.0 Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E The crux of the issue seems to be... * the same directory is reused for testing the example in java6 and then java7 * in some versions of cygwin, SIGINT does not do a clean shutdown of jetty+solr (with jvm close hooks that would do a hard commit) * when solr is shutdown uncleanly (the java6 run), the tlog is used on startup of the next (java7) run. * tlog recovery concurrent with rapid updates on startup can be problematic, commits may be ignored. The underlying questions about dealing with tlog recovery and concurrent updates from external clients have been spun off into SOLR-3888. this issue is focusing on changes that should be considered for the smoke tester. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463070#comment-13463070 ] Mark Miller commented on SOLR-3861: --- Looks like as Yonik says in SOLR-3884, the final shutdown commit is explicit not something that comes from auto commit. And the searcher we may try to open and get a rejeceted execution on, is done after commit anyway. So I'm back to really not thinking this is a problem. The refactoring work done in the last patch is much better then what we have though. regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.1, 5.0 Attachments: SOLR-3861.patch, SOLR-3861.patch, SOLR-3861.patch SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[ https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe reassigned SOLR-3884: - Assignee: Steven Rowe smoke tester on cygwin fails when testing example due to tlog recovery -- Key: SOLR-3884 URL: https://issues.apache.org/jira/browse/SOLR-3884 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Steven Rowe Fix For: 4.0 Attachments: java6.solr-example.log, java7.solr-example.log, solr-example.log while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester script fail while sanity checking the solr example. https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E The crux of the issue seems to be... * the same directory is reused for testing the example in java6 and then java7 * in some versions of cygwin, SIGINT does not do a clean shutdown of jetty+solr (with jvm close hooks that would do a hard commit) * when solr is shutdown uncleanly (the java6 run), the tlog is used on startup of the next (java7) run. * tlog recovery concurrent with rapid updates on startup can be problematic, commits may be ignored. The underlying questions about dealing with tlog recovery and concurrent updates from external clients have been spun off into SOLR-3888. this issue is focusing on changes that should be considered for the smoke tester. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463100#comment-13463100
]
Steven Rowe commented on SOLR-3884:
---
{quote}
I think it might be this: http://cygwin.com/ml/cygwin/2012-07/msg00250.html
The author does note that the Java shutdown hook is no longer called though.
{quote}
In an earlier thread a workaround is given - from
[http://cygwin.com/ml/cygwin/2012-05/msg00482.html]:
{quote}
Since apparently nobody wants to take ownership of this regression
I'll point out the workaround, for the benefit of those googling
and landing on this thread: start Java with -Xrs and use Ctrl-Break
instead of Ctrl-C. This will disable thread dump and break any
application that relies on normal signal handling, though.
{quote}
smoke tester on cygwin fails when testing example due to tlog recovery
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Steven Rowe
Fix For: 4.0
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
The crux of the issue seems to be...
* the same directory is reused for testing the example in java6 and then java7
* in some versions of cygwin, SIGINT does not do a clean shutdown of
jetty+solr (with jvm close hooks that would do a hard commit)
* when solr is shutdown uncleanly (the java6 run), the tlog is used on
startup of the next (java7) run.
* tlog recovery concurrent with rapid updates on startup can be problematic,
commits may be ignored.
The underlying questions about dealing with tlog recovery and concurrent
updates from external clients have been spun off into SOLR-3888. this issue
is focusing on changes that should be considered for the smoke tester.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3889) SmokeTest fail on my Linux machine.
Mark Miller created SOLR-3889: - Summary: SmokeTest fail on my Linux machine. Key: SOLR-3889 URL: https://issues.apache.org/jira/browse/SOLR-3889 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: 4.0, 5.0 The smoketest fails in testUTF-8 every time on my system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3889) SmokeTest fail on my Linux machine.
[ https://issues.apache.org/jira/browse/SOLR-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463107#comment-13463107 ] Mark Miller commented on SOLR-3889: --- Hossman was worried this would get lost, so filing an issue here. More details in SOLR-3884 until they can be moved here. SmokeTest fail on my Linux machine. --- Key: SOLR-3889 URL: https://issues.apache.org/jira/browse/SOLR-3889 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: 4.0, 5.0 The smoketest fails in testUTF-8 every time on my system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4425) Unclear documentation of StoredFieldVisitor.binaryValue
[
https://issues.apache.org/jira/browse/LUCENE-4425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463145#comment-13463145
]
Michael McCandless commented on LUCENE-4425:
+1
Unclear documentation of StoredFieldVisitor.binaryValue
---
Key: LUCENE-4425
URL: https://issues.apache.org/jira/browse/LUCENE-4425
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.0
Reporter: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4425.patch
When reading the binary value of a stored field, a StoredFieldsReader calls
StoredFieldVisitor.binaryValue(arr, offset, length).
Documentation currently doesn't state whether the byte[] can be reused
outside of the scope of {{StoredFieldVisitor.binaryValue}} but
{{DocumentStoredFieldVisitor}} assumes (as of r1389812) that it can.
So {{DocumentStoredFieldVisitor}} would break with a custom
{{StoredFieldsFormat}} that would call {{StoredFieldVisitor.binaryValue}}
with a slice of a reusable buffer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463146#comment-13463146
]
Michael McCandless commented on SOLR-3879:
--
I'll fix smokeTestRelease to check for this ...
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated SOLR-3879:
-
Attachment: SOLR-3879.patch
Patch (against 4.0.x branch) for smokeTestRelease.py. It fails on the 4.0.0 RC
with this:
{noformat}
Traceback (most recent call last):
File dev-tools/scripts/smokeTestRelease.py, line 1161, in module
File dev-tools/scripts/smokeTestRelease.py, line 1109, in main
File dev-tools/scripts/smokeTestRelease.py, line 1151, in smokeTest
File dev-tools/scripts/smokeTestRelease.py, line 446, in unpack
File dev-tools/scripts/smokeTestRelease.py, line 558, in verifyUnpacked
File dev-tools/scripts/smokeTestRelease.py, line 177, in checkSolrWAR
RuntimeError: WAR file
/l/40x/tmp/unpack/apache-solr-4.0.0/example/webapps/solr.war contains JAR file
WEB-INF/lib/javax.servlet-api-3.0.1.jar with illegal class
javax/servlet/ServletSecurityElement.class
{noformat}
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463155#comment-13463155
]
Mark Miller commented on SOLR-3879:
---
Very nice.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3884) smoke tester on cygwin fails when testing example due to tlog recovery
[
https://issues.apache.org/jira/browse/SOLR-3884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved SOLR-3884.
---
Resolution: Fixed
Fix Version/s: 5.0
4.1
Committed the {{smokeTestRelease.py}} patch that starts each binary Solr
distribution example test with a clean copy of the unpacked distribution:
- lucene_solr_4_0: [r1390046|http://svn.apache.org/viewvc?rev=1390046view=rev]
- branch_4x: [r1390053|http://svn.apache.org/viewvc?rev=1390053view=rev]
- trunk: [r1390055|http://svn.apache.org/viewvc?rev=1390055view=rev]
smoke tester on cygwin fails when testing example due to tlog recovery
--
Key: SOLR-3884
URL: https://issues.apache.org/jira/browse/SOLR-3884
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Steven Rowe
Fix For: 4.0, 4.1, 5.0
Attachments: java6.solr-example.log, java7.solr-example.log,
solr-example.log
while testing out 4.0-rc0, sarowe noted the he was seeing the smoke tester
script fail while sanity checking the solr example.
https://mail-archives.apache.org/mod_mbox/lucene-dev/201209.mbox/%3c6c78e97c707b5b4c8cc61d44f87545863ed...@suex10-mbx-03.ad.syr.edu%3E
The crux of the issue seems to be...
* the same directory is reused for testing the example in java6 and then java7
* in some versions of cygwin, SIGINT does not do a clean shutdown of
jetty+solr (with jvm close hooks that would do a hard commit)
* when solr is shutdown uncleanly (the java6 run), the tlog is used on
startup of the next (java7) run.
* tlog recovery concurrent with rapid updates on startup can be problematic,
commits may be ignored.
The underlying questions about dealing with tlog recovery and concurrent
updates from external clients have been spun off into SOLR-3888. this issue
is focusing on changes that should be considered for the smoke tester.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463161#comment-13463161
]
Uwe Schindler commented on SOLR-3879:
-
We should maybe also do the same check on all Lucene-generated jar files?
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463163#comment-13463163
]
Michael McCandless commented on SOLR-3879:
--
Uwe, good idea: I'll do that.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3890) release artifacts include solr.war file twice
Michael McCandless created SOLR-3890: Summary: release artifacts include solr.war file twice Key: SOLR-3890 URL: https://issues.apache.org/jira/browse/SOLR-3890 Project: Solr Issue Type: Improvement Reporter: Michael McCandless Working on SOLR-3879 I noticed that the solr.war appears twice in our released .tgz/.zip binary artifacts: * example/webapps/solr.war * dist/apache-solr-4.0.0.war It's of course a big file (~15 MB for 4.0.0) so it would be best if we could only include it once ... but maybe we do this so the example is easy to run? Seems silly though ... Definitely NOT a blocker for 4.0.0... (eg 3.6.0 also dups the WAR). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated SOLR-3879:
-
Attachment: SOLR-3879.patch
Patch, also checking all *.jar in Lucene's binary releases.
I had to exclude lucene/demo/lib since it ships servlet-api-2.4.jar. (Should
we remove that demo webapp?).
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4427) remove webapp from lucene/demo
Michael McCandless created LUCENE-4427: -- Summary: remove webapp from lucene/demo Key: LUCENE-4427 URL: https://issues.apache.org/jira/browse/LUCENE-4427 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Spinoff of SOLR-3879: I think the webapp in lucene/demo is a poor demo ... we should remove it. EG it does not close its IndexReader, it uses the [very expert] XML QueryParser, it passes Version.LUCENE_CURRENT when creating the StandardAnalyzer ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463188#comment-13463188
]
Robert Muir commented on SOLR-3879:
---
+1 to commit mike's latest patch (the test) and Roman's patch (the fix). this
should be done in 4.0 branch as well.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned SOLR-3879:
Assignee: Michael McCandless
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Assignee: Michael McCandless
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4426) New ValueSource implementations that wrap DocValues
[
https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4426:
-
Attachment: LUCENE-4426.patch
Right, it makes sense to have all numeric types in the same class. Here is a
new patch that also adds FIXED_INTS_* support to {{NumericIndexDocValueSource}}
and adds a deprecation notice.
New ValueSource implementations that wrap DocValues
---
Key: LUCENE-4426
URL: https://issues.apache.org/jira/browse/LUCENE-4426
Project: Lucene - Core
Issue Type: New Feature
Components: modules/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Fix For: 4.1, 5.0
Attachments: LUCENE-4426.patch, LUCENE-4426.patch
We should have ValueSource implementations that wrap DocValues in
lucene-queries so that DocValues can be used in function queries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3879) war file has javax.servlet-api jar bundled
[
https://issues.apache.org/jira/browse/SOLR-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463199#comment-13463199
]
Uwe Schindler commented on SOLR-3879:
-
Looks good! My intention was to only check all Lucene product artifacts (not
dependencies and compile time depends), but its a good idea to also find
invalid artifacts from other projects. In Solr, of course the example folder
must be excluded, too as it contains jetty, too.
war file has javax.servlet-api jar bundled
--
Key: SOLR-3879
URL: https://issues.apache.org/jira/browse/SOLR-3879
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Roman Shaposhnik
Assignee: Michael McCandless
Priority: Critical
Fix For: 4.0
Attachments: SOLR-3879.patch, SOLR-3879.patch, SOLR-3879.patch.txt
This is incorrect and can lead to deployment issues:
{noformat}
Servlet Spec 2.5
SRV.9.7.2 Web Application Class Loader
The class loader that a container uses to load a servlet in a WAR must
allow the developer to load any resources contained in library JARs
within the WAR following normal J2SE semantics using getResource. As
described in the J2EE license agreement, servlet containers that are
not part of a J2EE product should not allow the application to
override J2SE platform classes, such as those in the java.* and
javax.* namespaces, that J2SE does not allow to be modified. Also,
servlet containers that are part of a J2EE product should not allow
the application to override J2SE or J2EE platform classes, such as
those in java.* and javax.* namespaces, that either J2SE or J2EE do
not allow to be modified. The container should not allow applications
to override or access the container’s implementation
{noformat}
The fix is pretty easy and it would be nice to include it in the upcoming
release of Solr 4.0
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
