[
https://issues.apache.org/jira/browse/SOLR-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502379#comment-13502379
]
Yonik Seeley commented on SOLR-4100:
------------------------------------
bq. Why should these 2 kinds of commits be different? In solr 3.6.0 they
weren't, now in solr 4.0.0 they are.
In the past, commit was both about update visibility and update durability.
The NRT reopen acted to decouple these concepts.
I made a judgement call that the uses of commitWithin were normally much more
about visibility than durability, and that on balance it was better to default
commitWithin to "soft". I understand if you consider it a bug, it is a change
in behavior from the past, but it was also intentional.
bq. The other problem is, even when I do a solrServer.commit() after the soft
commit, this will not trigger the replication because this second hard commit
will have nothing to commit.
That would definitely be a bug. Have you seen this behavior?
> commitWithin (soft commit = true): version number of master index not changed
> => no replication to slave is done!
> -----------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4100
> URL: https://issues.apache.org/jira/browse/SOLR-4100
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 4.0
> Reporter: Roland Deck
>
> I have a master and a slave solr instance. In solrconfig.xml, a replication
> handler is present (slave points to master via masterUrl).
> 1) If you add a document to the master solr via curl http:// ....: This works
> and the document is replicated to the slave.
> 2) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer =
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID");
> doc.addField("title", "some test title");
> UpdateResponse urep = solrServer.add(doc);
> System.out.println("response status: "+urep.getStatus());
> solrServer.commit();
> }
>
> This works and the document is replicated to the slave.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2}
> {add=[TEST_ID]} 0 249
> 21.11.2012 08:31:19 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: start
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy onCommit
> INFO: SolrDeletionPolicy.onCommit: commits:num=2
>
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_2,generation=2,filenames=[_0_Lucene40_0.tim,
> _0.fnm, _0_Lucene40_0.frq, _0_nrm.cfe, _0_1.del, segments_2, _0.fdx,
> _0_nrm.cfs, _0.si, _0_Lucene40_0.prx, _0.fdt, _0_Lucene40_0.tip]
>
> commit{dir=C:\temp\nimela\searchapp\master\nimela\solr\eventlocation\data\index,segFN=segments_3,generation=3,filenames=[_1_Lucene40_0.tim,
> _1_nrm.cfs, _0_Lucene40_0.tim, _0.fnm, _1_Lucene40_0.frq, _0_1.del,
> _0_nrm.cfs, _0_Lucene40_0.prx, _1.fnm, _1_Lucene40_0.prx, _1_Lucene40_0.tip,
> _1_nrm.cfe, _0_Lucene40_0.tip, _1.fdx, _0_Lucene40_0.frq, _1.fdt, _1.si,
> _0_nrm.cfe, _0.fdx, _0.si, segments_3, _0.fdt]
> 21.11.2012 08:31:19 org.apache.solr.core.SolrDeletionPolicy updateCommits
> INFO: newest commit = 3
> 3) If you add a document in Java via solrj and use the following code snippet:
> public static void main(String[] args) throws Exception {
> ConcurrentUpdateSolrServer solrServer =
> SolrServerFactory.createSolrServerForUpdate("localhost", "9100",
> "/solr", "eventlocation", 5, 2);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("id", "TEST_ID_DUE");
> doc.addField("title", "some test title for due");
> UpdateResponse urep = solrServer.add(doc, 10000); //commit within 10s.
> System.out.println("response status: "+urep.getStatus());
> }
> This works on the master, but the version number is left the same, so that
> replication doesn't take place, leaving the slave in the previous state.
> This is certainly a bug and should be fixed.
> The logfile states as following:
> INFO: [eventlocation] webapp=/solr path=/update params={wt=javabin&version=2}
> {add=[TEST_ID_DUE]} 0 249
> INFO: start
> commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true}
> 21.11.2012 08:37:30 org.apache.solr.search.SolrIndexSearcher <init>
> INFO: Opening Searcher@18590c5 main
> 21.11.2012 08:37:30 org.apache.solr.update.DirectUpdateHandler2 commit
> INFO: end_commit_flush
> It seams to me that this softCommit mechanism doesn't work properly yet.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
