Why does this error even exist? Users can access an old view while the indexer rebuilds it, right? Why can’t people access the old FTI while it’s being rebuilt?
Just hate having to add another “Your request could not be processed at this time. Try again.” message.
It turns out the fix wasn’t to the FT engine directly, it was to web searches.
This might help - it’s a wrapper function we wrote. Rather than calling NotesDatabase.FTSearch you call this instead. It will retry every second for up to one minute. It could be refined to trap the formal error (it’s just got a general “On Error” now) and cleaned up a bit but it works. SPR is referenced also:
Function attemptToFTSearch(db As NotesDatabase, Byval passedSearchString As String, _
Byval maxResults As Integer, Byval sortOptions As Integer) As NotesDocumentCollection
'This function is needed because if an FT index is being updated while a search is performed there is a small chance
'that the search will return an error. SPR# RSTN69WDYJ is tracking this in ND6/7. When that SPR is resolved we can
'avoid use of this function.
'attempts to search the FT Index of a database, retrying after sleeping 1 second (up to X times) if an error is encountered.
'If the limit is reached then an empty collection is returned.
Dim numTries As Integer
On Error Goto errHandle
doSearch:
Set attemptToFTSearch = db.FTSearch(passedSearchString, maxResults, sortOptions)
getOut:
Exit Function
errHandle:
numTries = numTries + 1
If (numTries >= 60) Then
Set attemptToFTSearch = getEmptyNotesDocumentCollection(db)
Resume getOut
Else
Sleep 1
Resume doSearch
End If
I’ll consider it if it becomes a problem. Since we got the new 8.5.1 server this problem happens a lot less. and when it does the user gets the gentle but generic message saying an error occurred and please try again. By the time they try it again, it always seems to work.
I’ve been considering adding loop checks like that for the errors that can’t be avoided. They’re just so hard to test properly…I haven’t been inspired to do it.
Subject: I thought this was fixed in 7.0.4… maybe regressed in 8.5.1?
IIRC the fix was to have Notes/Domino simply delay and retry the request (without prompting the user).
What’s also interesting is R5 never exhibited this behavior - the change to the GTR engine (FT engine) in ND6 introduced this and a couple other undesirable traits.
For now I’m going to call it a reporting error on my part and assume the user wasn’t on the 8.5.1 server. If it happens again I’ll know exactly what server it’s on.
Subject: Well, these are 6.5.1 clients going against the 8.5.1 server
I’ll try to get more detailed information the next time it happens. I’ll get the exact client version and I’ll confirm the client was on the 8.5.1 server (which everyone is supposed to be on…but you know Domino clustering…shifts people around.)
On the last error the client was on the 8.5.1 server when I checked…but I can’t verify that the client was server when the actual error happened.