Re: Down to 5
On Fri, Oct 9, 2009 at 4:17 AM, Yonik Seeley yo...@lucidimagination.comwrote: On Sun, Oct 4, 2009 at 6:13 PM, Grant Ingersoll gsing...@apache.org wrote: Coming along: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230versionId=12313351showOpenIssuesOnly=true If we can finish these up this week, I can generate RCs next week. Down to 4! We're still planning on a code freeze at the end of this week, right? I think all of the targeted issues are just waiting for the final commits? SOLR-1458Java Replication error: NullPointerException SEVERE: SnapPull failed on 2009-09-22 nightly SOLR-1449 solrconfig.xml syntax to add classpath elements from outside of instanceDir SOLR-1497 Remove solrjs from svn -- point docs to AJAX Solr SOLR-1475 Java-based replication doesn't properly reserve its commit point during backups Other issues: - Do we just bag chinese for now and force people to write their own factories? SOLR-1336 - Does the Lucene 2.9 bugfix branch have anything warranting upgrading to it? What about FastVectorHighlighter? https://issues.apache.org/jira/browse/SOLR-1268 -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-1501) DIH: Setting rows= on full-import has no effect
[ https://issues.apache.org/jira/browse/SOLR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1501: - Attachment: SOLR-1501.patch DIH: Setting rows= on full-import has no effect --- Key: SOLR-1501 URL: https://issues.apache.org/jira/browse/SOLR-1501 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1501.patch DIH: Setting rows= on full-import has no effect http://markmail.org/thread/omzkm2x52dsuzomy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1501) DIH: Setting rows= on full-import has no effect
[ https://issues.apache.org/jira/browse/SOLR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1501. -- Resolution: Fixed this was an issue when the root most entity had a rootEntity=false; commited r823446 DIH: Setting rows= on full-import has no effect --- Key: SOLR-1501 URL: https://issues.apache.org/jira/browse/SOLR-1501 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1501.patch DIH: Setting rows= on full-import has no effect http://markmail.org/thread/omzkm2x52dsuzomy -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Down to 5
Hi Shalin, What about FastVectorHighlighter? https://issues.apache.org/jira/browse/SOLR-1268 If we're targeting RC in this week, I'd like to push it to 1.5 because there is no patches. But perhaps you think 13 votes is considerable? Koji
[jira] Assigned: (SOLR-1268) Incorporate Lucene's FastVectorHighlighter
[ https://issues.apache.org/jira/browse/SOLR-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi reassigned SOLR-1268: Assignee: Koji Sekiguchi Incorporate Lucene's FastVectorHighlighter -- Key: SOLR-1268 URL: https://issues.apache.org/jira/browse/SOLR-1268 Project: Solr Issue Type: New Feature Components: highlighter Reporter: Koji Sekiguchi Assignee: Koji Sekiguchi Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1498) RegexTransformer: sourceColName version not handling multiValued fields correctly
[ https://issues.apache.org/jira/browse/SOLR-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1498: Fix Version/s: 1.4 Assignee: Shalin Shekhar Mangar This seems to be a regression therefore I'm marking it for 1.4 RegexTransformer: sourceColName version not handling multiValued fields correctly - Key: SOLR-1498 URL: https://issues.apache.org/jira/browse/SOLR-1498 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Environment: Windows XP, JDK 6, Tomcat 6 Linux (RedHat), JDK, Tomcat 5 Reporter: Chantal Ackermann Assignee: Shalin Shekhar Mangar Fix For: 1.4 Versions in use/compared: Solr 1.3 (Nightly 5th August) Nightly 22nd September As RegexTransformer is not different between the two nightlies, the issue probably appeared before. ISSUE: Using RegexTransformer with the 'sourceColName' notation will not populate multiValued (actually containing multiple values) fields with a list but instead add only one value per document. The version with 'groupNames' does. worked for 1.3 (regression): field column=participant sourceColName=person regex=([^\|]+)\|.* / field column=role sourceColName=person regex=[^\|]+\|\d+,\d+,\d+,(.*) / works for nightly 22nd Sept: field column=person groupNames=participant,role regex=([^\|]+)\|\d+,\d+,\d+,(.*) / (Both fields are of type solr.StrField and multiValued.) Comparing the source code of RegexTransformer 1.3 vs. 22nd Sept, I found: for (Object result : results) row.put(col, result); (lines 106-107 of transformRow() 22nd of Sept) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Down to 5
On Fri, Oct 9, 2009 at 6:08 PM, Koji Sekiguchi k...@r.email.ne.jp wrote: Hi Shalin, What about FastVectorHighlighter? https://issues.apache.org/jira/browse/SOLR-1268 If we're targeting RC in this week, I'd like to push it to 1.5 because there is no patches. But perhaps you think 13 votes is considerable? No, that is fine. We can push it to 1.5 unless it is very easy to make it work with Solr. It affects relatively few number of people. The applications mentioned in the comments (Blacklight etc) can choose to release with patched Solr versions I guess. The only common case which needs this feature is highlighting n-gram fields (for auto-complete). -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-1268) Incorporate Lucene's FastVectorHighlighter
[ https://issues.apache.org/jira/browse/SOLR-1268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-1268: - Fix Version/s: 1.5 Mark it to 1.5 because there is no patches. Incorporate Lucene's FastVectorHighlighter -- Key: SOLR-1268 URL: https://issues.apache.org/jira/browse/SOLR-1268 Project: Solr Issue Type: New Feature Components: highlighter Reporter: Koji Sekiguchi Assignee: Koji Sekiguchi Priority: Minor Fix For: 1.5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12764021#action_12764021
]
Yonik Seeley commented on SOLR-1475:
I'll take it - have a good vacation!
Java-based replication doesn't properly reserve its commit point during
backups
---
Key: SOLR-1475
URL: https://issues.apache.org/jira/browse/SOLR-1475
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.4
Reporter: Chris Harris
Assignee: Mark Miller
Fix For: 1.4
Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch,
SOLR-1475.patch
The issue title reflects Mark Miller's initial diagnosis of the problem.
Here are my symptoms:
This is regarding the backup feature of replication, as opposed to
replication. Backups seem to work fine on toy indexes. When trying backups
out on a copy of my production index (300GB-ish), though, I'm getting
FileNotFoundExceptions. These cancel the backup, and delete the
snapshot.mmdd* directory. It seems reproducible, in that every time I try
to make a backup of my large index it will fail the same way.
This is Solr r815830. I'm not sure if this is something that would
potentially be addressed by SOLR-1458? (That patch is from after r815830.)
For now I'm not using any event-based backup triggers; instead I'm manually
hitting
http://master_host:port/solr/replication?command=backup
This successfully sets off a snapshot, as seen in a thread dump. However,
after a while the snapshot fails. I'll paste in a couple of stack traces
below.
I haven't seen any other evidence that my index is corrupt; in particular,
searching the index and Java-based replication seem to be working fine, and
the Lucene CheckIndex tool did not report any problems with the index.
{code}
Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley reassigned SOLR-1475:
--
Assignee: Yonik Seeley (was: Mark Miller)
Java-based replication doesn't properly reserve its commit point during
backups
---
Key: SOLR-1475
URL: https://issues.apache.org/jira/browse/SOLR-1475
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.4
Reporter: Chris Harris
Assignee: Yonik Seeley
Fix For: 1.4
Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch,
SOLR-1475.patch
The issue title reflects Mark Miller's initial diagnosis of the problem.
Here are my symptoms:
This is regarding the backup feature of replication, as opposed to
replication. Backups seem to work fine on toy indexes. When trying backups
out on a copy of my production index (300GB-ish), though, I'm getting
FileNotFoundExceptions. These cancel the backup, and delete the
snapshot.mmdd* directory. It seems reproducible, in that every time I try
to make a backup of my large index it will fail the same way.
This is Solr r815830. I'm not sure if this is something that would
potentially be addressed by SOLR-1458? (That patch is from after r815830.)
For now I'm not using any event-based backup triggers; instead I'm manually
hitting
http://master_host:port/solr/replication?command=backup
This successfully sets off a snapshot, as seen in a thread dump. However,
after a while the snapshot fails. I'll paste in a couple of stack traces
below.
I haven't seen any other evidence that my index is corrupt; in particular,
searching the index and Java-based replication seem to be working fine, and
the Lucene CheckIndex tool did not report any problems with the index.
{code}
Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Down to 5
Realistically speaking, I can do an RC on Monday afternoon. So, how about we say Pencils down at 12 noon EDT on Monday and then I can create an RC that afternoon. -Grant On Oct 9, 2009, at 10:13 AM, Shalin Shekhar Mangar wrote: On Fri, Oct 9, 2009 at 6:08 PM, Koji Sekiguchi k...@r.email.ne.jp wrote: Hi Shalin, What about FastVectorHighlighter? https://issues.apache.org/jira/browse/SOLR-1268 If we're targeting RC in this week, I'd like to push it to 1.5 because there is no patches. But perhaps you think 13 votes is considerable? No, that is fine. We can push it to 1.5 unless it is very easy to make it work with Solr. It affects relatively few number of people. The applications mentioned in the comments (Blacklight etc) can choose to release with patched Solr versions I guess. The only common case which needs this feature is highlighting n-gram fields (for auto-complete). -- Regards, Shalin Shekhar Mangar.
[jira] Created: (SOLR-1502) Add form to perform updates
Add form to perform updates --- Key: SOLR-1502 URL: https://issues.apache.org/jira/browse/SOLR-1502 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 1.4 Reporter: Jason Rutherglen Priority: Minor Fix For: 1.5 A convenience UI to perform updates via the Web UI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1497) Remove solrjs from svn -- point docs to AJAX Solr
[ https://issues.apache.org/jira/browse/SOLR-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12764181#action_12764181 ] Yonik Seeley commented on SOLR-1497: As far as commits to svn, +1 for just removing. Remove solrjs from svn -- point docs to AJAX Solr - Key: SOLR-1497 URL: https://issues.apache.org/jira/browse/SOLR-1497 Project: Solr Issue Type: Task Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.4 The solrjs version in solr source tree needs some attention, yet progress seems unlikely. Meanwhile, AJAX solr (a solrjs fork) has made good progress and seems that it will be supported moving forward. We should archive solrjs and remove it from the source tree. For discussion, see: http://www.lucidimagination.com/search/document/900bf257f8df4e37/archive_solrjs_and_point_to_ajax_solr#13f6cb2ec40ae1f0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-1475:
---
Attachment: SOLR-1475.patch
OK, here's my update to Mark's patch... pretty much just using saveCommitPoint
instead of doing short duration reserves. I plan on committing shortly.
Java-based replication doesn't properly reserve its commit point during
backups
---
Key: SOLR-1475
URL: https://issues.apache.org/jira/browse/SOLR-1475
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.4
Reporter: Chris Harris
Assignee: Yonik Seeley
Fix For: 1.4
Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch,
SOLR-1475.patch, SOLR-1475.patch
The issue title reflects Mark Miller's initial diagnosis of the problem.
Here are my symptoms:
This is regarding the backup feature of replication, as opposed to
replication. Backups seem to work fine on toy indexes. When trying backups
out on a copy of my production index (300GB-ish), though, I'm getting
FileNotFoundExceptions. These cancel the backup, and delete the
snapshot.mmdd* directory. It seems reproducible, in that every time I try
to make a backup of my large index it will fail the same way.
This is Solr r815830. I'm not sure if this is something that would
potentially be addressed by SOLR-1458? (That patch is from after r815830.)
For now I'm not using any event-based backup triggers; instead I'm manually
hitting
http://master_host:port/solr/replication?command=backup
This successfully sets off a snapshot, as seen in a thread dump. However,
after a while the snapshot fails. I'll paste in a couple of stack traces
below.
I haven't seen any other evidence that my index is corrupt; in particular,
searching the index and Java-based replication seem to be working fine, and
the Lucene CheckIndex tool did not report any problems with the index.
{code}
Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Down to 5
Yonik Seeley yo...@lucidimagination.com writes: One further issue... should we commit the changes to the HTMLStripReader? https://issues.apache.org/jira/browse/SOLR-1394 As the reporter of that bug, I would obviously like to see a fix included in 1.4. It would be one thing to have the patch declared faulty, but having it miss the window due to being ignored bothers me a bit. Is there anything that I can do to help it along? Anders.
Re: Down to 5
Unfortunately we don't have good unit tests for this, so it's difficult for people to tell if we've avoided regressions while making progress. But since it's a bug fix... it is technically possible for it to be included after the code freeze deadline I think? -Yonik On Fri, Oct 9, 2009 at 5:20 PM, Anders Melchiorsen m...@spoon.kalibalik.dk wrote: Yonik Seeley yo...@lucidimagination.com writes: One further issue... should we commit the changes to the HTMLStripReader? https://issues.apache.org/jira/browse/SOLR-1394 As the reporter of that bug, I would obviously like to see a fix included in 1.4. It would be one thing to have the patch declared faulty, but having it miss the window due to being ignored bothers me a bit. Is there anything that I can do to help it along? Anders.
Re: svn commit: r823705 - /lucene/solr/trunk/CHANGES.txt
I don't envy casual users trying to make sense out of some of these release notes... any suggestions on how to make it easier are welcome. -Yonik http://www.lucidimagination.com On Fri, Oct 9, 2009 at 5:45 PM, yo...@apache.org wrote: Author: yonik Date: Fri Oct 9 21:45:49 2009 New Revision: 823705 URL: http://svn.apache.org/viewvc?rev=823705view=rev Log: doc - per-segment fieldcache issues Modified: lucene/solr/trunk/CHANGES.txt Modified: lucene/solr/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/solr/trunk/CHANGES.txt?rev=823705r1=823704r2=823705view=diff == --- lucene/solr/trunk/CHANGES.txt (original) +++ lucene/solr/trunk/CHANGES.txt Fri Oct 9 21:45:49 2009 @@ -30,6 +30,20 @@ faster for most cases. One can revert to the previous algorithm (which has also been improved somewhat) by adding facet.method=enum to the request. +Searching and sorting is now done on a per-segment basis, meaning that +the FieldCache entries used for sorting and for function queries are +created and used per-segment and can be reused for segments that don't +change between index updates. While generally beneficial, this can lead +to increased memory usage over 1.3 in certain scenarios: + 1) A single valued field that was used for both sorting and faceting +in 1.3 would have used the same top level FieldCache entry. In 1.4, +sorting will use entries at the segment level while faceting will still +use entries at the top reader level, leading to increased memory usage. + 2) Certain function queries such as ord() and rord() require a top level +FieldCache instance and can thus lead to increased memory usage. Consider +replacing ord() and rord() with alternatives, such as function queries +based on ms() for date boosting. + If you use custom Tokenizer or TokenFilter components in a chain specified in schema.xml, they must support reusability. If your Tokenizer or TokenFilter maintains state, it should implement reset(). If your TokenFilteFactory does
[jira] Resolved: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-1475.
Resolution: Fixed
committed.
Java-based replication doesn't properly reserve its commit point during
backups
---
Key: SOLR-1475
URL: https://issues.apache.org/jira/browse/SOLR-1475
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.4
Reporter: Chris Harris
Assignee: Yonik Seeley
Fix For: 1.4
Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch,
SOLR-1475.patch, SOLR-1475.patch
The issue title reflects Mark Miller's initial diagnosis of the problem.
Here are my symptoms:
This is regarding the backup feature of replication, as opposed to
replication. Backups seem to work fine on toy indexes. When trying backups
out on a copy of my production index (300GB-ish), though, I'm getting
FileNotFoundExceptions. These cancel the backup, and delete the
snapshot.mmdd* directory. It seems reproducible, in that every time I try
to make a backup of my large index it will fail the same way.
This is Solr r815830. I'm not sure if this is something that would
potentially be addressed by SOLR-1458? (That patch is from after r815830.)
For now I'm not using any event-based backup triggers; instead I'm manually
hitting
http://master_host:port/solr/replication?command=backup
This successfully sets off a snapshot, as seen in a thread dump. However,
after a while the snapshot fails. I'll paste in a couple of stack traces
below.
I haven't seen any other evidence that my index is corrupt; in particular,
searching the index and Java-based replication seem to be working fine, and
the Lucene CheckIndex tool did not report any problems with the index.
{code}
Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
SEVERE: Exception while creating snapshot
java.io.FileNotFoundException: Source
'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
exist
at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
at
org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
at
org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
