RE: verbose logging
Yeah, it would be nice to have those, because with the Jenkins Web GUI you could then inspect stdout from each test, like that one from forbiddenAPIs: http://jenkins.thetaphi.de/job/Forbidden-APIs/119/testReport/src.test.antunit/TestClassDeclaration_xml/testForbiddenExtends/? Can we maybe limit the amount and only have something like "tail -", so you get at least the recent stdout. I know that the plain text files are easier to write/manage, but the XML files are good for inspection of test output with Jenkins. Currently the XML output is only filled when test fail. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf > Of Dawid Weiss > Sent: Tuesday, March 05, 2013 8:00 AM > To: dev@lucene.apache.org > Subject: Re: verbose logging > > common-build.xml: > > > outputStreams="no" /> > > Like I said though -- I would *not* bring stdout/stderr back to those XML > files > unless you want to deal with other problems resulting from > 10+mb XML files. They also take a lot longer to serialize/ save than > just plain text output. > > Dawid > > > On Tue, Mar 5, 2013 at 7:58 AM, Dawid Weiss > wrote: > >> I though the XML report files contain the whole stdout? > >> > >> http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/ws/solr/build/so > >> lr-core/test/TEST-org.apache.solr.update.TestAtomicUpdateErrorCases.x > >> ml > >> > >> But its empty... This would be the most "correct" variant. I know that by > default stock JUnit saves the whole stdout/stderr in the XML file, but JUnit4 > runner does not seem to do this? > > > > I used to emit stdout to those XML files but Solr emits so much > > logging information from certain tests that it got XML parsers/ > > transformers hit OOM a few times on jenkins... I disabled it > > intentionally. Those plain-text files are still saved and they're more > > compact than XML output. I kept the XML output so that jenkins has > > stuff for its own analysis pipeline but standard output is not needed > > there. > > > > Dawid > > - > 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
Re: verbose logging
common-build.xml: Like I said though -- I would *not* bring stdout/stderr back to those XML files unless you want to deal with other problems resulting from 10+mb XML files. They also take a lot longer to serialize/ save than just plain text output. Dawid On Tue, Mar 5, 2013 at 7:58 AM, Dawid Weiss wrote: >> I though the XML report files contain the whole stdout? >> >> http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/ws/solr/build/solr-core/test/TEST-org.apache.solr.update.TestAtomicUpdateErrorCases.xml >> >> But its empty... This would be the most "correct" variant. I know that by >> default stock JUnit saves the whole stdout/stderr in the XML file, but >> JUnit4 runner does not seem to do this? > > I used to emit stdout to those XML files but Solr emits so much > logging information from certain tests that it got XML parsers/ > transformers hit OOM a few times on jenkins... I disabled it > intentionally. Those plain-text files are still saved and they're more > compact than XML output. I kept the XML output so that jenkins has > stuff for its own analysis pipeline but standard output is not needed > there. > > Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: verbose logging
> I though the XML report files contain the whole stdout? > > http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/ws/solr/build/solr-core/test/TEST-org.apache.solr.update.TestAtomicUpdateErrorCases.xml > > But its empty... This would be the most "correct" variant. I know that by > default stock JUnit saves the whole stdout/stderr in the XML file, but JUnit4 > runner does not seem to do this? I used to emit stdout to those XML files but Solr emits so much logging information from certain tests that it got XML parsers/ transformers hit OOM a few times on jenkins... I disabled it intentionally. Those plain-text files are still saved and they're more compact than XML output. I kept the XML output so that jenkins has stuff for its own analysis pipeline but standard output is not needed there. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4503) Add REST API methods to get schema information: fields, dynamicFields, fieldTypes, and copyFields
[
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-4503:
-
Attachment: SOLR-4503.patch
{quote}
Also related: SOLR-4210
We should aim for being able to hit any node in the cluster w/o worrying about
which nodes are hosting which collections.
{quote}
I set up a cluster with two collections with different configurations so I
could easily verify I was getting responses from the right collection. Turns
out that the schema info GET requests were being converted into POST requests
as a side-effect of calling {{con.getOutputStream()}} in
{{SolrDispatchFilter.remoteQuery()}}, and failing as a result. In the patch
snippet below, which is included in the attached patch, I skip forwarding the
request body unless the original request's method is POST:
{code:java}
@@ -353,13 +365,17 @@
try {
con.connect();
-InputStream is = req.getInputStream();
-OutputStream os = con.getOutputStream();
-try {
- IOUtils.copyLarge(is, os);
-} finally {
- IOUtils.closeQuietly(os);
- IOUtils.closeQuietly(is); // TODO: I thought we weren't supposed to
explicitly close servlet streams
+InputStream is;
+OutputStream os;
+if ("POST".equals(req.getMethod())) {
+ is = req.getInputStream();
+ os = con.getOutputStream(); // side effect: method is switched to
POST
+ try {
+IOUtils.copyLarge(is, os);
+ } finally {
+IOUtils.closeQuietly(os);
+IOUtils.closeQuietly(is); // TODO: I thought we weren't supposed
to explicitly close servlet streams
+ }
}
resp.setStatus(con.getResponseCode());
{code}
The patch also contains some fixed tests for the schema REST API (I didn't
update the tests after I removed printing of copyField maxChars when it's zero).
'ant test' under Solr passes, as does 'ant precommit'.
If there are no objections, I'll commit this form of the patch in a day or so.
> Add REST API methods to get schema information: fields, dynamicFields,
> fieldTypes, and copyFields
> -
>
> Key: SOLR-4503
> URL: https://issues.apache.org/jira/browse/SOLR-4503
> Project: Solr
> Issue Type: Sub-task
> Components: Schema and Analysis
>Affects Versions: 4.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 4.2
>
> Attachments: all.dynamic.fields.json, all.dynamic.fields.json,
> all.fields.json, all.fields.json, all.field.types.json, all.field.types.json,
> coordinate.dynamic.field.json, coordinate.dynamic.field.json,
> copyfields.json, date.field.type.json, date.field.type.json,
> price.field.json, price.field.json, SOLR-4503.patch, SOLR-4503.patch,
> SOLR-4503.patch, SOLR-4503.patch
>
>
> Add REST methods that provide properties for fields, dynamicFields,
> fieldTypes, and copyFields, using paths:
> /solr/(corename)/schema/fields
> /solr/(corename)/schema/fields/fieldname
> /solr/(corename)/schema/dynamicfields
> /solr/(corename)/schema/dynamicfields/pattern
> /solr/(corename)/schema/fieldtypes
> /solr/(corename)/schema/fieldtypes/typename
> /solr/(corename)/schema/copyfields
--
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-3239) DocTransformer for formatting CurrencyField as a virtual field
[
https://issues.apache.org/jira/browse/SOLR-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3239:
---
Summary: DocTransformer for formatting CurrencyField as a virtual field
(was: Function for returning a CurrencyField as a virtual field)
FYI: SOLR-4138 added a currency(...) function like the one i proposed. the
only thing left is a DocTransformer for arbitrary currency formatting.
> DocTransformer for formatting CurrencyField as a virtual field
> --
>
> Key: SOLR-3239
> URL: https://issues.apache.org/jira/browse/SOLR-3239
> Project: Solr
> Issue Type: New Feature
>Reporter: Jan Høydahl
> Fix For: 4.2, 5.0
>
>
> With the new CurrencyField from SOLR-2202, we can now do range queries, sort
> and soon faceting on CurrencyField.
> One thing we cannot do is return a converted value. We can only return the
> stored value which must be in the same currency as it was entered, e.g.
> "10.0,USD". People now have to do this conversion in application layer,
> reading the same currency.xml file as in Solr. This is a mess to keep in
> sync, and is hard to support with other ExchangeRateProviders or in other
> client languages than Java.
> This patch should implement a Function which takes a field name and requested
> currency as input and returns the converted value. Optionally it could also
> take care of localized display, e.g. "$10.0" instead of "10.0,USD". Proposed
> syntax:
> {code}
> &fl=title,price:currency(price_c,EUR) # Returns price_c in EUR as
> "price"
> &fl=title,price:currency(price_c,EUR,en_US) # Returns price_c in EUR,
> formatted according to en_US locale
> {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
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 1040 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/1040/ All tests passed Build Log: [...truncated 21322 lines...] check-licenses: [echo] License check under: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:381: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:67: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/solr/build.xml:234: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 78 minutes 23 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts 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_15) - Build # 4543 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4543/ Java: 32bit/jdk1.7.0_15 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 21428 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:381: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:67: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:234: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 42 minutes 55 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_15 -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
[jira] [Commented] (SOLR-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592937#comment-13592937 ] Commit Tag Bot commented on SOLR-4416: -- [branch_4x commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1452629 SOLR-4416: fix SHA files for tika upgrade (merge r1452626) > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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 (64bit/jdk1.6.0_41) - Build # 4573 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/4573/ Java: 64bit/jdk1.6.0_41 -XX:+UseParallelGC All tests passed Build Log: [...truncated 20437 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:381: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:234: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 43 minutes 51 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.6.0_41 -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-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592923#comment-13592923 ] Commit Tag Bot commented on SOLR-4416: -- [trunk commit] Chris M. Hostetter http://svn.apache.org/viewvc?view=revision&revision=1452626 SOLR-4416: fix SHA files for tika upgrade > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 289 - Failure!
FYI: SHA fix in progress... waiting on precommit. : Date: Tue, 5 Mar 2013 01:00:56 + (UTC) : From: Policeman Jenkins Server : Reply-To: dev@lucene.apache.org : To: dev@lucene.apache.org, hoss...@apache.org, mikemcc...@apache.org, : markrmil...@apache.org : Subject: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 289 - : Failure! : : Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/289/ : Java: 64bit/jdk1.7.0 -XX:+UseSerialGC : : All tests passed : : Build Log: : [...truncated 21132 lines...] : check-licenses: : [echo] License check under: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/fontbox-1.7.1.jar : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/jempbox-1.7.1.jar : : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/pdfbox-1.7.1.jar : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/tika-core-1.3.jar : [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/tika-parsers-1.3.jar : : [...truncated 1 lines...] : BUILD FAILED : /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:381: The following error occurred while executing this line: : /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:67: The following error occurred while executing this line: : /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:234: The following error occurred while executing this line: : /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. : : Total time: 81 minutes 34 seconds : Build step 'Invoke Ant' marked build as failure : Archiving artifacts : Recording test results : Description set: Java: 64bit/jdk1.7.0 -XX:+UseSerialGC : Email was triggered for: Failure : Sending email for trigger: Failure : : : -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4524) ReturnFields could not support hash '#' in filed name
[
https://issues.apache.org/jira/browse/SOLR-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592897#comment-13592897
]
Commit Tag Bot commented on SOLR-4524:
--
[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1452613
SOLR-4524: test proving this works (merge r1452612)
> ReturnFields could not support hash '#' in filed name
> --
>
> Key: SOLR-4524
> URL: https://issues.apache.org/jira/browse/SOLR-4524
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.1
>Reporter: Benjamin POUSSIN
>Assignee: Hoss Man
> Labels: field, fl, query, queryparser
>
> If some fields start with '#' and we try to put it in fl param, this field
> and all next fields are not in response document
> With query:
> q=*:*&fl=score,#id,myOtherField
> Document response is like:
>SolrDocument{score=3.809621}
> this bug is similar to SOLR-2719 and SOLR-4374
--
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: Ability to specify 2 different query analyzers for same indexed field in Solr
Tom: I wonder if you could do something with payloads here. Index all terms with payloads of 10, but synonyms with 1? Random thought off the top of my head. Erick On Mon, Mar 4, 2013 at 6:25 PM, Tom Burton-West wrote: > Hi Jack, > > Sorry the example is not clear. Below is the normal way to accomplish > what I am trying to do using a copyField and two separate fieldTypes with > the index analyzer the same but the query time analyzer different. > > So the query would be something like q=plain:foobar^10 OR syn:foobar^1 to > get synonyms but scored much lower than an exact match. > > The problem with this is since the analysis chain used for indexing is the > same in both cases, I would rather not have to actually index the exact > same content in the exact same way twice. > > Does that make it any clearer or do I need a more compelling use case? > > Tom > > > > > > > > > > > > > > > > > > > > > ignoreCase="true" expand="true"/> > > > > > On Mon, Mar 4, 2013 at 4:43 PM, Jack Krupansky wrote: > >> Please clarify, and try providing a couple more use cases. I mean, the >> case you provided suggests that the contents of the index will be different >> between the two fields, while you told us that you wanted to share the same >> indexed field. In other words, it sounds like you will have two copies of >> similar data anyway. >> >> Maybe you simply want one copy of the stored value for the field and then >> have one or more copyfields that index the same source data differently, >> but don’t re-store the copied source data. >> >> -- Jack Krupansky >> >> *From:* Tom Burton-West >> *Sent:* Monday, March 04, 2013 3:57 PM >> *To:* dev@lucene.apache.org >> *Subject:* Ability to specify 2 different query analyzers for same >> indexed field in Solr >> >> Hello, >> >> We would like to be able to specify two different fields that both use >> the same indexed field but use different analyzers. An example use-case >> for this might be doing query-time synonym expansion with the synonyms >> weighted lower than an exact match. >> >> q=exact_field^10 OR synonyms^1 >> >> The normal way to do this in Solr, which is just to set up separate >> analyzer chains and use a copyfield, will not work for us because the field >> in question is huge. It is about 7 TB of OCR. >> >> Is there a way to do this currently in Solr? If not , >> >> 1) should I open a JIRA issue? >> 2) can someone point me towards the part of the code I might need to >> modify? >> >> Tom >> >> Tom Burton-West >> Information Retrieval Programmer >> Digital Library Production Service >> University of Michigan Library >> http://www.hathitrust.org/blogs/large-scale-search >> >> >> > >
[jira] [Comment Edited] (SOLR-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592892#comment-13592892 ] Hoss Man edited comment on SOLR-4416 at 3/5/13 1:17 AM: This is causing build failures because of SHA & license checking on -transient- jars EDIT: the problem isn't actually transitive dependencies, the jars with SHA problems are explicitly listed, but their SHA files weren't updated. was (Author: hossman): This is causing build failures because of SHA & license checking on transient jars > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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] [Reopened] (SOLR-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened SOLR-4416: This is causing build failures because of SHA & license checking on transient jars > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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-4524) ReturnFields could not support hash '#' in filed name
[
https://issues.apache.org/jira/browse/SOLR-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-4524.
Resolution: Cannot Reproduce
Tests added...
Committed revision 1452612.
Committed revision 1452613.
> ReturnFields could not support hash '#' in filed name
> --
>
> Key: SOLR-4524
> URL: https://issues.apache.org/jira/browse/SOLR-4524
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.1
>Reporter: Benjamin POUSSIN
>Assignee: Hoss Man
> Labels: field, fl, query, queryparser
>
> If some fields start with '#' and we try to put it in fl param, this field
> and all next fields are not in response document
> With query:
> q=*:*&fl=score,#id,myOtherField
> Document response is like:
>SolrDocument{score=3.809621}
> this bug is similar to SOLR-2719 and SOLR-4374
--
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-4524) ReturnFields could not support hash '#' in filed name
[
https://issues.apache.org/jira/browse/SOLR-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592885#comment-13592885
]
Commit Tag Bot commented on SOLR-4524:
--
[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1452612
SOLR-4524: test proving this works
> ReturnFields could not support hash '#' in filed name
> --
>
> Key: SOLR-4524
> URL: https://issues.apache.org/jira/browse/SOLR-4524
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.1
>Reporter: Benjamin POUSSIN
>Assignee: Hoss Man
> Labels: field, fl, query, queryparser
>
> If some fields start with '#' and we try to put it in fl param, this field
> and all next fields are not in response document
> With query:
> q=*:*&fl=score,#id,myOtherField
> Document response is like:
>SolrDocument{score=3.809621}
> this bug is similar to SOLR-2719 and SOLR-4374
--
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.7.0_15) - Build # 4542 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4542/ Java: 32bit/jdk1.7.0_15 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 21252 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:381: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:67: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:234: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 61 minutes 7 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_15 -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-trunk-MacOSX (64bit/jdk1.7.0) - Build # 289 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/289/ Java: 64bit/jdk1.7.0 -XX:+UseSerialGC All tests passed Build Log: [...truncated 21132 lines...] check-licenses: [echo] License check under: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:381: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:67: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:234: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 81 minutes 34 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.7.0 -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
[jira] [Comment Edited] (LUCENE-4694) Add back IndexReader.fields() -> Multi*, or discourage term vectors in some better way
[ https://issues.apache.org/jira/browse/LUCENE-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592819#comment-13592819 ] Uwe Schindler edited comment on LUCENE-4694 at 3/5/13 12:03 AM: Mike: If you really, really want to move it up: - Make fields() abstract in IndexReader, only add the final methods that delegate to the abstract one - leave fields() abstract in AtomicReader and CompositeReader, too - add the MultiFields implementation into BaseCompositeReader -> and only there (maybe final) - the javadocs with warning are only in CompositeReader The current patch is as worse as IndexReader before the split into composite/atomic! IndexReader is an abstract class without concrete implementations. The final methods only delegate to abstract methods, so they are no "implementations". But I don't like the whole thing in general. Just because few users are doing those thing, we should never ever expose postings on composite readers. In my opinion, the term vectors should simply go away? Stored fields with the binary search are only there to make "result display" possible. Maybe we should remove stored fields from IndexReader base class, too. Instead stored field are only accessible through IndexSearcher (which delegates using its reader contexts)? was (Author: thetaphi): Mike: If you really, really want to move it up: - Make fields() abstract in IndexReader, only add the final methods that delegate to the abstract one - leave fields() abstract in AtomicReader and CompositeReader, too - add the MultiFields implementation into BaseCompositeReader -> and only there (maybe final) The current patch is as worse as IndexReader before the split into composite/atomic! IndexReader is an abstract class without concrete implementations. The final methods only delegate to abstract methods, so they are no "implementations". > Add back IndexReader.fields() -> Multi*, or discourage term vectors in some > better way > -- > > Key: LUCENE-4694 > URL: https://issues.apache.org/jira/browse/LUCENE-4694 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4694.patch > > > Users can easily get term vectors from any indexreader, but not postings > lists. this encourages them to do really slow things: like pulling term > vectors for every single document. > this is really really so much worse than going through multifields or > whatever. -- 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-4694) Add back IndexReader.fields() -> Multi*, or discourage term vectors in some better way
[ https://issues.apache.org/jira/browse/LUCENE-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592819#comment-13592819 ] Uwe Schindler commented on LUCENE-4694: --- Mike: If you really, really want to move it up: - Make fields() abstract in IndexReader, only add the final methods that delegate to the abstract one - leave fields() abstract in AtomicReader and CompositeReader, too - add the MultiFields implementation into BaseCompositeReader -> and only there (maybe final) The current patch is as worse as IndexReader before the split into composite/atomic! IndexReader is an abstract class without concrete implementations. The final methods only delegate to abstract methods, so they are no "implementations". > Add back IndexReader.fields() -> Multi*, or discourage term vectors in some > better way > -- > > Key: LUCENE-4694 > URL: https://issues.apache.org/jira/browse/LUCENE-4694 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4694.patch > > > Users can easily get term vectors from any indexreader, but not postings > lists. this encourages them to do really slow things: like pulling term > vectors for every single document. > this is really really so much worse than going through multifields or > whatever. -- 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-MAVEN] Lucene-Solr-Maven-trunk #790: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/790/ 1 tests failed. REGRESSION: org.apache.solr.cloud.SyncSliceTest.testDistribSearch Error Message: Test Setup Failure: shard1 should have just been set up to be inconsistent - but it's still consistent. Leader:http://127.0.0.1:35140/zv/collection1skip list:[CloudJettyRunner [url=http://127.0.0.1:28486/zv/collection1], CloudJettyRunner [url=http://127.0.0.1:28486/zv/collection1]] Stack Trace: java.lang.AssertionError: Test Setup Failure: shard1 should have just been set up to be inconsistent - but it's still consistent. Leader:http://127.0.0.1:35140/zv/collection1skip list:[CloudJettyRunner [url=http://127.0.0.1:28486/zv/collection1], CloudJettyRunner [url=http://127.0.0.1:28486/zv/collection1]] at __randomizedtesting.SeedInfo.seed([4510B6D6F811A0C3:C4F638CE8F4EC0FF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:212) Build Log: [...truncated 22634 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4694) Add back IndexReader.fields() -> Multi*, or discourage term vectors in some better way
[ https://issues.apache.org/jira/browse/LUCENE-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592812#comment-13592812 ] Uwe Schindler commented on LUCENE-4694: --- Oh my god :( > Add back IndexReader.fields() -> Multi*, or discourage term vectors in some > better way > -- > > Key: LUCENE-4694 > URL: https://issues.apache.org/jira/browse/LUCENE-4694 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4694.patch > > > Users can easily get term vectors from any indexreader, but not postings > lists. this encourages them to do really slow things: like pulling term > vectors for every single document. > this is really really so much worse than going through multifields or > whatever. -- 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-4694) Add back IndexReader.fields() -> Multi*, or discourage term vectors in some better way
[ https://issues.apache.org/jira/browse/LUCENE-4694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-4694: --- Attachment: LUCENE-4694.patch Patch, moving the postings APIs up from AR to IR, and calling MultiFields.getFields by default. > Add back IndexReader.fields() -> Multi*, or discourage term vectors in some > better way > -- > > Key: LUCENE-4694 > URL: https://issues.apache.org/jira/browse/LUCENE-4694 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4694.patch > > > Users can easily get term vectors from any indexreader, but not postings > lists. this encourages them to do really slow things: like pulling term > vectors for every single document. > this is really really so much worse than going through multifields or > whatever. -- 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: Ability to specify 2 different query analyzers for same indexed field in Solr
Hi Jack, Sorry the example is not clear. Below is the normal way to accomplish what I am trying to do using a copyField and two separate fieldTypes with the index analyzer the same but the query time analyzer different. So the query would be something like q=plain:foobar^10 OR syn:foobar^1 to get synonyms but scored much lower than an exact match. The problem with this is since the analysis chain used for indexing is the same in both cases, I would rather not have to actually index the exact same content in the exact same way twice. Does that make it any clearer or do I need a more compelling use case? Tom On Mon, Mar 4, 2013 at 4:43 PM, Jack Krupansky wrote: > Please clarify, and try providing a couple more use cases. I mean, the > case you provided suggests that the contents of the index will be different > between the two fields, while you told us that you wanted to share the same > indexed field. In other words, it sounds like you will have two copies of > similar data anyway. > > Maybe you simply want one copy of the stored value for the field and then > have one or more copyfields that index the same source data differently, > but don’t re-store the copied source data. > > -- Jack Krupansky > > *From:* Tom Burton-West > *Sent:* Monday, March 04, 2013 3:57 PM > *To:* dev@lucene.apache.org > *Subject:* Ability to specify 2 different query analyzers for same > indexed field in Solr > > Hello, > > We would like to be able to specify two different fields that both use the > same indexed field but use different analyzers. An example use-case for > this might be doing query-time synonym expansion with the synonyms weighted > lower than an exact match. > > q=exact_field^10 OR synonyms^1 > > The normal way to do this in Solr, which is just to set up separate > analyzer chains and use a copyfield, will not work for us because the field > in question is huge. It is about 7 TB of OCR. > > Is there a way to do this currently in Solr? If not , > > 1) should I open a JIRA issue? > 2) can someone point me towards the part of the code I might need to > modify? > > Tom > > Tom Burton-West > Information Retrieval Programmer > Digital Library Production Service > University of Michigan Library > http://www.hathitrust.org/blogs/large-scale-search > > >
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_41) - Build # 4571 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/4571/ Java: 32bit/jdk1.6.0_41 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 20411 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:381: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:67: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:234: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 50 minutes 19 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.6.0_41 -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] [Closed] (SOLR-600) XML parser stops working under heavy load
[ https://issues.apache.org/jira/browse/SOLR-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-600. Resolution: Cannot Reproduce Closing as this seems not to be an issue with current versions. Please re-open if you discover this again. > XML parser stops working under heavy load > - > > Key: SOLR-600 > URL: https://issues.apache.org/jira/browse/SOLR-600 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.3 > Environment: Linux 2.6.19.7-ss0 #4 SMP Wed Mar 12 02:56:42 GMT 2008 > x86_64 Intel(R) Xeon(R) CPU X5450 @ 3.00GHz GenuineIntel GNU/Linux > Tomcat 6.0.16 > SOLR nightly 16 Jun 2008, and versions prior > JRE 1.6.0 >Reporter: John Smith > > Under heavy load, the following is spat out for every update: > org.apache.solr.common.SolrException log > SEVERE: java.lang.NullPointerException > at java.util.AbstractList$SimpleListIterator.hasNext(Unknown Source) > at > org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:225) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:66) > at > org.apache.solr.handler.XmlUpdateRequestHandler.processUpdate(XmlUpdateRequestHandler.java:196) > at > org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpdateRequestHandler.java:123) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:735) -- 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-3459) Change ChainedFilter to use FixedBitSet
[ https://issues.apache.org/jira/browse/LUCENE-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592746#comment-13592746 ] Uwe Schindler commented on LUCENE-3459: --- If you look into the details of usage, you will see recognize that OpenBitSet is only usd by Solr. Lucene does not use it anymore except at these few places. ChainedFilter needs some additional bit operations, FixedBitSet currently does not support. Performance-wise FixedBitSet is better for filters because it has less checks and does not support resize (the bit set size is fixed). > Change ChainedFilter to use FixedBitSet > --- > > Key: LUCENE-3459 > URL: https://issues.apache.org/jira/browse/LUCENE-3459 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 3.4, 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.2 > > > ChainedFilter also uses OpenBitSet(DISI) at the moment. It should also be > changed to use FixedBitSet. There are two issues: > - It exposes sometimes OpenBitSetDISI to it's public API - we should remove > those methods like in BooleanFilter and break backwards > - It allows a XOR operation. This is not yet supported by FixedBitSet, but > it's easy to add (like for BooleanFilter). On the other hand, this XOR > operation is bogus, as it may mark documents in the BitSet that are deleted, > breaking new features like applying Filters down-low (LUCENE-1536). We should > remove the XOR operation maybe or force it to use IR.validDocs() (trunk) or > IR.isDeleted() -- 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-3459) Change ChainedFilter to use FixedBitSet
[ https://issues.apache.org/jira/browse/LUCENE-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592740#comment-13592740 ] David Smiley commented on LUCENE-3459: -- Ha! I was just about to report the reverse problem -- make TermsFilter return OpenBitset for optimal compatibility with ChainedFilter. I'm using TermsFilters with ChainedFilter and the mis-match of OpenBitSet and FixedBitSet is definitely not optimal since I want it to intersect those bitsets together quickly. I don't understand why there are both. My IDE says FixedBitSet has 206 usages compared to OpenBitSet's 230. That's closer than I thought. I recall [~thetaphi] saying he would like OBS deprecated, but I pointed out that it is OBS that is fully public and FixedBitSet that is marked as @lucene.internal. > Change ChainedFilter to use FixedBitSet > --- > > Key: LUCENE-3459 > URL: https://issues.apache.org/jira/browse/LUCENE-3459 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 3.4, 4.0-ALPHA >Reporter: Uwe Schindler >Assignee: Uwe Schindler > Fix For: 4.2 > > > ChainedFilter also uses OpenBitSet(DISI) at the moment. It should also be > changed to use FixedBitSet. There are two issues: > - It exposes sometimes OpenBitSetDISI to it's public API - we should remove > those methods like in BooleanFilter and break backwards > - It allows a XOR operation. This is not yet supported by FixedBitSet, but > it's easy to add (like for BooleanFilter). On the other hand, this XOR > operation is bogus, as it may mark documents in the BitSet that are deleted, > breaking new features like applying Filters down-low (LUCENE-1536). We should > remove the XOR operation maybe or force it to use IR.validDocs() (trunk) or > IR.isDeleted() -- 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_15) - Build # 4540 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4540/ Java: 64bit/jdk1.7.0_15 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 21446 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/fontbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/jempbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/metadata-extractor-2.6.2.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/pdfbox-1.7.1.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-core-1.3.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/contrib/extraction/lib/tika-parsers-1.3.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:381: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:67: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/solr/build.xml:234: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:43: License check failed. Check the logs. Total time: 48 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.7.0_15 -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] [Commented] (LUCENE-4810) Positions are incremented for each ngram in EdgeNGramTokenFilter
[ https://issues.apache.org/jira/browse/LUCENE-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592711#comment-13592711 ] David Smiley commented on LUCENE-4810: -- +1 > Positions are incremented for each ngram in EdgeNGramTokenFilter > > > Key: LUCENE-4810 > URL: https://issues.apache.org/jira/browse/LUCENE-4810 > Project: Lucene - Core > Issue Type: Bug > Components: modules/analysis >Reporter: Walter Underwood > Attachments: LUCENE-4810.diff > > > Edge ngrams should be like synonyms, with all the ngrams generated from a > token having the same position as that original token. The current code > increments position. > For the text "molecular biology", the query "mol bio" should match as a > phrase in neighboring positions. It does not. > You can see this in the Analysis page in the admin UI. -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592685#comment-13592685 ] Uwe Schindler commented on SOLR-4526: - The general problem here is the admin UI, as mentioned by Felix. The output of the MX data is very JVM-specific, so the UI should not rely on key/value pairs are always available. If you e.g. start Solr with IBM J9, the whole Andmin UI shows nothing at all for those statistics, same for JRockit. If you look into browser JS logs you see errors about missing keys. The RequestHandler on the Solr side is fine and produces no log entries. Because of that you will see no errors in the log file, as the UI cannot log anything to the Solr log. The reason why the Ubuntu-Jetty does not display those information might be because the Webapp context is restricted and does not provide the OS-MXBean. The Jetty included with Solr has no security settings at all and the webapp is running in the root context. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey >Assignee: Stefan Matheis (steffkes) > Attachments: built-in-jetty8.png, ubuntu-jetty6.png > > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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-Windows (64bit/jdk1.6.0_41) - Build # 2618 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2618/ Java: 64bit/jdk1.6.0_41 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 28646 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:381: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:60: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:591: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1591: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1625: Compile failed; see the compiler error output for details. Total time: 72 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.6.0_41 -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
Re: Ability to specify 2 different query analyzers for same indexed field in Solr
Please clarify, and try providing a couple more use cases. I mean, the case you provided suggests that the contents of the index will be different between the two fields, while you told us that you wanted to share the same indexed field. In other words, it sounds like you will have two copies of similar data anyway. Maybe you simply want one copy of the stored value for the field and then have one or more copyfields that index the same source data differently, but don’t re-store the copied source data. -- Jack Krupansky From: Tom Burton-West Sent: Monday, March 04, 2013 3:57 PM To: dev@lucene.apache.org Subject: Ability to specify 2 different query analyzers for same indexed field in Solr Hello, We would like to be able to specify two different fields that both use the same indexed field but use different analyzers. An example use-case for this might be doing query-time synonym expansion with the synonyms weighted lower than an exact match. q=exact_field^10 OR synonyms^1 The normal way to do this in Solr, which is just to set up separate analyzer chains and use a copyfield, will not work for us because the field in question is huge. It is about 7 TB of OCR. Is there a way to do this currently in Solr? If not , 1) should I open a JIRA issue? 2) can someone point me towards the part of the code I might need to modify? Tom Tom Burton-West Information Retrieval Programmer Digital Library Production Service University of Michigan Library http://www.hathitrust.org/blogs/large-scale-search
[jira] [Comment Edited] (SOLR-3798) copyField logic in LukeRequestHandler is primitive, doesn't work well with dynamicFields
[ https://issues.apache.org/jira/browse/SOLR-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592665#comment-13592665 ] Steve Rowe edited comment on SOLR-3798 at 3/4/13 9:43 PM: -- In the latest patch on SOLR-4503, I've included a dynamic copy field refactoring in IndexSchema.java that fixes cases 7, 11, 14, and 15 from the above table - with that patch, the Solr schema parse succeeds for those cases. But LukeRequestHandler's response can only carry those cases where at least one of the source or the dest is a declared field or dynamic field name, so its current implementation won't handle cases 11, 12, 15, or 16. I think LukeRequestHandler should split out copyField info, something like the way I did it on SOLR-4503, so that subset patterns can be reported. was (Author: steve_rowe): In the latest patch on SOLR-4503, I've included a dynamic copy field refactoring in IndexSchema.java that fixes cases 7, 11, 14, and 15 from the above table - with that patch, the Solr schema parse succeeds for those cases. But LukeRequestHandler's response can only carry those cases where at least one of the source or the dest is a declared field or dynamic field name, so it's current implementation won't handle cases 11, 12, 15, or 16. I think LukeRequestHandler should split out copyField info, something like the way I did it on SOLR-4503, so that subset patterns can be reported. > copyField logic in LukeRequestHandler is primitive, doesn't work well with > dynamicFields > > > Key: SOLR-3798 > URL: https://issues.apache.org/jira/browse/SOLR-3798 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man > Attachments: SOLR-3798.patch > > > looking into SOLR-3795 i realized there is a much bigger problem with how > LukeRequestHandler tries to get copyfield info for fields and dynamicFields > the same way, and it just doesn't work. > see the patch in SOLR-3795 for a commented out example of a test that still > fails (ie: trying to get the "copySource" info for a dynamicField) -- 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-3798) copyField logic in LukeRequestHandler is primitive, doesn't work well with dynamicFields
[ https://issues.apache.org/jira/browse/SOLR-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592665#comment-13592665 ] Steve Rowe commented on SOLR-3798: -- In the latest patch on SOLR-4503, I've included a dynamic copy field refactoring in IndexSchema.java that fixes cases 7, 11, 14, and 15 from the above table - with that patch, the Solr schema parse succeeds for those cases. But LukeRequestHandler's response can only carry those cases where at least one of the source or the dest is a declared field or dynamic field name, so it's current implementation won't handle cases 11, 12, 15, or 16. I think LukeRequestHandler should split out copyField info, something like the way I did it on SOLR-4503, so that subset patterns can be reported. > copyField logic in LukeRequestHandler is primitive, doesn't work well with > dynamicFields > > > Key: SOLR-3798 > URL: https://issues.apache.org/jira/browse/SOLR-3798 > Project: Solr > Issue Type: Bug >Reporter: Hoss Man > Attachments: SOLR-3798.patch > > > looking into SOLR-3795 i realized there is a much bigger problem with how > LukeRequestHandler tries to get copyfield info for fields and dynamicFields > the same way, and it just doesn't work. > see the patch in SOLR-3795 for a commented out example of a test that still > fails (ie: trying to get the "copySource" info for a dynamicField) -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592661#comment-13592661 ] Felix Buenemann commented on SOLR-4526: --- Hoss: Solr is not logging any errors. I've tried with logging for solr and children set to INFO. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey >Assignee: Stefan Matheis (steffkes) > Attachments: built-in-jetty8.png, ubuntu-jetty6.png > > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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-4138) currency field doesn't work with functions (ie: isn't compatible with frange query)
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592650#comment-13592650
]
Commit Tag Bot commented on SOLR-4138:
--
[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1452508
SOLR-4138: doc typos
> currency field doesn't work with functions (ie: isn't compatible with frange
> query)
> ---
>
> Key: SOLR-4138
> URL: https://issues.apache.org/jira/browse/SOLR-4138
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.0
>Reporter: Grzegorz Sobczyk
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4135-test.patch, SOLR-4138.patch, SOLR-4138.patch
>
>
> In general, using CurrencyField with FunctionQueries doesn't work
> In particular, as originally reported...
> Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-4138) currency field doesn't work with functions (ie: isn't compatible with frange query)
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592649#comment-13592649
]
Commit Tag Bot commented on SOLR-4138:
--
[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1452527
SOLR-4138: CurrencyField fields can now be used in a ValueSources. There is
also a new currency(field,[CODE]) function (merge r1452483 and r1452508)
> currency field doesn't work with functions (ie: isn't compatible with frange
> query)
> ---
>
> Key: SOLR-4138
> URL: https://issues.apache.org/jira/browse/SOLR-4138
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.0
>Reporter: Grzegorz Sobczyk
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4135-test.patch, SOLR-4138.patch, SOLR-4138.patch
>
>
> In general, using CurrencyField with FunctionQueries doesn't work
> In particular, as originally reported...
> Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592648#comment-13592648 ] Felix Buenemann commented on SOLR-4526: --- Hoss: I'll try to get my VM back into the prober state and check it. Regarding what the JS could do better: It would be a good idea to check if the accessed array keys are undefined, to avoid an exception. This would make the JS code more verbose though. Had the code checked for undefined values, it would have shown the JVM usage just fine. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey >Assignee: Stefan Matheis (steffkes) > Attachments: built-in-jetty8.png, ubuntu-jetty6.png > > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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: verbose logging
Oh,
I though the XML report files contain the whole stdout?
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/ws/solr/build/solr-core/test/TEST-org.apache.solr.update.TestAtomicUpdateErrorCases.xml
But its empty... This would be the most "correct" variant. I know that by
default stock JUnit saves the whole stdout/stderr in the XML file, but JUnit4
runner does not seem to do this?
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf
> Of Dawid Weiss
> Sent: Monday, March 04, 2013 9:55 PM
> To: dev@lucene.apache.org
> Subject: Re: verbose logging
>
> The system variable has nothing to do with it. The output from tests is passed
> to report plugins and the default one printing to console simply discards
> whatever goes to sysout/syserr if a test passed (and within its suite's
> boundary). There is another report plugin that saves full output to disk so
> you have a few choices:
>
> 1) enable full sysout/syserr logging by passing tests.showSuccess=true to
> jenkins (or committing it in to the repo),
> 2) going to a particular jenkins plan, accessing the workspace and fetching
> build output for that test. For example:
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-
> Linux/ws/lucene/build/core/test/tests-report.txt
>
> (this file may not be there if a build hasn't reached it yet).
>
> 3) ask Uwe or whoever is the jenkins admin to preserve **/tests-report.txt
> as a build artefact; this way you'd have some history to look at. These files
> are *big* though, especially for Solr which emits tons of logs.
>
> Dawid
>
> On Mon, Mar 4, 2013 at 9:47 PM, Erick Erickson
> wrote:
> > I wasn't very clear. Since I can't get the tests to fail in my local
> > environment, I was trying for the verbose output for this particular
> > test _whenever_ the test was run. Is it reasonable to set the system
> > var for tests.showSuccess=true in my @BeforeClass?
> >
> > Thanks,
> > Erick
> >
> >
> > On Mon, Mar 4, 2013 at 9:52 AM, Dawid Weiss
> >
> > wrote:
> >>
> >> By default the output from tests that passed is not dumped to the
> >> console (you wouldn't be able to track which JVM dumped what anyway
> >> when running on multicore). If you need a full log then:
> >>
> >> > ant test-help
> >> ...
> >> [echo] # Include additional information like what is printed to
> >> [echo] # sysout/syserr, even if the test passes.
> >> [echo] # Enabled automatically when running for a single test case.
> >> [echo] ant -Dtests.showSuccess=true test
> >>
> >> Should do the job. If you'd like to see the output from jenkins or
> >> any other build server then, unless it fails, it won't be on the console.
> >>
> >> Dawid
> >>
> >> On Mon, Mar 4, 2013 at 3:48 PM, Erick Erickson
> >>
> >> wrote:
> >> > I tried turning on verbose in the OpenCloseCoreStressTests by
> >> > setting System.setProperty("tests.verbose", "true"); in
> >> > @BeforeClass and, of course, it works on my machine. But the failed
> >> > test logs don't have verbose output, is there some magic here? For
> >> > the nonce, I'm just doing a bit of hard logging.
> >> >
> >> > I also found another place where I screwed up the a Stream by not
> >> > closing it, ZkCLI of all places. I've checked that in.
> >> >
> >> > Of course all tests pass on my machine. Scant comfort that.
> >> >
> >> > I also had yet another assumption proved wrong so I didn't get any
> >> > useful info from last night's failure, trying to add some more
> >> > logging again today.
> >> > Don't panic that the checking has my initials init, that's so I'm
> >> > absolutely sure to know to take it out.
> >> >
> >> > Thanks,
> >> > Erick
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> >> additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4138) currency field doesn't work with functions (ie: isn't compatible with frange query)
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-4138.
Resolution: Fixed
Fix Version/s: 5.0
4.2
Committed revision 1452483.
Committed revision 1452508.
Committed revision 1452527.
> currency field doesn't work with functions (ie: isn't compatible with frange
> query)
> ---
>
> Key: SOLR-4138
> URL: https://issues.apache.org/jira/browse/SOLR-4138
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.0
>Reporter: Grzegorz Sobczyk
>Assignee: Hoss Man
> Fix For: 4.2, 5.0
>
> Attachments: SOLR-4135-test.patch, SOLR-4138.patch, SOLR-4138.patch
>
>
> In general, using CurrencyField with FunctionQueries doesn't work
> In particular, as originally reported...
> Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-4526: -- Assignee: Stefan Matheis (steffkes) Felix: can you confirm no errors in the server logs, just javacsript was having problems from the null keys? asigning to steffkes in the hopes that he can take a look -- but based on the screen shot i'm not really sure what if anything it could do better in a situation like this -- if the values aren't available from the JVM, showing "blank" bar sharts seems as good an option as any ... i guess maybe labeling them with "?" could be a little better though. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey >Assignee: Stefan Matheis (steffkes) > Attachments: built-in-jetty8.png, ubuntu-jetty6.png > > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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
Ability to specify 2 different query analyzers for same indexed field in Solr
Hello, We would like to be able to specify two different fields that both use the same indexed field but use different analyzers. An example use-case for this might be doing query-time synonym expansion with the synonyms weighted lower than an exact match. q=exact_field^10 OR synonyms^1 The normal way to do this in Solr, which is just to set up separate analyzer chains and use a copyfield, will not work for us because the field in question is huge. It is about 7 TB of OCR. Is there a way to do this currently in Solr? If not , 1) should I open a JIRA issue? 2) can someone point me towards the part of the code I might need to modify? Tom Tom Burton-West Information Retrieval Programmer Digital Library Production Service University of Michigan Library http://www.hathitrust.org/blogs/large-scale-search
[jira] [Updated] (SOLR-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Buenemann updated SOLR-4526: -- Attachment: built-in-jetty8.png ubuntu-jetty6.png Screenshots illustrating the problem. The JVM values are only empty because of an exception in index.js, which was looking for the missing keys 'maxFileDescriptorCount' and 'openFileDescriptorCount' in system_data['system']. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > Attachments: built-in-jetty8.png, ubuntu-jetty6.png > > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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: verbose logging
The system variable has nothing to do with it. The output from tests
is passed to report plugins and the default one printing to console
simply discards whatever goes to sysout/syserr if a test passed (and
within its suite's boundary). There is another report plugin that
saves full output to disk so you have a few choices:
1) enable full sysout/syserr logging by passing tests.showSuccess=true
to jenkins (or committing it in to the repo),
2) going to a particular jenkins plan, accessing the workspace and
fetching build output for that test. For example:
http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/ws/lucene/build/core/test/tests-report.txt
(this file may not be there if a build hasn't reached it yet).
3) ask Uwe or whoever is the jenkins admin to preserve
**/tests-report.txt as a build artefact; this way you'd have some
history to look at. These files are *big* though, especially for Solr
which emits tons of logs.
Dawid
On Mon, Mar 4, 2013 at 9:47 PM, Erick Erickson wrote:
> I wasn't very clear. Since I can't get the tests to fail in my local
> environment, I was trying for the verbose output for this particular test
> _whenever_ the test was run. Is it reasonable to set the system var for
> tests.showSuccess=true in my @BeforeClass?
>
> Thanks,
> Erick
>
>
> On Mon, Mar 4, 2013 at 9:52 AM, Dawid Weiss
> wrote:
>>
>> By default the output from tests that passed is not dumped to the
>> console (you wouldn't be able to track which JVM dumped what anyway
>> when running on multicore). If you need a full log then:
>>
>> > ant test-help
>> ...
>> [echo] # Include additional information like what is printed to
>> [echo] # sysout/syserr, even if the test passes.
>> [echo] # Enabled automatically when running for a single test case.
>> [echo] ant -Dtests.showSuccess=true test
>>
>> Should do the job. If you'd like to see the output from jenkins or any
>> other build server then, unless it fails, it won't be on the console.
>>
>> Dawid
>>
>> On Mon, Mar 4, 2013 at 3:48 PM, Erick Erickson
>> wrote:
>> > I tried turning on verbose in the OpenCloseCoreStressTests by setting
>> > System.setProperty("tests.verbose", "true");
>> > in @BeforeClass and, of course, it works on my machine. But the failed
>> > test
>> > logs don't have verbose output, is there some magic here? For the nonce,
>> > I'm
>> > just doing a bit of hard logging.
>> >
>> > I also found another place where I screwed up the a Stream by not
>> > closing
>> > it, ZkCLI of all places. I've checked that in.
>> >
>> > Of course all tests pass on my machine. Scant comfort that.
>> >
>> > I also had yet another assumption proved wrong so I didn't get any
>> > useful
>> > info from last night's failure, trying to add some more logging again
>> > today.
>> > Don't panic that the checking has my initials init, that's so I'm
>> > absolutely
>> > sure to know to take it out.
>> >
>> > Thanks,
>> > Erick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592624#comment-13592624 ] Commit Tag Bot commented on SOLR-4416: -- [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1452504 SOLR-4416: Upgrade to Tika 1.3. > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-4416. --- Resolution: Fixed Committed to 4x and 5x - not sure why the 4.2 commit msg is so slow... Thanks Markus! > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592616#comment-13592616 ] Felix Buenemann commented on SOLR-4526: --- The problem turned out to be jetty6 vs. jetty8 and not OpenJDK. The dev system was running Solr's built-in jetty, while the production system was running the jetty version that was shipping with Ubuntu 12.04 Server. I noticed this after building a VM to simulate the problem with the closed Oracle JDK7 and encountered the same behavior. I'm attaching two screenshots to show the problem. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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: verbose logging
Jenkins saves complete sysout. Jou just have to go to build artifacts and
download the test xml file.
Erick Erickson schrieb:
>I wasn't very clear. Since I can't get the tests to fail in my local
>environment, I was trying for the verbose output for this particular
>test
>_whenever_ the test was run. Is it reasonable to set the system var for
>tests.showSuccess=true in my @BeforeClass?
>
>Thanks,
>Erick
>
>
>On Mon, Mar 4, 2013 at 9:52 AM, Dawid Weiss
>wrote:
>
>> By default the output from tests that passed is not dumped to the
>> console (you wouldn't be able to track which JVM dumped what anyway
>> when running on multicore). If you need a full log then:
>>
>> > ant test-help
>> ...
>> [echo] # Include additional information like what is printed to
>> [echo] # sysout/syserr, even if the test passes.
>> [echo] # Enabled automatically when running for a single test
>case.
>> [echo] ant -Dtests.showSuccess=true test
>>
>> Should do the job. If you'd like to see the output from jenkins or
>any
>> other build server then, unless it fails, it won't be on the console.
>>
>> Dawid
>>
>> On Mon, Mar 4, 2013 at 3:48 PM, Erick Erickson
>
>> wrote:
>> > I tried turning on verbose in the OpenCloseCoreStressTests by
>setting
>> > System.setProperty("tests.verbose", "true");
>> > in @BeforeClass and, of course, it works on my machine. But the
>failed
>> test
>> > logs don't have verbose output, is there some magic here? For the
>nonce,
>> I'm
>> > just doing a bit of hard logging.
>> >
>> > I also found another place where I screwed up the a Stream by not
>closing
>> > it, ZkCLI of all places. I've checked that in.
>> >
>> > Of course all tests pass on my machine. Scant comfort that.
>> >
>> > I also had yet another assumption proved wrong so I didn't get any
>useful
>> > info from last night's failure, trying to add some more logging
>again
>> today.
>> > Don't panic that the checking has my initials init, that's so I'm
>> absolutely
>> > sure to know to take it out.
>> >
>> > Thanks,
>> > Erick
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de
Re: verbose logging
I wasn't very clear. Since I can't get the tests to fail in my local
environment, I was trying for the verbose output for this particular test
_whenever_ the test was run. Is it reasonable to set the system var for
tests.showSuccess=true in my @BeforeClass?
Thanks,
Erick
On Mon, Mar 4, 2013 at 9:52 AM, Dawid Weiss wrote:
> By default the output from tests that passed is not dumped to the
> console (you wouldn't be able to track which JVM dumped what anyway
> when running on multicore). If you need a full log then:
>
> > ant test-help
> ...
> [echo] # Include additional information like what is printed to
> [echo] # sysout/syserr, even if the test passes.
> [echo] # Enabled automatically when running for a single test case.
> [echo] ant -Dtests.showSuccess=true test
>
> Should do the job. If you'd like to see the output from jenkins or any
> other build server then, unless it fails, it won't be on the console.
>
> Dawid
>
> On Mon, Mar 4, 2013 at 3:48 PM, Erick Erickson
> wrote:
> > I tried turning on verbose in the OpenCloseCoreStressTests by setting
> > System.setProperty("tests.verbose", "true");
> > in @BeforeClass and, of course, it works on my machine. But the failed
> test
> > logs don't have verbose output, is there some magic here? For the nonce,
> I'm
> > just doing a bit of hard logging.
> >
> > I also found another place where I screwed up the a Stream by not closing
> > it, ZkCLI of all places. I've checked that in.
> >
> > Of course all tests pass on my machine. Scant comfort that.
> >
> > I also had yet another assumption proved wrong so I didn't get any useful
> > info from last night's failure, trying to add some more logging again
> today.
> > Don't panic that the checking has my initials init, that's so I'm
> absolutely
> > sure to know to take it out.
> >
> > Thanks,
> > Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
Re: svn commit: r1452483 - in /lucene/dev/trunk/solr: ./ core/src/java/org/apache/solr/schema/ core/src/java/org/apache/solr/search/ core/src/test-files/solr/collection1/conf/ core/src/test/org/apache
Bah ... i swear i ran "ant precommit" on this, and yet i just found
doclint problems (merging to 4x) ... fix coming.
: Date: Mon, 04 Mar 2013 20:25:37 -
: From: hoss...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: svn commit: r1452483 - in /lucene/dev/trunk/solr: ./
: core/src/java/org/apache/solr/schema/
: core/src/java/org/apache/solr/search/
: core/src/test-files/solr/collection1/conf/
: core/src/test/org/apache/solr/schema/
: core/src/test/org/apache/solr/search/
:
: Author: hossman
: Date: Mon Mar 4 20:25:37 2013
: New Revision: 1452483
:
: URL: http://svn.apache.org/r1452483
: Log:
: SOLR-4138: CurrencyField fields can now be used in a ValueSources. There is
also a new currency(field,[CODE]) function
:
: Modified:
: lucene/dev/trunk/solr/CHANGES.txt
:
lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CurrencyField.java
:
lucene/dev/trunk/solr/core/src/java/org/apache/solr/search/ValueSourceParser.java
:
lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/schema15.xml
:
lucene/dev/trunk/solr/core/src/test/org/apache/solr/schema/AbstractCurrencyFieldTest.java
:
lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/QueryEqualityTest.java
:
: Modified: lucene/dev/trunk/solr/CHANGES.txt
: URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?rev=1452483&r1=1452482&r2=1452483&view=diff
: ==
: --- lucene/dev/trunk/solr/CHANGES.txt (original)
: +++ lucene/dev/trunk/solr/CHANGES.txt Mon Mar 4 20:25:37 2013
: @@ -98,6 +98,14 @@ New Features
:Similarity when you know the optimal "Sweet Spot" of values for the field
:length and TF scoring factors. (hossman)
:
: +* SOLR-4138: CurrencyField fields can now be used in a ValueSources to
: + get the "raw" value (using the default number of fractional digits) in
: + the default currency of the field type. There is also a new
: + currency(field,[CODE]) function for generating a ValueSource of the
: + "natural" value, converted to an optionally specified currency to
: + override the default for the field type.
: + (hossman)
: +
: Bug Fixes
: --
:
:
: Modified:
lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CurrencyField.java
: URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CurrencyField.java?rev=1452483&r1=1452482&r2=1452483&view=diff
: ==
: ---
lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CurrencyField.java
(original)
: +++
lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CurrencyField.java
Mon Mar 4 20:25:37 2013
: @@ -242,6 +242,67 @@ public class CurrencyField extends Field
: return getRangeQuery(parser, field, valueDefault, valueDefault, true,
true);
:}
:
: + /**
: + *
: + * Returns a ValueSource over this field in which the numeric value for
: + * each document represents the indexed value as converted to the default
: + * currency for the field, normalized to it's most granular form based
: + * on the default fractional digits.
: + *
: + *
: + * For example: If the default Currency specified for a field is
: + * USD, then the values returned by this value source would
: + * represent the equivilent number of "cents" (ie: value in dollars * 100)
: + * after converting each document's native currency to USD -- because the
: + * default fractional digits for USD is "2".
: + * So for a document whose indexed value was currently equivilent to
: + * "5.43,USD" using the the exchange provider for this field,
: + * this ValueSource would return a value of "543"
: + *
: + *
: + * @see #PARAM_DEFAULT_CURRENCY
: + * @see #DEFAULT_DEFAULT_CURRENCY
: + * @see Currency#getDefaultFractionDigits
: + * @see getConvertedValueSource
: + */
: + public RawCurrencyValueSource getValueSource(SchemaField field,
: + QParser parser) {
: +field.checkFieldCacheSource(parser);
: +return new RawCurrencyValueSource(field, defaultCurrency, parser);
: + }
: +
: + /**
: + *
: + * Returns a ValueSource over this field in which the numeric value for
: + * each document represents the value from the underlying
: + * RawCurrencyValueSource as converted to the specified
target
: + * Currency.
: + *
: + *
: + * For example: If the targetCurrencyCode param is set to
: + * USD, then the values returned by this value source would
: + * represent the equivilent number of dollars after converting each
: + * document's raw value to USD. So for a document whose
: + * indexed value was currently equivilent to "5.43,USD"
: + * using the the exchange provider for this field, this ValueSource would
: + * return a value
Re: Lucene/Solr 4.2
I'd appreciate it if this was in: https://issues.apache.org/jira/browse/LUCENE-4810 wunder On Mar 4, 2013, at 11:58 AM, Mark Miller wrote: > Just a reminder - I'm looking to start pushing this release very soon. I'd > like to get an RC up by early next week if I can. > > Please help me out by getting what you want into 4.2 as soon as possible. > > - Mark > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[jira] [Commented] (SOLR-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592611#comment-13592611 ] Commit Tag Bot commented on SOLR-4416: -- [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1452499 SOLR-4416: Upgrade to Tika 1.3. > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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-4138) currency field doesn't work with functions (ie: isn't compatible with frange query)
[
https://issues.apache.org/jira/browse/SOLR-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592603#comment-13592603
]
Commit Tag Bot commented on SOLR-4138:
--
[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revision&revision=1452483
SOLR-4138: CurrencyField fields can now be used in a ValueSources. There is
also a new currency(field,[CODE]) function
> currency field doesn't work with functions (ie: isn't compatible with frange
> query)
> ---
>
> Key: SOLR-4138
> URL: https://issues.apache.org/jira/browse/SOLR-4138
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.0
>Reporter: Grzegorz Sobczyk
>Assignee: Hoss Man
> Attachments: SOLR-4135-test.patch, SOLR-4138.patch, SOLR-4138.patch
>
>
> In general, using CurrencyField with FunctionQueries doesn't work
> In particular, as originally reported...
> Filtering using {!frange} syntax isn't work properly. (rather at all)
--
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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592597#comment-13592597 ] Shawn Heisey commented on SOLR-4526: Additional note from the user on IRC: I adjusted the live server config to run the solr built-in jetty and now all the stats are showing up, even on openjdk, so the issue seems to be with older jetty versions. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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-4416) Upgrade to Tika 1.3
[ https://issues.apache.org/jira/browse/SOLR-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-4416: - Assignee: Mark Miller > Upgrade to Tika 1.3 > --- > > Key: SOLR-4416 > URL: https://issues.apache.org/jira/browse/SOLR-4416 > Project: Solr > Issue Type: Task > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.1 >Reporter: Erik Hatcher >Assignee: Mark Miller >Priority: Critical > Fix For: 4.2, 5.0 > > Attachments: SOLR-4416-trunk-1.patch > > > Tika 1.3 was recently released with these improvements: > http://www.apache.org/dist/tika/CHANGES-1.3.txt -- 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-4811) *DocValuesField should extend Field not StoredField
[ https://issues.apache.org/jira/browse/LUCENE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592582#comment-13592582 ] Commit Tag Bot commented on LUCENE-4811: [trunk commit] Michael McCandless http://svn.apache.org/viewvc?view=revision&revision=1452474 LUCENE-4811: fix *DVField to extend Field not StoredField > *DocValuesField should extend Field not StoredField > --- > > Key: LUCENE-4811 > URL: https://issues.apache.org/jira/browse/LUCENE-4811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0 > > Attachments: LUCENE-4811.patch > > > I think it's confusing because it implies the field will be stored as well as > added to doc values ... > I also noticed StorableFieldType is unused. -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592581#comment-13592581 ] Shawn Heisey commented on SOLR-4526: I think perhaps I was a little too aggressive in framing this issue. I should have scaled it back a little bit to focus on the UI issue, not the java classes. The title may need changing, and it may require filing another issue. I see two problems. With OpenJDK, the file descriptor info and the JVM memory info are not showing on the dashboard. Side note: I don't have OpenJDK running anywhere and don't have unallocated hardware I can fiddle with right now. The underlying issue is that the user says the file descriptor info is not found in /admin/system output running under OpenJDK, but it is there under Apple or Oracle JVMs. If the info is available at all from OpenJDK, it may require a code change to get it. The java issue is triggering a javascript issue. An educated guess is that the code that populates the file descriptor bar is failing and causing the JVM memory bar calculation (JVM memory info is available in /admin/system) to be skipped entirely. A simple fix for that issue would be to re-order the javascript code so that jvm memory is done before the file descriptor. A better fix would be to make sure that a nonexistent piece of information doesn't cause problems. I'm very weak in both javascript and java reflection, or I would have already tried to come up with patches. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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-4811) *DocValuesField should extend Field not StoredField
[ https://issues.apache.org/jira/browse/LUCENE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-4811. Resolution: Fixed > *DocValuesField should extend Field not StoredField > --- > > Key: LUCENE-4811 > URL: https://issues.apache.org/jira/browse/LUCENE-4811 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0 > > Attachments: LUCENE-4811.patch > > > I think it's confusing because it implies the field will be stored as well as > added to doc values ... > I also noticed StorableFieldType is unused. -- 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-4465) Configurable Collectors
[ https://issues.apache.org/jira/browse/SOLR-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592576#comment-13592576 ] Joel Bernstein commented on SOLR-4465: -- Dan, This patch doesn't work with grouping because grouping is done within a separate flow with a separate set of collectors. SOLR-1680 was a custom collectors patch that was meant to allow grouping to be merged into the main flow, but was never committed. Possibly grouping could be implemented using a collector factory but that would be a follow-on to getting this as part of the core. I'll work on resolving the npe with the default collector in the next patch. As you mentioned the caching implications here need to be fully understood. Perhaps you could elaborate on "Additionally since the collector is free to alter results between requests". Can you explain the use case where this would occur? > Configurable Collectors > --- > > Key: SOLR-4465 > URL: https://issues.apache.org/jira/browse/SOLR-4465 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 4.1 >Reporter: Joel Bernstein > Fix For: 4.2, 5.0 > > Attachments: SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, SOLR-4465.patch, > SOLR-4465.patch, SOLR-4465.patch > > > This issue is to add configurable custom collectors to Solr. This expands the > design and work done in issue SOLR-1680 to include: > 1) CollectorFactory configuration in solconfig.xml > 2) Http parameters to allow clients to dynamically select a CollectorFactory > and construct a custom Collector. > 3) Make aspects of QueryComponent pluggable so that the output from > distributed search can conform with custom collectors at the shard level. -- 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
Lucene/Solr 4.2
Just a reminder - I'm looking to start pushing this release very soon. I'd like to get an RC up by early next week if I can. Please help me out by getting what you want into 4.2 as soon as possible. - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4527) Atomic updates when running distributed seem broken.
[ https://issues.apache.org/jira/browse/SOLR-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-4527: -- Fix Version/s: 5.0 4.2 > Atomic updates when running distributed seem broken. > > > Key: SOLR-4527 > URL: https://issues.apache.org/jira/browse/SOLR-4527 > Project: Solr > Issue Type: Bug > Components: SolrCloud, update >Affects Versions: 4.1 >Reporter: mike st. john > Fix For: 4.2, 5.0 > > > When using solrcloud as a nosql solution, i've run into the issue where i've > sent some atomic updates and i'm receiving an error "missing required > field:" implying that this is an add instead of an update. when i add > distrib=false to the url and send the doc to the index where it resides, the > update is applied. > Possibly related...when i try and do a real time get for the id, its > throwing an NPE > "trace":"java.lang.NullPointerException\n\tat > org.apache.solr.handler.component.RealTimeGetComponent.createSubRequests(RealTimeGetComponent.java:368)\n\tat > > org.apache.solr.handler.component.RealTimeGetComponent.distributedProcess(RealTimeGetComponent.java:325)\n\tat > > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:244)\n\tat > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat > org.apache.solr.core.SolrCore.execute(SolrCore.java:1808)\n\tat > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:583)\n\tat > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:293)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)\n\tat > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat > > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)\n\tat > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)\n\tat > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)\n\tat > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat > java.lang.Thread.run(Thread.java:679)\n", > "code":500}} > the command will succeed , if i use the url the doc exists on and add > distrib=false to the end. -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4526: --- Description: A user on IRC was having trouble getting file descriptor counts and JVM memory usage in the admin UI, but it worked perfectly fine on another system. The problem system uses OpenJDK, the other one uses the Apple JDK. The user had tracked it down to an exception while trying to get open file descriptor info. Looking in the SystemInfoHandler.java file, I see a comment reference to com.sun.management.UnixOperatingSystemMXBean at the point where it is getting file descriptor info. A little extra searching turned up ZOOKEEPER-1579 which refers to HBASE-6945, the same problem with OpenJDK. was: A user on IRC was having trouble getting file descriptor counts and JVM memory usage in the admin UI, but it worked perfectly fine on another system. The problem system uses OpenJDK, the other one uses the Apple JDK. The user had tracked it down to an exception while trying to get open file descriptor info. Looking in the SystemInfoHandler.java file, I see a comment reference to com.sun.management.UnixOperatingSystemMXBean at the point where it is getting file descriptor info. A little extra searching turned up ZOOKEEPER-1579 which refers to HBASE-6495, the same problem with OpenJDK. I'm confused: SystemInfoHandler doesn't directly depend on UnixOperatingSystemMXBean, it uses reflection to ensure that it only calls methods on the OperatingSystemMXBean if they already exist -- so even if it isn't a sun JVM, or isn't an UnixOperatingSystemMXBean instance, or is an older version of UnixOperatingSystemMXBean that doesn't have some of those methods, it still shouldn't be an error -- at worst those properties just won't be included in the response. perhaps the problem is just that that admin UI Javascript assumes those properties will always be available? (but that wouldn't explain the comment about "tracked it down to an exception while trying to get open file descriptor info") can anyone who can actually reproduce this problem please post the specifics of the exception they see, or the behavior they see in the admin ui (ie: screenshot) > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6945, the same problem with OpenJDK. -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
[ https://issues.apache.org/jira/browse/SOLR-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592519#comment-13592519 ] Shawn Heisey commented on SOLR-4526: If File descriptor info just isn't available in OpenJDK, then that is life. The file descriptor problem seems to be causing another problem - the JVM memory info isn't showing up on the dashboard. I haven't looked at the code yet, and I don't know javascript very well, but the user suspects that when the file descriptor info is not found, it causes the code that puts the JVM memory info together to be skipped. > Admin UI dependence on UnixOperationSystemMXBean > > > Key: SOLR-4526 > URL: https://issues.apache.org/jira/browse/SOLR-4526 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.1 > Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 > 23.7-b01) >Reporter: Shawn Heisey > > A user on IRC was having trouble getting file descriptor counts and JVM > memory usage in the admin UI, but it worked perfectly fine on another system. > The problem system uses OpenJDK, the other one uses the Apple JDK. The user > had tracked it down to an exception while trying to get open file descriptor > info. > Looking in the SystemInfoHandler.java file, I see a comment reference to > com.sun.management.UnixOperatingSystemMXBean at the point where it is getting > file descriptor info. A little extra searching turned up ZOOKEEPER-1579 > which refers to HBASE-6495, the same problem with OpenJDK. -- 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-4527) Atomic updates when running distributed seem broken.
mike st. john created SOLR-4527: --- Summary: Atomic updates when running distributed seem broken. Key: SOLR-4527 URL: https://issues.apache.org/jira/browse/SOLR-4527 Project: Solr Issue Type: Bug Components: SolrCloud, update Affects Versions: 4.1 Reporter: mike st. john When using solrcloud as a nosql solution, i've run into the issue where i've sent some atomic updates and i'm receiving an error "missing required field:" implying that this is an add instead of an update. when i add distrib=false to the url and send the doc to the index where it resides, the update is applied. Possibly related...when i try and do a real time get for the id, its throwing an NPE "trace":"java.lang.NullPointerException\n\tat org.apache.solr.handler.component.RealTimeGetComponent.createSubRequests(RealTimeGetComponent.java:368)\n\tat org.apache.solr.handler.component.RealTimeGetComponent.distributedProcess(RealTimeGetComponent.java:325)\n\tat org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:244)\n\tat org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat org.apache.solr.core.SolrCore.execute(SolrCore.java:1808)\n\tat org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:583)\n\tat org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:293)\n\tat org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)\n\tat org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)\n\tat org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)\n\tat org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)\n\tat org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat java.lang.Thread.run(Thread.java:679)\n", "code":500}} the command will succeed , if i use the url the doc exists on and add distrib=false to the end. -- 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] [Reopened] (SOLR-4524) ReturnFields could not support hash '#' in filed name
[
https://issues.apache.org/jira/browse/SOLR-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reopened SOLR-4524:
Assignee: Hoss Man
There is no problem here, i think there is just user confusion about how to
include a "#" character in a URL -- "#" is a reserved character in URLs for
dealing with relative anchors, when you type a URL like this in your browser...
{noformat}
http://localhost:8983/solr/select?q=id:HOSS&fl=score&fl=#foo_s&fl=id
{noformat}
...the browser never sends anything after the "#" to the server.
If you URL escape it, then everything works fine...
{noformat}
$ curl -sS
'http://localhost:8983/solr/select?q=id:HOSS&fl=score&fl=%23foo_s&fl=id&indent=true&wt=json'
{
"responseHeader":{
"status":0,
"QTime":1,
"params":{
"fl":["score",
"#foo_s",
"id"],
"indent":"true",
"q":"id:HOSS",
"wt":"json"}},
"response":{"numFound":1,"start":0,"maxScore":3.8033605,"docs":[
{
"id":"HOSS",
"#foo_s":"special",
"score":3.8033605}]
}}
{noformat}
I've re-opened and assigned to myself to add a unit test demonstrating that a
field name like this works in the fl param.
> ReturnFields could not support hash '#' in filed name
> --
>
> Key: SOLR-4524
> URL: https://issues.apache.org/jira/browse/SOLR-4524
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.1
>Reporter: Benjamin POUSSIN
>Assignee: Hoss Man
> Labels: field, fl, query, queryparser
>
> If some fields start with '#' and we try to put it in fl param, this field
> and all next fields are not in response document
> With query:
> q=*:*&fl=score,#id,myOtherField
> Document response is like:
>SolrDocument{score=3.809621}
> this bug is similar to SOLR-2719 and SOLR-4374
--
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-4503) Add REST API methods to get schema information: fields, dynamicFields, fieldTypes, and copyFields
[ https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-4503: - Fix Version/s: 4.2 Description: Add REST methods that provide properties for fields, dynamicFields, fieldTypes, and copyFields, using paths: /solr/(corename)/schema/fields /solr/(corename)/schema/fields/fieldname /solr/(corename)/schema/dynamicfields /solr/(corename)/schema/dynamicfields/pattern /solr/(corename)/schema/fieldtypes /solr/(corename)/schema/fieldtypes/typename /solr/(corename)/schema/copyfields was: Add REST methods that provide properties for fields, dynamic fields, and field types, using paths: /solr/(corename)/schema/fields /solr/(corename)/schema/fields/fieldname /solr/(corename)/schema/dynamicfields /solr/(corename)/schema/dynamicfields/pattern /solr/(corename)/schema/fieldtypes /solr/(corename)/schema/fieldtypes/typename Summary: Add REST API methods to get schema information: fields, dynamicFields, fieldTypes, and copyFields (was: Add REST API methods to get schema information: fields, dynamic fields, and field types) > Add REST API methods to get schema information: fields, dynamicFields, > fieldTypes, and copyFields > - > > Key: SOLR-4503 > URL: https://issues.apache.org/jira/browse/SOLR-4503 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Affects Versions: 4.1 >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: 4.2 > > Attachments: all.dynamic.fields.json, all.dynamic.fields.json, > all.fields.json, all.fields.json, all.field.types.json, all.field.types.json, > coordinate.dynamic.field.json, coordinate.dynamic.field.json, > copyfields.json, date.field.type.json, date.field.type.json, > price.field.json, price.field.json, SOLR-4503.patch, SOLR-4503.patch, > SOLR-4503.patch > > > Add REST methods that provide properties for fields, dynamicFields, > fieldTypes, and copyFields, using paths: > /solr/(corename)/schema/fields > /solr/(corename)/schema/fields/fieldname > /solr/(corename)/schema/dynamicfields > /solr/(corename)/schema/dynamicfields/pattern > /solr/(corename)/schema/fieldtypes > /solr/(corename)/schema/fieldtypes/typename > /solr/(corename)/schema/copyfields -- 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-4526) Admin UI dependence on UnixOperationSystemMXBean
Shawn Heisey created SOLR-4526: -- Summary: Admin UI dependence on UnixOperationSystemMXBean Key: SOLR-4526 URL: https://issues.apache.org/jira/browse/SOLR-4526 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1 Environment: Oracle Corporation OpenJDK 64-Bit Server VM (1.7.0_15 23.7-b01) Reporter: Shawn Heisey A user on IRC was having trouble getting file descriptor counts and JVM memory usage in the admin UI, but it worked perfectly fine on another system. The problem system uses OpenJDK, the other one uses the Apple JDK. The user had tracked it down to an exception while trying to get open file descriptor info. Looking in the SystemInfoHandler.java file, I see a comment reference to com.sun.management.UnixOperatingSystemMXBean at the point where it is getting file descriptor info. A little extra searching turned up ZOOKEEPER-1579 which refers to HBASE-6495, the same problem with OpenJDK. -- 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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types
[ https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-4503: - Attachment: SOLR-4503.patch all.field.types.json all.fields.json all.dynamic.fields.json coordinate.dynamic.field.json date.field.type.json price.field.json copyfields.json Patch, I think it's ready to go. I've also attached updated example outputs. I've split off a new /schema/copyfields/ request, because it wasn't possible to attach copyFields with subset pattern dynamic field references off of anything in the /schema/fields/ structure. /schema/copyfields/ also now contains maxChars, sourceDynamicBase and destDynamicBase, if applicable. I had to refactor dynamic field handling in IndexSchema.java in order to fix a bug identified in SOLR-3798 - this refactoring+fix is included in this patch. By default, all requests now exclude default properties. A "showDefaults" query parameter causes them to be included in the response. By default, all requests are indented JSON. There are tests for everything, 'ant test' passes under Solr, 'ant precommit' passes, and I've added CHANGES.txt entries. > Add REST API methods to get schema information: fields, dynamic fields, and > field types > --- > > Key: SOLR-4503 > URL: https://issues.apache.org/jira/browse/SOLR-4503 > Project: Solr > Issue Type: Sub-task > Components: Schema and Analysis >Affects Versions: 4.1 >Reporter: Steve Rowe >Assignee: Steve Rowe > Attachments: all.dynamic.fields.json, all.dynamic.fields.json, > all.fields.json, all.fields.json, all.field.types.json, all.field.types.json, > coordinate.dynamic.field.json, coordinate.dynamic.field.json, > copyfields.json, date.field.type.json, date.field.type.json, > price.field.json, price.field.json, SOLR-4503.patch, SOLR-4503.patch, > SOLR-4503.patch > > > Add REST methods that provide properties for fields, dynamic fields, and > field types, using paths: > /solr/(corename)/schema/fields > /solr/(corename)/schema/fields/fieldname > /solr/(corename)/schema/dynamicfields > /solr/(corename)/schema/dynamicfields/pattern > /solr/(corename)/schema/fieldtypes > /solr/(corename)/schema/fieldtypes/typename -- 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-4752) Merge segments to sort them
[
https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592366#comment-13592366
]
Adrien Grand commented on LUCENE-4752:
--
bq. How can you early terminate a query for a single segment? [...] To early
terminate efficiently, you must have the segments in a consistent order, e.g.
S1 > S2 > S3.
I think this is just an API limitation? Segments being processed independently,
we should be able to terminate collection on a per-segment basis?
bq. instead of stuffing into IWC what seems like a random setting
(pick-segments-for-sorting), we should have something more generic, like
AtomicReaderFactory
I didn't mean this should be a boolean. Of course it should be something more
flexible/configurable! I'm very bad at picking names, but following your naming
suggestion, we could have something like
{code}
abstract class AtomicReaderFactory {
abstract List reorder(List segmentReaders);
}
{code}?
The default impl would be the identity whereas the sorting impl would return a
singleton containing a sorted view over the segment readers?
bq. Also, a custom SegmentMerger to implement the zig-zag merge would help too.
This is another option. I actually started exploring this option when David
opened this issue, but it can become complicated, especially for postings lists
merging, whereas reusing the sorted view from LUCENE-3918 would make merging
trivial.
> Merge segments to sort them
> ---
>
> Key: LUCENE-4752
> URL: https://issues.apache.org/jira/browse/LUCENE-4752
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/index
>Reporter: David Smiley
>Assignee: Adrien Grand
>
> It would be awesome if Lucene could write the documents out in a segment
> based on a configurable order. This of course applies to merging segments
> to. The benefit is increased locality on disk of documents that are likely to
> be accessed together. This often applies to documents near each other in
> time, but also spatially.
--
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-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592362#comment-13592362 ] David Smiley commented on LUCENE-4752: -- I wonder what other big-data software is also sorting its data files both within-file *and* across them (the latter being the tricker part I think)? Cassandra, HBase, or Accumulo? The code details are going to be specific to the platform but I'm interested in the scheduling / merging algorithm, which seems like the biggest challenge to me. I bet this has been solved before. My initial attempts at coming up with an algorithm on my notepad isn't showing much promise. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592355#comment-13592355 ] Shai Erera commented on LUCENE-4752: I was commenting on Adrien's statement about how this would benefit early termination. If we open up the hooks (AtomicReaderFactory and custom SegmentMerger), I think that will open the way for many interesting things to do during merging, including merge-sorting segments. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592346#comment-13592346 ] David Smiley commented on LUCENE-4752: -- Shai, Early-termination is a non-goal for this issue. Locality of reference is, with further index compression being a bonus. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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
SolrJ client changes
Hi all, First off, thanks for the great project. We're really excited about incorporating Solr into our stack. Thanks! We're looking at making some changes to the SolrJ client to meet our operational needs: - routing of requests to specific nodes for better cache hit ratios - adding instrumentation via JMX (list of availability of Solr servers, response time, various counters) - implementing connection pooling (failure detection and recovery); this is probably achievable on a layer atop the SolrJ client vs. as a part of it - logging errors more consistently - miscellaneous changes (debugging, use of POST, optional custom User-Agent, etc.) So far, it appears that these changes can be made by adding hooks or optional APIs to SolrJ that we would then implement with our custom logic. So there's no secret sauce or anything. We are curious for your recommendations about how best to make these changes. A few questions: 1. It seems that the SolrJ client is part of the overall Solr project, so it would be harder/slower for us to get our changes in, committed, and released in a timely manner. 2. We're specifically interested in the load balancing SolrJ client (LBHttpSolrServer) but it doesn't appear to be recommended for production use. Thoughts on its usage? 3. Are there perhaps other clients for Solr for Java other than SolrJ and scalikesolr? Thanks, Kirk
[jira] [Commented] (LUCENE-3918) Port index sorter to trunk APIs
[ https://issues.apache.org/jira/browse/LUCENE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592301#comment-13592301 ] David Smiley commented on LUCENE-3918: -- bq. Global ordering over a multi-segment index seems less useful than the local per-segment ordering - after all, the main use cases are compression improvements and early termination strategies, both of which operate on a per-segment basis. Those are two "main use-cases" but there is a third that (to me) is far more important than either -- locality of reference. Retrieving documents near each other (according to the configured sort order) should ideally have their stored fields data very close together. The early-termination use-case is clearly important to you but is not the goal of LUCENE-4752. > Port index sorter to trunk APIs > --- > > Key: LUCENE-3918 > URL: https://issues.apache.org/jira/browse/LUCENE-3918 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 4.0-ALPHA >Reporter: Robert Muir > Fix For: 4.2, 5.0 > > Attachments: LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch > > > LUCENE-2482 added an IndexSorter to 3.x, but we need to port this > functionality to 4.0 apis. -- 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-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592289#comment-13592289 ] Shai Erera commented on LUCENE-4752: How can you early terminate a query for a single segment? Say that you have 3 sorted segments (individually) and your query asks to get the top-10 of some criteria. The top-10 may come from the 3 segments as follows: seg1=4, seg2=4, seg3=2. But you don't know that until you processed all 3 segments right? While you could make a decision on a per-segment basis to 'terminate', there's no mechanism today to tell IndexSearcher "I'm done w/ that segment, move on". Today, if you want to early terminate, you need to throw an exception from the Collector, and catch it outside, in your application code? To early terminate efficiently, you must have the segments in a consistent order, e.g. S1 > S2 > S3. Then, after you've processed enough elements from S1, you can early terminate the entire query because you're guaranteed that successive documents will be "smaller". Unless, you add to your Collector.collect() an "if (done) return" and consider that a no-op, or make your own IndexSearcher logic ... then per-segment early termination is doable. As for the approach you describe, I think that instead of stuffing into IWC what seems like a random setting (pick-segments-for-sorting), we should have something more generic, like AtomicReaderFactory, which IW will use instead of always loading SegmentReader. That will let you load your custom AtomicReader? Or, perhaps this can be a SortingCodec? Also, a custom SegmentMerger to implement the zig-zag merge would help too. > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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: verbose logging
By default the output from tests that passed is not dumped to the
console (you wouldn't be able to track which JVM dumped what anyway
when running on multicore). If you need a full log then:
> ant test-help
...
[echo] # Include additional information like what is printed to
[echo] # sysout/syserr, even if the test passes.
[echo] # Enabled automatically when running for a single test case.
[echo] ant -Dtests.showSuccess=true test
Should do the job. If you'd like to see the output from jenkins or any
other build server then, unless it fails, it won't be on the console.
Dawid
On Mon, Mar 4, 2013 at 3:48 PM, Erick Erickson wrote:
> I tried turning on verbose in the OpenCloseCoreStressTests by setting
> System.setProperty("tests.verbose", "true");
> in @BeforeClass and, of course, it works on my machine. But the failed test
> logs don't have verbose output, is there some magic here? For the nonce, I'm
> just doing a bit of hard logging.
>
> I also found another place where I screwed up the a Stream by not closing
> it, ZkCLI of all places. I've checked that in.
>
> Of course all tests pass on my machine. Scant comfort that.
>
> I also had yet another assumption proved wrong so I didn't get any useful
> info from last night's failure, trying to add some more logging again today.
> Don't panic that the checking has my initials init, that's so I'm absolutely
> sure to know to take it out.
>
> Thanks,
> Erick
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4505) Deadlock around SolrCoreState update lock.
[ https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592250#comment-13592250 ] Erick Erickson commented on SOLR-4505: -- Tagged http://svn.apache.org/viewvc?view=revision&revision=1452321 to the wrong JIRA, should have been SOLR-4525 > Deadlock around SolrCoreState update lock. > -- > > Key: SOLR-4505 > URL: https://issues.apache.org/jira/browse/SOLR-4505 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: newstack.txt, newstack.txt, newstack.txt, > SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch > > > Erick found a deadlock with his core stress tool - see > http://markmail.org/message/aq5hghbqia2uimgl -- 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
verbose logging
I tried turning on verbose in the OpenCloseCoreStressTests by setting
System.setProperty("tests.verbose", "true");
in @BeforeClass and, of course, it works on my machine. But the failed test
logs don't have verbose output, is there some magic here? For the nonce,
I'm just doing a bit of hard logging.
I also found another place where I screwed up the a Stream by not closing
it, ZkCLI of all places. I've checked that in.
Of course all tests pass on my machine. Scant comfort that.
I also had yet another assumption proved wrong so I didn't get any useful
info from last night's failure, trying to add some more logging again
today. Don't panic that the checking has my initials init, that's so I'm
absolutely sure to know to take it out.
Thanks,
Erick
[jira] [Commented] (LUCENE-3918) Port index sorter to trunk APIs
[ https://issues.apache.org/jira/browse/LUCENE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592237#comment-13592237 ] Shai Erera commented on LUCENE-3918: I agree that per-segment sorting may improve compression, but I don't see how it can help with early termination. If Lucene allowed you to terminate on a per-segment basis then maybe, but today (as far as I know), the only way to early terminate a query is by throwing an exception and catching it outside, right? At any rate, per-segment sorting doesn't help much when segments are merged, because then you lose sorting again. Unless, we add some API to IW / SegmentMerger for you to control how the segments are merged... > Port index sorter to trunk APIs > --- > > Key: LUCENE-3918 > URL: https://issues.apache.org/jira/browse/LUCENE-3918 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 4.0-ALPHA >Reporter: Robert Muir > Fix For: 4.2, 5.0 > > Attachments: LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch > > > LUCENE-2482 added an IndexSorter to 3.x, but we need to port this > functionality to 4.0 apis. -- 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-4505) Deadlock around SolrCoreState update lock.
[ https://issues.apache.org/jira/browse/SOLR-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592229#comment-13592229 ] Commit Tag Bot commented on SOLR-4505: -- [trunk commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1452321 SOLR-4505, another place where I missed closing the stream > Deadlock around SolrCoreState update lock. > -- > > Key: SOLR-4505 > URL: https://issues.apache.org/jira/browse/SOLR-4505 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: newstack.txt, newstack.txt, newstack.txt, > SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch, SOLR-4505.patch > > > Erick found a deadlock with his core stress tool - see > http://markmail.org/message/aq5hghbqia2uimgl -- 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: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b79) - Build # 4533 - Still Failing!
> > The parent process or the worker child? > > The parent. The reason here was to avoid spawning a background thread on > the child to avoid any interference with existing tests. So the parent tracks > events that tell where the child is going (entering or leaving a suite/ test) > and > is from this deducing where a child may be. > The status means the child is not executing any suite; it used to > be the case that OOM-ed code would hang forever on System.exit, for > example... > > > Can you see from the messages *where* it might hang? > > Not really, not if it's a JVM issue. > > > Interestingly another one is now hanging with the following message: > > > > [junit4:junit4] HEARTBEAT J0 PID(11405@serv1): 2013-03-04T13:16:16, > > stalled for 7086s at: > > UIMABaseAnalyzerTest.baseUIMAAnalyzerIntegrationTest > > If this one is not responsive to regular stack trace probing then it's > definitely a > JVM freeze somewhere. It was also frozen! Was only possible to kill -9. Unfortunately attaching with gdb did not work to me, I'll try next time again. Uwe - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b79) - Build # 4533 - Still Failing!
> The parent process or the worker child? The parent. The reason here was to avoid spawning a background thread on the child to avoid any interference with existing tests. So the parent tracks events that tell where the child is going (entering or leaving a suite/ test) and is from this deducing where a child may be. The status means the child is not executing any suite; it used to be the case that OOM-ed code would hang forever on System.exit, for example... > Can you see from the messages *where* it might hang? Not really, not if it's a JVM issue. > Interestingly another one is now hanging with the following message: > > [junit4:junit4] HEARTBEAT J0 PID(11405@serv1): 2013-03-04T13:16:16, stalled > for 7086s at: UIMABaseAnalyzerTest.baseUIMAAnalyzerIntegrationTest If this one is not responsive to regular stack trace probing then it's definitely a JVM freeze somewhere. D. - 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-b79) - Build # 4535 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4535/ Java: 32bit/jdk1.8.0-ea-b79 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 6055 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/java -server -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=D1F2BAB08DD89503 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.2 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/uima/test/temp -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy -Dlucene.version=4.2-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dfile.encoding=ISO-8859-1 -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/uima/classes/test:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/common/lucene-analyzers-common-4.2-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/uima/src/test-files:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/uima/lib/Tagger-2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/uima/lib/WhitespaceTokenizer-2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/analysis/uima/lib/uimaj-core-2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.8.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/analysis/uima/classes/java:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-netrexx.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.jar:/var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.8.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.sla
RE: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b79) - Build # 4533 - Still Failing!
I can try to hook it up with gdb and report to the hotspot mailing list. Unfortunately, we have nothing to report, only that the JVM hangs. Who is printing the messages? The parent process or the worker child? If the parent prints them, the child can be dead altogether, otherwise it might still be able to print messages. Can you see from the messages *where* it might hang? [junit4:junit4] HEARTBEAT J0 PID(6790@serv1): 2013-03-04T08:01:06, stalled for 2464s at: Interestingly another one is now hanging with the following message: [junit4:junit4] HEARTBEAT J0 PID(11405@serv1): 2013-03-04T13:16:16, stalled for 7086s at: UIMABaseAnalyzerTest.baseUIMAAnalyzerIntegrationTest Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf > Of Dawid Weiss > Sent: Monday, March 04, 2013 9:12 AM > To: dev@lucene.apache.org > Subject: Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b79) - Build # > 4533 - Still Failing! > > It'd be nice to get a native stack/ core dump of this via gdb and report back > to > the hotspot folks. I know too little about gdb to help here but I bet it's > possible. > > Dawid > > On Mon, Mar 4, 2013 at 9:03 AM, Uwe Schindler wrote: > > Killed again! Again 32 bit JDK8 with G1 Collector > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > >> -Original Message- > >> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de] > >> Sent: Monday, March 04, 2013 9:02 AM > >> To: dev@lucene.apache.org > >> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b79) - > >> Build # > >> 4533 - Still Failing! > >> > >> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4533/ > >> Java: 32bit/jdk1.8.0-ea-b79 -client -XX:+UseG1GC > >> > >> All tests passed > >> > >> Build Log: > >> [...truncated 5917 lines...] > >> [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: > >> /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b79/jre/bin/java > >> -client - XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError - > >> XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=3B99A947D2A6DD6D > - > >> Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false > >> - Dtests.codec=random -Dtests.postingsformat=random - > >> Dtests.docvaluesformat=random -Dtests.locale=random - > >> Dtests.timezone=random -Dtests.directory=random - > >> Dtests.linedocsfile=europarl.lines.txt.gz > >> -Dtests.luceneMatchVersion=4.2 - Dtests.cleanthreads=perMethod - > >> Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr > >> -4.x- Linux/lucene/tools/junit4/logging.properties > >> -Dtests.nightly=false - Dtests.weekly=false -Dtests.slow=true > >> -Dtests.asserts.gracious=false - > >> Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. - > >> Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/build/analysis/uima/test/temp - > >> Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/build/clover/db - > >> Djava.security.manager=org.apache.lucene.util.TestSecurityManager - > >> Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/tools/junit4/tests.policy -Dlucene.version=4.2-SNAPSHOT > >> - > >> Djetty.testMode=1 -Djetty.insecurerandom=1 - > >> Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory - > >> Djava.awt.headless=true -classpath > /mnt/ssd/jenkins/workspace/Lucene- > >> Solr-4.x- > >> Linux/lucene/build/analysis/uima/classes/test:/mnt/ssd/jenkins/worksp > >> ace > >> /Lucene-Solr-4.x-Linux/lucene/build/test- > >> framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Luc > >> en > >> e-Solr-4.x-Linux/lucene/build/analysis/common/lucene-analyzers- > common > >> - > >> 4.2-SNAPSHOT.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/analysis/uima/src/test- > >> files:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/analysis/uima/lib/Tagger- > >> 2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/analysis/uima/lib/WhitespaceTokenizer- > >> 2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/analysis/uima/lib/uimaj-core- > >> 2.3.1.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> > Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucen > >> e- > >> Solr-4.x-Linux/lucene/test-framework/lib/junit- > >> 4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test > >> - > >> framework/lib/randomizedtesting-runner- > >> 2.0.8.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x- > >> Linux/lucene/build/analysis/uima/classes/java:/var/lib/jenkins/tools/ > >> hudson > >> .tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant- > >>
[jira] [Updated] (LUCENE-3918) Port index sorter to trunk APIs
[ https://issues.apache.org/jira/browse/LUCENE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shai Erera updated LUCENE-3918: --- Attachment: LUCENE-3918.patch Patch: * Consolidates tests into less classes, also creates the test index in BeforeClass * Randomizing tests: #docs, sort permutations * Added _TestUtil.checkIndex and checkReader (see below) - this uncovered few bugs * Moved relevant classes to inherit from their FilterXYZ counterpart - reduced code In SortingAtomicReaderTest I had to call _TestUtil.checkReader with crossCheckTermVectors=false. I put a comment why, but I'll repeat it here. Let's say that your permutation is [2,0,1] which means doc 0 goes to 2, 1 goes to 0 and 2 goes to 1. You then ask for termVectors(0), and receive, correctly, those of document 2. Now, when crossCheck validation occurs, it iterates on the terms of the TV, expecting to find each term associated with document 0 (since CheckIndex doesn't know about sorting reader, and that in fact it works now w/ doc #2). However, the terms of doc #2 are mapped, again - correctly, to document #1 (as the permutation specifies). Therefore CheckIndex fails since it expects doc 0 but receives doc 1. Unless I misunderstand how this cross-checking should work, I think that it's ok to disable cross-checking on the reader, in this case. In SorterUtilTest, where I addIndexes, I do checkIndex with cross-checking, and there it passes (as it should). All that's missing is CHANGES, but I'll let others review ... > Port index sorter to trunk APIs > --- > > Key: LUCENE-3918 > URL: https://issues.apache.org/jira/browse/LUCENE-3918 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 4.0-ALPHA >Reporter: Robert Muir > Fix For: 4.2, 5.0 > > Attachments: LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch > > > LUCENE-2482 added an IndexSorter to 3.x, but we need to port this > functionality to 4.0 apis. -- 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-4654) Test duration statistics from multiple test runs should be reused (locally).
[ https://issues.apache.org/jira/browse/LUCENE-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592172#comment-13592172 ] Commit Tag Bot commented on LUCENE-4654: [branch_4x commit] Dawid Weiss http://svn.apache.org/viewvc?view=revision&revision=1452277 LUCENE-4654: Test duration statistics from multiple test runs should be reused (locally). > Test duration statistics from multiple test runs should be reused (locally). > > > Key: LUCENE-4654 > URL: https://issues.apache.org/jira/browse/LUCENE-4654 > Project: Lucene - Core > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 4.2, 5.0 > > > This is trivial to accomplish: when somebody (or jenkins) runs tests multiple > times the execution statistics could be reused to improve load balancing on > the local machine (local hardware and settings) in favor of the precached > values currently version in the svn repo. > At this moment we already do this, but keep the stats under build/ and every > ant clean effectively removes them. I could move those stats under an > svn-ignored folder elsewhere so that these stats are not lost and reused for > balancing. -- 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-NightlyTests-trunk - Build # 196 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/196/ All tests passed Build Log: [...truncated 29229 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:388: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/build.xml:320: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/licenses/carrot2-mini-LICENSE-BSD_LIKE.txt * solr/licenses/carrot2-mini-NOTICE.txt Total time: 107 minutes 14 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts 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
[jira] [Commented] (LUCENE-4654) Test duration statistics from multiple test runs should be reused (locally).
[ https://issues.apache.org/jira/browse/LUCENE-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592165#comment-13592165 ] Commit Tag Bot commented on LUCENE-4654: [trunk commit] Dawid Weiss http://svn.apache.org/viewvc?view=revision&revision=1452276 LUCENE-4654: Test duration statistics from multiple test runs should be reused (locally). > Test duration statistics from multiple test runs should be reused (locally). > > > Key: LUCENE-4654 > URL: https://issues.apache.org/jira/browse/LUCENE-4654 > Project: Lucene - Core > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 4.2, 5.0 > > > This is trivial to accomplish: when somebody (or jenkins) runs tests multiple > times the execution statistics could be reused to improve load balancing on > the local machine (local hardware and settings) in favor of the precached > values currently version in the svn repo. > At this moment we already do this, but keep the stats under build/ and every > ant clean effectively removes them. I could move those stats under an > svn-ignored folder elsewhere so that these stats are not lost and reused for > balancing. -- 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-4654) Test duration statistics from multiple test runs should be reused (locally).
[ https://issues.apache.org/jira/browse/LUCENE-4654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-4654. - Resolution: Fixed I've implemented this and committed it in along with an update to precomputed statistics. This will *not* make your tests a whole lot faster because there is job-stealing by default anyway so unless you really hit a long test scheduled at the very end of a series of per-jvm tests it won't make a difference. Obviously it won't make any difference if you're running with a single JVM either. What may make a (small) difference is for people with a lot of cores or, paradoxically, a few cores on slower machines. I think it's an improvement over the existing version anyway so it's for the better. > Test duration statistics from multiple test runs should be reused (locally). > > > Key: LUCENE-4654 > URL: https://issues.apache.org/jira/browse/LUCENE-4654 > Project: Lucene - Core > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: 4.2, 5.0 > > > This is trivial to accomplish: when somebody (or jenkins) runs tests multiple > times the execution statistics could be reused to improve load balancing on > the local machine (local hardware and settings) in favor of the precached > values currently version in the svn repo. > At this moment we already do this, but keep the stats under build/ and every > ant clean effectively removes them. I could move those stats under an > svn-ignored folder elsewhere so that these stats are not lost and reused for > balancing. -- 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-4503) Add REST API methods to get schema information: fields, dynamic fields, and field types
[
https://issues.apache.org/jira/browse/SOLR-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592122#comment-13592122
]
Steve Rowe commented on SOLR-4503:
--
Thanks for the review, Yonik.
bq. It seems like there are multiple use-cases for the fields API...
{quote}
One just wants to get all the info/properties for a field, and they don't care
how that field is defined.
For example, they may want to look up field X to see if it's indexed, w/o
having to worry about if it's a "dynamic" field or not.
{quote}
I originally had code to do index lookup, but this API is about the schema, so
I took it out, thinking that index queries didn't belong.
bq. allowing the fields API to be used for dynamic fields also, but provide an
indicator about what pattern matched
In my current state I do have an "includeDynamic" query param for the
/schema/fields/fieldname request, to report the matching dynamic field
properties if fieldname isn't an explicitly declared field.
{quote}
One wants to get the actual definition definition in the schema (or as close to
that as possible), and they would expect to see something very close to what
they defined (or sent in using the fields API to create a new field). Showing
all possible field properties like "storeOffsetsWithPositions" are going to be
potentially confusing since people won't know what they mean and when/why they
have to specify them when creating new fields.
{quote}
bq. only returning non-default properties... so if you create an integer field
with "indexed=true", that's pretty much all you get back.
bq. having a parameter to allow requesting all "look through" properties.
Good idea, I'll do this.
{quote}
Also related: SOLR-4210
We should aim for being able to hit any node in the cluster w/o worrying about
which nodes are hosting which collections.
{quote}
Skimming Mark's patch modifying SolrDispatchFilter, I think the schema REST
requests will already be proxied, but I'll test to be sure.
bq. We should probably also default to indented JSON output.
OK, I'll switch to that.
> Add REST API methods to get schema information: fields, dynamic fields, and
> field types
> ---
>
> Key: SOLR-4503
> URL: https://issues.apache.org/jira/browse/SOLR-4503
> Project: Solr
> Issue Type: Sub-task
> Components: Schema and Analysis
>Affects Versions: 4.1
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: all.dynamic.fields.json, all.fields.json,
> all.field.types.json, coordinate.dynamic.field.json, date.field.type.json,
> price.field.json, SOLR-4503.patch, SOLR-4503.patch
>
>
> Add REST methods that provide properties for fields, dynamic fields, and
> field types, using paths:
> /solr/(corename)/schema/fields
> /solr/(corename)/schema/fields/fieldname
> /solr/(corename)/schema/dynamicfields
> /solr/(corename)/schema/dynamicfields/pattern
> /solr/(corename)/schema/fieldtypes
> /solr/(corename)/schema/fieldtypes/typename
--
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-Windows (32bit/jdk1.7.0_15) - Build # 2601 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2601/ Java: 32bit/jdk1.7.0_15 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 30094 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:381: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:320: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:120: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/licenses/carrot2-mini-LICENSE-BSD_LIKE.txt * solr/licenses/carrot2-mini-NOTICE.txt Total time: 72 minutes 28 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 32bit/jdk1.7.0_15 -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
[jira] [Commented] (LUCENE-4752) Merge segments to sort them
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592107#comment-13592107 ] Adrien Grand commented on LUCENE-4752: -- I think a very simple first step could be have an experimental IndexWriterConfig option to tell IndexWriter to provide an atomic sorted view (easy once LUCENE-3918 is committed) of the segments to merge to SegmentMerger instead of the segments themselves (see calls to SegmentMerger.add(SegmentReader) in IndexWriter.mergeMiddle). Initial segments would remain unsorted, but the big ones, those that are interesting for both index compression and early query termination, would be sorted. It can seem inefficient to sort segments over and over but I don't think we should worry too much: - if we are merging "initial" segments (those created from IndexWriter.flush), they would be small so sorting/merging them would be fast? - if we are merging big segments, I think that the following reasons could make merging slower than a regular merge: 1. computing the new doc ID mapping, 2. random I/O access, 3. not being able to use the specialized codec merging methods. But if the segments to merge are sorted, computing the new doc ID mapping could be actually fast (some sorting algorithms such as [TimSort|http://en.wikipedia.org/wiki/Timsort] perform in O(n) when the input is a succession of sorted sequences), and the access patterns to the individual segments would be I/O cache-friendly (because each segment would be read sequentially). So I think this approach could be fast enough? > Merge segments to sort them > --- > > Key: LUCENE-4752 > URL: https://issues.apache.org/jira/browse/LUCENE-4752 > Project: Lucene - Core > Issue Type: New Feature > Components: core/index >Reporter: David Smiley >Assignee: Adrien Grand > > It would be awesome if Lucene could write the documents out in a segment > based on a configurable order. This of course applies to merging segments > to. The benefit is increased locality on disk of documents that are likely to > be accessed together. This often applies to documents near each other in > time, but also spatially. -- 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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592104#comment-13592104 ] Per Steffensen commented on SOLR-4470: -- My time was prioritized to work on something else. But now I am back on this issue, and hopefully I will provide patch soon. > Support for basic http auth in internal solr requests > - > > Key: SOLR-4470 > URL: https://issues.apache.org/jira/browse/SOLR-4470 > Project: Solr > Issue Type: Bug > Components: clients - java, multicore, replication (java), SolrCloud >Affects Versions: 4.0 >Reporter: Per Steffensen > Labels: authentication, solrclient, solrcloud > Fix For: 4.2 > > > We want to protect any HTTP-resource (url). We want to require credentials no > matter what kind of HTTP-request you make to a Solr-node. > It can faily easy be acheived as described on > http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes > also make "internal" request to other Solr-nodes, and for it to work > credentials need to be provided here also. > Ideally we would like to "forward" credentials from a particular request to > all the "internal" sub-requests it triggers. E.g. for search and update > request. > But there are also "internal" requests > * that only indirectly/asynchronously triggered from "outside" requests (e.g. > shard creation/deletion/etc based on calls to the "Collection API") > * that do not in any way have relation to an "outside" "super"-request (e.g. > replica synching stuff) > We would like to aim at a solution where "original" credentials are > "forwarded" when a request directly/synchronously trigger a subrequest, and > fallback to a configured "internal credentials" for the > asynchronous/non-rooted requests. > In our solution we would aim at only supporting basic http auth, but we would > like to make a "framework" around it, so that not to much refactoring is > needed if you later want to make support for other kinds of auth (e.g. digest) > We will work at a solution but create this JIRA issue early in order to get > input/comments from the community as early as possible. -- 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-3918) Port index sorter to trunk APIs
[ https://issues.apache.org/jira/browse/LUCENE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592093#comment-13592093 ] Andrzej Bialecki commented on LUCENE-3918: --- Shai, bq. That way, one can use it to achieve per-segment sorting .. if it means something for anyone (perhaps for better compression). Global ordering over a multi-segment index seems less useful than the local per-segment ordering - after all, the main use cases are compression improvements and early termination strategies, both of which operate on a per-segment basis. > Port index sorter to trunk APIs > --- > > Key: LUCENE-3918 > URL: https://issues.apache.org/jira/browse/LUCENE-3918 > Project: Lucene - Core > Issue Type: Task > Components: modules/other >Affects Versions: 4.0-ALPHA >Reporter: Robert Muir > Fix For: 4.2, 5.0 > > Attachments: LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, > LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch, LUCENE-3918.patch > > > LUCENE-2482 added an IndexSorter to 3.x, but we need to port this > functionality to 4.0 apis. -- 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-4259) Carrot2 dependency should be declared on the mini version, not the core
[ https://issues.apache.org/jira/browse/SOLR-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592087#comment-13592087 ] Commit Tag Bot commented on SOLR-4259: -- [branch_4x commit] Dawid Weiss http://svn.apache.org/viewvc?view=revision&revision=1452221 SOLR-4259: Carrot2 dependency should be declared on the mini version, not the core. > Carrot2 dependency should be declared on the mini version, not the core > --- > > Key: SOLR-4259 > URL: https://issues.apache.org/jira/browse/SOLR-4259 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.2, 5.0 > > > Check why we depend on the full core POM anyway; the mini version should be > enough for algorithms (we wouldn't need so many exclusions then). -- 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-4259) Carrot2 dependency should be declared on the mini version, not the core
[ https://issues.apache.org/jira/browse/SOLR-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved SOLR-4259. --- Resolution: Fixed > Carrot2 dependency should be declared on the mini version, not the core > --- > > Key: SOLR-4259 > URL: https://issues.apache.org/jira/browse/SOLR-4259 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.2, 5.0 > > > Check why we depend on the full core POM anyway; the mini version should be > enough for algorithms (we wouldn't need so many exclusions then). -- 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-4259) Carrot2 dependency should be declared on the mini version, not the core
[ https://issues.apache.org/jira/browse/SOLR-4259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592083#comment-13592083 ] Commit Tag Bot commented on SOLR-4259: -- [trunk commit] Dawid Weiss http://svn.apache.org/viewvc?view=revision&revision=1452220 SOLR-4259: Carrot2 dependency should be declared on the mini version, not the core. > Carrot2 dependency should be declared on the mini version, not the core > --- > > Key: SOLR-4259 > URL: https://issues.apache.org/jira/browse/SOLR-4259 > Project: Solr > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.2, 5.0 > > > Check why we depend on the full core POM anyway; the mini version should be > enough for algorithms (we wouldn't need so many exclusions then). -- 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-4506) [solr4.0.0] many index.{date} dir in replication node
[
https://issues.apache.org/jira/browse/SOLR-4506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592075#comment-13592075
]
zhuojunjian commented on SOLR-4506:
---
hi
do you have any plan for this issue ?
4.1 or other ?
> [solr4.0.0] many index.{date} dir in replication node
> --
>
> Key: SOLR-4506
> URL: https://issues.apache.org/jira/browse/SOLR-4506
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.0
> Environment: the solr4.0 runs on suse11.
> mem:32G
> cpu:16 cores
>Reporter: zhuojunjian
> Fix For: 4.0
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> in our test,we used solrcloud feature in solr4.0(version detail
> :4.0.0.2012.10.06.03.04.33).
> the solrcloud configuration is 3 shards and 2 replications each shard.
> we found that there are over than 25 dirs which named index.{date} in one
> replication node belonging to shard 3.
> for example:
> index.2013021725864 index.20130218012211880 index.20130218015714713
> index.20130218023101958 index.20130218030424083 tlog
> index.20130218005648324 index.20130218012751078 index.20130218020141293
> the issue seems like SOLR-1781. but it is fixed in 4.0-BETA,5.0.
> so is solr4.0 ? if it is fixed too in solr4.0, why we find the issue again ?
> what can I do?
--
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
