[jira] Updated: (SOLR-807) UUIDField type cannot be recognized when wt=javabin is used
[
https://issues.apache.org/jira/browse/SOLR-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-807:
---
Attachment: SOLR-807.patch
Updated with a test to verify the encoding/decoding of UUID with the changes to
BinaryResponseWriter. All tests pass.
With this change, we make a lookup on a HashSet for each field to be written
out. Someone who knows more about the javabin format should take a look. Yonik
or Noble?
UUIDField type cannot be recognized when wt=javabin is used
---
Key: SOLR-807
URL: https://issues.apache.org/jira/browse/SOLR-807
Project: Solr
Issue Type: Bug
Components: clients - java, search
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.3.1
Attachments: SOLR-807.patch, SOLR-807.patch, SOLR-807.patch,
SOLR-807.patch
I'm using UUID via Solrj in my project. When I use javabin (default), I got:
*java.util.UUID:* 391e3214-4f8e-4abd-aa6b-4f12be79534f
as the uuid value. But if I use xml, I got:
391e3214-4f8e-4abd-aa6b-4f12be79534f
I think the both of them should return same string.
program for reproducing the problem:
{code:java}
public static void main(String[] args) throws Exception {
CommonsHttpSolrServer server = new CommonsHttpSolrServer(
http://localhost:8983/solr; );
SolrQuery query = new SolrQuery().setQuery( *:* );
//server.setParser( new XMLResponseParser() ); // uncomment for wt=xml
System.out.println( = +
server.getParser().getClass().getSimpleName() + = );
QueryResponse rsp = server.query( query );
SolrDocumentList docs = rsp.getResults();
for( SolrDocument doc : docs ){
Object id = doc.getFieldValue( id );
System.out.println( type = + id.getClass().getName() + , id = +
id );
Object timestamp = doc.getFieldValue( timestamp );
System.out.println( type = + timestamp.getClass().getName() + ,
timestamp = + timestamp );
}
}
{code}
result for wt=javabin
{code:title=javabin}
= BinaryResponseParser =
type = java.lang.String, id =
java.util.UUID:391e3214-4f8e-4abd-aa6b-4f12be79534f
type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
{code}
result for wt=xml
{code:title=xml}
= XMLResponseParser =
type = java.lang.String, id = 391e3214-4f8e-4abd-aa6b-4f12be79534f
type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: remove solr-common-1.4-SNAPSHOT from maven repos
done. On Dec 9, 2008, at 11:08 PM, Ryan McKinley wrote: Since SOLR-900, 'common' is bundled with 'solrj', we should remove the stale snapshot from the apache snapshot repos. Grant, it looks like you need to remove the file: /x1/www/people.apache.org/repo/m2-snapshot-repository/org/apache/ solr/solr-common/1.4-SNAPSHOT thanks! ryan
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván de Prado updated SOLR-236: --- Attachment: collapsing-patch-to-1.3.0-ivan_2.patch A new patch with problems solved in my first submitted patch. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.4 Attachments: collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- 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-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655269#action_12655269 ] ivan.prado edited comment on SOLR-236 at 12/10/08 8:34 AM: -- I have attached new patch with the problems solved in my first submitted patch. Doug Steigerwald, could you check if this patch works with for you? Thanks. was (Author: ivan.prado): A new patch with problems solved in my first submitted patch. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.4 Attachments: collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- 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-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655269#action_12655269 ] ivan.prado edited comment on SOLR-236 at 12/10/08 8:35 AM: -- I have attached new patch with the problems solved in my first submitted patch. Doug Steigerwald, could you check if this patch works well for you? Thanks. was (Author: ivan.prado): I have attached new patch with the problems solved in my first submitted patch. Doug Steigerwald, could you check if this patch works with for you? Thanks. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.4 Attachments: collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655285#action_12655285 ] Doug Steigerwald commented on SOLR-236: --- Looks fine from my little bit of testing. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.4 Attachments: collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-904) explose the pending ListSolrInputDocument and the ListString of ids to delete in the solrj UpdateRequest
[ https://issues.apache.org/jira/browse/SOLR-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-904. Resolution: Fixed explose the pending ListSolrInputDocument and the ListString of ids to delete in the solrj UpdateRequest Key: SOLR-904 URL: https://issues.apache.org/jira/browse/SOLR-904 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Trivial Fix For: 1.4 Attachments: SOLR-904-solrj-pending-docs.patch Clients who want to buffer documents as they go into solr need access to the pending SolrInputDocuments -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-906) Buffered / Streaming SolrServer implementaion
Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[
https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655298#action_12655298
]
Ryan McKinley commented on SOLR-906:
One basic problem with calling add( SolrInputDocument) with the
CommonsHttpSolrServer is that it logs a request for each document. This can be
a substantial impact. For example while indexing 40K docs on my machine, it
takes ~3 1/2 mins. If I turn logging off the time drops to ! 2 1/2 mins. With
the streaming approach, the time drops to 20sec! Some of that is obviously
because it limits the logging:
{code}
INFO: {add=[id1,id2,id3,id4, ...(38293 more)]} 0 20714
{code}
Buffered / Streaming SolrServer implementaion
-
Key: SOLR-906
URL: https://issues.apache.org/jira/browse/SOLR-906
Project: Solr
Issue Type: New Feature
Components: clients - java
Reporter: Ryan McKinley
Fix For: 1.4
While indexing lots of documents, the CommonsHttpSolrServer add(
SolrInputDocument ) is less then optimal. This makes a new request for each
document.
With a StreamingHttpSolrServer, documents are buffered and then written to
a single open Http connection.
For related discussion see:
http://www.nabble.com/solr-performance-tt9055437.html#a20833680
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-906: --- Attachment: StreamingHttpSolrServer.java This implementation buffers documents in a BlockingQueueSolrInputDocument when a document is added, it makes sure a Thread is working on sending the queue to solr. While this implementation only starts one thread, it would be easy to extent this so that multiple threads are writing to solr simultaneously and draining the same Queue. Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655302#action_12655302 ] Ryan McKinley commented on SOLR-906: The error handling behavior is less then ideal (as it is for add with multiple documents already) As is, it will break the connection when an error occures, but will not know which one. However, it will continue indexing the Queue when an error occures. Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: remove solr-common-1.4-SNAPSHOT from maven repos
But does solr-core have a dependency to solr-common still? Try clearing your local repository and rebuilding. I get an error... Path to dependency: 1) com.name.removed:jar:0.0.5-SNAPSHOT 2) org.apache.solr:solr-core:jar:1.4-SNAPSHOT 3) org.apache.solr:solr-common:jar:1.4-SNAPSHOT Grant Ingersoll-6 wrote: done. On Dec 9, 2008, at 11:08 PM, Ryan McKinley wrote: Since SOLR-900, 'common' is bundled with 'solrj', we should remove the stale snapshot from the apache snapshot repos. Grant, it looks like you need to remove the file: /x1/www/people.apache.org/repo/m2-snapshot-repository/org/apache/ solr/solr-common/1.4-SNAPSHOT thanks! ryan -- View this message in context: http://www.nabble.com/remove-solr-common-1.4-SNAPSHOT-from-maven-repos-tp20928822p20941870.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: remove solr-common-1.4-SNAPSHOT from maven repos
fixed in trunk. http://svn.apache.org/viewvc?rev=725397view=rev but it will be another day until that gets out to the repository, so you may have to build your own for now... since SOLR-900, solr-core does not have a dependency on common, our problem is that the pom.xml files are not used to build artifacts, so their state is not necessarily correct. ryan On Dec 10, 2008, at 2:02 PM, jayson.minard wrote: But does solr-core have a dependency to solr-common still? Try clearing your local repository and rebuilding. I get an error... Path to dependency: 1) com.name.removed:jar:0.0.5-SNAPSHOT 2) org.apache.solr:solr-core:jar:1.4-SNAPSHOT 3) org.apache.solr:solr-common:jar:1.4-SNAPSHOT Grant Ingersoll-6 wrote: done. On Dec 9, 2008, at 11:08 PM, Ryan McKinley wrote: Since SOLR-900, 'common' is bundled with 'solrj', we should remove the stale snapshot from the apache snapshot repos. Grant, it looks like you need to remove the file: /x1/www/people.apache.org/repo/m2-snapshot-repository/org/apache/ solr/solr-common/1.4-SNAPSHOT thanks! ryan -- View this message in context: http://www.nabble.com/remove-solr-common-1.4-SNAPSHOT-from-maven-repos-tp20928822p20941870.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: logo contest
On 8-Dec-08, at 10:47 AM, Mike Klaas wrote: On 7-Dec-08, at 7:40 PM, Chris Hostetter wrote: : I would personally prefer more of an elimination-style vote (i.e., STV). Ah... yeah, that seems like it would be a more fair way to deal with things then my suggestion, and it doesn't violate the spirt of the rules as original outlined (it's still a vote of ranked preferences). Are you volunteering to do the vote counting Mike? Sure thing. I take it that there are no objections? If so, I'll call a vote by the end of the week. cheers, -Mike
Re: logo contest
On Wed, Dec 10, 2008 at 3:30 PM, Mike Klaas [EMAIL PROTECTED] wrote: On 8-Dec-08, at 10:47 AM, Mike Klaas wrote: On 7-Dec-08, at 7:40 PM, Chris Hostetter wrote: : I would personally prefer more of an elimination-style vote (i.e., STV). Ah... yeah, that seems like it would be a more fair way to deal with things then my suggestion, and it doesn't violate the spirt of the rules as original outlined (it's still a vote of ranked preferences). Are you volunteering to do the vote counting Mike? Sure thing. I take it that there are no objections? If so, I'll call a vote by the end of the week. +1 I just wish we had used this method with the community vote. I guess as a committer I should try and figure out what order the community would have voted and do that. -Yonik
1.4 Planning
I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant
[jira] Updated: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-906: --- Attachment: SOLR-906-StreamingHttpSolrServer.patch Here is an updated version that lets you specify how many threads should work on emptying the Queue. It also adds tests to make sure it passes all the same tests that CommonsHttpSolrServer and EmbeddedSolrServer already pass. That is, it is a drop in replacement and passes all existing tests. One big change is that calling commit or optimize with waitSearcher=true: 1. blocks adding new docs to the Queue 2. waits for the Queue to empty (send all docs) 3. waits for commit waitSearcher=true / to return 4. unblocks everything 5. finally continues execution. My threading chops are not great, so I may be doing something really strange. It would be good to get some more eyes on this! Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: SOLR-906-StreamingHttpSolrServer.patch, StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655363#action_12655363 ] Ryan McKinley commented on SOLR-906: also, using the recent patch with a Queue size = 20 and thread count=3 (on a dual core machine), the indexing time dropped from 30 secs - 20 secs. In sum: with the data I am working with, switch from CommonsHttpSolrServer = StreamingHttpSolrServer changes the index time from 3.5 min = 20 sec, or ~10x faster Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: SOLR-906-StreamingHttpSolrServer.patch, StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.4 Planning
sounds good. is lucene planning a release anytime soon? If so, is it worth *trying* to coordinate? On Dec 10, 2008, at 3:49 PM, Grant Ingersoll wrote: I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant
Re: logo contest
On Dec 10, 2008, at 3:41 PM, Yonik Seeley wrote: On Wed, Dec 10, 2008 at 3:30 PM, Mike Klaas [EMAIL PROTECTED] wrote: On 8-Dec-08, at 10:47 AM, Mike Klaas wrote: On 7-Dec-08, at 7:40 PM, Chris Hostetter wrote: : I would personally prefer more of an elimination-style vote (i.e., STV). Ah... yeah, that seems like it would be a more fair way to deal with things then my suggestion, and it doesn't violate the spirt of the rules as original outlined (it's still a vote of ranked preferences). Are you volunteering to do the vote counting Mike? Sure thing. I take it that there are no objections? If so, I'll call a vote by the end of the week. +1 I just wish we had used this method with the community vote. I guess as a committer I should try and figure out what order the community would have voted and do that. Yes -- I am only comfortable with a 'committer only' vote if it is clear we are all operating to figure out what the first community vote intended -- not to select our own preferences. (unless it is an explicit veto) ryan
Re: logo contest
On 10-Dec-08, at 12:41 PM, Yonik Seeley wrote: Sure thing. I take it that there are no objections? If so, I'll call a vote by the end of the week. +1 I just wish we had used this method with the community vote. I guess as a committer I should try and figure out what order the community would have voted and do that. I could run the results of the community vote interpreted as STV, if that would help (it'll be a few days, though). -Mike
RE: 1.4 Planning
One of the things about the 1.3 release that I didn't care for, was the inclusion of a non-release version of Lucene. It was very difficult to track down the source code for the dev version that was used. Once Lucene had release its official version, I upgraded to that (which went well) so that I had access to Lucene source. If Lucene is going to release relatively soon, a release after that might be nice. For what it's worth, I understand the difficulty of having 2 projects running in parallel with the dependency between them. While trying to improve both at the same time. I'm not trying to throw stones, just sharing an opinion. -Todd Feak -Original Message- From: Ryan McKinley [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 1:20 PM To: solr-dev@lucene.apache.org Subject: Re: 1.4 Planning sounds good. is lucene planning a release anytime soon? If so, is it worth *trying* to coordinate? On Dec 10, 2008, at 3:49 PM, Grant Ingersoll wrote: I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemod e=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=1231023 0fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant
[jira] Commented: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value
[ https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655394#action_12655394 ] Todd Feak commented on SOLR-899: For our use, I will be subclassing the SolrInputDocument class and putting null checks there. This avoids having to maintain a different version of this library. My question is this, is putting the same null checks into the SolrInputDocument class itself a valuable solution? If so, I can create a patch and submit it here. Looking for feedback from the devs on whether or not this is a desirable solution. NullPointerException in ClientUtils.writeXML on NULL field value Key: SOLR-899 URL: https://issues.apache.org/jira/browse/SOLR-899 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Reporter: Todd Feak Priority: Trivial This exception occurs if I have a field in a document with a null value. java.lang.NullPointerException at org.apache.solr.client.solrj.util.ClientUtils.writeXML(ClientUtils.java:117) at org.apache.solr.client.solrj.request.UpdateRequest.getXML(UpdateRequest.java:169) at org.apache.solr.client.solrj.request.UpdateRequest.getContentStreams(UpdateRequest.java:160) ... Previous versions of this class had a null check, which was subsequently removed. I have no problem with removing the previous null-check, as it seemed to hide a programming mistake (i.e. null values). However, I think that the exception that occurs here could at least be a bit more informative. Performing a null check and then throwing some sort of RuntimeException or IOException with a descriptive message would be very helpful. Such as Failure, NULL value for field named[foo] detected. Alternatively, I think that an argument could be made that this NULL shouldn't have been allowed in the document in the first place. If that is the case, then NULL checks with similarly helpful messages could be performed upstream of this issue. I personally lean this way, as I prefer to find a programming mistake closer to the source of the issue. It allows me to find out exactly where the NULL was inserted in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.4 Planning
I agree if it is close to a release we should try to synchronize. Since i don't live in an environment where official release is important, it has never felt like a big deal. Also if you are cracking into the lucene source, it seems like you are beyond that too... The lucene version should be well documented in CHANGS.txt, but we could do more to make it easier. Perhaps add maven source artifacts? I'm not sure this would even work, but is it possible for us to add an svn link to the lucene version we are currently depending on? svn:externals or something like that? ryan On Dec 10, 2008, at 5:28 PM, Feak, Todd wrote: One of the things about the 1.3 release that I didn't care for, was the inclusion of a non-release version of Lucene. It was very difficult to track down the source code for the dev version that was used. Once Lucene had release its official version, I upgraded to that (which went well) so that I had access to Lucene source. If Lucene is going to release relatively soon, a release after that might be nice. For what it's worth, I understand the difficulty of having 2 projects running in parallel with the dependency between them. While trying to improve both at the same time. I'm not trying to throw stones, just sharing an opinion. -Todd Feak -Original Message- From: Ryan McKinley [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 1:20 PM To: solr-dev@lucene.apache.org Subject: Re: 1.4 Planning sounds good. is lucene planning a release anytime soon? If so, is it worth *trying* to coordinate? On Dec 10, 2008, at 3:49 PM, Grant Ingersoll wrote: I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemod e=hidesorter/order=DESCsorter/ field=priorityresolution=-1pid=1231023 0fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant
Re: putting UnInvertedField instances in a SolrCache?
: - might want a way to dynamically add caches.. but for now adding a : magic facetCache that exists even when not on solrconfig.xml is prob : easiest (the current solr caches do not get instantiated if they are : not in solrconfig.xml - they are seen as optional). thinking about it more -- keeping the same behavior as filterCache isn't really a bad idea, it would certianly obey the law of least suprise for users who are upgrading: if a facetCache doesn't exist, default to the old enum behavior. (however: facetCache doesn't exist but facet.method=fc then an error pointing outhte facetCache needs to be defined seems appropriate) -Hoss
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655427#action_12655427 ] Ian Holsman commented on SOLR-906: -- how much of the 3.5minutes - 30seconds is due to the logging? would it be simpler to change the log message to 'DEBUG' instead of 'INFO' and see how the performance of the regular commons server behaves then? Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: SOLR-906-StreamingHttpSolrServer.patch, StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: logo contest
I added some more math to the script I used to generate the results
page... and what do you know: no official winner by any of the
methods! (assuming my math is correct)
check:
http://people.apache.org/~ryan/solr-logo-results.html
for a variety of attempts.
The problem with the STV method is that it continues until you meed a
quota: (votes/seats+1)+1, in our case (19/2)+1=10. Nothing ever gets
to 10, so you will notice that stv==votes for everything!
So the next option is to try instant runoff voting:
http://en.wikipedia.org/wiki/Instant-runoff_voting
in that method, the losers of each round is tossed out and the vote
continues until there is a majority. Again, we never reach a
majority, but the last two logos to lose are:
eliminating (4)
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg
eliminating (4)
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
Other things to perhaps consider. Using the scoring method,
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
is the winner.
The STV or vote counting method puts
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg
or
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_b_red.jpg
at the top.
If we only count the first round of voting
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
wins followed by:
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_b_red.jpg
There you go. clear as mud!
As I see it, we either call a new community poll -- nothing in the
rules says we can't. or vote on:
1.
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
last eliminated by instant runoff and it won the 'soring' method
2.
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg
last eliminated by instant runoff and *may* have won if the other
similar logos were not involved.
ryan
here is the hacked up code if you are curious...
String[][] v = new String[][] {
{
https://issues.apache.org/jira/secure/attachment/12394267/apache_solr_c_blue.jpg
,
https://issues.apache.org/jira/secure/attachment/12394265/apache_solr_b_blue.jpg
,
https://issues.apache.org/jira/secure/attachment/12394263/apache_solr_a_blue.jpg
,
},
{
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
https://issues.apache.org/jira/secure/attachment/12394366/solr3_maho.png
,
https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg
,
https://issues.apache.org/jira/secure/attachment/12394266/apache_solr_b_red.jpg
,
https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png
,
},
{
https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png
,
https://issues.apache.org/jira/secure/attachment/12394376/solr_sp.png
,
https://issues.apache.org/jira/secure/attachment/12393951/sslogo-solr-classic.png
,
https://issues.apache.org/jira/secure/attachment/12391946/apache_solr_burning.png
,
https://issues.apache.org/jira/secure/attachment/12392306/apache_solr_sun.png
,
},
{
https://issues.apache.org/jira/secure/attachment/12394267/apache_solr_c_blue.jpg
,
https://issues.apache.org/jira/secure/attachment/12394268/apache_solr_c_red.jpg
,
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
https://issues.apache.org/jira/secure/attachment/12394366/solr3_maho.png
,
https://issues.apache.org/jira/secure/attachment/12393936/logo_remake.jpg
,
},
{
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
},
{
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
https://issues.apache.org/jira/secure/attachment/12394475/solr2_maho-vote.png
,
https://issues.apache.org/jira/secure/attachment/12394268/apache_solr_c_red.jpg
,
},
{
https://issues.apache.org/jira/secure/attachment/12394263/apache_solr_a_blue.jpg
,
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
},
{
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
https://issues.apache.org/jira/secure/attachment/12394266/apache_solr_b_red.jpg
,
},
{
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png
,
https://issues.apache.org/jira/secure/attachment/12394282/solr2_maho_impression.png
,
https://issues.apache.org/jira/secure/attachment/12394353/solr.s5.jpg
,
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655438#action_12655438 ] Ryan McKinley commented on SOLR-906: how much of the 3.5minutes - 30seconds is due to the logging? ~1 min. When I turn off logging completely, the time is ~2.5 mins (also, note that with 3 threads, it is down to 20sec) RE: calling add( doc ) vs add( Listdoc )... yes, things are much better if you call add( Listdoc ) however, it is not the most convenient api if you are running though tons of things. I would expect (but have not tried) adding 40K docs in one call to add( Listdoc ) would have the same time as this StreamingHttpSolrServer. It is probably also similar if you buffer 100? 1,000? at a time, but I have not tried. The StreamingHttpSolrServer essentially handles the buffering for you. It keeps an http connection open as long as the Queue has docs to send. It can start multiple threads and drain the same Queue simultaneously. Essentially, this just offers an easier interface to get the best possible performance. The trade off (for now) is that there is no good error reporting. Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: SOLR-906-StreamingHttpSolrServer.patch, StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-906) Buffered / Streaming SolrServer implementaion
[ https://issues.apache.org/jira/browse/SOLR-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655442#action_12655442 ] Ryan McKinley commented on SOLR-906: The other aspect no note is that StreamingHttpSolrServer sends the request in the background so after you call: add( doc ) or add( list ) that thread is free to keep working. With the off the shelf CommonsHttpSolrServer the client needs to wait for the server to parse the request and index the data before it can continue. This switches where the client gets blocked. * with CommonsHttpSolrServer it blocks while waiting for solr to *write the response* * with StreamingHttpSolrServer it blocks while waiting for solr to *read the request* Buffered / Streaming SolrServer implementaion - Key: SOLR-906 URL: https://issues.apache.org/jira/browse/SOLR-906 Project: Solr Issue Type: New Feature Components: clients - java Reporter: Ryan McKinley Fix For: 1.4 Attachments: SOLR-906-StreamingHttpSolrServer.patch, StreamingHttpSolrServer.java While indexing lots of documents, the CommonsHttpSolrServer add( SolrInputDocument ) is less then optimal. This makes a new request for each document. With a StreamingHttpSolrServer, documents are buffered and then written to a single open Http connection. For related discussion see: http://www.nabble.com/solr-performance-tt9055437.html#a20833680 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: logo contest
: There you go. clear as mud! : As I see it, we either call a new community poll -- nothing in the rules says : we can't. or vote on: FWIW: My opinion hasn't really changed since i said... committers should cast their votes as they feel appropriate to best serve the interests of the community -- it's not really different then voting on an implementation approach for a feature, or what logging framework to use, or a decisison to switch from java 1.5 to 1.6 ... we have to make a subjective decision based on the feedback we've observed from the community as a whole (with solr-logo-results.html serving as our cliff notes) ... i suggest we move forward with a straight STV/IRV based vote of committers (if anyone was going to VETO a submission i'm sure they would have done it by now) and let individual committers rank things the way they feel best represents the wishes of community. since we have to subjectively interpret the community vote, let's apply individual subjective interpretations and aggregate them (in line with the orriginal contest rules) instead of picking one arbitrary subjective interpretation and then voting +1. If we can't trust ourselves to represent the community fairly on picking a logo, we have no business committing any code. -Hoss
[VOTE] LOGO
This thread is for solr committers to list the top 4 logos preferences from the community logo contest. As a guide, we should look at: http://people.apache.org/~ryan/solr-logo-results.html The winner will be tabulated using instant runoff voting -- if this happens to result in a tie, the winner will be picked by the 'Single transferable vote' http://en.wikipedia.org/wiki/Instant-runoff_voting http://en.wikipedia.org/wiki/Single_transferable_vote To cast a valid vote, you *must* include 4 options. ryan
Re: [VOTE] LOGO
https://issues.apache.org/jira/secure/attachment/12394070/sslogo-solr-finder2.0.png https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg https://issues.apache.org/jira/secure/attachment/12394266/apache_solr_b_red.jpg https://issues.apache.org/jira/secure/attachment/12394165/solr-logo.png ryan On Dec 10, 2008, at 8:51 PM, Ryan McKinley wrote: This thread is for solr committers to list the top 4 logos preferences from the community logo contest. As a guide, we should look at: http://people.apache.org/~ryan/solr-logo-results.html The winner will be tabulated using instant runoff voting -- if this happens to result in a tie, the winner will be picked by the 'Single transferable vote' http://en.wikipedia.org/wiki/Instant-runoff_voting http://en.wikipedia.org/wiki/Single_transferable_vote To cast a valid vote, you *must* include 4 options. ryan
Re: logging revisited...
but i don't think changing the api Solr compiles against to commons-logging makes sense -- not since we're already using the least common denominator API (slf4j) sounds good. I agree. We could add a new dependency tomorow that uses log4j, and ship with log4j-over-slf4j.jar; but would we then change the debate to whether the Solr code should use the commons API or the log4j API or the slf4j API? ... why bother when it's all going to go through slf4j anyway? great. as is, our .war ships with jcl-over-slf4j-1.5.5.jar so I think we can put this discussion permanently in the bag. ryan
Re: [VOTE] LOGO
https://issues.apache.org/jira/secure/attachment/12394376/solr_sp.png https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png https://issues.apache.org/jira/secure/attachment/12394475/solr2_maho-vote.png is this one ok? https://issues.apache.org/jira/secure/attachment/12392306/apache_solr_sun.png If #3 above is not OK: https://issues.apache.org/jira/secure/attachment/12394376/solr_sp.png https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png https://issues.apache.org/jira/secure/attachment/12392306/apache_solr_sun.png https://issues.apache.org/jira/secure/attachment/12391946/apache_solr_burning.png Otis - Original Message From: Ryan McKinley [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Wednesday, December 10, 2008 8:51:42 PM Subject: [VOTE] LOGO This thread is for solr committers to list the top 4 logos preferences from the community logo contest. As a guide, we should look at: http://people.apache.org/~ryan/solr-logo-results.html The winner will be tabulated using instant runoff voting -- if this happens to result in a tie, the winner will be picked by the 'Single transferable vote' http://en.wikipedia.org/wiki/Instant-runoff_voting http://en.wikipedia.org/wiki/Single_transferable_vote To cast a valid vote, you *must* include 4 options. ryan
Re: [VOTE] LOGO
Doesn't limiting to top 4 defeat the purpose of using STV to overcome splitting-the-vote? Seems like we should rank the whole list (or all that an individual finds acceptable) -Yonik On Wed, Dec 10, 2008 at 8:51 PM, Ryan McKinley [EMAIL PROTECTED] wrote: This thread is for solr committers to list the top 4 logos preferences from the community logo contest. As a guide, we should look at: http://people.apache.org/~ryan/solr-logo-results.html The winner will be tabulated using instant runoff voting -- if this happens to result in a tie, the winner will be picked by the 'Single transferable vote' http://en.wikipedia.org/wiki/Instant-runoff_voting http://en.wikipedia.org/wiki/Single_transferable_vote To cast a valid vote, you *must* include 4 options. ryan
Re: 1.4 Planning
Great! We should try to have a release ASAP because we already have a critical mass of features.A release in January should be a good milestone. The official release is very important for a lot of users because their organizations have a such a policy. We can freeze on a list of bugs and can start focusing on cleaning them up. If Lucene is planning to have a release we can try to synchronize with that --Noble On Thu, Dec 11, 2008 at 2:19 AM, Grant Ingersoll [EMAIL PROTECTED] wrote: I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant -- --Noble Paul
[jira] Updated: (SOLR-821) replication must allow copying conf file in a different name to slave
[
https://issues.apache.org/jira/browse/SOLR-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-821:
Fix Version/s: 1.4
replication must allow copying conf file in a different name to slave
-
Key: SOLR-821
URL: https://issues.apache.org/jira/browse/SOLR-821
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Priority: Minor
Fix For: 1.4
It is likely that a file is different in master and slave. for instance
replicating solrconfig.xml is not possible with the current config if master
and slave has diffferent solrconfig.xml (which is always true)
We can add an alias feature in the confFiles as
{code}
str
name=confFilesslave_solrconfig.xml:solrconfig.xml,slave_schema.xml:schema.xml/str
{code}
This means that the file slave_solrconfig.xml should be copied to the slave
as solrconfig.xml and slave_schema.xml must be saved to slave as schema.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] LOGO
I don't think STV makes much sense unless we are picking more then one. The key in STV is that the extra votes for the winner get passed on to the choice. Since there really is not a next choice it does not help. Instant Runoff however does make sense. We cycle through the votes and at each round toss out the losing candidate. In each round, everyone gets to vote for their top choice of available candidates until something has a majority or no other candidates are left. If there is a tie at the end, the STV tally can break the tie. We could rank more then 4 to ensure that the rounds could go longer... but i hope that is not necessary. For things to work out though it is important that everyone vote for the same number of choices. On Dec 10, 2008, at 10:52 PM, Yonik Seeley wrote: Doesn't limiting to top 4 defeat the purpose of using STV to overcome splitting-the-vote? Seems like we should rank the whole list (or all that an individual finds acceptable) -Yonik On Wed, Dec 10, 2008 at 8:51 PM, Ryan McKinley [EMAIL PROTECTED] wrote: This thread is for solr committers to list the top 4 logos preferences from the community logo contest. As a guide, we should look at: http://people.apache.org/~ryan/solr-logo-results.html The winner will be tabulated using instant runoff voting -- if this happens to result in a tie, the winner will be picked by the 'Single transferable vote' http://en.wikipedia.org/wiki/Instant-runoff_voting http://en.wikipedia.org/wiki/Single_transferable_vote To cast a valid vote, you *must* include 4 options. ryan
[jira] Updated: (SOLR-821) replication must allow copying conf file in a different name to slave
[
https://issues.apache.org/jira/browse/SOLR-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-821:
Attachment: SOLR-821.patch
untested.
replication must allow copying conf file in a different name to slave
-
Key: SOLR-821
URL: https://issues.apache.org/jira/browse/SOLR-821
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Priority: Minor
Fix For: 1.4
Attachments: SOLR-821.patch
It is likely that a file is different in master and slave. for instance
replicating solrconfig.xml is not possible with the current config if master
and slave has diffferent solrconfig.xml (which is always true)
We can add an alias feature in the confFiles as
{code}
str
name=confFilesslave_solrconfig.xml:solrconfig.xml,slave_schema.xml:schema.xml/str
{code}
This means that the file slave_solrconfig.xml should be copied to the slave
as solrconfig.xml and slave_schema.xml must be saved to slave as schema.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] LOGO
On Dec 10, 2008, at 10:12 PM, Otis Gospodnetic wrote: https://issues.apache.org/jira/secure/attachment/12394475/solr2_maho-vote.png is this one ok? Seems totally fine by me.
[jira] Commented: (SOLR-807) UUIDField type cannot be recognized when wt=javabin is used
[
https://issues.apache.org/jira/browse/SOLR-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655523#action_12655523
]
Noble Paul commented on SOLR-807:
-
This does not impact the 'javabin' format in any way. Just that the objects
passed to the NamedListCodec will be different if they are not 'supported'
There is a small overhead of a HashSet lookup for each object . (which is
trivial I guess)
UUIDField type cannot be recognized when wt=javabin is used
---
Key: SOLR-807
URL: https://issues.apache.org/jira/browse/SOLR-807
Project: Solr
Issue Type: Bug
Components: clients - java, search
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Assignee: Shalin Shekhar Mangar
Priority: Trivial
Fix For: 1.3.1
Attachments: SOLR-807.patch, SOLR-807.patch, SOLR-807.patch,
SOLR-807.patch
I'm using UUID via Solrj in my project. When I use javabin (default), I got:
*java.util.UUID:* 391e3214-4f8e-4abd-aa6b-4f12be79534f
as the uuid value. But if I use xml, I got:
391e3214-4f8e-4abd-aa6b-4f12be79534f
I think the both of them should return same string.
program for reproducing the problem:
{code:java}
public static void main(String[] args) throws Exception {
CommonsHttpSolrServer server = new CommonsHttpSolrServer(
http://localhost:8983/solr; );
SolrQuery query = new SolrQuery().setQuery( *:* );
//server.setParser( new XMLResponseParser() ); // uncomment for wt=xml
System.out.println( = +
server.getParser().getClass().getSimpleName() + = );
QueryResponse rsp = server.query( query );
SolrDocumentList docs = rsp.getResults();
for( SolrDocument doc : docs ){
Object id = doc.getFieldValue( id );
System.out.println( type = + id.getClass().getName() + , id = +
id );
Object timestamp = doc.getFieldValue( timestamp );
System.out.println( type = + timestamp.getClass().getName() + ,
timestamp = + timestamp );
}
}
{code}
result for wt=javabin
{code:title=javabin}
= BinaryResponseParser =
type = java.lang.String, id =
java.util.UUID:391e3214-4f8e-4abd-aa6b-4f12be79534f
type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
{code}
result for wt=xml
{code:title=xml}
= XMLResponseParser =
type = java.lang.String, id = 391e3214-4f8e-4abd-aa6b-4f12be79534f
type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.4 Planning
+1 This is great! Thanks for taking the initiative, Grant. On Thu, Dec 11, 2008 at 2:19 AM, Grant Ingersoll [EMAIL PROTECTED]wrote: I'd like to suggest we start thinking about 1.4 being released in early January. Here's my reasoning: 1. I think we all agree that 1.2 - 1.3 was way too long 2. Quarterly releases seem to be a pretty nice timeframe for people such that you aren't constantly upgrading, yet you don't have to wait for eternity for new features 3. And here's where the rubber meets the road: We've actually put in some significant features and bug fixes, namely Java-based Replication, Tika Integration, new more scalable faceting implementation and on and on, not to mention Lucene improvements and other bug fixes. Read about it at https://svn.apache.org/repos/asf/lucene/solr/trunk/CHANGES.txt Here's what's currently targeted to 1.4: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12313351 Since I so enjoyed doing the release last time, I volunteer to do it again this time. Thoughts? -Grant -- Regards, Shalin Shekhar Mangar.
