Searching WebHelp Pro sometimes fails to find terms that are there

[Rocky_XYZZY]

I've seen postings about this before, but we're seeing searches fail with the message "Sorry, we were unable to find a good answer for your question." even though the term being searched is present in countless places within the help.

To address this we have increased the java heap space, as advocated elsewhere and we are seeing the same intermittent problem. Digging into this further we've examined the SQL server logs and according to one of our engineers it appears that RoboHelp is occassionally passing invalid syntax as part of its search query, which causes the search engine (Lucene, I guess) to throw the error.

The pattern seems to be that a particular term or two will produce the "Sorry..." message for a week or so then another term or two will exhibit the problem and the original terms will work properly.

Here's another puzzing detail: if I right-click the body of the WebHelp Pro help page and cut the URL from the Properties dialog and then paste the same URL into a different browser page, log in past the Admin page, and perform the same search, then the search works fine.

Has anyone experienced this sort of behavior? Any ideas what might be going on?

[johndaigle]

Hi, Rocky

Can you verify that in the Configuration Manager application (which is on the server machine) is set to "Reindex Documents at Server" is checked?

If you could zip up the Tomcat log file that would be helpful.

You'll find it on this path on the Server machine:

C:\Program Files (x86)\Apache Software Foundation\Tomcat 6.0\logs\robohelpserver.log

Send it to my email which you can find in my profile at right. I'll send that to an Adobe engineer and see if we can diagnose this.

BTW, did you finally get the issue resolved mentioned in this thread?

http://forums.adobe.com/message/4014314#4014314

Thanks

John Daigle

Adobe Certified RoboHelp and Captivate Instructor

Evergreen, Colorado

www.showmethedemo.com

[Rocky_XYZZY]

Thank you! When I return to the office tomorrow I'll investigate whether or not this etting is enabled and also pull the log files.

As for the other thread, we worked around the issue by resurrecting the virtual machine image that contained our trial install, which had been working fine, and activated the expired trial install with our newly purchased license. For whatever reason, this seemed to work fine.

[Rocky_XYZZY]

It's funny about the "reindex at server setting." We have three or four terms that fail the search in a predictable fashion: changing this setting from On to Off alters which of the group fails or succeeds when searching. For example, "On," results in terms A and B failing but C and D work whereas "Off" results in C and D failing but A and B work. This is repeatable.

Thanks for your help. I hope they find something in the logs.

[johndaigle]

Hi, Rocky. The Adobe engineers that I wanted to review your logs are returning from an extended holiday break. I will have an opportunity this week to raise this issue now that they are back.

Thanks

john

[johndaigle]

As a follow up to folks following this thread: Adobe engineers identified Rocky's problem after looking at his server log files and it was successfully resolved. If anyone encounters a similar problem, post it here on the forum and we'll see if we can help.

John Daigle

Adobe Certified RoboHelp and Captivate Instructor

Evergreen, Colorado

www.showmethedemo.com

[Guest]

Hi John,

I looked into this thread, looks related, but you didn't tell how Adobe engineer solve this issue. I just posted

Webhelp pro does not show the same searching result as webhelp

would it be related to this thread? if so, maybe you already have answer?

Thank you!

Frances

[Rocky_XYZZY]

Adobe solved our problem by providing the patch "SearchUtils.class." Apparently, the problem was with certain combinations of characters in the search queries.

In response to your original issue, it didn't have any effect on differences between webhelp pro versus webhelp results. We've seen differences, but we're so happy to have searching working again that we're overlooking it.

[Guest]

Hi Rocky,

Thank you very much for your reply!

we once turned on "reindex at server setting" and asked by adobe support to turn off. now we have " substring..." turned on in configuration manager. however, we still have inconsistent searching result for substring:

search term is vaccine, it returns the result, but if I enter vacci doesn't work, while vaccin works.

Do you think the patch "SearchUtils.class." will solve our problem? whom do you suggest we contact to so that we can get fix quickly?

Frances

[Rocky_XYZZY]

Here’s a summary of what we’ve experienced:

• The failure on certain search terms (I think they were any terms that had the letter "e" in it) was fixed by the patch that I referenced earlier. That bug has not reappeared.
• There are still two persistent bugs that we see:
  • Searching for strings that contain certain combinations of the word “not” cause the search to fail and the search pane to disappear until the user quits and relaunches the help.
  • If we’ve modified a topic by adding keyword metadata to the keyword field and then perform a search that results in that topic being found, the topic appears in the listing displayed by its file name, not but its topic title.
• By altering the “Reindex documents at server” checkbox, we can affect the behavior of these two bugs:
  • Checking “Reindex documents at server” fixes the "search fails on 'not' bug" but introduces the "display search results using file name instead of topic title" bug.
  • Unchecking this checkbox does the inverse: doing so reintroduces the "not" bug and fixes the "display search results using file name instead of topic title" bug.
• I note that the “Substring search is enabled for client index” can only be checked if the parent checkbox, "Reindex documents at server" is unchecked. This specific checkbox has no effect on the behavior of the two bugs described above.

Because we’d rather have the “display by file name” bug instead of the failed search bug that requires a help relaunch, we keep “Reindex documents at server” checked. This means that partial string searches is disabled for us.

[Guest]

Hi John

I am having similar problems as stated above. We have 5 different RoboServer projects going and have identified different words in different projects that return zero results even with the word in the title. The words are "volunteer", "Bailee", "Fees", "Fee", "Mueller".. seems like we might be experiencing the same problem related to search queries containing some combination containing the letter 'e'.

We have RoboServer 9, the Search works perfect on those same words, in preview mode, just an issue when run on the server. Any chance I can get access to the SearchUtils.class patch?

Thanks

Curt

[johndaigle]

Hi,

I have not found it. I thought it was in  Knowledge Base article. I have queried Adobe about it and hopefully will get a reply soon.

Thanks

john

[Guest]

Thanks I appreciate it greatly.

[Guest]

We secured the file and applied the patch and I republished the project and am still experiencing the same problem. In terms of applying the fix, does it matter if the server option for Reindex documents at server is checked or unchecked? We currently have it off.

Thanks

Curt

[RoboColum_n_]

It maybe worth ensuring that Tomcat has been stopped and restarted.

Colum

[Guest]

We did and I republished the project