[jira] Commented: (SOLR-1383) Replication causes master to fail to delete old index files
[
https://issues.apache.org/jira/browse/SOLR-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748688#action_12748688
]
Noble Paul commented on SOLR-1383:
--
bq.he files do not go away. Not after another commit, not after restarting solr.
All the old files are necessary for the index to work. The latest commit is not
the only one that is used. You do an optimize and the old files will go away
> Replication causes master to fail to delete old index files
> ---
>
> Key: SOLR-1383
> URL: https://issues.apache.org/jira/browse/SOLR-1383
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Environment: Linux CentOS - latest Solr 1.4 trunk - Java 1.6
>Reporter: Lance Norskog
> Fix For: 1.4
>
>
> I have developed a way to make replication leave old index files in the
> master's data/index directory. It is timing-dependent. A sequence of commands
> runs correctly or fails, depending on the timing between the commands.
> Here is the test scenario:
> Start a master and slave version of the Solr distributed example. I used 8080
> for the slave. (See example/etc/jetty.xml)
> Be sure to start with empty solr/data/index files on both master and slave.
> Open the replication administration jsp on the slave (
> http://localhost:8080/solr/admin/replication/index.jsp )
> Disable polling.
> In a text window, go to the example/exampledocs directory and run this script
> {code}
> for x in *.xml
> do
> echo $x
> sh post.sh $x
> sleep 15
> curl "http://localhost:8080/solr/replication?command=fetchindex";
> done
> {code}
> This prints each example file, indexes it, and does a replication command. At
> the end of this exercise, the master and slave solr/data/index files will be
> identical.
> Now, kill master & slave, remove the solr/index/data directories, and start
> over. This time, remove the sleep command from the script. In my
> environment, old Lucene index files were left in the master's data/index.
> Here is what is left in the master data/index.
> The segments_? files are random across runs, but the index files left over
> are consistent.
> Note (courtesy of the Linux 'ls -l /proc/PID/fd' command) that the old files
> are not kept open by the master solr; they are merely left behind.
> In the master server:
> {code}
> % ls solr/data/index
> _0.fdt _1.prx _2.tvx _4.nrm _5.tii _7.frq _8.tvd _a.tvx _c.nrm
> _0.fdx _1.tii _3.fdt _4.prx _5.tis _7.nrm _8.tvf _b.fdt _c.prx
> _0.fnm _1.tis _3.fdx _4.tii _6.fdt _7.prx _8.tvx _b.fdx _c.tii
> _0.frq _2.fdt _3.fnm _4.tis _6.fdx _7.tii _a.fdt _b.fnm _c.tis
> _0.nrm _2.fdx _3.frq _4.tvd _6.fnm _7.tis _a.fdx _b.frq segments.gen
> _0.prx _2.fnm _3.nrm _4.tvf _6.frq _8.fdt _a.fnm _b.nrm segments_8
> _0.tii _2.frq _3.prx _4.tvx _6.nrm _8.fdx _a.frq _b.prx segments_9
> _0.tis _2.nrm _3.tii _5.fdt _6.prx _8.fnm _a.nrm _b.tii segments_a
> _1.fdt _2.prx _3.tis _5.fdx _6.tii _8.frq _a.prx _b.tis segments_b
> _1.fdx _2.tii _4.fdt _5.fnm _6.tis _8.nrm _a.tii _c.fdt segments_c
> _1.fnm _2.tis _4.fdx _5.frq _7.fdt _8.prx _a.tis _c.fdx segments_d
> _1.frq _2.tvd _4.fnm _5.nrm _7.fdx _8.tii _a.tvd _c.fnm
> _1.nrm _2.tvf _4.frq _5.prx _7.fnm _8.tis _a.tvf _c.frq
> {code}
> {code}
> % ls -l /proc/PID/fd
> lr-x-- 1 root root 64 Aug 25 22:52 137 ->
> /index/master/solr/data/index/_a.tis
> lr-x-- 1 root root 64 Aug 25 22:52 138 ->
> /index/master/solr/data/index/_a.frq
> lr-x-- 1 root root 64 Aug 25 22:52 139 ->
> /index/master/solr/data/index/_a.prx
> lr-x-- 1 root root 64 Aug 25 22:52 140 ->
> /index/master/solr/data/index/_a.fdt
> lr-x-- 1 root root 64 Aug 25 22:52 141 ->
> /index/master/solr/data/index/_a.fdx
> lr-x-- 1 root root 64 Aug 25 22:52 142 ->
> /index/master/solr/data/index/_a.tvx
> lr-x-- 1 root root 64 Aug 25 22:52 143 ->
> /index/master/solr/data/index/_a.tvd
> lr-x-- 1 root root 64 Aug 25 22:52 144 ->
> /index/master/solr/data/index/_a.tvf
> lr-x-- 1 root root 64 Aug 25 22:52 145 ->
> /index/master/solr/data/index/_a.nrm
> lr-x-- 1 root root 64 Aug 25 22:52 72 ->
> /index/master/solr/data/index/_b.tis
> lr-x-- 1 root root 64 Aug 25 22:52 73 ->
> /index/master/solr/data/index/_b.frq
> lr-x-- 1 root root 64 Aug 25 22:52 74 ->
> /index/master/solr/data/index/_b.prx
> lr-x-- 1 root root 64 Aug 25 22:52 76 ->
> /index/master/solr/data/index/_b.fdt
> lr-x-- 1 root root 64 Aug 25 22:52 78 ->
> /index/master/solr/data/index/_b.fdx
> lr-x-- 1 root root 64 Aug 25 22:52 79 ->
> /index/master/solr/data/index/_b.nrm
> lr-x-- 1 root root 64 Aug 25 22:52 80 ->
> /index/master/solr/data/index/_c.tis
> lr-x-- 1 root root 64 Aug 25 22:
[jira] Commented: (SOLR-1383) Replication causes master to fail to delete old index files
[
https://issues.apache.org/jira/browse/SOLR-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748682#action_12748682
]
Lance Norskog commented on SOLR-1383:
-
I checked again- the files do not go away. Not after another commit, not after
restarting solr.
The replication commit reservation code definitely has a bug.
> Replication causes master to fail to delete old index files
> ---
>
> Key: SOLR-1383
> URL: https://issues.apache.org/jira/browse/SOLR-1383
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Environment: Linux CentOS - latest Solr 1.4 trunk - Java 1.6
>Reporter: Lance Norskog
> Fix For: 1.4
>
>
> I have developed a way to make replication leave old index files in the
> master's data/index directory. It is timing-dependent. A sequence of commands
> runs correctly or fails, depending on the timing between the commands.
> Here is the test scenario:
> Start a master and slave version of the Solr distributed example. I used 8080
> for the slave. (See example/etc/jetty.xml)
> Be sure to start with empty solr/data/index files on both master and slave.
> Open the replication administration jsp on the slave (
> http://localhost:8080/solr/admin/replication/index.jsp )
> Disable polling.
> In a text window, go to the example/exampledocs directory and run this script
> {code}
> for x in *.xml
> do
> echo $x
> sh post.sh $x
> sleep 15
> curl "http://localhost:8080/solr/replication?command=fetchindex";
> done
> {code}
> This prints each example file, indexes it, and does a replication command. At
> the end of this exercise, the master and slave solr/data/index files will be
> identical.
> Now, kill master & slave, remove the solr/index/data directories, and start
> over. This time, remove the sleep command from the script. In my
> environment, old Lucene index files were left in the master's data/index.
> Here is what is left in the master data/index.
> The segments_? files are random across runs, but the index files left over
> are consistent.
> Note (courtesy of the Linux 'ls -l /proc/PID/fd' command) that the old files
> are not kept open by the master solr; they are merely left behind.
> In the master server:
> {code}
> % ls solr/data/index
> _0.fdt _1.prx _2.tvx _4.nrm _5.tii _7.frq _8.tvd _a.tvx _c.nrm
> _0.fdx _1.tii _3.fdt _4.prx _5.tis _7.nrm _8.tvf _b.fdt _c.prx
> _0.fnm _1.tis _3.fdx _4.tii _6.fdt _7.prx _8.tvx _b.fdx _c.tii
> _0.frq _2.fdt _3.fnm _4.tis _6.fdx _7.tii _a.fdt _b.fnm _c.tis
> _0.nrm _2.fdx _3.frq _4.tvd _6.fnm _7.tis _a.fdx _b.frq segments.gen
> _0.prx _2.fnm _3.nrm _4.tvf _6.frq _8.fdt _a.fnm _b.nrm segments_8
> _0.tii _2.frq _3.prx _4.tvx _6.nrm _8.fdx _a.frq _b.prx segments_9
> _0.tis _2.nrm _3.tii _5.fdt _6.prx _8.fnm _a.nrm _b.tii segments_a
> _1.fdt _2.prx _3.tis _5.fdx _6.tii _8.frq _a.prx _b.tis segments_b
> _1.fdx _2.tii _4.fdt _5.fnm _6.tis _8.nrm _a.tii _c.fdt segments_c
> _1.fnm _2.tis _4.fdx _5.frq _7.fdt _8.prx _a.tis _c.fdx segments_d
> _1.frq _2.tvd _4.fnm _5.nrm _7.fdx _8.tii _a.tvd _c.fnm
> _1.nrm _2.tvf _4.frq _5.prx _7.fnm _8.tis _a.tvf _c.frq
> {code}
> {code}
> % ls -l /proc/PID/fd
> lr-x-- 1 root root 64 Aug 25 22:52 137 ->
> /index/master/solr/data/index/_a.tis
> lr-x-- 1 root root 64 Aug 25 22:52 138 ->
> /index/master/solr/data/index/_a.frq
> lr-x-- 1 root root 64 Aug 25 22:52 139 ->
> /index/master/solr/data/index/_a.prx
> lr-x-- 1 root root 64 Aug 25 22:52 140 ->
> /index/master/solr/data/index/_a.fdt
> lr-x-- 1 root root 64 Aug 25 22:52 141 ->
> /index/master/solr/data/index/_a.fdx
> lr-x-- 1 root root 64 Aug 25 22:52 142 ->
> /index/master/solr/data/index/_a.tvx
> lr-x-- 1 root root 64 Aug 25 22:52 143 ->
> /index/master/solr/data/index/_a.tvd
> lr-x-- 1 root root 64 Aug 25 22:52 144 ->
> /index/master/solr/data/index/_a.tvf
> lr-x-- 1 root root 64 Aug 25 22:52 145 ->
> /index/master/solr/data/index/_a.nrm
> lr-x-- 1 root root 64 Aug 25 22:52 72 ->
> /index/master/solr/data/index/_b.tis
> lr-x-- 1 root root 64 Aug 25 22:52 73 ->
> /index/master/solr/data/index/_b.frq
> lr-x-- 1 root root 64 Aug 25 22:52 74 ->
> /index/master/solr/data/index/_b.prx
> lr-x-- 1 root root 64 Aug 25 22:52 76 ->
> /index/master/solr/data/index/_b.fdt
> lr-x-- 1 root root 64 Aug 25 22:52 78 ->
> /index/master/solr/data/index/_b.fdx
> lr-x-- 1 root root 64 Aug 25 22:52 79 ->
> /index/master/solr/data/index/_b.nrm
> lr-x-- 1 root root 64 Aug 25 22:52 80 ->
> /index/master/solr/data/index/_c.tis
> lr-x-- 1 root root 64 Aug 25 22:52 81 ->
> /index/master/solr/data/index/_c.frq
> lr-x-- 1 root roo
[jira] Updated: (SOLR-1391) The XPath field in the XPathEntityResolver should use the resolver to replace possible tokens
[
https://issues.apache.org/jira/browse/SOLR-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1391:
-
Fix Version/s: 1.4
> The XPath field in the XPathEntityResolver should use the resolver to replace
> possible tokens
> -
>
> Key: SOLR-1391
> URL: https://issues.apache.org/jira/browse/SOLR-1391
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Abdul Chaudhry
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: xpath.patch
>
>
> If you have a data-import configuration that nests an entity that includes an
> XPath with an XPathEntityProcessor - like so :-
>datasource="
>
>dataSource="filereader"
> processor="XPathEntityProcessor"
> ... etc />
>
>
>
> This will fail with an error like so
> Caused by: java.lang.RuntimeException: xpath must start with '/' :
> ${a.xpath_value}
> We should allow the xpath to be replaced with the token from entity a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1391) The XPath field in the XPathEntityResolver should use the resolver to replace possible tokens
[
https://issues.apache.org/jira/browse/SOLR-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-1391.
--
Resolution: Fixed
committed : r808759
thanks Abdul
> The XPath field in the XPathEntityResolver should use the resolver to replace
> possible tokens
> -
>
> Key: SOLR-1391
> URL: https://issues.apache.org/jira/browse/SOLR-1391
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Abdul Chaudhry
>Assignee: Noble Paul
> Attachments: xpath.patch
>
>
> If you have a data-import configuration that nests an entity that includes an
> XPath with an XPathEntityProcessor - like so :-
>datasource="
>
>dataSource="filereader"
> processor="XPathEntityProcessor"
> ... etc />
>
>
>
> This will fail with an error like so
> Caused by: java.lang.RuntimeException: xpath must start with '/' :
> ${a.xpath_value}
> We should allow the xpath to be replaced with the token from entity a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1385) Add an 'enable' attribute to all plugins
[
https://issues.apache.org/jira/browse/SOLR-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-1385:
Assignee: Noble Paul
> Add an 'enable' attribute to all plugins
> -
>
> Key: SOLR-1385
> URL: https://issues.apache.org/jira/browse/SOLR-1385
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-1385.patch
>
>
> Let us add an attribute 'enable' to all the plugins to enable/disable it at
> start time.
> example:
> {code:xml}
>
> {code}
> This helps in having a common solrconfig for master and slave and enable
> disable components from external params
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1385) Add an 'enable' attribute to all plugins
[
https://issues.apache.org/jira/browse/SOLR-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748671#action_12748671
]
Noble Paul edited comment on SOLR-1385 at 8/27/09 10:18 PM:
I guess this is trivial enough to be added to 1.4
was (Author: noble.paul):
I guess this is trivial enogh to be added to 1.4
> Add an 'enable' attribute to all plugins
> -
>
> Key: SOLR-1385
> URL: https://issues.apache.org/jira/browse/SOLR-1385
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-1385.patch
>
>
> Let us add an attribute 'enable' to all the plugins to enable/disable it at
> start time.
> example:
> {code:xml}
>
> {code}
> This helps in having a common solrconfig for master and slave and enable
> disable components from external params
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1385) Add an 'enable' attribute to all plugins
[
https://issues.apache.org/jira/browse/SOLR-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1385:
-
Attachment: SOLR-1385.patch
I guess this is trivial enogh to be added to 1.4
> Add an 'enable' attribute to all plugins
> -
>
> Key: SOLR-1385
> URL: https://issues.apache.org/jira/browse/SOLR-1385
> Project: Solr
> Issue Type: New Feature
>Reporter: Noble Paul
> Attachments: SOLR-1385.patch
>
>
> Let us add an attribute 'enable' to all the plugins to enable/disable it at
> start time.
> example:
> {code:xml}
>
> {code}
> This helps in having a common solrconfig for master and slave and enable
> disable components from external params
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1391) The XPath field in the XPathEntityResolver should use the resolver to replace possible tokens
[
https://issues.apache.org/jira/browse/SOLR-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-1391:
Assignee: Noble Paul
> The XPath field in the XPathEntityResolver should use the resolver to replace
> possible tokens
> -
>
> Key: SOLR-1391
> URL: https://issues.apache.org/jira/browse/SOLR-1391
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Abdul Chaudhry
>Assignee: Noble Paul
> Attachments: xpath.patch
>
>
> If you have a data-import configuration that nests an entity that includes an
> XPath with an XPathEntityProcessor - like so :-
>datasource="
>
>dataSource="filereader"
> processor="XPathEntityProcessor"
> ... etc />
>
>
>
> This will fail with an error like so
> Caused by: java.lang.RuntimeException: xpath must start with '/' :
> ${a.xpath_value}
> We should allow the xpath to be replaced with the token from entity a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr
[
https://issues.apache.org/jira/browse/SOLR-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748639#action_12748639
]
Jason Rutherglen commented on SOLR-908:
---
There is a bug that seems to be related to
HTMLStripStandardTokenizerFactory where a single word query
fails to generate a token using the following chain. However a
StandardTokenizer in it's place returns a token as expected.
When SOLR-908.patch was tested with rev 799698, HTMLSSTF worked.
{code}
{code}
> Port of Nutch CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
> Issue Type: Wish
> Components: Analysis
>Reporter: Tom Burton-West
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch,
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow. We are reluctant
> to just use stop words due to various problems with false hits and some
> things becoming impossible to search with stop words turned on. (For example
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.)
>
> Several postings regarding slow phrase queries have suggested using the
> approach used by Nutch. Perhaps someone with more Java/Solr experience might
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr and create
> a suitable Solr FilterFactory so that it could be used in Solr by listing it
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing.
> Optimize phrase queries to use the n-grams. Single terms are still indexed
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1391) The XPath field in the XPathEntityResolver should use the resolver to replace possible tokens
[
https://issues.apache.org/jira/browse/SOLR-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abdul Chaudhry updated SOLR-1391:
-
Attachment: xpath.patch
The fix is simple from what I can tell and I have updated the patch. I just
used resolver.replaceTokens on the xpath field
> The XPath field in the XPathEntityResolver should use the resolver to replace
> possible tokens
> -
>
> Key: SOLR-1391
> URL: https://issues.apache.org/jira/browse/SOLR-1391
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Abdul Chaudhry
> Attachments: xpath.patch
>
>
> If you have a data-import configuration that nests an entity that includes an
> XPath with an XPathEntityProcessor - like so :-
>datasource="
>
>dataSource="filereader"
> processor="XPathEntityProcessor"
> ... etc />
>
>
>
> This will fail with an error like so
> Caused by: java.lang.RuntimeException: xpath must start with '/' :
> ${a.xpath_value}
> We should allow the xpath to be replaced with the token from entity a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1391) The XPath field in the XPathEntityResolver should use the resolver to replace possible tokens
The XPath field in the XPathEntityResolver should use the resolver to replace
possible tokens
-
Key: SOLR-1391
URL: https://issues.apache.org/jira/browse/SOLR-1391
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Abdul Chaudhry
If you have a data-import configuration that nests an entity that includes an
XPath with an XPathEntityProcessor - like so :-
This will fail with an error like so
Caused by: java.lang.RuntimeException: xpath must start with '/' :
${a.xpath_value}
We should allow the xpath to be replaced with the token from entity a
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1390) add timestamp for last update/commit to stats page
[ https://issues.apache.org/jira/browse/SOLR-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748608#action_12748608 ] Hoss Man commented on SOLR-1390: most recent update is kind of vague and hard to track. most recent commit is essentially the same thing as the openedAt stat from "searcher" > add timestamp for last update/commit to stats page > -- > > Key: SOLR-1390 > URL: https://issues.apache.org/jira/browse/SOLR-1390 > Project: Solr > Issue Type: Wish > Components: web gui >Reporter: solrize >Priority: Minor > > For purposes of monitoring the health of a running search system, it would be > handy if the admin stats page (I guess in the "update handler" section) > displayed the date/time of the most recent update and/or most recent commit. > If the application is expected to post updates once in a while but the solr > stats page doesn't show any recent updates, that is a sign that something is > wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1390) add timestamp for last update/commit to stats page
add timestamp for last update/commit to stats page -- Key: SOLR-1390 URL: https://issues.apache.org/jira/browse/SOLR-1390 Project: Solr Issue Type: Wish Components: web gui Reporter: solrize Priority: Minor For purposes of monitoring the health of a running search system, it would be handy if the admin stats page (I guess in the "update handler" section) displayed the date/time of the most recent update and/or most recent commit. If the application is expected to post updates once in a while but the solr stats page doesn't show any recent updates, that is a sign that something is wrong. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-1389) When 'Organisms' is given as the keyword, it returns "Organizations". Please note that this happens under normal step and configuration environment.
[ https://issues.apache.org/jira/browse/SOLR-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher closed SOLR-1389. -- Resolution: Invalid This is a user question about configuration of stemming analysis. Please ask on the solr-user list. > When 'Organisms' is given as the keyword, it returns "Organizations". Please > note that this happens under normal step and configuration environment. > > > Key: SOLR-1389 > URL: https://issues.apache.org/jira/browse/SOLR-1389 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Normal initial setup without much modifcations, the > schema was used from Nutch, to update the index files from nutch. >Reporter: chandrasekaran rangasamy > > When 'Organisms' is given as the keyword, it returns "Organizations". Not > sure why this happens. It uses standard search handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1389) When 'Organisms' is given as the keyword, it returns "Organizations". Please note that this happens under normal step and configuration environment.
When 'Organisms' is given as the keyword, it returns "Organizations". Please note that this happens under normal step and configuration environment. Key: SOLR-1389 URL: https://issues.apache.org/jira/browse/SOLR-1389 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Environment: Normal initial setup without much modifcations, the schema was used from Nutch, to update the index files from nutch. Reporter: chandrasekaran rangasamy When 'Organisms' is given as the keyword, it returns "Organizations". Not sure why this happens. It uses standard search handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-908) Port of Nutch CommonGrams filter to Solr
[ https://issues.apache.org/jira/browse/SOLR-908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated SOLR-908: -- Attachment: SOLR-908.patch I changed: if (prev != null && prev.type() != "gram") from checking for "word" which when a token was created from StandardFilter, would be of type "" and was being discarded. This was causing at least one of the bugs, though there may be another. > Port of Nutch CommonGrams filter to Solr > - > > Key: SOLR-908 > URL: https://issues.apache.org/jira/browse/SOLR-908 > Project: Solr > Issue Type: Wish > Components: Analysis >Reporter: Tom Burton-West >Assignee: Shalin Shekhar Mangar >Priority: Minor > Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, > SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch > > > Phrase queries containing common words are extremely slow. We are reluctant > to just use stop words due to various problems with false hits and some > things becoming impossible to search with stop words turned on. (For example > "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) > > Several postings regarding slow phrase queries have suggested using the > approach used by Nutch. Perhaps someone with more Java/Solr experience might > take this on. > It should be possible to port the Nutch CommonGrams code to Solr and create > a suitable Solr FilterFactory so that it could be used in Solr by listing it > in the Solr schema.xml. > "Construct n-grams for frequently occuring terms and phrases while indexing. > Optimize phrase queries to use the n-grams. Single terms are still indexed > too, with n-grams overlaid." > http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1091) "phps" (serialized PHP) writer produces invalid output
[
https://issues.apache.org/jira/browse/SOLR-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1091:
---
Attachment: SOLR-1091.patch
Here's a patch that can handle the modified UTF8 that Jetty puts out, as well
as speeding up the normal UTF8 case using Lucene's UTF8 encoding.
modified UTF8 support is switched on if the jetty.home property is set (jetty
does this by default).
> "phps" (serialized PHP) writer produces invalid output
> --
>
> Key: SOLR-1091
> URL: https://issues.apache.org/jira/browse/SOLR-1091
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
> Environment: Sun JRE 1.6.0 on Centos 5
>Reporter: frank farmer
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1091.patch
>
>
> The serialized PHP output writer can outputs invalid string lengths for
> certain (unusual) input values. Specifically, I had a document containing
> the following 6 byte character sequence: \xED\xAF\x80\xED\xB1\xB8
> I was able to create a document in the index containing this value without
> issue; however, when fetching the document back out using the serialized PHP
> writer, it returns a string like the following:
> s:4:"􀁸";
> Note that the string length specified is 4, while the string is actually 6
> bytes long.
> When using PHP's native serialize() function, it correctly sets the length to
> 6:
> # php -r 'var_dump(serialize("\xED\xAF\x80\xED\xB1\xB8"));'
> string(13) "s:6:"􀁸";"
> The "wt=php" writer, which produces output to be parsed with eval(), doesn't
> have any trouble with this string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr
[ https://issues.apache.org/jira/browse/SOLR-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748423#action_12748423 ] Tom Burton-West commented on SOLR-908: -- Hi Jason, If the last non-common word in a query is part of the previous common-gram then it gets removed by design. i.e.query=" see the hat" query filter output should be |see-the|the-hat| Is this a different case? The test cases should have caught the bug. Maybe we need to add a few more test cases. Could you send me a test case that shows the bug? Tom > Port of Nutch CommonGrams filter to Solr > - > > Key: SOLR-908 > URL: https://issues.apache.org/jira/browse/SOLR-908 > Project: Solr > Issue Type: Wish > Components: Analysis >Reporter: Tom Burton-West >Assignee: Shalin Shekhar Mangar >Priority: Minor > Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, > SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch > > > Phrase queries containing common words are extremely slow. We are reluctant > to just use stop words due to various problems with false hits and some > things becoming impossible to search with stop words turned on. (For example > "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) > > Several postings regarding slow phrase queries have suggested using the > approach used by Nutch. Perhaps someone with more Java/Solr experience might > take this on. > It should be possible to port the Nutch CommonGrams code to Solr and create > a suitable Solr FilterFactory so that it could be used in Solr by listing it > in the Solr schema.xml. > "Construct n-grams for frequently occuring terms and phrases while indexing. > Optimize phrase queries to use the n-grams. Single terms are still indexed > too, with n-grams overlaid." > http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1091) "phps" (serialized PHP) writer produces invalid output
[
https://issues.apache.org/jira/browse/SOLR-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748419#action_12748419
]
frank farmer commented on SOLR-1091:
Thanks for looking in to this. I take it this issue can be closed, and I
should go open a ticket against Jetty?
> "phps" (serialized PHP) writer produces invalid output
> --
>
> Key: SOLR-1091
> URL: https://issues.apache.org/jira/browse/SOLR-1091
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
> Environment: Sun JRE 1.6.0 on Centos 5
>Reporter: frank farmer
>Priority: Minor
> Fix For: 1.4
>
>
> The serialized PHP output writer can outputs invalid string lengths for
> certain (unusual) input values. Specifically, I had a document containing
> the following 6 byte character sequence: \xED\xAF\x80\xED\xB1\xB8
> I was able to create a document in the index containing this value without
> issue; however, when fetching the document back out using the serialized PHP
> writer, it returns a string like the following:
> s:4:"􀁸";
> Note that the string length specified is 4, while the string is actually 6
> bytes long.
> When using PHP's native serialize() function, it correctly sets the length to
> 6:
> # php -r 'var_dump(serialize("\xED\xAF\x80\xED\xB1\xB8"));'
> string(13) "s:6:"􀁸";"
> The "wt=php" writer, which produces output to be parsed with eval(), doesn't
> have any trouble with this string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1388) Show the download link more prominently on the website
Show the download link more prominently on the website -- Key: SOLR-1388 URL: https://issues.apache.org/jira/browse/SOLR-1388 Project: Solr Issue Type: Improvement Reporter: Shalin Shekhar Mangar Priority: Minor Fix For: 1.4 The download link should be shown on the home page prominently. Users shouldn't be forced to search for a download link. Also see http://twitter.com/kevsmith/status/3579783776 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1091) "phps" (serialized PHP) writer produces invalid output
[
https://issues.apache.org/jira/browse/SOLR-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748403#action_12748403
]
Yonik Seeley commented on SOLR-1091:
Confirmed - it's jetty. The latest version of Jetty exhibits the same behavior
- it produces incorrect UT8 for code points outside the BMP. I tried with
LucidWorks/Solr (Tomcat based) and it works correctly by only outputting 4
bytes.
> "phps" (serialized PHP) writer produces invalid output
> --
>
> Key: SOLR-1091
> URL: https://issues.apache.org/jira/browse/SOLR-1091
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
> Environment: Sun JRE 1.6.0 on Centos 5
>Reporter: frank farmer
>Priority: Minor
> Fix For: 1.4
>
>
> The serialized PHP output writer can outputs invalid string lengths for
> certain (unusual) input values. Specifically, I had a document containing
> the following 6 byte character sequence: \xED\xAF\x80\xED\xB1\xB8
> I was able to create a document in the index containing this value without
> issue; however, when fetching the document back out using the serialized PHP
> writer, it returns a string like the following:
> s:4:"􀁸";
> Note that the string length specified is 4, while the string is actually 6
> bytes long.
> When using PHP's native serialize() function, it correctly sets the length to
> 6:
> # php -r 'var_dump(serialize("\xED\xAF\x80\xED\xB1\xB8"));'
> string(13) "s:6:"􀁸";"
> The "wt=php" writer, which produces output to be parsed with eval(), doesn't
> have any trouble with this string.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
I kicked off the nightly build manually - seems to have worked for now at least. -Yonik http://www.lucidimagination.com On Thu, Aug 27, 2009 at 8:26 AM, Yonik Seeley wrote: > I think these failures might be due to waiting until a commit, but not > waiting until the new searcher is registered before trying the search. > I'll see if I can work up a patch. > > -Yonik > http://www.lucidimagination.com > > > > On Thu, Aug 27, 2009 at 4:37 AM, wrote: >> >> init-forrest-entities: >> [mkdir] Created dir: /tmp/apache-solr-nightly/build >> [mkdir] Created dir: /tmp/apache-solr-nightly/build/web >> >> compile-solrj: >> [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj >> [javac] Compiling 84 source files to /tmp/apache-solr-nightly/build/solrj >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -Xlint:deprecation for details. >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> >> compile: >> [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr >> [javac] Compiling 373 source files to /tmp/apache-solr-nightly/build/solr >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -Xlint:deprecation for details. >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> >> compileTests: >> [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests >> [javac] Compiling 167 source files to /tmp/apache-solr-nightly/build/tests >> [javac] Note: Some input files use or override a deprecated API. >> [javac] Note: Recompile with -Xlint:deprecation for details. >> [javac] Note: Some input files use unchecked or unsafe operations. >> [javac] Note: Recompile with -Xlint:unchecked for details. >> >> junit: >> [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results >> [junit] Running org.apache.solr.BasicFunctionalityTest >> [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 41.021 sec >> [junit] Running org.apache.solr.ConvertedLegacyTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 21.869 sec >> [junit] Running org.apache.solr.DisMaxRequestHandlerTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 17.514 sec >> [junit] Running org.apache.solr.EchoParamsTest >> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 9.449 sec >> [junit] Running org.apache.solr.MinimalSchemaTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 13.767 sec >> [junit] Running org.apache.solr.OutputWriterTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.592 sec >> [junit] Running org.apache.solr.SampleTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.018 sec >> [junit] Running org.apache.solr.SolrInfoMBeanTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.092 sec >> [junit] Running org.apache.solr.TestDistributedSearch >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 78.793 sec >> [junit] Running org.apache.solr.TestSolrCoreProperties >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.717 sec >> [junit] Running org.apache.solr.TestTrie >> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 18.558 sec >> [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.771 sec >> [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest >> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.695 sec >> [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.717 sec >> [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest >> [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.462 sec >> [junit] Running org.apache.solr.analysis.LengthFilterTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.197 sec >> [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.475 sec >> [junit] Running org.apache.solr.analysis.TestBufferedTokenStream >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.76 sec >> [junit] Running org.apache.solr.analysis.TestCapitalizationFilter >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.925 sec >> [junit] Running >> org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.735 sec >> [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.866 sec >> [junit] Running o
[jira] Commented: (SOLR-1240) Numerical Range faceting
[ https://issues.apache.org/jira/browse/SOLR-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748374#action_12748374 ] Gijs Kunze commented on SOLR-1240: -- I'd love to add it as a separate component, maybe moving date faceting to the same component since date faceting and numerical faceting is practically identical. But as I said, I'm not really that proficient in Java, haven't done any real Java programming since Swing was still new. So I'm not really sure I'm up to the task. Looking at SOLR-792 as an example I looked at converting my patch but I think some re-factoring on the side of SimpleFacets might be in order first. My patch makes use of the parseParams method (which handles tagging/exclusion local parameters) and I can't see how to cleanly make use of that functionality from a separate component. I could copy the method and the member variables it manipulates to the component but I'd rather not perpetrate that code maintenance no-no. > Numerical Range faceting > > > Key: SOLR-1240 > URL: https://issues.apache.org/jira/browse/SOLR-1240 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Gijs Kunze >Priority: Minor > Attachments: SOLR-1240.patch > > > For faceting numerical ranges using many facet.query query arguments leads to > unmanageably large queries as the fields you facet over increase. Adding the > same faceting parameter for numbers which already exists for dates should fix > this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
I think these failures might be due to waiting until a commit, but not waiting until the new searcher is registered before trying the search. I'll see if I can work up a patch. -Yonik http://www.lucidimagination.com On Thu, Aug 27, 2009 at 4:37 AM, wrote: > > init-forrest-entities: > [mkdir] Created dir: /tmp/apache-solr-nightly/build > [mkdir] Created dir: /tmp/apache-solr-nightly/build/web > > compile-solrj: > [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj > [javac] Compiling 84 source files to /tmp/apache-solr-nightly/build/solrj > [javac] Note: Some input files use or override a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > > compile: > [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr > [javac] Compiling 373 source files to /tmp/apache-solr-nightly/build/solr > [javac] Note: Some input files use or override a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > > compileTests: > [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests > [javac] Compiling 167 source files to /tmp/apache-solr-nightly/build/tests > [javac] Note: Some input files use or override a deprecated API. > [javac] Note: Recompile with -Xlint:deprecation for details. > [javac] Note: Some input files use unchecked or unsafe operations. > [javac] Note: Recompile with -Xlint:unchecked for details. > > junit: > [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results > [junit] Running org.apache.solr.BasicFunctionalityTest > [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 41.021 sec > [junit] Running org.apache.solr.ConvertedLegacyTest > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 21.869 sec > [junit] Running org.apache.solr.DisMaxRequestHandlerTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 17.514 sec > [junit] Running org.apache.solr.EchoParamsTest > [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 9.449 sec > [junit] Running org.apache.solr.MinimalSchemaTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 13.767 sec > [junit] Running org.apache.solr.OutputWriterTest > [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.592 sec > [junit] Running org.apache.solr.SampleTest > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.018 sec > [junit] Running org.apache.solr.SolrInfoMBeanTest > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.092 sec > [junit] Running org.apache.solr.TestDistributedSearch > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 78.793 sec > [junit] Running org.apache.solr.TestSolrCoreProperties > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.717 sec > [junit] Running org.apache.solr.TestTrie > [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 18.558 sec > [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.771 sec > [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest > [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.695 sec > [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.717 sec > [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest > [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.462 sec > [junit] Running org.apache.solr.analysis.LengthFilterTest > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.197 sec > [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.475 sec > [junit] Running org.apache.solr.analysis.TestBufferedTokenStream > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.76 sec > [junit] Running org.apache.solr.analysis.TestCapitalizationFilter > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.925 sec > [junit] Running > org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory > [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.735 sec > [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.866 sec > [junit] Running org.apache.solr.analysis.TestKeepFilterFactory > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.046 sec > [junit] Running org.apache.solr.analysis.TestKeepWordFilter > [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.311 sec > [j
[jira] Commented: (SOLR-1240) Numerical Range faceting
[ https://issues.apache.org/jira/browse/SOLR-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748350#action_12748350 ] Erik Hatcher commented on SOLR-1240: Let's please stop adding stuff to SimpleFacets. See SOLR-792 for an approach of adding additional faceting components instead of overloading the now not-so-SimpleFacets. > Numerical Range faceting > > > Key: SOLR-1240 > URL: https://issues.apache.org/jira/browse/SOLR-1240 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Gijs Kunze >Priority: Minor > Attachments: SOLR-1240.patch > > > For faceting numerical ranges using many facet.query query arguments leads to > unmanageably large queries as the fields you facet over increase. Adding the > same faceting parameter for numbers which already exists for dates should fix > this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 84 source files to /tmp/apache-solr-nightly/build/solrj [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 373 source files to /tmp/apache-solr-nightly/build/solr [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 167 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 41.021 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 21.869 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 17.514 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 9.449 sec [junit] Running org.apache.solr.MinimalSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 13.767 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.592 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.018 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.092 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 78.793 sec [junit] Running org.apache.solr.TestSolrCoreProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.717 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 18.558 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.771 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.695 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.717 sec [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.462 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.197 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.475 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.76 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.925 sec [junit] Running org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 7.735 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.866 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.046 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.311 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.422 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 5.864 sec [junit] Running org.apache.solr.analysis.TestPatternToken
[jira] Resolved: (SOLR-1355) add an enable value in master/slave configuration
[
https://issues.apache.org/jira/browse/SOLR-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-1355.
--
Resolution: Fixed
commmitted: r808305
> add an enable value in master/slave configuration
> -
>
> Key: SOLR-1355
> URL: https://issues.apache.org/jira/browse/SOLR-1355
> Project: Solr
> Issue Type: Improvement
> Components: replication (java)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1355.patch, SOLR-1355.patch
>
>
> add an enable tag for master/slave so that it can be changed in the runtime
> with a variable
> {code:xml}
>
>
> true
> commit
> schema.xml,stopwords.txt
>
>
>true
>http://localhost:8983/solr/replication
>00:00:60
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1355) add an enable value in master/slave configuration
[
https://issues.apache.org/jira/browse/SOLR-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1355:
-
Attachment: SOLR-1355.patch
> add an enable value in master/slave configuration
> -
>
> Key: SOLR-1355
> URL: https://issues.apache.org/jira/browse/SOLR-1355
> Project: Solr
> Issue Type: Improvement
> Components: replication (java)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1355.patch, SOLR-1355.patch
>
>
> add an enable tag for master/slave so that it can be changed in the runtime
> with a variable
> {code:xml}
>
>
> true
> commit
> schema.xml,stopwords.txt
>
>
>true
>http://localhost:8983/solr/replication
>00:00:60
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1355) add an enable value in master/slave configuration
[
https://issues.apache.org/jira/browse/SOLR-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1355:
-
Attachment: SOLR-1355.patch
in the details command just show the master details of master
> add an enable value in master/slave configuration
> -
>
> Key: SOLR-1355
> URL: https://issues.apache.org/jira/browse/SOLR-1355
> Project: Solr
> Issue Type: Improvement
> Components: replication (java)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1355.patch
>
>
> add an enable tag for master/slave so that it can be changed in the runtime
> with a variable
> {code:xml}
>
>
> true
> commit
> schema.xml,stopwords.txt
>
>
>true
>http://localhost:8983/solr/replication
>00:00:60
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1355) add an enable value in master/slave configuration
[
https://issues.apache.org/jira/browse/SOLR-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-1355:
-
Attachment: (was: SOLR-1355.patch)
> add an enable value in master/slave configuration
> -
>
> Key: SOLR-1355
> URL: https://issues.apache.org/jira/browse/SOLR-1355
> Project: Solr
> Issue Type: Improvement
> Components: replication (java)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1355.patch
>
>
> add an enable tag for master/slave so that it can be changed in the runtime
> with a variable
> {code:xml}
>
>
> true
> commit
> schema.xml,stopwords.txt
>
>
>true
>http://localhost:8983/solr/replication
>00:00:60
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
