[jira] [Updated] (LUCENE-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3977.patch latest patch, found a few unrelated things: * join module links to package-private classes * MorfologikFilterFactory is in a solr/contrib, but the jar is added to lucene-libs (into the war) versus being plugged Lucene parts here should work. Solr is not ready yet, need to define a macro as before so these contribs/test-framework/etc can add their own links. > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch, > LUCENE-3977.patch, LUCENE-3977.patch, LUCENE-3977.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3385) Extended Dismax parser ignores all regular search terms when one search term is using + (dismax behaves differently)
[ https://issues.apache.org/jira/browse/SOLR-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Kaiser updated SOLR-3385: -- Attachment: select_PLUSsales_edismax_9600results.xml select_PLUSsales_dismax_9600results.xml select_dev_sales_miau_edismax_0results.xml select_dev_PLUSsales_miau_edismax_9600results.xml select_dev_PLUSsales_miau_dismax_0results.xml select_dev_PLUSsales_edismax_9600results.xml select_dev_PLUSsales_dismax_553results.xml Added explain queries for the cases explained in the description. Tried both dismax and edismax parser. the file name format is: select_[used search terms (PLUS means +)]_[dismax / edismax]_[number of results]results.xml DISMAX: As you can see, dismax behaves differently (it always assumes a search term without a + behaves as if it had + specified). "+sales" -> 9600 results "dev +sales" -> 553 results "dev +sales miau" -> 0 results (miau is not in index). EDISMAX: On the other hand, edismax parser ignores the terms that do not start with + if another term has + specified. "+sales" -> 9600 results "dev +sales" -> 9600 results "dev +sales miau" -> 9600 results "dev sales miau" -> 0 results (the bug only occurs if at least one search term uses + or -) > Extended Dismax parser ignores all regular search terms when one search term > is using + (dismax behaves differently) > > > Key: SOLR-3385 > URL: https://issues.apache.org/jira/browse/SOLR-3385 > Project: Solr > Issue Type: Bug > Components: query parsers >Affects Versions: 3.5 >Reporter: Nils Kaiser > Attachments: select_PLUSsales_dismax_9600results.xml, > select_PLUSsales_edismax_9600results.xml, > select_dev_PLUSsales_dismax_553results.xml, > select_dev_PLUSsales_edismax_9600results.xml, > select_dev_PLUSsales_miau_dismax_0results.xml, > select_dev_PLUSsales_miau_edismax_9600results.xml, > select_dev_sales_miau_edismax_0results.xml > > > When using the extended dismax parser with at least one term using + or -, > all other search terms are ignored. > Example: > (the terms dev and sales are found in the index, the term miau is not part of > the index) > "dev sales miau", "+dev +sales +miau", "dev +sales +miau" all give me 0 > results (as expected) > "dev +sales miau", "dev +sales" or "+sales" return the same number of results > (dev and miau terms are ignored) > The standard dismax parser always treats search terms as +, so "dev sales > miau", "+dev +sales miau", "dev +sales miau" return the same number of > results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3977.patch Updated patch that improves our docs/api/index.html (the javadocs-index.html task), to also include the project description (from the ant file). I also tried to clean up these descriptions and make them useful. I think the index.html looks much more useful now, and this is really a possible way we can nuke the manually-maintained forrest index under src/site in the future (but not here). > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch, > LUCENE-3977.patch, LUCENE-3977.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Affects Version/s: (was: 3.6.1) removed 3.6 from affected versions > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3134-shard-info-3_6.patch, > SOLR-3369-shards-tolerant-3_6.patch, SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error when shards are > down. This patch allows users to use the shard tolerance feature with facet > and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3386) ExtractingRequestHandler applies fname settings to literals
[ https://issues.apache.org/jira/browse/SOLR-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Hebert updated SOLR-3386: --- Description: The SolrContentHandler.addLiterals() method call the SolrContentHandler.addField() which itself obtains the field with SolrContentHandler.findMappedName(). If this call makes sense with SolrContentHandler.addMetadata() [and others] because the user can't set the name of the fields otherwise, with literals it isn't useful, the name of the field is manually given by the user and it shouldn't be modified at all (maybe applying unknownFieldPrefix or defaultField could be done, but even that doesn't seem quite normal). I got this issue with the following usecase: I have a schema containing a "title" field which is mandatory and contains only one value. My documents have an internal title which is used as the value of the "title" field. When sending one of these documents (and HTML document), if it contains a "title" metadata I get an exception because I have multiple values for my "title" field (an exception I expect). To fix that I used "fname.title=tika_title", so the title provided by tika is kept under another name. Both titles (the original one I pass manually, and the metadata one) are now stored in the field "tika_title" and I get an exception because the "title" field hasn't been provided at all. An easy workaround for this bug is sending the literal named as "my_title", and adding the following fnames "fname.my_title=title&fname.title=tika_title". A small swicheroo which puts back the correct value in the expected field. A way to fix that is extracting the first part of SolrContentHandler.addField() (lowerNames and findMappedName()) in an external method (or put the lowerNames check in SolrContentHandler.findMappedName() ) and use that external method (or findMappedName() ) _before_ calling SolrContentHandler.addField() was: The SolrContentHandler.addLiterals() method call the SolrContentHandler.addField() which itself obtains the field with SolrContentHandler.findMappedName(). If this call makes sense with SolrContentHandler.addMetadata() [and others] because the user can't set the name of the fields otherwise, with literals, the name of the field is manually given by the user and it shouldn't be changed at all (maybe applying unknownFieldPrefix or defaultField could be done, but even that doesn't seem quite normal). I got this issue with the following usecase: I have a schema containing a "title" field which is mandatory and contains only one value. My documents have an internal title which is used as the value of the "title" field. When sending one of these documents (and HTML document), if it contains a "title" metadata I get an exception because I have multiple values for my "title" field (an exception I expect). To fix that I used "fname.title=tika_title", so the title provided by tika is kept under another name. Both titles (the original one I pass manually, and the metadata one) are now stored in the field "tika_title" and I get an exception because the "title" field hasn't been provided at all. An easy workaround for this bug is sending the literal named as "my_title", and adding the following fnames "fname.my_title=title&fname.title=tika_title". A small swicheroo which puts back the correct value in the expected field. A way to fix that is extracting the first part of SolrContentHandler.addField() (lowerNames and findMappedName()) in an external method (or put the lowerNames check in SolrContentHandler.findMappedName() ) and use that external method (or findMappedName() ) _before_ calling SolrContentHandler.addField() > ExtractingRequestHandler applies fname settings to literals > --- > > Key: SOLR-3386 > URL: https://issues.apache.org/jira/browse/SOLR-3386 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 3.5 >Reporter: Colin Hebert >Priority: Minor > > The SolrContentHandler.addLiterals() method call the > SolrContentHandler.addField() which itself obtains the field with > SolrContentHandler.findMappedName(). > If this call makes sense with SolrContentHandler.addMetadata() [and others] > because the user can't set the name of the fields otherwise, with literals it > isn't useful, the name of the field is manually given by the user and it > shouldn't be modified at all (maybe applying unknown
[jira] [Updated] (SOLR-3386) ExtractingRequestHandler applies fname settings to literals
[ https://issues.apache.org/jira/browse/SOLR-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin Hebert updated SOLR-3386: --- Description: The SolrContentHandler.addLiterals() method call the SolrContentHandler.addField() which itself obtains the field with SolrContentHandler.findMappedName(). If this call makes sense with SolrContentHandler.addMetadata() [and others] because the user can't set the name of the fields otherwise, with literals, the name of the field is manually given by the user and it shouldn't be changed at all (maybe applying unknownFieldPrefix or defaultField could be done, but even that doesn't seem quite normal). I got this issue with the following usecase: I have a schema containing a "title" field which is mandatory and contains only one value. My documents have an internal title which is used as the value of the "title" field. When sending one of these documents (and HTML document), if it contains a "title" metadata I get an exception because I have multiple values for my "title" field (an exception I expect). To fix that I used "fname.title=tika_title", so the title provided by tika is kept under another name. Both titles (the original one I pass manually, and the metadata one) are now stored in the field "tika_title" and I get an exception because the "title" field hasn't been provided at all. An easy workaround for this bug is sending the literal named as "my_title", and adding the following fnames "fname.my_title=title&fname.title=tika_title". A small swicheroo which puts back the correct value in the expected field. A way to fix that is extracting the first part of SolrContentHandler.addField() (lowerNames and findMappedName()) in an external method (or put the lowerNames check in SolrContentHandler.findMappedName() ) and use that external method (or findMappedName() ) _before_ calling SolrContentHandler.addField() was: The SolrContentHandler.addLiterals() method call the SolrContentHandler.addField() which itself obtain the field with SolrContentHandler.findMappedName(). If this call makes sense with SolrContentHandler.addMetadata() [and others] because the user can't set the name of the fields otherwise, but with literals, the name of the field is manually given by the user so it shouldn't be changed at all (maybe applying unknownFieldPrefix or defaultField could be done, but even that doesn't seem quite normal). I got this issue with the following usecase: I have a schema containing a "title" field which is mandatory and contains only one value. My documents have an internal title which is used as the value of the "title" field. When sending one of these documents (and HTML document), if it contains a "title" metadata I get an exception because I have multiple values for my "title" field (as I would expect). To fix that I used "fname.title=tika_title", so the title provided by tika is kept under another name. Both titles (the original one I pass manually, and the metadata one) are now named "tika_title" and I get an exception because "title" hasn't been provided at all. An easy workaround for this bug is sending the literal as "my_title", and adding the following fnames "fname.my_title=title&fname.title=tika_title". A small swicheroo which puts back the correct value in the expected field. A way to fix that is extracting the first blocks of SolrContentHandler.addField() in an external method (or put the lowerNames check in SolrContentHandler.findMappedName() ) and use that external method (or findMappedName() ) _before_ calling SolrContentHandler.addField() > ExtractingRequestHandler applies fname settings to literals > --- > > Key: SOLR-3386 > URL: https://issues.apache.org/jira/browse/SOLR-3386 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 3.5 >Reporter: Colin Hebert >Priority: Minor > > The SolrContentHandler.addLiterals() method call the > SolrContentHandler.addField() which itself obtains the field with > SolrContentHandler.findMappedName(). > If this call makes sense with SolrContentHandler.addMetadata() [and others] > because the user can't set the name of the fields otherwise, with literals, > the name of the field is manually given by the user and it shouldn't be > changed at all (maybe applying unknownFieldPrefix or defaultField could be > done, but even that doesn't seem quite normal). > &g
[jira] [Updated] (LUCENE-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3977.patch sorry, i had attached the wrong patch. > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch, > LUCENE-3977.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: (was: LUCENE-3997.patch) > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch, > LUCENE-3977.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3997.patch updated patch, that generates relative links (i wrongly had linkOffline=true set) > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch, > LUCENE-3997.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3977.patch here's a prototype (not ready for committing yet!) .zip binary release is reduced 12MB again: -rw-rw-r-- 1 rmuir rmuir 56883313 2012-04-20 09:53 lucene-4.0.0.zip .tgz (for reference): -rw-rw-r-- 1 rmuir rmuir 47958933 2012-04-20 09:53 lucene-4.0.0.tgz basically all i did here is the core/ dependency: but i can easily fix the others, and then solr. the idea is to remove javadocs-all, instead when you are in queries/ javadocs and click IndexReader it jumps you to core/. solr would keep its 'define-javadoc-url' stuff, except instead of it pointing to whatever/whatever/api/all/ it would just point to whatever/whatever/api and be used as the prefix. > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch, LUCENE-3977.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3371) Admin UI breaks with a core named 'logging' or 'threads'
[ https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3371: Attachment: SOLR-3371.patch Updated Patch (Line-Numbers in cloud.js changed). Ryan, Core-Admin works for me :? Does it still not work for you? And if so, did you get an error message or just no reaction while browsing Core-Admin? And beside this, which OS/Browser is it? > Admin UI breaks with a core named 'logging' or 'threads' > > > Key: SOLR-3371 > URL: https://issues.apache.org/jira/browse/SOLR-3371 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Fix For: 4.0 > > Attachments: SOLR-3371.patch, SOLR-3371.patch > > > If you make a core with the name "logging" or "threads" the UI gets confused > with the logging or threads page. > It seems like the ~threads and ~logging should be enough to distinguish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3363) Replace RuntimeExceptions in Analysis Factories
[
https://issues.apache.org/jira/browse/SOLR-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated SOLR-3363:
-
Attachment: SOLR-3363.patch
Patch.
> Replace RuntimeExceptions in Analysis Factories
> ---
>
> Key: SOLR-3363
> URL: https://issues.apache.org/jira/browse/SOLR-3363
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Chris Male
> Attachments: SOLR-3363.patch
>
>
> Currently there is no consistent use of Exceptions in Analysis factories.
> Some throw RuntimeExceptions, some throw SolrExceptions, some include
> information about an Exception they are wrapping, others just wrap, throw and
> move on.
> I think a better way would be to have an InitializationException that the
> Factories can throw in {{init()}} or {{inform(ResourceLoader)}}. We can then
> tailor the Exception to meet the needs of the Factories, and it gives us a
> bit of future proofing if/when we improve the property validation done in the
> factories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3383) Async responses in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen updated SOLR-3383: - Description: Today it is like this - SolrServer.request returns NamedList - SolrRequest.process returns SolrResponse - Public methods on SolrServer like addX, optimize, commit, queryX etc. returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) - etc This is all synchronous - that is, the calling thread of those methods will wait for the response before being able to continue. I believe the industry today agrees that "operations" like client-server network-requireing operations should be done asynchronously seens from the client API. Therefore basically we should change those methods - SolrServer.request returns Future> - SolrRequest.process returns Future - SolrServer.xxx returns Future and make the appropriate changes in the implementations below. My main argument for this right now, is that ConcurrentUpdateSolrServer really is not able to hand over responses to the calling client. Guess that it is also the reason why it is only a "Update"-SolrServer and not a complete SolrServer (being able to do queries etc.) - updates does not require sending responses (except primitive errors) back to the client, queries etc does. Now that we do "finegrained error propagation" (SOLR-3382) in order to send "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178) back to the client in responses to update-request, suddenly it is not true anymore that updates does not require sending responses back to the client. Making the changes suggested above (returning Futures) would - Allow ConcurrentUpdateSolrServer to be used for updates potentially resulting in "unique key constraint"- and "versioning"-errors - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also being able to do queries etc - Do cool stuff like SOLR-3384 - Make SolrJ more modern with respect to asynchronous principles was: Today it is like this - SolrServer.request returns NamedList - SolrRequest.process returns SolrResponse - Public methods on SolrServer like addX, optimize, commit, queryX etc. returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) - etc This is all synchronous - that is, the calling thread of those methods will wait for the response before being able to continue. I believe the industry today agrees that "operations" like client-server network-requireing operations should be done asynchronously seens from the client API. Therefore basically we should change those methods - SolrServer.request returns Future> - SolrRequest.process returns Future - SolrServer.xxx returns Future and make the appropriate changes in the implementations below. My main argument for this right now, is that ConcurrentUpdateSolrServer really is not able to hand over responses to the calling client. Guess that it is also the reason why it is only a "Update"-SolrServer and not a complete SolrServer (being able to do queries etc.) - updates does not require sending responses (except primitive errors) back to the client, queries etc does. Now that we do "finegrained error propagation" (SOLR-3382) in order to send "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178) back to the client in responses to update-request, suddenly it is not true anymore that updates does not require sending responses back to the client. Making the changes suggested above (returning Futures) would - Allow ConcurrentUpdateSolrServer to be used for updates potentially resulting in "unique key constraint"- and "versioning"-errors - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also being able to do queries etc - Make SolrJ more modern with respect to asynchronous principles > Async responses in SolrJ > > > Key: SOLR-3383 > URL: https://issues.apache.org/jira/browse/SOLR-3383 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.5 >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: async, asynchronous, concurrency, query, solrj, update > Fix For: 4.0 > > > Today it is like this > - SolrServer.request returns NamedList > - SolrRequest.process returns SolrResponse > - Public methods on SolrServer like addX, optimize, commit, queryX etc. > returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) > - etc > This is all synchronous - that is, the calling thread of those methods will > wait for the response befor
[jira] [Updated] (SOLR-3383) Async responses in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen updated SOLR-3383: - Description: Today it is like this - SolrServer.request returns NamedList - SolrRequest.process returns SolrResponse - Public methods on SolrServer like addX, optimize, commit, queryX etc. returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) - etc This is all synchronous - that is, the calling thread of those methods will wait for the response before being able to continue. I believe the industry today agrees that "operations" like client-server network-requireing operations should be done asynchronously seens from the client API. Therefore basically we should change those methods - SolrServer.request returns Future> - SolrRequest.process returns Future - SolrServer.xxx returns Future and make the appropriate changes in the implementations below. My main argument for this right now, is that ConcurrentUpdateSolrServer really is not able to hand over responses to the calling client. Guess that it is also the reason why it is only a "Update"-SolrServer and not a complete SolrServer (being able to do queries etc.) - updates does not require sending responses (except primitive errors) back to the client, queries etc does. Now that we do "finegrained error propagation" (SOLR-3382) in order to send "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178) back to the client in responses to update-request, suddenly it is not true anymore that updates does not require sending responses back to the client. Making the changes suggested above (returning Futures) would - Allow ConcurrentUpdateSolrServer to be used for updates potentially resulting in "unique key constraint"- and "versioning"-errors - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also being able to do queries etc - Make SolrJ more modern with respect to asynchronous principles was: Today it is like this - SolrServer.request returns NamedList - SolrRequest.process returns SolrResponse - Public methods on SolrServer like addX, optimize, commit, queryX etc. returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) - etc This is all synchronous - that is, the calling thread of those methods will wait for the response before being able to continue. I believe the industry today agrees that "operations" like client-server network-requireing operations should be done asynchronously seens from the client API. Therefore basically we should change those methods - SolrServer.request returns Future> - SolrRequest.process returns Future - SolrServer.xxx returns Future and make the appropriate changes in the implementations below. My main argument for this right now, is that ConcurrentUpdateSolrServer really is not able to hand over responses to the calling client. Guess that it is also the reason why it is only a "Update"-SolrServer and not a complete SolrServer (being able to do queries etc.) - updates does not require sending responses (except primitive errors) back to the client, queries etc does. Now that we do "finegrained error propagation" (SOLR-3382) in order to send "unique key constraint"- and "versioning"-errors (SOLR-3173 and SOLR-3178) back to the client in responses to update-request, suddenly it is not true anymore that updates does not require sending responses back to the client. Making the changes suggested above (returning Futures) would - Allow ConcurrentUpdateSolrServer to be used for updates potentially resulting in "unique key constraint"- and "versioning"-errors - Allow ConcurrentUpdateSolrServer to become ConcurrentSolrServer - also being able to do queries etc - Make Solr more modern with respect to asynchronous principles > Async responses in SolrJ > > > Key: SOLR-3383 > URL: https://issues.apache.org/jira/browse/SOLR-3383 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.5 >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: async, asynchronous, concurrency, query, solrj, update > Fix For: 4.0 > > > Today it is like this > - SolrServer.request returns NamedList > - SolrRequest.process returns SolrResponse > - Public methods on SolrServer like addX, optimize, commit, queryX etc. > returns subclasses of SolrResponse (e.g. "add" returns UpdateResponse) > - etc > This is all synchronous - that is, the calling thread of those methods will > wait for the response before being able to continue. I believe th
[jira] [Updated] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-3178: --- Attachment: SOLR-3178.patch Here's a patch that seems to work fine. There's really no extra input-API - all you do is supply a _version_ in the document (or as a parameter on the URL for a delete) and you get back a 409 if it's incorrect. I'll probably commit this soon and we can incrementally improve by adding better support to SolrJ (I'm not sure there's an easy way to specify the version for a delete from solrJ). > Versioning - optimistic locking > --- > > Key: SOLR-3178 > URL: https://issues.apache.org/jira/browse/SOLR-3178 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 3.5 > Environment: All >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, > update, versioning > Fix For: 4.0 > > Attachments: SOLR-3178.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > In order increase the ability of Solr to be used as a NoSql database (lots of > concurrent inserts, updates, deletes and queries in the entire lifetime of > the index) instead of just a search index (first: everything indexed (in one > thread), after: only queries), I would like Solr to support versioning to be > used for optimistic locking. > When my intent (see SOLR-3173) is to update an existing document, I will need > to provide a version-number equal to "the version number I got when I fetched > the existing document for update" plus one. If this provided version-number > does not correspond to "the newest version-number of that document at the > time of update" plus one, I will get a VersionConflict error. If it does > correspond the document will be updated with the new one, so that "the newest > version-number of that document" is NOW one higher than before the update. > Correct but efficient concurrency handling. > When my intent (see SOLR-3173) is to insert a new document, the version > number provided will not be used - instead a version-number 0 will be used. > According to SOLR-3173 insert will only succeed if a document with the same > value on uniqueKey-field does not already exist. > In general when talking about different versions of "the same document", of > course we need to be able to identify when a document "is the same" - that, > per definition, is when the values of the uniqueKey-fields are equal. > The functionality provided by this issue is only really meaningfull when you > run with "updateLog" activated. > This issue might be solved more or less at the same time as SOLR-3173, and > only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3174: Attachment: SOLR-3174-rgraph.png SOLR-3174-graph.png Updated Screens, to show what it will typically look like. > Visualize Cluster State > --- > > Key: SOLR-3174 > URL: https://issues.apache.org/jira/browse/SOLR-3174 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, > SOLR-3174-graph.png, SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, > SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, SOLR-3174.patch, > SOLR-3174.patch, SOLR-3174.patch > > > It would be great to visualize the cluster state in the new UI. > See Mark's wish: > https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3174: Attachment: SOLR-3174.patch So, there we go, updated patch with the logic, previously described > Visualize Cluster State > --- > > Key: SOLR-3174 > URL: https://issues.apache.org/jira/browse/SOLR-3174 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, > SOLR-3174-graph.png, SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, > SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, SOLR-3174.patch, > SOLR-3174.patch, SOLR-3174.patch > > > It would be great to visualize the cluster state in the new UI. > See Mark's wish: > https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3381) FieldStreamDataSource should support CLOBs
[
https://issues.apache.org/jira/browse/SOLR-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Watermeyer updated SOLR-3381:
-
Attachment: FieldStreamDataSource.java
> FieldStreamDataSource should support CLOBs
> --
>
> Key: SOLR-3381
> URL: https://issues.apache.org/jira/browse/SOLR-3381
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 3.5
>Reporter: Andreas Watermeyer
>Priority: Minor
> Attachments: FieldStreamDataSource.java
>
>
> The {{FieldStreamDataSource}} should be capable to handle {{java.sql.Clob}}
> s, too.
> Currently it handles {{java.sql.Blob}} s and {{byte[]}} only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3381) FieldStreamDataSource should support CLOBs
[
https://issues.apache.org/jira/browse/SOLR-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Watermeyer updated SOLR-3381:
-
Attachment: (was: FieldStreamDataSource.java)
> FieldStreamDataSource should support CLOBs
> --
>
> Key: SOLR-3381
> URL: https://issues.apache.org/jira/browse/SOLR-3381
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 3.5
>Reporter: Andreas Watermeyer
>Priority: Minor
> Attachments: FieldStreamDataSource.java
>
>
> The {{FieldStreamDataSource}} should be capable to handle {{java.sql.Clob}}
> s, too.
> Currently it handles {{java.sql.Blob}} s and {{byte[]}} only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3381) FieldStreamDataSource should support CLOBs
[
https://issues.apache.org/jira/browse/SOLR-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Watermeyer updated SOLR-3381:
-
Attachment: FieldStreamDataSource.java
I have attached a subclass of FieldStreamDataSource which supports Clobs, too.
> FieldStreamDataSource should support CLOBs
> --
>
> Key: SOLR-3381
> URL: https://issues.apache.org/jira/browse/SOLR-3381
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 3.5
>Reporter: Andreas Watermeyer
>Priority: Minor
> Attachments: FieldStreamDataSource.java
>
>
> The {{FieldStreamDataSource}} should be capable to handle {{java.sql.Clob}}
> s, too.
> Currently it handles {{java.sql.Blob}} s and {{byte[]}} only.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3377) eDismax: A fielded query wrapped by parens is not recognized
[
https://issues.apache.org/jira/browse/SOLR-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-3377:
--
Fix Version/s: 3.6.1
> eDismax: A fielded query wrapped by parens is not recognized
>
>
> Key: SOLR-3377
> URL: https://issues.apache.org/jira/browse/SOLR-3377
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 3.6
>Reporter: Jan Høydahl
> Fix For: 4.0, 3.6.1
>
> Attachments: SOLR-3377.patch
>
>
> As reported by "bernd" on the user list, a query like this
> {{q=(name:test)}}
> will yield 0 hits in 3.6 while it worked in 3.5. It works without the parens.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3374) HttpClient jar not included in distribution
[ https://issues.apache.org/jira/browse/SOLR-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3374: - Fix Version/s: 3.6.1 Assignee: Sami Siren HttpSolrServer in 3.6.0 is buggy (SOLR-3375) so even if the libs were there you should probably not use it. I am marking this to be fixed in 3.6.1 to get this fixed if there's another release from 3.x (trunk should be fine). > HttpClient jar not included in distribution > --- > > Key: SOLR-3374 > URL: https://issues.apache.org/jira/browse/SOLR-3374 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.6 >Reporter: Roger HÃ¥kansson >Assignee: Sami Siren >Priority: Minor > Fix For: 3.6.1 > > > In 3.6 CommonsHttpSolrServer is deprecated in favor for HttpSolrServer > however in the distribution under solrj-lib, non of the required jar files > for HttpClient 4.x is included -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3375:
-
Affects Version/s: (was: 3.6.1)
(was: 4.0)
Fix Version/s: 3.6.1
Thanks Roger for the detailed report. I already fixed some bugs in trunk that I
introduced in SOLR-2020 and I believe that this problem should be fixed there
(r1327635).
I will leave this issue open so that if there will be a 3.6.1 release this fix
must be backported. In the meanwhile on 3.x the only workaround is to use the
CommonsHttpSolrServer.
> Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
> -
>
> Key: SOLR-3375
> URL: https://issues.apache.org/jira/browse/SOLR-3375
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 3.6
>Reporter: Roger HÃ¥kansson
> Fix For: 3.6.1
>
> Attachments: SolrTest.java, commonshttpsolrserver-dump.txt,
> httpsolrserver-dump.txt
>
>
> I've written an application which sends PDF files to Solr for indexing, but I
> also need to index some meta-data which isn't contained inside the PDF.
> I recently upgraded to 3.6.0 and when recompiling my app, I got some
> deprecated messages which mainly was to switch from CommonsHttpSolrServer to
> HttpSolrServer.
> The problem I've noticed since doing this, is that all extra fields which I
> add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
> matter, anything above char 127 is sent as '?'. This was not the behaviour of
> CommonsHttpSolrServer.
> I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
> entity.addPart(name, new StringBody(value));
> The problem is that StringBody(String text) maps to
> StringBody(text, "text/plain", null);
> and in
> StringBody(String text, String mimeType, Charset charset)
> we have this piece of code:
> if (charset == null) {
> charset = Charset.forName("US-ASCII");
> }
> this.content = text.getBytes(charset.name());
> this.charset = charset;
> So unless charset is set everything is converted to US-ASCII.
> On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
> this line
> parts.add(new StringPart(p, v, "UTF-8"));
> which adds everything as UTF-8.
> The simple solution would be to change the faulty line in HttpSolrServer.java
> to
> entity.addPart(name, new StringBody(value,Charset.forName("UTF-8")));
> However, this doesn't work either since my tests have shown that neither
> Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
> (8859-1 I guess).
> So changing HttpSolrServer.java to
> entity.addPart(name, new StringBody(value,Charset.forName("ISO-8859-1")));
> actually gives me the same result as using CommonsHttpSolrServer.
> But my investigations have shown that there is a difference in how
> Commons-HttpClient and HttpClient-4.x works.
> Commons-HttpClient sends all parameters as regular POST parameters but
> URLEncoded (/update/extract?param1=value¶m2=value2) while
> HttpClient-4.x sends them as multipart/form-data messages and I think that
> the problem is that each multipart-message should have its own charset
> parameter.
> I.e HttpClient-4.x sends
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> åäö
> ---
> But it should probably send something like this
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> Content-Type: text/plain; charset=utf-8
> åäö
> ---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2155) Geospatial search using geohash prefixes
[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-2155:
---
Description:
{panel:title=NOTICE} The status of this issue is a plugin for Solr 3.x located
here: https://github.com/dsmiley/SOLR-2155. Look at the introductory readme
and download the plugin .jar file. Lucene 4's new spatial module is largely
based on this code. The Solr 4 glue for it should come very soon but as of
this writing it's hosted temporarily at https://github.com/spatial4j. For more
information on using SOLR-2155 with Solr 3, see
http://wiki.apache.org/solr/SpatialSearch#SOLR-2155 This JIRA issue is closed
because it won't be committed in its current form.
{panel}
There currently isn't a solution in Solr for doing geospatial filtering on
documents that have a variable number of points. This scenario occurs when
there is location extraction (i.e. via a "gazateer") occurring on free text.
None, one, or many geospatial locations might be extracted from any given
document and users want to limit their search results to those occurring in a
user-specified area.
I've implemented this by furthering the GeoHash based work in Lucene/Solr with
a geohash prefix based filter. A geohash refers to a lat-lon box on the earth.
Each successive character added further subdivides the box into a 4x8 (or 8x4
depending on the even/odd length of the geohash) grid. The first step in this
scheme is figuring out which geohash grid squares cover the user's search
query. I've added various extra methods to GeoHashUtils (and added tests) to
assist in this purpose. The next step is an actual Lucene Filter,
GeoHashPrefixFilter, that uses these geohash prefixes in TermsEnum.seek() to
skip to relevant grid squares in the index. Once a matching geohash grid is
found, the points therein are compared against the user's query to see if it
matches. I created an abstraction GeoShape extended by subclasses named
PointDistance... and CartesianBox to support different queried shapes so
that the filter need not care about these details.
This work was presented at LuceneRevolution in Boston on October 8th.
was:
{panel:title=NOTICE} There is a .zip attached to the issue with a .jar you can
drop in to Solr 3.x. Lucene 4's new spatial module is largely based on this
code. The Solr 4 glue for it should come very soon but as of this writing it's
hosted temporarily at Spatial4j.com. For more information on using SOLR-2155
with Solr 3, see http://wiki.apache.org/solr/SpatialSearch#SOLR-2155 This JIRA
issue is closed because it won't be committed in its current form.
{panel}
There currently isn't a solution in Solr for doing geospatial filtering on
documents that have a variable number of points. This scenario occurs when
there is location extraction (i.e. via a "gazateer") occurring on free text.
None, one, or many geospatial locations might be extracted from any given
document and users want to limit their search results to those occurring in a
user-specified area.
I've implemented this by furthering the GeoHash based work in Lucene/Solr with
a geohash prefix based filter. A geohash refers to a lat-lon box on the earth.
Each successive character added further subdivides the box into a 4x8 (or 8x4
depending on the even/odd length of the geohash) grid. The first step in this
scheme is figuring out which geohash grid squares cover the user's search
query. I've added various extra methods to GeoHashUtils (and added tests) to
assist in this purpose. The next step is an actual Lucene Filter,
GeoHashPrefixFilter, that uses these geohash prefixes in TermsEnum.seek() to
skip to relevant grid squares in the index. Once a matching geohash grid is
found, the points therein are compared against the user's query to see if it
matches. I created an abstraction GeoShape extended by subclasses named
PointDistance... and CartesianBox to support different queried shapes so
that the filter need not care about these details.
This work was presented at LuceneRevolution in Boston on October 8th.
I updated this issue's leading description info box to point to my GitHub repo
for this code and its evolution. It's also where the releases are posted now.
> Geospatial search using geohash prefixes
>
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
> GeoHashPrefixFilter.patch,
> SOLR-2155_GeoHashPrefixFilter_wit
[jira] [Updated] (LUCENE-3990) TestRandomChains failure caused by incorrect delegation in CharReader/CharFilter/CharStream API
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3990: Fix Version/s: 3.6.1 > TestRandomChains failure caused by incorrect delegation in > CharReader/CharFilter/CharStream API > --- > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe >Assignee: Uwe Schindler > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3990-CharFilterFix.patch, LUCENE-3990.patch, > analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >>at > org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) > The root cause of this is inconsequent override of several Reader methods in > subclasses of CharFilter. We should fix this urgently, thanks to the random > chains we found this bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3971) MappingCharFilter rarely has wrong correctOffset (for finalOffset)
[
https://issues.apache.org/jira/browse/LUCENE-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3971:
Fix Version/s: 3.6.1
> MappingCharFilter rarely has wrong correctOffset (for finalOffset)
> ---
>
> Key: LUCENE-3971
> URL: https://issues.apache.org/jira/browse/LUCENE-3971
> Project: Lucene - Java
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Robert Muir
>Assignee: Dawid Weiss
> Fix For: 4.0, 3.6.1
>
> Attachments: LUCENE-3971.patch, LUCENE-3971_test.patch
>
>
> Found this bug over on LUCENE-3969, but I'm currently tracking a ton of bugs,
> so
> I figure I would open an issue and see if this one is obvious to anyone:
> Consider this input string: "gzw f quaxot" (length = 12) with a
> WhitespaceTokenizer.
> If i have mapping rules like this, then it works!:
> {noformat}
> "t" => ""
> {noformat}
> But if I have mapping rules like this:
> {noformat}
> "t" => ""
> "tmakdbl" => "c"
> {noformat}
> Then it will compute final offset wrong:
> {noformat}
> [junit] junit.framework.AssertionFailedError: finalOffset expected:<12>
> but was:<11>
> {noformat}
> Looks like some logic/recursion bug in the correctOffset method? The second
> rule is not even "used" for this string,
> it just happens to also start with 't'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3942) SynonymFilter should set pos length att
[ https://issues.apache.org/jira/browse/LUCENE-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3942: Fix Version/s: 3.6.1 > SynonymFilter should set pos length att > --- > > Key: LUCENE-3942 > URL: https://issues.apache.org/jira/browse/LUCENE-3942 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3942.patch > > > Tokenizers/Filters can now produce graphs instead of a single linear > chain of tokens, by setting the PositionLengthAttribute, expressing > where (how many positions ahead) this token "ends". > The default is 1, meaning it ends at the next position, to be > backwards compatible. > SynonymFilter produces graph output tokens, as long as the output is a > single token, but currently never sets the pos length to express this. > EG for the rule "wifi network -> hotspot", the hotspot token should > have pos length = 2. With LUCENE-3940 this will allow us to verify > that the offsets for such tokens are correct... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3940) When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole
[ https://issues.apache.org/jira/browse/LUCENE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3940: Fix Version/s: 3.6.1 > When Japanese (Kuromoji) tokenizer removes a punctuation token it should > leave a hole > - > > Key: LUCENE-3940 > URL: https://issues.apache.org/jira/browse/LUCENE-3940 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch, > LUCENE-3940.patch > > > I modified BaseTokenStreamTestCase to assert that the start/end > offsets match for graph (posLen > 1) tokens, and this caught a bug in > Kuromoji when the decompounding of a compound token has a punctuation > token that's dropped. > In this case we should leave hole(s) so that the graph is intact, ie, > the graph should look the same as if the punctuation tokens were not > initially removed, but then a StopFilter had removed them. > This also affects tokens that have no compound over them, ie we fail > to leave a hole today when we remove the punctuation tokens. > I'm not sure this is serious enough to warrant fixing in 3.6 at the > last minute... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3968) Factor MockGraphTokenFilter into LookaheadTokenFilter + random tokens
[ https://issues.apache.org/jira/browse/LUCENE-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3968: Fix Version/s: 3.6.1 > Factor MockGraphTokenFilter into LookaheadTokenFilter + random tokens > - > > Key: LUCENE-3968 > URL: https://issues.apache.org/jira/browse/LUCENE-3968 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3968.patch > > > MockGraphTokenFilter is rather hairy... I've managed to simplify it (I > think!) by breaking apart its two functions... > I think LookaheadTokenFilter can be used in the future for other graph aware > filters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3873) tie MockGraphTokenFilter into all analyzers tests
[ https://issues.apache.org/jira/browse/LUCENE-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3873: Fix Version/s: 3.6.1 > tie MockGraphTokenFilter into all analyzers tests > - > > Key: LUCENE-3873 > URL: https://issues.apache.org/jira/browse/LUCENE-3873 > Project: Lucene - Java > Issue Type: Task > Components: modules/analysis >Reporter: Robert Muir >Assignee: Michael McCandless > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3873.patch, LUCENE-3873.patch > > > Mike made a MockGraphTokenFilter on LUCENE-3848. > Many filters currently arent tested with anything but a simple tokenstream. > we should test them with this, too, it might find bugs (zero-length terms, > stacked terms/synonyms, etc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3919) more thorough testing of analysis chains
[ https://issues.apache.org/jira/browse/LUCENE-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3919: Fix Version/s: 3.6.1 > more thorough testing of analysis chains > > > Key: LUCENE-3919 > URL: https://issues.apache.org/jira/browse/LUCENE-3919 > Project: Lucene - Java > Issue Type: Task > Components: modules/analysis >Affects Versions: 3.6, 4.0 >Reporter: Robert Muir >Assignee: Robert Muir > Fix For: 4.0, 3.6.1 > > Attachments: LUCENE-3919-generics-fixes.patch, LUCENE-3919.patch, > LUCENE-3919.patch, LUCENE-3919.patch > > > In lucene we essentially test each analysis component separately. we also > give some > good testing to the example Analyzers we provide that combine them. > But we don't test various combinations that are possible: which is bad because > it doesnt test possibilities for custom analyzers (especially since lots of > solr users > etc define their own). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3379) Make logging of threadpool configuration report correct values
[ https://issues.apache.org/jira/browse/SOLR-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lyle updated SOLR-3379: Priority: Minor (was: Major) > Make logging of threadpool configuration report correct values > -- > > Key: SOLR-3379 > URL: https://issues.apache.org/jira/browse/SOLR-3379 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.6, 4.0 >Reporter: David M. Lyle >Priority: Minor > Fix For: 4.0, 3.6.1 > > Attachments: SOLR-3379-3x_branch.patch, SOLR-3379-trunk.patch > > > SOLR-3221 allows configuration of the shard handler thread pool. When the > thread pool configuration is changed the configuration changed is logged but > the value reported is always the socket timeout. > This patch will report the value of the configuration item changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3379) Make logging of threadpool configuration report correct values
[ https://issues.apache.org/jira/browse/SOLR-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lyle updated SOLR-3379: Attachment: SOLR-3379-3x_branch.patch > Make logging of threadpool configuration report correct values > -- > > Key: SOLR-3379 > URL: https://issues.apache.org/jira/browse/SOLR-3379 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.6, 4.0 >Reporter: David M. Lyle > Fix For: 4.0, 3.6.1 > > Attachments: SOLR-3379-3x_branch.patch, SOLR-3379-trunk.patch > > > SOLR-3221 allows configuration of the shard handler thread pool. When the > thread pool configuration is changed the configuration changed is logged but > the value reported is always the socket timeout. > This patch will report the value of the configuration item changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3379) Make logging of threadpool configuration report correct values
[ https://issues.apache.org/jira/browse/SOLR-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David M. Lyle updated SOLR-3379: Attachment: SOLR-3379-trunk.patch > Make logging of threadpool configuration report correct values > -- > > Key: SOLR-3379 > URL: https://issues.apache.org/jira/browse/SOLR-3379 > Project: Solr > Issue Type: Improvement >Affects Versions: 3.6, 4.0 >Reporter: David M. Lyle > Fix For: 4.0, 3.6.1 > > Attachments: SOLR-3379-trunk.patch > > > SOLR-3221 allows configuration of the shard handler thread pool. When the > thread pool configuration is changed the configuration changed is logged but > the value reported is always the socket timeout. > This patch will report the value of the configuration item changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3377) eDismax: A fielded query wrapped by parens is not recognized
[
https://issues.apache.org/jira/browse/SOLR-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-3377:
--
Attachment: SOLR-3377.patch
This first patch only reproduces the bug with a failing unit test
> eDismax: A fielded query wrapped by parens is not recognized
>
>
> Key: SOLR-3377
> URL: https://issues.apache.org/jira/browse/SOLR-3377
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Affects Versions: 3.6
>Reporter: Jan Høydahl
> Fix For: 4.0
>
> Attachments: SOLR-3377.patch
>
>
> As reported by "bernd" on the user list, a query like this
> {{q=(name:test)}}
> will yield 0 hits in 3.6 while it worked in 3.5. It works without the parens.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3376: -- Affects Version/s: (was: 4.0) Fix Version/s: 4.0 > SolrCloud: Specifying shardId not working correctly, although the failures > are inconsistent. > > > Key: SOLR-3376 > URL: https://issues.apache.org/jira/browse/SOLR-3376 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Erick Erickson > Fix For: 4.0 > > > I'm seeing some odd results when specifying "shardId" parameter. I'm trying > the 4-node, 2-shard example from the Wiki and specifying shardIds like this: > dir shardId start orderrunnng ZK port > example 1 1 y8983 > example22 2 y7574 > example31 3 y8900 > example42 4 y7500 > And I'm waiting a bit between starting various examples to let ZK settle down. > Once all of them are started, I was looking at > http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks > like (pretty cool IMO, especially since I didn't have to do it). The problem > was that shard 2 only reported a single instance, while shard1 showed the two > instances I was expecting. I'm running with 3 embedded ZK instances, just for > yucks. Interestingly the node that didn't show up was the only node that was > NOT running ZK. > When I removed all the "shardId" parameters, nuked zoo_data from all > directories and just started them up (with numShards=2 on the bootstrap ZK > node), all 4 nodes showed up just fine. > When starting with shardId specified and trying to go straight to the admin > interface on the node that wasn't showing up, I'd get odd errors like "This > interface requires that you activate the admin request handlers, add the > following configuration to your solrconfig.xml:". I also couldn't search > directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a > 404 error. > Command starting server that's giving me trouble: java -Xmx1G > -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 > -DshardId=2 -jar start.jar > Command for one that works fine: java -Xmx1G > -Djetty.port=8900 -DzkRun > -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar > start.jar > Sami Siren and he reports similar issues via e-mail conversation. Sami says > that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for > him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the > recent stuff with Ivy, I may have screwed up when/where the JARs were. > So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which > seems highly suspicious to me. It was failing every time before with 3.3.4, > so it sounds like gremlins. > And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the > ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other > directories) and it works fine there too now. Sh. Mostly this is a > placeholder to insure we try this, I guarantee that sys admins will want to > assign specific machines to specific shards, so this'll get used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger HÃ¥kansson updated SOLR-3375:
--
Attachment: httpsolrserver-dump.txt
commonshttpsolrserver-dump.txt
Uploaded network dumps which shows difference between CommonsHttpSolrServer and
HttpSolrServer
> Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
> -
>
> Key: SOLR-3375
> URL: https://issues.apache.org/jira/browse/SOLR-3375
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 3.6, 4.0, 3.6.1
>Reporter: Roger HÃ¥kansson
> Attachments: SolrTest.java, commonshttpsolrserver-dump.txt,
> httpsolrserver-dump.txt
>
>
> I've written an application which sends PDF files to Solr for indexing, but I
> also need to index some meta-data which isn't contained inside the PDF.
> I recently upgraded to 3.6.0 and when recompiling my app, I got some
> deprecated messages which mainly was to switch from CommonsHttpSolrServer to
> HttpSolrServer.
> The problem I've noticed since doing this, is that all extra fields which I
> add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
> matter, anything above char 127 is sent as '?'. This was not the behaviour of
> CommonsHttpSolrServer.
> I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
> entity.addPart(name, new StringBody(value));
> The problem is that StringBody(String text) maps to
> StringBody(text, "text/plain", null);
> and in
> StringBody(String text, String mimeType, Charset charset)
> we have this piece of code:
> if (charset == null) {
> charset = Charset.forName("US-ASCII");
> }
> this.content = text.getBytes(charset.name());
> this.charset = charset;
> So unless charset is set everything is converted to US-ASCII.
> On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
> this line
> parts.add(new StringPart(p, v, "UTF-8"));
> which adds everything as UTF-8.
> The simple solution would be to change the faulty line in HttpSolrServer.java
> to
> entity.addPart(name, new StringBody(value,Charset.forName("UTF-8")));
> However, this doesn't work either since my tests have shown that neither
> Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
> (8859-1 I guess).
> So changing HttpSolrServer.java to
> entity.addPart(name, new StringBody(value,Charset.forName("ISO-8859-1")));
> actually gives me the same result as using CommonsHttpSolrServer.
> But my investigations have shown that there is a difference in how
> Commons-HttpClient and HttpClient-4.x works.
> Commons-HttpClient sends all parameters as regular POST parameters but
> URLEncoded (/update/extract?param1=value¶m2=value2) while
> HttpClient-4.x sends them as multipart/form-data messages and I think that
> the problem is that each multipart-message should have its own charset
> parameter.
> I.e HttpClient-4.x sends
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> åäö
> ---
> But it should probably send something like this
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> Content-Type: text/plain; charset=utf-8
> åäö
> ---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[
https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-3376:
-
Description:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the
4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start orderrunnng ZK port
example 1 1 y8983
example22 2 y7574
example31 3 y8900
example42 4 y7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at
http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks
like (pretty cool IMO, especially since I didn't have to do it). The problem
was that shard 2 only reported a single instance, while shard1 showed the two
instances I was expecting. I'm running with 3 embedded ZK instances, just for
yucks. Interestingly the node that didn't show up was the only node that was
NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all
directories and just started them up (with numShards=2 on the bootstrap ZK
node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin
interface on the node that wasn't showing up, I'd get odd errors like "This
interface requires that you activate the admin request handlers, add the
following configuration to your solrconfig.xml:". I also couldn't search
directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a
404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500
-DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G
-Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900
-DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says
that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him,
but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent
stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems
highly suspicious to me. It was failing every time before with 3.3.4, so it
sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK
3.3.4, rebuilt, removed zoo_data, recopied example to three other directories)
and it works fine there too now. Sh. Mostly this is a placeholder to
insure we try this, I guarantee that sys admins will want to assign specific
machines to specific shards, so this'll get used.
was:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the
4-node, 2-shard example from the Wiki and specifying shardIds like this:
{{{
dir shardId start orderrunnng ZK port
example 1 1 y8983
example22 2 y7574
example31 3 y8900
example42 4 y7500
}}}
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at
http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks
like (pretty cool IMO, especially since I didn't have to do it). The problem
was that shard 2 only reported a single instance, while shard1 showed the two
instances I was expecting. I'm running with 3 embedded ZK instances, just for
yucks. Interestingly the node that didn't show up was the only node that was
NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all
directories and just started them up (with numShards=2 on the bootstrap ZK
node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin
interface on the node that wasn't showing up, I'd get odd errors like "This
interface requires that you activate the admin request handlers, add the
following configuration to your solrconfig.xml:". I also couldn't search
directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a
404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500
-DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G
-Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-3376: - Description: I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this: dir shardId start orderrunnng ZK port example 1 1 y8983 example22 2 y7574 example31 3 y8900 example42 4 y7500 And I'm waiting a bit between starting various examples to let ZK settle down. Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK. When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine. When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a 404 error. Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were. So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins. And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Sh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used. was: I'm seeing some odd results when specifying "shardId" parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this: dir shardId start orderrunnng ZK port example 1 1 y8983 example22 2 y7574 example31 3 y8900 example42 4 y7500 And I'm waiting a bit between starting various examples to let ZK settle down. Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK. When I removed all the "shardId" parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine. When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like "This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:". I also couldn't search directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a 404 error. Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -D
[jira] [Updated] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[
https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-3376:
-
Description:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the
4-node, 2-shard example from the Wiki and specifying shardIds like this:
{{{
dir shardId start orderrunnng ZK port
example 1 1 y8983
example22 2 y7574
example31 3 y8900
example42 4 y7500
}}}
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at
http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks
like (pretty cool IMO, especially since I didn't have to do it). The problem
was that shard 2 only reported a single instance, while shard1 showed the two
instances I was expecting. I'm running with 3 embedded ZK instances, just for
yucks. Interestingly the node that didn't show up was the only node that was
NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all
directories and just started them up (with numShards=2 on the bootstrap ZK
node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin
interface on the node that wasn't showing up, I'd get odd errors like "This
interface requires that you activate the admin request handlers, add the
following configuration to your solrconfig.xml:". I also couldn't search
directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a
404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500
-DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G
-Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900
-DshardId=1 -jar start.jar
Sami Siren and he reports similar issues via e-mail conversation. Sami says
that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him,
but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent
stuff with Ivy, I may have screwed up when/where the JARs were.
So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems
highly suspicious to me. It was failing every time before with 3.3.4, so it
sounds like gremlins.
And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK
3.3.4, rebuilt, removed zoo_data, recopied example to three other directories)
and it works fine there too now. Sh. Mostly this is a placeholder to
insure we try this, I guarantee that sys admins will want to assign specific
machines to specific shards, so this'll get used.
was:
I'm seeing some odd results when specifying "shardId" parameter. I'm trying the
4-node, 2-shard example from the Wiki and specifying shardIds like this:
dir shardId start orderrunnng ZK port
example 1 1 y8983
example22 2 y7574
example31 3 y8900
example42 4 y7500
And I'm waiting a bit between starting various examples to let ZK settle down.
Once all of them are started, I was looking at
http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks
like (pretty cool IMO, especially since I didn't have to do it). The problem
was that shard 2 only reported a single instance, while shard1 showed the two
instances I was expecting. I'm running with 3 embedded ZK instances, just for
yucks. Interestingly the node that didn't show up was the only node that was
NOT running ZK.
When I removed all the "shardId" parameters, nuked zoo_data from all
directories and just started them up (with numShards=2 on the bootstrap ZK
node), all 4 nodes showed up just fine.
When starting with shardId specified and trying to go straight to the admin
interface on the node that wasn't showing up, I'd get odd errors like "This
interface requires that you activate the admin request handlers, add the
following configuration to your solrconfig.xml:". I also couldn't search
directly on that machine, "http://localhost:7574/solr/select?q=*:*"; returns a
404 error.
Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500
-DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar
Command for one that works fine: java -Xmx1G
-Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost
[jira] [Updated] (SOLR-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: SOLR-3134-shard-info-3_6.patch > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3134-shard-info-3_6.patch, > SOLR-3369-shards-tolerant-3_6.patch, SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error when shards are > down. This patch allows users to use the shard tolerance feature with facet > and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger HÃ¥kansson updated SOLR-3375:
--
Attachment: SolrTest.java
Test program to show the problem.
Pass a URL to a Solr server as first arg and a PDF file as second.
Then search for id 1234567890 and 1234567891 and see the difference in
string_txt/string2_txt between the documents
> Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
> -
>
> Key: SOLR-3375
> URL: https://issues.apache.org/jira/browse/SOLR-3375
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 3.6, 4.0, 3.6.1
>Reporter: Roger HÃ¥kansson
> Attachments: SolrTest.java
>
>
> I've written an application which sends PDF files to Solr for indexing, but I
> also need to index some meta-data which isn't contained inside the PDF.
> I recently upgraded to 3.6.0 and when recompiling my app, I got some
> deprecated messages which mainly was to switch from CommonsHttpSolrServer to
> HttpSolrServer.
> The problem I've noticed since doing this, is that all extra fields which I
> add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
> matter, anything above char 127 is sent as '?'. This was not the behaviour of
> CommonsHttpSolrServer.
> I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
> entity.addPart(name, new StringBody(value));
> The problem is that StringBody(String text) maps to
> StringBody(text, "text/plain", null);
> and in
> StringBody(String text, String mimeType, Charset charset)
> we have this piece of code:
> if (charset == null) {
> charset = Charset.forName("US-ASCII");
> }
> this.content = text.getBytes(charset.name());
> this.charset = charset;
> So unless charset is set everything is converted to US-ASCII.
> On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
> this line
> parts.add(new StringPart(p, v, "UTF-8"));
> which adds everything as UTF-8.
> The simple solution would be to change the faulty line in HttpSolrServer.java
> to
> entity.addPart(name, new StringBody(value,Charset.forName("UTF-8")));
> However, this doesn't work either since my tests have shown that neither
> Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
> (8859-1 I guess).
> So changing HttpSolrServer.java to
> entity.addPart(name, new StringBody(value,Charset.forName("ISO-8859-1")));
> actually gives me the same result as using CommonsHttpSolrServer.
> But my investigations have shown that there is a difference in how
> Commons-HttpClient and HttpClient-4.x works.
> Commons-HttpClient sends all parameters as regular POST parameters but
> URLEncoded (/update/extract?param1=value¶m2=value2) while
> HttpClient-4.x sends them as multipart/form-data messages and I think that
> the problem is that each multipart-message should have its own charset
> parameter.
> I.e HttpClient-4.x sends
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> åäö
> ---
> But it should probably send something like this
> ---
> --jNljZ3jE1sHG529HrzSjZWYEad-6Wu
> Content-Disposition: form-data; name="literal.string_txt"
> Content-Type: text/plain; charset=utf-8
> åäö
> ---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3358: Attachment: SOLR-3358-compile-path.patch Steven, do these .pom changes make sense to you? +1 on your additional.dependencies change The problem with idea build is that it includes everything in lib. The options I see are to either list the jars explicitly (leaving out -over-slf4j) or make a new lib folder under webapp. Thoughts? > Capture Logging Events from JUL and Log4j > - > > Key: SOLR-3358 > URL: https://issues.apache.org/jira/browse/SOLR-3358 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, > SOLR-3358-logging.patch > > > The UI should be able to show the last few log messages. To support this, we > will need to register an Appender (log4j) or Handler > (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3987) Ivy/maven config to pull from sonatype releases
[ https://issues.apache.org/jira/browse/LUCENE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3987: Attachment: LUCENE-3987.patch Patch with module-specific ivy settings and maven settings. > Ivy/maven config to pull from sonatype releases > --- > > Key: LUCENE-3987 > URL: https://issues.apache.org/jira/browse/LUCENE-3987 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Attachments: LUCENE-3987.patch, ivy-sonatype.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3998) facet module should have no dependencies, consolidate examples into demo/
[
https://issues.apache.org/jira/browse/LUCENE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3998:
Attachment: LUCENE-3998.patch
here's an initial patch (all tests pass), but there are things i don't like:
see the comments in the script (which you must run first, before applying the
patch):
{noformat}
mkdir -p lucene/demo/src/java/org/apache/lucene/facet
svn add lucene/demo/src/java/org/apache/lucene/facet
svn mv lucene/facet/src/examples/org/apache/lucene/facet/example
lucene/demo/src/java/org/apache/lucene/facet
svn delete lucene/facet/src/examples
mkdir -p lucene/demo/src/test/org/apache/lucene/facet
svn add lucene/demo/src/test/org/apache/lucene/facet
svn mv lucene/facet/src/test/org/apache/lucene/facet/example
lucene/demo/src/test/org/apache/lucene/facet
# move to test-framework
svn move lucene/facet/src/test/org/apache/lucene/util/SlowRAMDirectory.java
lucene/test-framework/src/java/org/apache/lucene/util
# nocommit: can we improve this? some facet tests testing real functionality,
but
# using example stuff... if the tests arent actually testing the example they
should stay in facet/
# and we won't need to bogusly code-dup the FacetTestUtils?
svn copy lucene/facet/src/test/org/apache/lucene/facet/FacetTestUtils.java
lucene/demo/src/test/org/apache/lucene/facet
svn move
lucene/facet/src/test/org/apache/lucene/facet/enhancements/EnhancementsPayloadIteratorTest.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/search/TestTotalFacetCounts.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/search/TestTotalFacetCountsCache.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/index/FacetsPayloadProcessorProviderTest.java
lucene/demo/src/test/org/apache/lucene/facet/example
{noformat}
> facet module should have no dependencies, consolidate examples into demo/
> -
>
> Key: LUCENE-3998
> URL: https://issues.apache.org/jira/browse/LUCENE-3998
> Project: Lucene - Java
> Issue Type: Task
> Components: modules/facet
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3998.patch
>
>
> currently facets depends on analyzers-common, but this is unnecessary.
> additionally it has a nice examples/ package (even with javadocs! are they
> actually seen anywhere?!),
> as well as tests for those examples.
> I think instead it would be better if facet/ had no dependencies,
> and if examples+examples tests were in demo/.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3997:
Attachment: LUCENE-3997.patch
Patch, after:
{noformat}
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java
lucene/core/src/java/org/apache/lucene/search
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/GroupDocs.java
lucene/core/src/java/org/apache/lucene/search
{noformat}
> join module should not depend on grouping module
>
>
> Key: LUCENE-3997
> URL: https://issues.apache.org/jira/browse/LUCENE-3997
> Project: Lucene - Java
> Issue Type: Task
>Affects Versions: 4.0
>Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-3997.patch, LUCENE-3997.patch
>
>
> I think TopGroups/GroupDocs should simply be in core?
> Both grouping and join modules use these trivial classes, but join depends on
> grouping just for them.
> I think its better that we try to minimize these inter-module dependencies.
> Of course, another option is to combine grouping and join into one module, but
> last time i brought that up nobody could agree on a name.
> Anyway I think the change is pretty clean: its similar to having basic stuff
> like Analyzer.java in core,
> so other things can work with Analyzer without depending on any specific
> implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3997:
Attachment: LUCENE-3997.patch
Patch, after:
{noformat}
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java
lucene/core/src/java/org/apache/lucene/search
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/GroupDocs.java
lucene/core/src/java/org/apache/lucene/search
{noformat}
> join module should not depend on grouping module
>
>
> Key: LUCENE-3997
> URL: https://issues.apache.org/jira/browse/LUCENE-3997
> Project: Lucene - Java
> Issue Type: Task
>Affects Versions: 4.0
>Reporter: Robert Muir
> Fix For: 4.0
>
> Attachments: LUCENE-3997.patch
>
>
> I think TopGroups/GroupDocs should simply be in core?
> Both grouping and join modules use these trivial classes, but join depends on
> grouping just for them.
> I think its better that we try to minimize these inter-module dependencies.
> Of course, another option is to combine grouping and join into one module, but
> last time i brought that up nobody could agree on a name.
> Anyway I think the change is pretty clean: its similar to having basic stuff
> like Analyzer.java in core,
> so other things can work with Analyzer without depending on any specific
> implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3371) Admin UI breaks with a core named 'logging' or 'threads'
[ https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3371: Attachment: SOLR-3371.patch bq. It seems like the ~threads and ~logging should be enough to distinguish Hum, yes .. that was the idea :/ Attached Patch changes Handling for "global" Actions (prefixed with ~) > Admin UI breaks with a core named 'logging' or 'threads' > > > Key: SOLR-3371 > URL: https://issues.apache.org/jira/browse/SOLR-3371 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Fix For: 4.0 > > Attachments: SOLR-3371.patch > > > If you make a core with the name "logging" or "threads" the UI gets confused > with the logging or threads page. > It seems like the ~threads and ~logging should be enough to distinguish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3330) Show changes in plugin statistics across multiple requests
[
https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3330:
Attachment: SOLR-3330.patch
bq. Right now the UI shows the values from 1, then updates the changes between
2&3 – the problem is that the values that may have changed between 1&2 are not
reflected in the UI. (Not a huge deal, but not accurate)
Attached Patch would fix this, i changed the workflow a bit - fetching the
'reference xml' is now done right after loading the initial page.
After a bit playing around with it, i'm not sure, if this is what the user
would expect? image the following: Users loads the page, requests
{{/admin/ping}} or something like this, afterwards hit's the "watching changes"
button and stop's this action. he'll see at least two changes .. one on the
ping-handler, and one on the mbeans-handler. i would expect, that recording
changes just begin's when i hit the button?
Perhaps it's just a UI-Thing .. maybe we show use some 'loading'-Icon for
"Watch Changes" instead of the Eye-Icon, to illustrate that we already watch
for changes?
> Show changes in plugin statistics across multiple requests
> --
>
> Key: SOLR-3330
> URL: https://issues.apache.org/jira/browse/SOLR-3330
> Project: Solr
> Issue Type: New Feature
> Components: web gui
>Reporter: Ryan McKinley
> Fix For: 4.0
>
> Attachments: SOLR-3330-pluggins-diff.patch,
> SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png,
> SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch,
> SOLR-3330-ui-update.patch, SOLR-3330.patch
>
>
> When debugging configuration and performance, I often:
> 1. Look at stats values
> 2. run some queries
> 3. See how the stats values changed
> This is fine, but is often a bit clunky and you have to really know what you
> are looking for to see any changes.
> It would be great if the 'plugins' page had a button that would make this
> easier
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3364: Attachment: SOLR-3364.patch > Logging UI allows multiple selections staying open > -- > > Key: SOLR-3364 > URL: https://issues.apache.org/jira/browse/SOLR-3364 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) > Fix For: 4.0 > > Attachments: SOLR-3364.patch, multiple.png > > > [Jan pointed > out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], > that the Logging UI currently allows multiple open selections. Opening a new > selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3977) generated/duplicated javadocs are wasteful and bloat the release
[ https://issues.apache.org/jira/browse/LUCENE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3977: Attachment: LUCENE-3977-triplication.patch patch to remove the triplication (so its only duplication) by excluding these from the binary release (they only go into maven). Before: -rw-rw-r-- 1 rmuir rmuir 82046115 2012-04-18 01:10 lucene-4.0-SNAPSHOT.zip After: -rw-rw-r-- 1 rmuir rmuir 69982949 2012-04-18 01:15 lucene-4.0-SNAPSHOT.zip > generated/duplicated javadocs are wasteful and bloat the release > > > Key: LUCENE-3977 > URL: https://issues.apache.org/jira/browse/LUCENE-3977 > Project: Lucene - Java > Issue Type: Bug > Components: general/javadocs >Reporter: Robert Muir >Priority: Blocker > Fix For: 4.0 > > Attachments: LUCENE-3977-triplication.patch > > > Some stats for the generated javadocs of 3.6: > * 9,146 files > * 161,872 KB uncompressed > * 25MB compressed (this is responsible for nearly half of our binary release) > The fact we intentionally double our javadocs size with the 'javadocs-all' > thing > is truly wasteful and compression doesn't help at all. Just testing, i nuked > 'all' > and found: > * 4,944 files > * 81,084 KB uncompressed > * 12.8MB compressed > We need to clean this up for 4.0. We only need to ship javadocs 'one way'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3371) Admin UI breaks with a core named 'logging' or 'threads'
[ https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3371: Component/s: web gui > Admin UI breaks with a core named 'logging' or 'threads' > > > Key: SOLR-3371 > URL: https://issues.apache.org/jira/browse/SOLR-3371 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Fix For: 4.0 > > > If you make a core with the name "logging" or "threads" the UI gets confused > with the logging or threads page. > It seems like the ~threads and ~logging should be enough to distinguish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3370) CSVResponseWriter does not honor fl globs
[ https://issues.apache.org/jira/browse/SOLR-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Fligg updated SOLR-3370: -- Attachment: SOLR-3370.patch Fix and unit test patches attached. > CSVResponseWriter does not honor fl globs > - > > Key: SOLR-3370 > URL: https://issues.apache.org/jira/browse/SOLR-3370 > Project: Solr > Issue Type: Bug > Components: Response Writers >Affects Versions: 4.0 >Reporter: Keith Fligg >Priority: Minor > Attachments: SOLR-3370.patch > > > The fl query parameter is not honored by the CSVResponseWriter when it has > globs, e.g., fl=foo* will return all fields in the document. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Description: In a distributed environment, shards.tolerant=true allows for partial results to be returned when individual shards are down. For group=true and facet=true queries, using this feature results in an error when shards are down. This patch allows users to use the shard tolerance feature with facet and grouping queries. (was: In a distributed environment, shards.tolerant=true allows for partial results to be returned when individual shards are down. For group=true and facet=true queries, using this feature results in an error. This patch allows users to use the shard tolerance feature with facet and grouping queries. ) > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3369-shards-tolerant-3_6.patch, > SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error when shards are > down. This patch allows users to use the shard tolerance feature with facet > and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: SOLR-3369-shards-tolerant-3_6.patch > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3369-shards-tolerant-3_6.patch, > SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error. This patch > allows users to use the shard tolerance feature with facet and grouping > queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: SOLR-3369-shards-tolerant.patch > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3369-shards-tolerant-3_6.patch, > SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error. This patch > allows users to use the shard tolerance feature with facet and grouping > queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: SOLR-3369-shards-tolerant-3_6.patch > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3369-shards-tolerant-3_6.patch, > SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error. This patch > allows users to use the shard tolerance feature with facet and grouping > queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: (was: SOLR-3369-shards-tolerant-3_6.patch) > shards.tolerant=true broken on group and facet queries > -- > > Key: SOLR-3369 > URL: https://issues.apache.org/jira/browse/SOLR-3369 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0, 3.6.1 > Environment: Distributed environment (shards) >Reporter: Russell Black > Labels: patch > Attachments: SOLR-3369-shards-tolerant-3_6.patch, > SOLR-3369-shards-tolerant.patch > > > In a distributed environment, shards.tolerant=true allows for partial results > to be returned when individual shards are down. For group=true and > facet=true queries, using this feature results in an error. This patch > allows users to use the shard tolerance feature with facet and grouping > queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3993) Polishing annoyances from JUnit4
[ https://issues.apache.org/jira/browse/LUCENE-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3993: Description: - @Ignore and @TestGroup-ignored tests should report the reason much like assumption-ignored tests. https://github.com/carrotsearch/randomizedtesting/issues/82 - perturb randomness in @BeforeClass hooks so that bad apples are more evently distributed across suites. https://issues.apache.org/jira/browse/LUCENE-3995 - IntelliJ Idea test configs https://github.com/carrotsearch/randomizedtesting/issues/83 was: - @Ignore and @TestGroup-ignored tests should report the reason much like assumption-ignored tests. https://github.com/carrotsearch/randomizedtesting/issues/82 > Polishing annoyances from JUnit4 > > > Key: LUCENE-3993 > URL: https://issues.apache.org/jira/browse/LUCENE-3993 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/build, general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > - @Ignore and @TestGroup-ignored tests should report the reason much like > assumption-ignored tests. > https://github.com/carrotsearch/randomizedtesting/issues/82 > - perturb randomness in @BeforeClass hooks so that bad apples are more > evently distributed across suites. > https://issues.apache.org/jira/browse/LUCENE-3995 > - IntelliJ Idea test configs > https://github.com/carrotsearch/randomizedtesting/issues/83 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3367) Show Logging Events in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3367: Component/s: web gui > Show Logging Events in Admin UI > --- > > Key: SOLR-3367 > URL: https://issues.apache.org/jira/browse/SOLR-3367 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley > Fix For: 4.0 > > > We can show logging events in the Admin UI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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] (LUCENENET-485) IndexOutOfRangeException in FrenchStemmer
[
https://issues.apache.org/jira/browse/LUCENENET-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Currens updated LUCENENET-485:
--
Attachment: tt.diff
The diff doesn't specify files, but should be easy to figure out.
> IndexOutOfRangeException in FrenchStemmer
> -
>
> Key: LUCENENET-485
> URL: https://issues.apache.org/jira/browse/LUCENENET-485
> Project: Lucene.Net
> Issue Type: Bug
> Components: Lucene.Net Contrib
>Affects Versions: Lucene.Net 3.0.3
>Reporter: Christopher Currens
> Fix For: Lucene.Net 3.0.3
>
> Attachments: tt.diff
>
>
> {quote}
> Hi list,
> I am not sure how to report bugs, or even if anybody is interested in bug
> reports. However, I have been playing with lucene lately, and found out an
> implementation bug in the Frenchstemmer
> (/src/contrib/Analyzers/Fr/FrenchStemmer.cs). Whenever I tried to add a new
> document to an index, I got an index out of range error. So I looked at the
> code and fixed that issue: see my diff file attached.
> Please note that I also changed a few funky characters to unicode notation.
> The code worked well with the funky characters, but I think it just looks
> better with the \uxxx bits...
> Anyways, the important bits is the replacement of a couple of sb.Insert by
> sb.Append.
> I hope this helps.
> Cheers,
> Sylvain
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3358: Component/s: (was: web gui) Issue Type: New Feature (was: Bug) Summary: Capture Logging Events from JUL and Log4j (was: Show Logging Events in Admin UI) > Capture Logging Events from JUL and Log4j > - > > Key: SOLR-3358 > URL: https://issues.apache.org/jira/browse/SOLR-3358 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch > > > The UI should be able to show the last few log messages. To support this, we > will need to register an Appender (log4j) or Handler > (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3994) some nightly tests take hours
[
https://issues.apache.org/jira/browse/LUCENE-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3994:
Attachment: LUCENE-3994.patch
Patch, removing n^2 growth in these tests, and some other tuning of atLeast.
In general, when tests like this hog the cpu for so long, we lose coverage
overall.
I'll keep an eye on the nightlies for other cpu-hogs.
Here are the new timings for analyzers/ tests after the patch.
'ant test' with no multiplier:
{noformat}
BUILD SUCCESSFUL
Total time: 1 minute 28 seconds
{noformat}
'ant test -Dtests.multiplier=3 -Dtests.nightly=true'
{noformat}
BUILD SUCCESSFUL
Total time: 3 minutes 15 seconds
{noformat}
> some nightly tests take hours
> -
>
> Key: LUCENE-3994
> URL: https://issues.apache.org/jira/browse/LUCENE-3994
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3994.patch
>
>
> The nightly builds are taking 4-7 hours.
> This is caused by a few bad apples (can be seen
> https://builds.apache.org/job/Lucene-trunk/1896/testReport/).
> The top 5 are (all in analysis):
> * TestSynonymMapFilter: 1 hr 54 min
> * TestRandomChains: 1 hr 22 min
> * TestRemoveDuplicatesTokenFilter: 32 min
> * TestMappingCharFilter: 28 min
> * TestWordDelimiterFilter: 22 min
> so thats 4.5 hours right there for that run
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3284) StreamingUpdateSolrServer swallows exceptions
[ https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-3284: --- Attachment: SOLR-3284.patch First crack at a patch for throwing delayed exceptions. It should do this on any request when a previous request resulted in an error, not just on commits. > StreamingUpdateSolrServer swallows exceptions > - > > Key: SOLR-3284 > URL: https://issues.apache.org/jira/browse/SOLR-3284 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 3.5, 4.0 >Reporter: Shawn Heisey > Attachments: SOLR-3284.patch > > > StreamingUpdateSolrServer eats exceptions thrown by lower level code, such as > HttpClient, when doing adds. It may happen with other methods, though I know > that query and deleteByQuery will throw exceptions. I believe that this is a > result of the queue/Runner design. That's what makes SUSS perform better, > but it means you sacrifice the ability to programmatically determine that > there was a problem with your update. All errors are logged via slf4j, but > that's not terribly helpful except with determining what went wrong after the > fact. > When using CommonsHttpSolrServer, I've been able to rely on getting an > exception thrown by pretty much any error, letting me use try/catch to detect > problems. > There's probably enough dependent code out there that it would not be a good > idea to change the design of SUSS, unless there were alternate constructors > or additional methods available to configure new/old behavior. Fixing this > is probably not trivial, so it's probably a better idea to come up with a new > server object based on CHSS. This is outside my current skillset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-2300) snapinstaller on slave is failing
[
https://issues.apache.org/jira/browse/SOLR-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-2300:
-
Component/s: (was: clients - java)
replication (scripts)
> This setup is giving issue only in linux. Is this known bug on linux?
I think the deletion problem is a combination of using nfs and solr (or some
other process) holding some file open.
I realize this issue is pretty old but have you tried with more recent version
of Solr, does the problem still exist?
> snapinstaller on slave is failing
> -
>
> Key: SOLR-2300
> URL: https://issues.apache.org/jira/browse/SOLR-2300
> Project: Solr
> Issue Type: Bug
> Components: replication (scripts)
>Affects Versions: 1.3
> Environment: Linux, Jboss 5.0GA, solr 1.3.0
>Reporter: sakunthala padmanabhuni
>
> Hi,
> We are using Solr on Mac OSX and it is working fine. Same setup we have
> moved to Linux. We have master, slave setup. Every 5 minutes, index will be
> replicated from Master to Slave and will be installed on slave. But on Linux
> on the slave when the snapinstaller script is called, it is failing and
> showing below error in logs.
> /bin/rm: cannot remove
> `/ngs/app/esearcht/Slave2index/data/index/.nfs000111030749':
> Device or resource busy
> This error is occuring in snapinstaller script at below lines.
> cp -lr ${name}/ ${data_dir}/index.tmp$$ && \
> /bin/rm -rf ${data_dir}/index && \
> mv -f ${data_dir}/index.tmp$$ ${data_dir}/index
> It is not able to remove the index folder. So the index.tmp files are keep
> growing in the data directory.
> Our data directory is "/ngs/app/esearcht/Slave2index/data". When checked
> with ls -al in the index directory, there are some .nfs files still there,
> which are not letting index directory to be deleted. And these .nfs files
> are still being used by SOLR in jboss.
> This setup is giving issue only in linux. Is this known bug on linux?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-1976) Commit on StreamingUpdateSolrServer can happen before all previously added docs have been sent to Solr
[ https://issues.apache.org/jira/browse/SOLR-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1976: - Priority: Minor (was: Major) I tried to reproduce this with a testcase but so far after doing few thousand iterations of clean, add, commit, check result-size: no success Stephen: can you provide a testcase that show this error? > Commit on StreamingUpdateSolrServer can happen before all previously added > docs have been sent to Solr > -- > > Key: SOLR-1976 > URL: https://issues.apache.org/jira/browse/SOLR-1976 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.4.1 >Reporter: Stephen Duncan Jr >Priority: Minor > > Because of it's multi-threaded nature, calling commit on > StreamingUpdateSolrServer can send the commit before all the added documents > have been sent to Solr. Calling blockUntilFinished() does not change this. > It needs to be possible to send a commit that will commit all the documents > that have been added previously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
dev@lucene.apache.org
[ https://issues.apache.org/jira/browse/SOLR-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1196: - Component/s: (was: clients - java) > Incorrect matches when using non alphanumeric search string !@#$%\^\&\*\(\) > --- > > Key: SOLR-1196 > URL: https://issues.apache.org/jira/browse/SOLR-1196 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 > Environment: Solr 1.3/ Java 1.6/ Win XP/Eclipse 3.3 >Reporter: Sam Michael > > When matching strings that do not include alphanumeric chars, all the data is > returned as matches. (There is actually no match, so nothing should be > returned.) > When I run a query like - (activity_type:NAME) AND title:(\!@#$%\^&\*\(\)) > all the documents are returned even though there is not a single match. There > is no title that matches the string (which has been escaped). > My document structure is as follows > > NAME > Bathing > > > The title field is of type text_title which is described below. > positionIncrementGap="100"> > > > generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="1" > splitOnCaseChange="1"/> > > > > > > ignoreCase="true" expand="true"/> > generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="1" > splitOnCaseChange="1"/> > > > > > - > Yonik's analysis as follows. > -features:foo features:(\!@#$%\^&\*\(\)) > -features:foo features:(\!@#$%\^&\*\(\)) > -features:foo > -features:foo > The text analysis is throwing away non alphanumeric chars (probably > the WordDelimiterFilter). The Lucene (and Solr) query parser throws > away term queries when the token is zero length (after analysis). > Solr then interprets the left over "-features:foo" as "all documents > not containing foo in the features field", so you get a bunch of > matches. > As per his suggestion, a bug is filed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-1212) TestNG Test Case
[ https://issues.apache.org/jira/browse/SOLR-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-1212: - Component/s: (was: clients - java) > TestNG Test Case > - > > Key: SOLR-1212 > URL: https://issues.apache.org/jira/browse/SOLR-1212 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Environment: Java 6 >Reporter: Karthik K > Fix For: 4.0 > > Attachments: SOLR-1212.patch, testng-5.9-jdk15.jar > > Original Estimate: 1h > Remaining Estimate: 1h > > TestNG equivalent of AbstractSolrTestCase , without using JUnit altogether . > New Class created: AbstractSolrNGTest > LICENSE.txt , NOTICE.txt modified as appropriate. ( TestNG under Apache > License 2.0 ) > TestNG 5.9-jdk15 added to lib. > Justification: In some workplaces - people are moving towards TestNG and > take out JUnit altogether from the classpath. Hence useful in those cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-1888) Annotated beans source generation with maven plugin
[
https://issues.apache.org/jira/browse/SOLR-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-1888:
-
Component/s: (was: clients - java)
> Annotated beans source generation with maven plugin
> ---
>
> Key: SOLR-1888
> URL: https://issues.apache.org/jira/browse/SOLR-1888
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.5
> Environment: java, maven
>Reporter: Matthias Epheser
> Fix For: 4.0
>
> Attachments: maven-solr-plugin.zip
>
>
> As I stumbled over a lot of copy pasting while creating java annotated beans
> representing a schema.xml, i decided to make a shortcut and create a maven
> plugin.
> Think about it as source generation similar to castor/jaxb code generation
> from an xsd. You just point to a schema.xml and connect to the
> generate-sources phase. This leads to a java bean in
> target/generated-sources/solr that contains all fields from the schema well
> annotated.
> The mapping reads the section and maps field="string" to
> solr.StringField to java.lang String etc. Multivalured fields generate lists,
> dynamic fields Maps. Currently the code generation is plain simple, just a
> fileWriter with some intends. The getValidJavaName(String name) may act more
> professional than now.
> Just install the plugin contained in the zip using mvn install and connect it
> to an existing solrj project:
> {{
>
>org.apache.solr
>maven-solr-plugin
>
> test-data/solr/conf/schema.xml
> org.test.MyBean
>
>
>
> generate-sources
>
> generate
>
>
>
>
> }}
> The generated fiels will be automatically added to the classpath after the
> first run of mvn generate/compile. So just execute mvn eclipse:eclipse once
> after that. After every change in the schema, generate again and your bean
> will be updated and fields and getters and setters will be present.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2483) DIH - an uppercase problem in query parameters
[
https://issues.apache.org/jira/browse/SOLR-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-2483:
-
Component/s: (was: clients - java)
> DIH - an uppercase problem in query parameters
> --
>
> Key: SOLR-2483
> URL: https://issues.apache.org/jira/browse/SOLR-2483
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.1
> Environment: Windows Vista
> Java 1.6
>Reporter: Lubo Torok
> Labels: DataImportHandler, entity, newdev, parameter, sql
>
> I have two tables called "PROBLEM" and "KOMENTAR"(means 'comment' in English)
> in DB. One problem can have more comments. I want to index them all.
> schema.xml looks as follows
> ... some fields ...
>
> ... some fields...
> data-config.xml:
>
> pk="problem_id">
>
>
>
> If you write '${problem.PROBLEM_ID}' in lower case, i.e.
> '${problem.problem_id}' SOLR will not import the inner entity. Seems strange
> to me and it took me some time to figure this out.
> Note that primary key in "PROBLEM" is called "ID". I defined the alias
> "problem_id" (yes,lower case) in SQL. In schema, there is this field defined
> as "problem_id" again in lower case. But, when I run
> http://localhost:8983/solr/dataimport?command=full-import&debug=true&verbose=on
> so I can see some debug information there is this part
> ...
>
> −
>
> −
>
> −
>
> select to_char(id) as problem_id, nazov as problem_nazov, cislo as
> problem_cislo, popis as problem_popis from problem
>
> 0:0:0.465
> --- row #1-
> test zodpovedneho
> 2533274790395945
> 201009304
> csfdewafedewfw
> -
> −
>
> −
>
> select id as komentar_id, nazov as komentar_nazov, text as komentar_text from
> komentar where to_char(fk_problem)='2533274790395945'
>
> ...
> where you can see that, internally, the fields of "PROBLEM" are represented
> in uppercase despite the user (me) had not defined them this way. The result
> is I guess that parameter referring to the parent entity ${entity.field}
> should always be in uppercase, i.e. ${entity.FIELD}.
> Here is an example of the indexed entity as written after full-import command
> with debug and verbose on:
>
> −
>
> −
>
> test zodpovedneho
>
> −
>
> 2533274790395945
>
> −
>
> 201009304
>
> −
>
> csfdewafedewfw
>
> −
>
> java.math.BigDecimal:5066549580791985
>
> −
>
> a.TXT
>
>
> here are the field names in lower case. I consider this as a bug. Maybe I am
> wrong and its a feature. I work with SOLR only for few days.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2990) solr OOM issues
[ https://issues.apache.org/jira/browse/SOLR-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-2990: - Component/s: (was: clients - java) contrib - Solr Cell (Tika extraction) > solr OOM issues > --- > > Key: SOLR-2990 > URL: https://issues.apache.org/jira/browse/SOLR-2990 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 4.0 > Environment: CentOS 5.x/6.x > Solr Build apache-solr-4.0-2011-11-04_09-29-42 (includes tika 1.0) > java -server -Xms2G -Xmx2G -XX:+HeapDumpOnOutOfMemoryError > -XX:HeapDumpPath=/var/log/oom/solr.dump.1 -Dsolr.data.dir=/opt/solr.data > -Djava.util.logging.config.file=solr-logging.properties -DSTOP.PORT=8907 > -DSTOP.KEY=STOP -jar start.jar >Reporter: Rob Tulloh > > We see intermittent issues with OutOfMemory caused by tika failing to process > content. Here is an example: > Dec 29, 2011 7:12:05 AM org.apache.solr.common.SolrException log > SEVERE: java.lang.OutOfMemoryError: Java heap space > at > org.apache.poi.hmef.attribute.TNEFAttribute.(TNEFAttribute.java:50) > at > org.apache.poi.hmef.attribute.TNEFAttribute.create(TNEFAttribute.java:76) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:74) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.process(HMEFMessage.java:98) > at org.apache.poi.hmef.HMEFMessage.(HMEFMessage.java:63) > at > org.apache.tika.parser.microsoft.TNEFParser.parse(TNEFParser.java:79) > at > org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:242) > at > org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:242) > at > org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:129) > at > org.apache.solr.handler.extraction.ExtractingDocumentLoader.load(ExtractingDocumentLoader.java:195) > at > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:58) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) > at > org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:244) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1478) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) > at > org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3174: Attachment: SOLR-3174.patch This one is for you Erick ;> > Visualize Cluster State > --- > > Key: SOLR-3174 > URL: https://issues.apache.org/jira/browse/SOLR-3174 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley >Assignee: Stefan Matheis (steffkes) > Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png, > SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch, > SOLR-3174.patch, SOLR-3174.patch > > > It would be great to visualize the cluster state in the new UI. > See Mark's wish: > https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3364: Attachment: multiple.png > Logging UI allows multiple selections staying open > -- > > Key: SOLR-3364 > URL: https://issues.apache.org/jira/browse/SOLR-3364 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 4.0 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) > Fix For: 4.0 > > Attachments: multiple.png > > > [Jan pointed > out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], > that the Logging UI currently allows multiple open selections. Opening a new > selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3174) Visualize Cluster State
[
https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3174:
Comment: was deleted
(was: Mark, this should be possible - can we decide about the priority of each
state? Just for starting the discussion, what i've understood right now:
{code}active : green
recovering : yellow
down: orange
recovery_failed : red
gone: gray{code}
And the other question: how to check the correct state? Which one includes a
check against live_nodes and which not?)
> Visualize Cluster State
> ---
>
> Key: SOLR-3174
> URL: https://issues.apache.org/jira/browse/SOLR-3174
> Project: Solr
> Issue Type: New Feature
> Components: web gui
>Reporter: Ryan McKinley
>Assignee: Stefan Matheis (steffkes)
> Attachments: SOLR-3174-graph.png, SOLR-3174-graph.png,
> SOLR-3174-rgraph.png, SOLR-3174-rgraph.png, SOLR-3174.patch, SOLR-3174.patch,
> SOLR-3174.patch
>
>
> It would be great to visualize the cluster state in the new UI.
> See Mark's wish:
> https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jamie Johnson updated SOLR-3362: Environment: RHEL lucene svn revision 1308309 was:MacOSX > FacetComponent throws NPE when doing distributed query > -- > > Key: SOLR-3362 > URL: https://issues.apache.org/jira/browse/SOLR-3362 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: RHEL > lucene svn revision 1308309 >Reporter: Jamie Johnson > > When executing a query against a field in my index I am getting the following > exception > The query I am executing is as follows: > http://host:port/solr/collection1/select?q=bob&facet=true&facet.field=organization > debugging the FacetComponent line 489 sfc is null > SEVERE: java.lang.NullPointerException >at > org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) >at > org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) >at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) >at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) >at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) >at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) >at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) >at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) >at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) >at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) >at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) >at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) >at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) >at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) >at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) >at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) >at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) >at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) >at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) >at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) >at org.eclipse.jetty.server.Server.handle(Server.java:351) >at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) >at > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) >at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) >at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) >at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) >at > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) >at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) >at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) >at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) >at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) >at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-2510) migrate solr analysis factories to analyzers module
[ https://issues.apache.org/jira/browse/LUCENE-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Male updated LUCENE-2510: --- Attachment: LUCENE-2510.patch Patch updated to trunk. I'm going to commit this shortly and then tackle the factories themselves. > migrate solr analysis factories to analyzers module > --- > > Key: LUCENE-2510 > URL: https://issues.apache.org/jira/browse/LUCENE-2510 > Project: Lucene - Java > Issue Type: Task > Components: modules/analysis >Affects Versions: 4.0 >Reporter: Robert Muir > Fix For: 4.0 > > Attachments: LUCENE-2510.patch, LUCENE-2510.patch > > > In LUCENE-2413 all TokenStreams were consolidated into the analyzers module. > This is a good step, but I think the next step is to put the Solr factories > into the analyzers module, too. > This would make analyzers artifacts plugins to both lucene and solr, with > benefits such as: > * users could use the old analyzers module with solr, too. This is a good > step to use real library versions instead of Version for backwards compat. > * analyzers modules such as smartcn and icu, that aren't currently available > to solr users due to large file sizes or dependencies, would be simple > optional plugins to solr and easily available to users that want them. > Rough sketch in this thread: > http://www.lucidimagination.com/search/document/3465a0e55ba94d58/solr_and_analyzers_module > Practically, I havent looked much and don't really have a plan for how this > will work yet, so ideas are very welcome. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3358) Show Logging Events in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3358: Attachment: SOLR-3358-logging.patch Here is an updated patch. Rather then have a static initialization in a RequestHandler, this moves the LogWatcher to CoreContainer and makes sure it is initialized early in the process. This also avoids wrapping each event like the previous patch. Each framework needs to convert the message (LogRecord or LoggingEvent) to a SolrDocument that gets passed to the UI > Show Logging Events in Admin UI > --- > > Key: SOLR-3358 > URL: https://issues.apache.org/jira/browse/SOLR-3358 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch > > > The UI should be able to show the last few log messages. To support this, we > will need to register an Appender (log4j) or Handler > (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3361) "maxNumberOfBackups" does not work with "backupAfter"=commit
[ https://issues.apache.org/jira/browse/SOLR-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3361: - Attachment: SOLR-3361-failingtest.patch Tomas provided this test on SOLR-3033. > "maxNumberOfBackups" does not work with "backupAfter"=commit > > > Key: SOLR-3361 > URL: https://issues.apache.org/jira/browse/SOLR-3361 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 3.6 >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Fix For: 4.0, 3.6.1 > > Attachments: SOLR-3361-failingtest.patch, SOLR-3361.patch > > > Tomás Fernández Löbbe reported on SOLR-3033 that when specifying the init > parameter combination "maxNumberOfBackups" with "backupAfter"=commit, the > backups do not get cleaned up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3361) "maxNumberOfBackups" does not work with "backupAfter"=commit
[ https://issues.apache.org/jira/browse/SOLR-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3361: - Attachment: SOLR-3361.patch here is the fix. I had not created a unit test for this to prevent the ReplicationHandler test taking even longer to complete. Bad idea as commits handle the backup in an entirely different code branch than the one I had originally modified! > "maxNumberOfBackups" does not work with "backupAfter"=commit > > > Key: SOLR-3361 > URL: https://issues.apache.org/jira/browse/SOLR-3361 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 3.6 >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Fix For: 4.0, 3.6.1 > > Attachments: SOLR-3361-failingtest.patch, SOLR-3361.patch > > > Tomás Fernández Löbbe reported on SOLR-3033 that when specifying the init > parameter combination "maxNumberOfBackups" with "backupAfter"=commit, the > backups do not get cleaned up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3992) TestIndexWriterOnJRECrash failure
[ https://issues.apache.org/jira/browse/LUCENE-3992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3992: Attachment: LUCENE-3992.patch patch, i also fixed the seed format so the test is more efficient... amazing the previous one slipped through really. > TestIndexWriterOnJRECrash failure > - > > Key: LUCENE-3992 > URL: https://issues.apache.org/jira/browse/LUCENE-3992 > Project: Lucene - Java > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-3992.patch > > > triggered this beasting a bunch of tests... gonna probably be hard to > reproduce... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3327) Logging UI should indicate which loggers are set vs implicit
[ https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3327: Attachment: multiple.png style looks good. thanks! The issue Jan points to -- where you can select multiple dialog windows is still there. See: !multiple.png! > Logging UI should indicate which loggers are set vs implicit > > > Key: SOLR-3327 > URL: https://issues.apache.org/jira/browse/SOLR-3327 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > Attachments: SOLR-3327.patch, SOLR-3327.patch, SOLR-3327.patch, > logging.png, multiple.png > > > The new logging UI looks great! > http://localhost:8983/solr/#/~logging > It would be nice to indicate which ones are set explicitly vs implicit -- > perhaps making the line bold when set=true -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - (/) rename tests.threadspercpu into tests.jvms (Steve) - (/) align to 80 cols terminals (Robert) - use simple class names and add truncation padding. - (/) the output is emitted twice in case of suite-level errors. was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - (/) rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - use simple class names and add truncation padding. - the output is emitted twice in case of suite-level errors. > Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing > contracts. Enforce thread leaks. > > > Key: LUCENE-3808 > URL: https://issues.apache.org/jira/browse/LUCENE-3808 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr > Switch the runner to RandomizedRunner. Enforce the following: > - (/) Random sharing will result in a failure/ exception. > - (/) -Add a validator for testXXX without @Test annotation.- (custom test > provider added). > - (/) Make sure tests are executed with assertions enabled (at least for > solr/lucene packages). > - (/) Add a validator for static hook shadowing (no-no). > - (/) Modify custom execution groups in LTC to be real @Groups. > Follow up from merging with trunk: > - (/) rename tests.threadspercpu into tests.jvms (Steve) > - (/) align to 80 cols terminals (Robert) - use simple class names and add > truncation padding. > - (/) the output is emitted twice in case of suite-level errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3327) Logging UI should indicate which loggers are set vs implicit
[ https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3327: Attachment: SOLR-3327.patch Oh noez, didn't realize - the js-part of the last patch got already committed yesterday while committing SOLR-3356. updated patch contains only css now > Logging UI should indicate which loggers are set vs implicit > > > Key: SOLR-3327 > URL: https://issues.apache.org/jira/browse/SOLR-3327 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > Attachments: SOLR-3327.patch, SOLR-3327.patch, SOLR-3327.patch, > logging.png > > > The new logging UI looks great! > http://localhost:8983/solr/#/~logging > It would be nice to indicate which ones are set explicitly vs implicit -- > perhaps making the line bold when set=true -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3327) Logging UI should indicate which loggers are set vs implicit
[ https://issues.apache.org/jira/browse/SOLR-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3327: Attachment: SOLR-3327.patch Thanks for the hint Ryan, updated Patch attached. > Logging UI should indicate which loggers are set vs implicit > > > Key: SOLR-3327 > URL: https://issues.apache.org/jira/browse/SOLR-3327 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Ryan McKinley >Priority: Trivial > Fix For: 4.0 > > Attachments: SOLR-3327.patch, SOLR-3327.patch, logging.png > > > The new logging UI looks great! > http://localhost:8983/solr/#/~logging > It would be nice to indicate which ones are set explicitly vs implicit -- > perhaps making the line bold when set=true -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3324) Put field name/type in the analysis URL
[ https://issues.apache.org/jira/browse/SOLR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3324: Attachment: SOLR-3324.patch Next try :> Submitting the Form will change the URL, afterwards the Analysis-Process is executed. bq. Can verbose also be in the URL? In Theory, yes .. right know, changing the state of verbose doesn't need to trigger a reload, it will only show additional informations in the results - they will be requested in every case, we just show them, if the box is checked. Will see how we can handle this > Put field name/type in the analysis URL > > > Key: SOLR-3324 > URL: https://issues.apache.org/jira/browse/SOLR-3324 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3324.patch, SOLR-3324.patch > > > It would be nice to be able to link directly to a page that loads the right > field in the analysis UI. > This will also let us link the query-browser page to the analysis page -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) TestRandomChains failure caused by incorrect delegation in CharReader/CharFilter/CharStream API
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3990: -- Description: 100% reproduces for me: 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA -Dargs="-Dfile.encoding=UTF-8" Running org.apache.lucene.analysis.core.TestRandomChains FAILURE 7.22s | TestRandomChains.testRandomChains > Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but was:<8> >at __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >at org.junit.Assert.fail(Assert.java:93) >at org.junit.Assert.failNotEquals(Assert.java:647) >at org.junit.Assert.assertEquals(Assert.java:128) >at org.junit.Assert.assertEquals(Assert.java:472) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) The root cause of this is inconsequent override of several Reader methods in subclasses of CharFilter. We should fix this urgently, thanks to the random chains we found this bug. was: 100% reproduces for me: 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA -Dargs="-Dfile.encoding=UTF-8" Running org.apache.lucene.analysis.core.TestRandomChains FAILURE 7.22s | TestRandomChains.testRandomChains > Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but was:<8> >at __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >at org.junit.Assert.fail(Assert.java:93) >at org.junit.Assert.failNotEquals(Assert.java:647) >at org.junit.Assert.assertEquals(Assert.java:128) >at org.junit.Assert.assertEquals(Assert.java:472) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) Summary: TestRandomChains failure caused by incorrect delegation in CharReader/CharFilter/CharStream API (was: TestRandomChains failure) > TestRandomChains failure caused by incorrect delegation in > CharReader/CharFilter/CharStream API > --- > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe >Assignee: Uwe Schindler > Fix For: 4.0 > > Attachments: LUCENE-3990-CharFilterFix.patch, LUCENE-3990.patch, > analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.an
[jira] [Updated] (LUCENE-3990) TestRandomChains failure
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-3990: -- Attachment: LUCENE-3990-CharFilterFix.patch Hi Robert, I investigated the problem, its indeed crazy wrapping: The problem was that CharFilter did not override read() (without char[]). The same applied to CharReader!!! By not overriding that method it was also slowing down *all* charfilters, because the base class Reader automatically delegates to read(char[]), creating a new char[1] every time. The attached patch fixes this to delegate correctly. > TestRandomChains failure > > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe >Assignee: Uwe Schindler > Attachments: LUCENE-3990-CharFilterFix.patch, LUCENE-3990.patch, > analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >>at > org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) TestRandomChains failure
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3990: Attachment: LUCENE-3990.patch The problem is that we are getting different results the first time we create the tokenstream components, versus after we reset(Reader) with the same text again. The bug was introduced by Uwe Schindler in r1311358: when the reader-wrapper was changed to use CharFilter instead. because of crazy CharFilter-Reader delegation. http://svn.apache.org/viewvc?view=revision&revision=1311358 Attached is a patch demonstrating the bug: with a standalone testcase, and backing out that change. Seed now passes (in addition to the test. > TestRandomChains failure > > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe > Attachments: LUCENE-3990.patch, analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >>at > org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3965:
Attachment: LUCENE-3965.patch
attached patch fixing maven too (still r1326433)
I can now do a full 'ant -Dversion=4.0.0 -Dgpg.key=322D7ECA prepare-release'
which produces reasonable artifacts.
I think this is ready to commit, it makes our trunk theoretically releasable
where it wasn't before.
I would keep the issue open to address more of the TODOs:
* merging all CHANGES/LICENSE/NOTICE
* fixing src/site and regenerating so the documentation links work
* fixing README's etc (e.g. notes about the demo).
Here is the script you need:
{noformat}
# svn moves
svn move lucene/contrib/demo lucene/demo
svn move lucene/contrib/highlighter lucene/highlighter
svn move lucene/contrib/memory lucene/memory
svn move lucene/contrib/misc lucene/misc
svn move lucene/contrib/sandbox lucene/sandbox
svn move modules/analysis lucene/analysis
svn move modules/benchmark lucene/benchmark
svn move modules/facet lucene/facet
svn move modules/grouping lucene/grouping
svn move modules/join lucene/join
svn move modules/queries lucene/queries
svn move modules/queryparser lucene/queryparser
svn move modules/spatial lucene/spatial
svn move modules/suggest lucene/suggest
# nuke modules dir
svn delete modules
# clean up svn:ignore's, all modules should be consistent
# under lucene/build now... so nuke this
svn pset svn:ignore pom.xml lucene/analysis
svn pset svn:ignore -F - \
lucene/facet \
lucene/grouping \
lucene/join \
lucene/queries \
lucene/queryparser \
lucene/spatial \
lucene/suggest << EOF
*.iml
pom.xml
EOF
svn pset svn:ignore -F - lucene/benchmark << EOF
temp
work
*.iml
pom.xml
EOF
# maven configurations
svn move dev-tools/maven/modules/analysis dev-tools/maven/lucene
svn move dev-tools/maven/modules/benchmark dev-tools/maven/lucene
svn move dev-tools/maven/modules/facet dev-tools/maven/lucene
svn move dev-tools/maven/modules/grouping dev-tools/maven/lucene
svn move dev-tools/maven/modules/join dev-tools/maven/lucene
svn move dev-tools/maven/modules/queries dev-tools/maven/lucene
svn move dev-tools/maven/modules/queryparser dev-tools/maven/lucene
svn move dev-tools/maven/modules/spatial dev-tools/maven/lucene
svn move dev-tools/maven/modules/suggest dev-tools/maven/lucene
svn delete dev-tools/maven/modules
svn move dev-tools/maven/lucene/contrib/demo dev-tools/maven/lucene
svn move dev-tools/maven/lucene/contrib/highlighter dev-tools/maven/lucene
svn move dev-tools/maven/lucene/contrib/memory dev-tools/maven/lucene
svn move dev-tools/maven/lucene/contrib/misc dev-tools/maven/lucene
svn move dev-tools/maven/lucene/contrib/sandbox dev-tools/maven/lucene
svn delete dev-tools/maven/lucene/contrib
# now apply patch
patch -p0 < LUCENE-3965.patch
{noformat}
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3965.patch, LUCENE-3965.patch, LUCENE-3965.patch,
> LUCENE-3965.patch, LUCENE-3965_module_build.patch,
> LUCENE-3965_module_build_pname.patch
>
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3965:
Attachment: LUCENE-3965.patch
updated patch for r1326433:
* fixed build directories and other general cleanup: all the lucene modules
build under lucene/build/XXX
* package-all-binary makes binary releases that actually make sense (NOTE:
still havent tackled any maven yet)
* lots of cleanups and simplifications.
Another TODO:
* src/site needs to be updated for all javadocs modules to link to their names
(in general the name 'contrib' is removed here and many are missing). But i
would do this after committing I think because it would make the patch harder
to manage.
There is now a new script, since its important to nuke the svn:ignores for the
previous bogus build directories:
{noformat}
# svn moves
svn move lucene/contrib/demo lucene/demo
svn move lucene/contrib/highlighter lucene/highlighter
svn move lucene/contrib/memory lucene/memory
svn move lucene/contrib/misc lucene/misc
svn move lucene/contrib/sandbox lucene/sandbox
svn move modules/analysis lucene/analysis
svn move modules/benchmark lucene/benchmark
svn move modules/facet lucene/facet
svn move modules/grouping lucene/grouping
svn move modules/join lucene/join
svn move modules/queries lucene/queries
svn move modules/queryparser lucene/queryparser
svn move modules/spatial lucene/spatial
svn move modules/suggest lucene/suggest
# nuke modules dir
svn delete modules
# clean up svn:ignore's, all modules should be consistent
# under lucene/build now... so nuke this
svn pset svn:ignore pom.xml lucene/analysis
svn pset svn:ignore -F - \
lucene/facet \
lucene/grouping \
lucene/join \
lucene/queries \
lucene/queryparser \
lucene/spatial \
lucene/suggest << EOF
*.iml
pom.xml
EOF
svn pset svn:ignore -F - lucene/benchmark << EOF
temp
work
*.iml
pom.xml
EOF
# now apply patch
patch -p0 < LUCENE-3965.patch
{noformat}
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3965.patch, LUCENE-3965.patch, LUCENE-3965.patch,
> LUCENE-3965_module_build.patch, LUCENE-3965_module_build_pname.patch
>
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - (/) rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - use simple class names and add truncation padding. - the output is emitted twice in case of suite-level errors. was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - use simple class names and add truncation padding. - the output is emitted twice in case of suite-level errors. > Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing > contracts. Enforce thread leaks. > > > Key: LUCENE-3808 > URL: https://issues.apache.org/jira/browse/LUCENE-3808 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr > Switch the runner to RandomizedRunner. Enforce the following: > - (/) Random sharing will result in a failure/ exception. > - (/) -Add a validator for testXXX without @Test annotation.- (custom test > provider added). > - (/) Make sure tests are executed with assertions enabled (at least for > solr/lucene packages). > - (/) Add a validator for static hook shadowing (no-no). > - (/) Modify custom execution groups in LTC to be real @Groups. > Follow up from merging with trunk: > - (/) rename tests.threadspercpu into tests.jvms (Steve) > - align to 80 cols terminals (Robert) - use simple class names and add > truncation padding. > - the output is emitted twice in case of suite-level errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - use simple class names and add truncation padding. - the output is emitted twice in case of suite-level errors. was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - the output is emitted twice in case of suite-level errors. > Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing > contracts. Enforce thread leaks. > > > Key: LUCENE-3808 > URL: https://issues.apache.org/jira/browse/LUCENE-3808 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr > Switch the runner to RandomizedRunner. Enforce the following: > - (/) Random sharing will result in a failure/ exception. > - (/) -Add a validator for testXXX without @Test annotation.- (custom test > provider added). > - (/) Make sure tests are executed with assertions enabled (at least for > solr/lucene packages). > - (/) Add a validator for static hook shadowing (no-no). > - (/) Modify custom execution groups in LTC to be real @Groups. > Follow up from merging with trunk: > - rename tests.threadspercpu into tests.jvms (Steve) > - align to 80 cols terminals (Robert) - use simple class names and add > truncation padding. > - the output is emitted twice in case of suite-level errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) - the output is emitted twice in case of suite-level errors. was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) > Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing > contracts. Enforce thread leaks. > > > Key: LUCENE-3808 > URL: https://issues.apache.org/jira/browse/LUCENE-3808 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr > Switch the runner to RandomizedRunner. Enforce the following: > - (/) Random sharing will result in a failure/ exception. > - (/) -Add a validator for testXXX without @Test annotation.- (custom test > provider added). > - (/) Make sure tests are executed with assertions enabled (at least for > solr/lucene packages). > - (/) Add a validator for static hook shadowing (no-no). > - (/) Modify custom execution groups in LTC to be real @Groups. > Follow up from merging with trunk: > - rename tests.threadspercpu into tests.jvms (Steve) > - align to 80 cols terminals (Robert) > - the output is emitted twice in case of suite-level errors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3808) Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing contracts. Enforce thread leaks.
[ https://issues.apache.org/jira/browse/LUCENE-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3808: Description: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. Follow up from merging with trunk: - rename tests.threadspercpu into tests.jvms (Steve) - align to 80 cols terminals (Robert) was: Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr Switch the runner to RandomizedRunner. Enforce the following: - (/) Random sharing will result in a failure/ exception. - (/) -Add a validator for testXXX without @Test annotation.- (custom test provider added). - (/) Make sure tests are executed with assertions enabled (at least for solr/lucene packages). - (/) Add a validator for static hook shadowing (no-no). - (/) Modify custom execution groups in LTC to be real @Groups. > Switch LuceneTestCaseRunner to RandomizedRunner. Enforce Random sharing > contracts. Enforce thread leaks. > > > Key: LUCENE-3808 > URL: https://issues.apache.org/jira/browse/LUCENE-3808 > Project: Lucene - Java > Issue Type: Sub-task > Components: general/test >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: 4.0 > > > Dev. branch at: https://github.com/dweiss/lucene_solr/tree/rr > Switch the runner to RandomizedRunner. Enforce the following: > - (/) Random sharing will result in a failure/ exception. > - (/) -Add a validator for testXXX without @Test annotation.- (custom test > provider added). > - (/) Make sure tests are executed with assertions enabled (at least for > solr/lucene packages). > - (/) Add a validator for static hook shadowing (no-no). > - (/) Modify custom execution groups in LTC to be real @Groups. > Follow up from merging with trunk: > - rename tests.threadspercpu into tests.jvms (Steve) > - align to 80 cols terminals (Robert) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) TestRandomChains failure
[ https://issues.apache.org/jira/browse/LUCENE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-3990: Attachment: analysis-common.tests-report.txt > TestRandomChains failure > > > Key: LUCENE-3990 > URL: https://issues.apache.org/jira/browse/LUCENE-3990 > Project: Lucene - Java > Issue Type: Bug > Components: modules/analysis >Reporter: Steven Rowe > Attachments: analysis-common.tests-report.txt > > > 100% reproduces for me: > 2> NOTE: reproduce with: ant test -Dtests.class=*.TestRandomChains > -Dtests.method=testRandomChains -Dtests.seed=88CA02C2BB7B1DA > -Dargs="-Dfile.encoding=UTF-8" > Running org.apache.lucene.analysis.core.TestRandomChains > FAILURE 7.22s | TestRandomChains.testRandomChains >> Throwable #1: java.lang.AssertionError: endOffset 1 expected:<7> but > was:<8> >>at > __randomizedtesting.SeedInfo.seed([88CA02C2BB7B1DA:356D894D6CA5AC1A]:0) >>at org.junit.Assert.fail(Assert.java:93) >>at org.junit.Assert.failNotEquals(Assert.java:647) >>at org.junit.Assert.assertEquals(Assert.java:128) >>at org.junit.Assert.assertEquals(Assert.java:472) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:165) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:662) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:486) >>at > org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:429) >>at > org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:820) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3965: Attachment: LUCENE-3965.patch updated patch for r1326380 cleaning up the javadocs-all task (the package assigning stuff), and removing some nocommits: nuking contrib-uptodate and using module-uptodate everywhere. next up: nuke the custom build directories so everything is organized under lucene/build/ > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > Attachments: LUCENE-3965.patch, LUCENE-3965.patch, > LUCENE-3965_module_build.patch, LUCENE-3965_module_build_pname.patch > > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3989) junit4 taskdef installation has wrong dependencies
[ https://issues.apache.org/jira/browse/LUCENE-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3989: Attachment: LUCENE-3989.patch trivial patch > junit4 taskdef installation has wrong dependencies > -- > > Key: LUCENE-3989 > URL: https://issues.apache.org/jira/browse/LUCENE-3989 > Project: Lucene - Java > Issue Type: Bug > Components: general/test >Reporter: Robert Muir > Attachments: LUCENE-3989.patch > > > # it hangs out in 'init' which only depends on that module's 'resolve' (not > test-framework) > # installing in init is not great because init is called often. > easy way to see the bug: ant clean clean-jars. Then cd modules/analysis/icu > and 'ant test'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3965:
Attachment: LUCENE-3965.patch
first take at a patch (works with r1326364).
don't fear the size of the patch, its mostly noise from svn moves (even though
i used --no-diff-deleted, it still lists every file that was moved)
first you run this:
{noformat}
svn move lucene/contrib/demo lucene/demo
svn move lucene/contrib/highlighter lucene/highlighter
svn move lucene/contrib/memory lucene/memory
svn move lucene/contrib/misc lucene/misc
svn move lucene/contrib/sandbox lucene/sandbox
svn move modules/analysis lucene/analysis
svn move modules/benchmark lucene/benchmark
svn move modules/facet lucene/facet
svn move modules/grouping lucene/grouping
svn move modules/join lucene/join
svn move modules/queries lucene/queries
svn move modules/queryparser lucene/queryparser
svn move modules/spatial lucene/spatial
svn move modules/suggest lucene/suggest
svn delete modules
{noformat}
'ant test' and 'ant javadocs' and such works, but prepare-release etc need some
help. Though: they didnt work before either :)
There are also some nocommits.
Still I'd like to get us in releasable shape with this issue... so I'm going to
keep iterating. but its a fairly easy change...
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3965.patch, LUCENE-3965_module_build.patch,
> LUCENE-3965_module_build_pname.patch
>
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3330: Attachment: SOLR-3330-ui-update.patch Hoss, like this? Visible enough? > Show changes in plugin statistics across multiple requests > -- > > Key: SOLR-3330 > URL: https://issues.apache.org/jira/browse/SOLR-3330 > Project: Solr > Issue Type: New Feature > Components: web gui >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: SOLR-3330-pluggins-diff.patch, > SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, > SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch, > SOLR-3330-ui-update.patch > > > When debugging configuration and performance, I often: > 1. Look at stats values > 2. run some queries > 3. See how the stats values changed > This is fine, but is often a bit clunky and you have to really know what you > are looking for to see any changes. > It would be great if the 'plugins' page had a button that would make this > easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3965: Attachment: LUCENE-3965_module_build_pname.patch just to clean up: this renames the project name to 'module-build' to match and fixes references. > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > Attachments: LUCENE-3965_module_build.patch, > LUCENE-3965_module_build_pname.patch > > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
