[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-139: --- Attachment: SOLR-139-IndexDocumentCommand.patch Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Attachments: SOLR-139-IndexDocumentCommand.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Connecting custom RequestHandler
On Sat, 2007-02-03 at 18:41 -0800, Ryan McKinley wrote: The 'new' request parser reads the content type header to see if it should parse the body as params or not. If the content type is application/x-www-form-urlencoded it parses them as params, if it is multipart/* it parses them as multipart. if it is *anything* else, it reads the body as a stream. curl defaults the content type to application/x-www-form-urlencoded so you will need to run curl with -H Content-Type: text/xml - - - - - - - Hmm, I patched the post.sh only regarding the URL. FILES=$* URL=http://localhost:8983/solr/update/stax for f in $FILES; do echo Posting file $f to $URL curl $URL --data-binary @$f -H 'Content-type:text/xml; charset=utf-8' echo done Meaning what you describe is already in there. I now played around again with it and surprise it works now. Thanks Ryan. I should add this to the wiki. Can we change the post.sh to use -H Content-Type: text/xml? This will not affect old updater and will work for new UpdateHandlers. It is see above. Not sure why it did not work the yesterday. Thanks for the feedback. salu2 ryan On 2/3/07, Thorsten Scherler [EMAIL PROTECTED] wrote: On Sat, 2007-02-03 at 18:14 +0100, Thorsten Scherler wrote: Hi all, I am working on SOLR-133 and I have wrapped up a first version of the XmlUpdateRequestHandlerStax.java. Now I am trying to connect it in the example but I have some problems. I am trying: requestHandler name=/update/stax class=solr.XmlUpdateRequestHandlerStax / Trying to curl to URL=http://localhost:8983/solr/update/stax Debugging this I used http://localhost:8983/solr/update/xml and I get the same error. So I figured that we still use the SolrUpdateServlet @Deprecated in the post.sh. For now I can test the StAX changing XmlUpdateRequestHandlerStax legacyUpdateHandler; and implementing a doLegacyUpdate method in the handler. salu2 I get: Posting file solr.xml to http://localhost:8983/solr/update/stax ?xml version=1.0 encoding=UTF-8? response lst name=responseHeaderint name=status0/intint name=QTime67/int/lst /response html head titleError 400 missing content stream stax/title /head body h2HTTP ERROR: 400/h2premissing content stream stax/pre pRequestURI=/solr/update/stax/p ... What did I forget that the content stream is not passed to the method? Any tip, hint or shoot in the dark welcome. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java XMLconsulting, training and solutions -- Thorsten Scherler thorsten.at.apache.org Open Source Java XMLconsulting, training and solutions
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470061 ] Yonik Seeley commented on SOLR-139: --- Haven't had a chance to check out any code, but a few quick comments: If the field modes were parameters, they could be reused for other update handlers like SQL or CSV Perhaps something like: /update/xml?modify=truef.price.mode=increment,f.features.mode=append sku=REMOVE is required because sku is a stored field that is written to with copyField. I'm not sure I quite grok what REMOVE means yet, and how it fixes the copyField problem. Another way to work around copyField is to only collect stored fields that aren't copyField targets. Then you run the copyField logic while indexing the document again (as you should anyway). I think I'll have a tagging usecase that requires removing a specific field value from a multivalued field. Removing based on a regex might be nice too. though. f.tag.mode=remove f.tag.mode=removeMatching or removeRegex Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Attachments: SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-XmlUpdater.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-124) use NewIndexModifier, LUCENE-565
[ https://issues.apache.org/jira/browse/SOLR-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-124: -- Summary: use NewIndexModifier, LUCENE-565 (was: use LUCENE-565) LUCEUE-565 has been committed, but Solr doesn't have that version yet. Lucene 2.1 is right around the corner though. use NewIndexModifier, LUCENE-565 Key: SOLR-124 URL: https://issues.apache.org/jira/browse/SOLR-124 Project: Solr Issue Type: Improvement Components: update Reporter: Yonik Seeley LUCENE-565 adds extension points to the IndexWriter, and adds delete-by-term functionality. We should probably take advantage of this (when available) in our UpdateHandler (a new one, or modify DU2?) and perhaps implement a more efficient deleteByQuery. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[
https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470081
]
Ryan McKinley commented on SOLR-139:
Is this what you are suggesting?
I added a second searcher to DirectUpdatehandler2 that is only closed when you
call commit();
// Check if the document has not been commited yet
Integer cnt = pset.get( id.toString() );
if( cnt != null cnt 0 ) {
commit( new CommitUpdateCommand(false) );
}
if( committedSearcher == null ) {
committedSearcher = core.newSearcher(DirectUpdateHandler2.committed);
}
Term t = new Term( uniqueKey.getName(), uniqueKey.getType().toInternal(
id.toString() ) );
int docID = committedSearcher.getFirstMatch( t );
if( docID = 0 ) {
Document luceneDoc = committedSearcher.doc( docID );
// set the new doc as the existingDoc + our changes
DocumentBuilder builder = new DocumentBuilder( schema );
add.doc = builder.bulid(
this.modifyDocument( luceneDoc, cmd.doc, cmd.mode ) );
}
- - - - - - -
This passes a new test that adds the same doc multiple times. BUT it does
commit each time.
Another alternative would be to keep a MapString,Document of the pending
documents in memory. Then we would not have to commit each time something has
changed.
Support updateable/modifiable documents
---
Key: SOLR-139
URL: https://issues.apache.org/jira/browse/SOLR-139
Project: Solr
Issue Type: Improvement
Components: update
Reporter: Ryan McKinley
Attachments: SOLR-139-IndexDocumentCommand.patch,
SOLR-139-IndexDocumentCommand.patch, SOLR-139-XmlUpdater.patch
It would be nice to be able to update some fields on a document without
having to insert the entire document.
Given the way lucene is structured, (for now) one can only modify stored
fields.
While we are at it, we can support incrementing an existing value - I think
this only makes sense for numbers.
for background, see:
http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470082 ] Ryan McKinley commented on SOLR-139: That wouldn't work for multi-valued fields though, right? 'REMOVE' on a mult-valued field would clear the old fields before adding the new ones. It is essentially the same as OVERWRITE, but you may or may not pass in a new value on top of the old one. If we keep this option, perhaps we should find a better name... how about 'IGNORE' or 'CLEAR' It is awkward because it refers to what was in in the document before, not what you are passing in. The more i think about it, I think we should drop the 'REMOVE' option. You can get the same effect using 'OVERWRITE' and passing in a null value. Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Attachments: SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-XmlUpdater.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SOLR-1.1 Performance Tuning
Hello, Can I send COMMIT and OPTIMIZE concurrently to ADD/DELETE? I temporary send it via synchronized method call. About 100 adds/deletes per second, commit each 1000 adds/deletes, and optimize each 1. Thanks, Fuad
Float Values shown as 1.2E7
Hello, http://www.tokenizer.org shows price (in CAD$) 1.2E7 instead of 1199.99 (that is real!) I use sfloat for a price field... If you see different page, click 'refresh' F5; HTTP Caching... Thanks, Fuad
Re: SOLR-1.1 Performance Tuning
On 2/4/07, Fuad Efendi [EMAIL PROTECTED] wrote: Hello, Can I send COMMIT and OPTIMIZE concurrently to ADD/DELETE? Yes, but adds will block while a commit or optimize is in progress. I temporary send it via synchronized method call. About 100 adds/deletes per second, commit each 1000 adds/deletes, and optimize each 1. You don't need to commit that often really, and you don't need to optimize until you are all done (assuming an index build and not incremental updating). -Yonik
Re: Float Values shown as 1.2E7
On 2/4/07, Fuad Efendi [EMAIL PROTECTED] wrote: Hello, http://www.tokenizer.org shows price (in CAD$) 1.2E7 instead of 1199.99 (that is real!) I use sfloat for a price field... An IEEE float only has 24 mantissa bits (7 decimal digits) of precision. 24*log(2)/log(10) = 7.22 Try an sdouble if you need exact prices that large. -Yonik
RE: Float Values shown as 1.2E7
Try an sdouble if you need exact prices that large. Thanks, Will it broke my indexes if I modify schema.xml and restart Tomcat?
Re: Float Values shown as 1.2E7
On 2/4/07, Fuad Efendi [EMAIL PROTECTED] wrote: Try an sdouble if you need exact prices that large. Thanks, Will it broke my indexes if I modify schema.xml and restart Tomcat? Yes, float isn't compatible with double since they are essentially stored in a modified IEEE format. You will need to re-index. -Yonik
Re: finer granularity of configuration
On 2/3/07, Erik Hatcher [EMAIL PROTECTED] wrote:
I'd like to be able to have a common schema.xml and solrconfig.xml
but be able to fire up Solr instances pointed to different data
directories. I realize we have SOLR-79 in JIRA. Is that the
approach we want long term?
Here's an off-the-cuff idea... what if we hook Config.get() to look
for system properties that would override configuration values.
SolrCore does this:
dataDir = SolrConfig.config.get(dataDir,Config.getInstanceDir()
+data);
If it looked for a system property (perhaps with a solr. prefix)
you could override anything Config serves up. Thoughts?
Seems like a good idea... and as long as the env vars don't clash,
this doesn't conflict with SOLR-79.
Perhaps the full path with a leading solr.
So -Dsolr.config.dataDir=/path
Speaking of which, is this incorrect in SolrCore.java?
public String getDataDir() { return index_path; } // shouldn't
this return dataDir?
public String getIndexDir() { return index_path; }
Fixed. getDataDir() wasn't used anywhere outside SolrCore, and I
changed uses of getDataDir to getIndexDir.
-Yonik
[jira] Commented: (SOLR-113) Some example + post.sh in docs in client/solrb
[ https://issues.apache.org/jira/browse/SOLR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470093 ] Antonio Eggberg commented on SOLR-113: -- Erik: Cool features you added this weekend. We can close this issue as you have already added sample data i.e. delicious examples under example dir. (probably we should add a line in the README file i.e how to load the sample data) .. Very cool work.. I like the new flare logo :-) .. I am just curious what else do you have in mind for next weekend? :-) or for flare .. Regards. Some example + post.sh in docs in client/solrb -- Key: SOLR-113 URL: https://issues.apache.org/jira/browse/SOLR-113 Project: Solr Issue Type: Wish Components: clients - ruby - flare Environment: OSX 10.4 Reporter: Antonio Eggberg Priority: Trivial I tried flare today really nice :=) It would be nice to add some example docs like current Solr distro for the Ruby/Flare client.. If I understand correctly the exampledocs in Solr i.e /example/exampledocs is not compatible with solrb.. Maybe I am doing something wrong? if so please clarify and delete the issue. The issue is not so important but good for the folks that are impetiant. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AutoCommitTest failing
On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote: With the latest changes to AutoCommitTest, now I'm getting failures: [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 5.593 sec [junit] Test org.apache.solr.update.AutoCommitTest FAILED Stack trace: INFO: Opening [EMAIL PROTECTED] main Feb 4, 2007 5:19:41 PM org.apache.solr.core.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:486) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:514) at org.apache.solr.update.DirectUpdateHandler2$CommitTracker.run(DirectUpdateHandler2.java:625) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -Yonik
Re: AutoCommitTest failing
On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote: is this on your machine or on the apache machine? I have never had a problem running on my machine. My local machine happens every time now. I think Erik said it was failing for him also. -Yonik
Re: AutoCommitTest failing
Can you tell specifically what part triggers the bad behavior? or is it whenever autocommit gets triggered? I wish I could be more useful, but from my system (win XP, jdk1.5.0_07) things look ok... On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote: On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote: is this on your machine or on the apache machine? I have never had a problem running on my machine. My local machine happens every time now. I think Erik said it was failing for him also. -Yonik
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470109 ] Ryan McKinley commented on SOLR-139: I added a new version of SOLR-139-IndexDocumentCommand.patch that: * gets rid of 'REMOVE' option * uses a separate searcher to search for existing docs * includes the XmlUpdateRequestHandler * moves general code from XmlUpdateRequestHandler to SolrPluginUtils * adds a few more tests Can someone with a better lucene understanding look into re-useint the existing searcher as Yonik suggests above - I don't quite understand the other DUH2 implications. I moved the part that parses (and validates) field mode parsing into SolrPluginUtils. This could be used by other RequestHandlers to parse the mode map. The XmlUpdateRequestHandler in this patch should support all legacy calls *except* cases where overwritePending != overwriteCommitted. There are no existing tests with this case, so it is not a problem from the testing standpoint. I don't know if anyone is using this (mis?) feature. Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: Improvement Components: update Reporter: Ryan McKinley Attachments: SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-XmlUpdater.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-60) Remove overwritePending, overwriteCommitted flags?
[ https://issues.apache.org/jira/browse/SOLR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470110 ] Ryan McKinley commented on SOLR-60: --- As a note, there are no tests where overwritePending != overwriteCommitted In SOLR-139, the XmlUpdateRequestHandler maps all varitions of allowDups, overwriteCommitted and overwritePending to a simpler 'overwrite' -- it throws an exception if overwritePending != overwriteCommitted. Remove overwritePending, overwriteCommitted flags? -- Key: SOLR-60 URL: https://issues.apache.org/jira/browse/SOLR-60 Project: Solr Issue Type: Improvement Components: update Reporter: Yonik Seeley Priority: Minor The overwritePending, overwriteCommitted, allowDups flags seem needlessly complex and don't add much value. Do people need/use separate control over pending vs committed documents? Perhaps all most people need is overwrite=true/false? overwritePending, overwriteCommitted were originally added because it was a (mis)feature that another internal search tool had. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AutoCommitTest failing
still trying (in vain) to make this fail on my setup... The one line that looks suspicious from your stack trace is: WARNING: best effort to remove C:\DOCUME~1\Yonik\LOCALS~1\Temp\org.apache.solr.update.AutoCommitTest-testMaxDocs-1170627577515 FAILED ! can you delete the directory where solr stores the testing index manually?
Re: AutoCommitTest failing
On Feb 4, 2007, at 8:34 PM, Yonik Seeley wrote: On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote: is this on your machine or on the apache machine? I have never had a problem running on my machine. My local machine happens every time now. I think Erik said it was failing for him also. Currently all is well (svn revision 503532): BUILD SUCCESSFUL Total time: 1 minute 16 seconds I ran it twice for good measure, and passed both times. Erik
Re: AutoCommitTest failing
On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote: OK, the wildcard seems to be norton antivirus. Antivirus on: BUILD FAILED Total time: 2 minutes 22 seconds Antivirus off: BUILD SUCCESSFUL Total time: 1 minute 24 seconds Not yet sure why that would make the difference... and only on this test. Ah wait.. it still is timing/performance related. With NAV disabled, and one other shell doing while true; do true; done, the test succeeds in 2m2s, but with two shells doing it, the test fails in 9m1s So I guess my antivirus is slowing my 3GHz P4 down enough to fail. It probably has more to do with the disk access checking than the CPU. [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 10.687 sec [junit] Test org.apache.solr.update.AutoCommitTest FAILED ?xml version=1.0 encoding=UTF-8 ? testsuite errors=0 failures=2 name=org.apache.solr.update.AutoCommitTest tests=2 time=10.687 properties property name=java.vendor value=Sun Microsystems Inc./property property name=sun.management.compiler value=HotSpot Client Compiler/property property name=dist value=dist/property property name=lib value=lib/property property name=os.name value=Windows XP/property property name=sun.boot.class.path value=C:\opt\jdk15\jre\lib\rt.jar;C:\opt\jdk15\jre\lib\i18n.jar;C:\opt\jdk15\jre\lib\sunrsasign.jar;C:\opt\jdk15\jre\lib\jsse.jar;C:\opt\jdk15\jre\lib\jce.jar;C:\opt\jdk15\jre\lib\charsets.jar;C:\opt\jdk15\jre\classes/property property name=fullnamever value=apache-solr-1.2-dev/property property name=TODAY value=February 4 2007/property property name=sun.desktop value=windows/property property name=java.vm.specification.vendor value=Sun Microsystems Inc./property property name=ant.home value=c:/opt/java/ant/property property name=java.runtime.version value=1.5.0_09-b01/property property name=user.name value=Yonik/property property name=dest value=build/property property name=user.language value=en/property property name=build.javadoc value=build/docs/api/property property name=sun.boot.library.path value=C:\opt\jdk15\jre\bin/property property name=ant.project.name value=solr/property property name=DSTAMP value=2007-02-04/property property name=java.version value=1.5.0_09/property property name=version value=1.2-dev/property property name=user.timezone value=/property property name=sun.arch.data.model value=32/property property name=java.endorsed.dirs value=C:\opt\jdk15\jre\lib\endorsed/property property name=sun.cpu.isalist value=/property property name=sun.jnu.encoding value=Cp1252/property property name=file.encoding.pkg value=sun.io/property property name=file.separator value=\/property property name=java.specification.name value=Java Platform API Specification/property property name=javadoc.packages value=org.apache.solr.*/property property name=java.class.version value=49.0/property property name=src value=src/property property name=user.country value=US/property property name=java.home value=C:\opt\jdk15\jre/property property name=java.vm.info value=mixed mode/property property name=ant.file value=c:\tmp555\solr\build.xml/property property name=os.version value=5.1/property property name=javadoc.access value=protected/property property name=path.separator value=;/property property name=specversion value=1.1.2007.02.04.23.20.45/property property name=java.vm.version value=1.5.0_09-b01/property property name=java.compat.version value=1.5/property property name=user.variant value=/property property name=ant.library.dir value=c:/opt/java/ant/lib/property property name=junit.output.dir value=C:\tmp555\solr\build\test-results/property property name=java.awt.printerjob value=sun.awt.windows.WPrinterJob/property property name=sun.io.unicode.encoding value=UnicodeLittle/property property name=awt.toolkit value=sun.awt.windows.WToolkit/property property name=javadoc.link.lucene value=http://lucene.apache.org/java/docs/api/;/property property name=user.home value=C:\Documents and Settings\Yonik/property property name=ant.file.solr value=C:\tmp555\solr\build.xml/property property name=java.specification.vendor value=Sun Microsystems Inc./property property name=java.library.path value=C:\opt\jdk15\jre\bin;.;C:\WINDOWS\system32;C:\WINDOWS;c:\opt\vcpp\bin;c:\opt\jdk15\bin;C:\cygwin\usr\local\bin;C:\cygwin\bin;C:\cygwin\bin;C:\cygwin\usr\X11R6\bin;c:\opt\ruby\bin;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;c:\bin;c:\opt\python;c:\opt\vim\vim63;c:\Program Files\ATI Technologies\ATI Control Panel;c:\Program Files\QuickTime\QTSystem\;c:\opt\mysql\bin;c:\opt\java\ant\bin;c:\opt\ruby\bin;c:\opt\maven\bin/property property name=java.vendor.url value=http://java.sun.com/;/property property name=checksum.algorithm value=md5/property property name=java.vm.vendor value=Sun Microsystems Inc./property property name=java.runtime.name value=Java(TM) 2
Re: AutoCommitTest failing
hymmm. what do you think the best option is? Should we increase the time it waits to check if stuff autocommited? It currently waits 1 second for something that *should* start an autocommit within 1/2 sec. Is the RejectedExecutionException only thrown because JUnit failed? or is this an exception that would be thrown in the wild?
[jira] Created: (SOLR-141) Errors/Exceptions should be formated by ResponseWriter
Errors/Exceptions should be formated by ResponseWriter -- Key: SOLR-141 URL: https://issues.apache.org/jira/browse/SOLR-141 Project: Solr Issue Type: Wish Reporter: Hoss Man Whenever possible, the Solr Dispatcher should to let the ResponseWriter format Exceptions using the format the user expects -- this should in no way change the fact that Exceptions currently generate non 200 HTTP status codes, nor should it prevent the Dispatcher from using the exception message as the HTTP status message -- but clients that want the full details of the error should be able to parse them in the format they expected based on the request. this would also give RequestHandlers the oportunity to return partial results - by adding both whatever results they have to the Response as well as the Exception they encountered. situations where this can't happen are obviously: * Exception thrown by ResponseWriter * Exception thrown so early in the request thta the DIspather doesn't know which ResposneWriter the client wanted. ...in those cases, plain text is a wise choice. thing that would probably need to be done to make this work: 1) if the Dispatcher catches an exception, it should call SolrQueryResponse.setException, set the HTTP status code/message as it currently does, but then hand off to the ResponseWriter. 2) Dispatcher needs to check SolrQueryResponse.getException and set the HTTP status code/message just like if it caught the exception itself. 3) all of the ResponseWriters should start looking at SolrQueryResponse.getException if they aren't already, and formatting it in a usefull way. 4) if the ResponseWriter throws an exception, Dispatcher needs to return a nice plain text error page extension to this idea... add a new method to ResponseWriter to generate a generic error message in the appropriate format that Dispatcher can use if the ResponseWriter throws an exception (as a backup before resorting to plain text) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
