Tuesday, April 24, 2007
Wireless Disabled After Resume from Suspend
After I resume my laptop (OpenSUSE 10.2, Dell 640m, Intel 3945ABG wireless card) from stand by (suspend to ram), the wireless usually stops working. The KNetworkManager applet stops showing the wireless device. After investigating further, it seems that the problem is with the HAL daemon, and restarting it fixes the problem.
However restarting HAL daemon manually every time after resume was not a good option. So I decided to use my time while waiting at the SF airport better by finding a solution to the problem. It seems that SuSE uses pm-utils for managing suspend and other power related options stating version 10.2. Some of the configurations are present in /etc/pm/config. It turns out that all the scripts present in /etc/pm/hooks/ are executed after every suspend or resume event. One of the following four option is passed as a command line argument to each of the script: hibernate, suspend, thaw, or resume. Since I wanted to restart haldaemon at every resume, all I had to do was to create a new executable file in /etc/pm/hooks/ with the following contents:
#!/bin/sh # File: /etc/pm/hooks/99haldaemon case "$1" in resume) /etc/init.d/haldaemon restart ;; *) ;; esac
And now the haldaemon is restarted at every resume, and the wireless works fine after I open the laptop lid. This is a hack, and I hope a proper fix will be included in future versions of SuSE.
Wednesday, April 11, 2007
Lucene Optimization Tip: Reuse Searcher
Lucene is a great text search engine, but some aspects of it are not clearly documented. For example, if you have multiple simultaneous requests (e.g., in a web application) searching for different queries, should there be a separate IndexSearcher for each thread or one shared IndexSearcher will do.
Initially we were using different IndexSearcher for different requests, creating a new instance at the start of the request and destroying soon after searching. After a lot of experimentation and exchange of a few mails over the lucene mailing list, I discovered that the efficient way is to use a single shared IndexSearcher across all requests. Multiple concurrent threads can easily invoke the search method on a single IndexSearcher object. Reusing cached data makes the single searcher approach very efficient both in terms of response time and memory usages. In our case, response times decreased by a factor of 2-3 after this change.
Remember that IndexSearcher object however needs to be destroyed and recreated after the index is modified or updated. Unless the searcher is recreated, it will not reflect the changes made to the index. A good strategy is to periodically destroy and recreate the shared index using a separate Timer thread.