[ 
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035112#comment-13035112
 ] 

Hoss Man commented on SOLR-2193:
--------------------------------

bq. I think that commitWithin should mean soft commit. Users of commitWithin 
care about when the changes become visible, not when they are guaranteed to be 
fsync'd.

while i don't know that we can assume that's the expectation of *all* existing 
commitWithin users, i think it probably is safe to assume that the users who 
*do* expect commitWithin to refer to fsync can be expected to pay attention 
enough if we add a new "hardCommitWithin=35" option and start using that if 
it's what they want.

Alternately: add commitWithin.style=(hard|soft) where the default is "soft" and 
let people specify it as a default on their update request handlers if the 
behavior they really want is "hard"

Or simplify things even further: eliminate "softCommit" as an explicit type of 
action and add a new "commit.type=(hard|soft)" param exists -- "commit.type" 
would affect both explicitly requested commits, and commitWithin.





> Re-architect Update Handler
> ---------------------------
>
>                 Key: SOLR-2193
>                 URL: https://issues.apache.org/jira/browse/SOLR-2193
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Mark Miller
>            Assignee: Mark Miller
>             Fix For: 4.0
>
>         Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch, 
> SOLR-2193.patch
>
>
> The update handler needs an overhaul.
> A few goals I think we might want to look at:
> 1. Cleanup - drop DirectUpdateHandler(2) line - move to something like 
> UpdateHandler, DefaultUpdateHandler
> 2. Expose the SolrIndexWriter in the api or add the proper abstractions to 
> get done what we now do with special casing:
> if (directupdatehandler2)
>   success
>  else
>   failish
> 3. Stop closing the IndexWriter and start using commit (still lazy IW init 
> though).
> 4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level.
> 5. Keep NRT support in mind.
> 6. Keep microsharding in mind (maintain logical index as multiple physical 
> indexes)
> 7. Address the current issues we face because multiple original/'reloaded' 
> cores can have a different IndexWriter on the same index.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to