Thanks Shawn,
>> <autoCommit> >> <maxTime>300000</maxTime> >> <openSearcher>false</openSearcher> >> </autoCommit> >> > > That autoCommit configuration is not affecting document visibility at all, > because openSearcher is set to false. Don't rush to change this -- this > kind of configuration is what you want. I would probably use one minute > here rather than five minutes, but again, don't be in a rush to change it > without some evidence that the change is needed. Well, I don't want change this... I showed this configuration only to make clear what's current situation. > > > But in order to have prices updates as soon as possible, we're >> planning to add a second client that, even while the first client is >> running, should submit many prices atomic updates. >> >> Now I'm worried about to have two clients on the same collection, even >> if those clients can be orchestrated using a kind of semaphore, I'm >> afraid that those atomic commits could come too quickly or in worst >> case might even overlap the other (first) client. >> > > Having multiple clients send updates should not be a problem. This is the > recommended way to increase indexing speed. > > When/where are the commits that open a new searcher happening? The > autoCommit settings aren't handling that. > > The first client does the following: 1. rollbacks all add/deletes made to the index since the last commit (in case previous client execution was completed unsuccessfully). 2. reads data from sql server 3. updates solr documents 4. manually commits And *important*, once a day, the first client deletes all the existing documents and reindex the entire collection from scratch. The second client is simpler, it manually commits after every atomic update. > There are several ways to accomplish commits that make changes visible. > Three of them are what I would call "correct" to pair with your autoCommit > settings. > > One good option is to configure autoSoftCommit, with a value that > describes how long after the first update a commit will take place. A > second option is to include a "commitWithin" parameter on every update > request, with a value that works similarly to autoSoftCommit. Another is > to send an update request that explicitly commits. Ideally those manual > commits will be soft commits. > > I would recommend one of the first two options, but be very careful about > making the intervals too short. The interval should be longer than it > takes for a typical commit to actually happen, probably two to three times > as long, or longer. I would not recommend manual commit requests unless > you can be sure that only one of your clients will send them, and that the > commits will be spaced far enough apart that they can't overlap. I am > using manual soft commits for updates on my own indexes. > > I could change current configuration adding autoSoftCommit and openSearcher=true. But not sure how can I, with this configuration, have once a day a full reindex. I mean, with the current configuration any change is visible only after the manual commit. So even when there is a full reindex, the new entire index is visible only when the client commits. I don't think I can do the same thing having autoSoftCommit with openSearcher=true. Right? -- Vincenzo D'Amore
