Re: solr release planning for 1.2
Me t.. :-) Just too add my two cents :-) I would rather see a 3 mos release cycle then mega big releases.. cos often times bugs i found were in customer site and manging customers wish... and most customer don't want to run nightly build on production. This is the case in enterprise segment. So I would love to see a regular cycle of release from solr. Off course this shouldn't create too much of a overhead so its takes the fun out of doing a release. I would love to see SOLR-20 but as I remember this is not ready yet. Cheers On 4/3/07, Ryan McKinley [EMAIL PROTECTED] wrote: I want it all!!! If you are thinking within the next week or two, I vote we focus on consistent response format and better error handling. I would suggest that rather then map /update to SolrUpdateServlet, it should use the new update handler framework - returning non 200 response for errors. I would also vote for something like SOLR-179, but i have not heard much feedback from others on that. If the timespan were longer, I would want to get in modifying/updating documents - but that still has a lot of design choices that we should all feel confident about. The other minor things I would like to see soon (but should not affect release) are SOLR-184 and SOLR-176 ryan On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: While it doesn't particularly feel like a natural place to have a release now, it has been 3.5 months since release 1.1, and that was while we were still in the incubator. More frequent releases allows users access to new features in a timely manner without using a nightly build, and thus allows developers more flexibility to change things between releases. So what features / issues do people think we need to resolve before we make a 1.2 release? -Yonik
Re: Replication with IP multicast/broadcast?
On 4/4/07, HUYLEBROECK Jeremy RD-ILAB-SSF [EMAIL PROTECTED] wrote: ...Has anybody thought about using IP multicast to replicate the master to the slaves and then avoid multiple rsync. The replication could happen right away as soon as a add/delete/update happens on the master If you need that, I'd rather go for something like a JMS bus to replicate indexing operations, instead of reinventing something similar. But making it transactional would be hard IMHO, and if it's not transactional the benefits compared to frequent rsyncs are not that big (again IMHO, it depends on your application of course). -Bertrand
Re: solr release planning for 1.2
On 4/3/07, Yonik Seeley [EMAIL PROTECTED] wrote: ...So what features / issues do people think we need to resolve before we make a 1.2 release?... I agree that having a non-incubator release would be good, and as long as it's stable I don't care too much about exactly what new features are in it (also because I have little time for helping ATM). -Bertrand
[jira] Assigned: (SOLR-184) add echoHandler=true to responseHeader, support echoParams=all
[ https://issues.apache.org/jira/browse/SOLR-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher reassigned SOLR-184: - Assignee: Erik Hatcher add echoHandler=true to responseHeader, support echoParams=all -- Key: SOLR-184 URL: https://issues.apache.org/jira/browse/SOLR-184 Project: Solr Issue Type: Wish Affects Versions: 1.2 Reporter: Ryan McKinley Assigned To: Erik Hatcher Priority: Trivial Fix For: 1.2 Attachments: SOLR-184-EchoHandler.patch, SOLR-184-EchoHandler.patch, SOLR-184-EchoHandler.patch optionally return what handler was used in the response header. This patch also extends echoParams so that it supports 'all' and 'none' It makes a small API change to the protected SolrCore.setResponseHeaderValues() -- it now passes in the handler that was used. Some URLs to check (but remember that the /debug/dump handler prints out its own 'params') http://localhost:8983/solr/debug/dump http://localhost:8983/solr/debug/dump?echoParams=allparam1=A http://localhost:8983/solr/debug/dump?echoParams=explicitparam1=A http://localhost:8983/solr/debug/dump?echoParams=falseparam1=A to keep things reasonable, i'm mapping: echoParams=true explicit echoParams=false none -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
