Bug 485820

Fixed here:
http://git.fedoraproject.org/git/?p=spacewalk.git;a=commitdiff;h=0f735c959f229a7946aa38e4ed9460934586c639

Now querying on all related server tables to see if any have changed.  Prior to fix, was only looking at "rhnServer".

verified.
Satellite-5.3.0-RHEL5-re20090227.1-i386-embedded-oracle.iso
1. Register SystemA
2. Wait for Search Server to index new system
3. Assign "room" to "west" in the webui for SystemA
4. Do a system search on "room" with the value "west".

With Satellite-5.3.0-RHEL5-re20090724.0, adding the room value or changing it has no effect on the search result the URL

https://rhndev6.z900.redhat.com/rhn/systems/Search.do?search_string=east&whereToSearch=all&view_mode=systemsearch_location_room

says

No matches found.

Hi Jan,

I think the search-server may have been in an odd state on rhndev6.  I saw the same behavior you mentioned, plus enough time elapsed where the re-indexing task should have picked up the change. Re-indexing is typically 5 minutes. 

I restarted search-server, and checked ~15 minutes later this was working.  

In the past I've seen odd behavior on the rhndev machines, for our stage testing we have been using rhndev1, in order for testing to proceed we needed to consume the resources of rhndev5 and rhndev7, we added the resources from all 3 machines together so it would have enough power for us.  Prior to this I've seen java process complain about not getting a timeslice to run.

Looking at /var/log/rhn/search/rhn_search_daemon.log

I see some exceptions about missing indexes, which should be harmless, I also see some errors implying date/time issues existed in the past day and were probably fixed.  This could create a problem if systems were indexed when the data was in 2010.   The table rhnIndexerWork would have an entry stating the last system info indexed was ID XXXXXX at time blah:blah:2010.   If the date is then corrected to 2009, modifications would not be picked up until a new system is added, at that point the rhnIndexerWork table would state ID XXXXXX+1 at time blah:blah:2009, now modifications would be picked up.  


STATUS | wrapper  | 2009/08/31 09:21:55 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2009/08/31 09:21:56 | Launching a JVM...
INFO   | jvm 1    | 2009/08/31 09:21:59 | Wrapper (Version 3.2.1) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2009/08/31 09:21:59 | 
INFO   | wrapper  | 2010/10/06 00:00:00 | The timer fell behind the system clock by 34532841100ms.
INFO   | jvm 1    | 2010/10/06 00:00:44 | The timer fell behind the system clock by 173102732ms.
STATUS | wrapper  | 2010/10/06 00:01:55 | TERM trapped.  Shutting down.
STATUS | wrapper  | 2010/10/06 00:01:56 | <-- Wrapper Stopped
STATUS | wrapper  | 2010/10/06 00:03:26 | --> Wrapper Started as Daemon
STATUS | wrapper  | 2010/10/06 00:03:26 | Launching a JVM...
INFO   | jvm 1    | 2010/10/06 00:03:29 | Wrapper (Version 3.2.1) http://wrapper.tanukisoftware.org
INFO   | jvm 1    | 2010/10/06 00:03:29 | 
INFO   | wrapper  | 2010/10/11 00:00:00 | The timer fell behind the system clock by 431726400ms.
INFO   | wrapper  | 2010/10/09 00:00:00 | The system clock fell behind the timer by 172832400ms.
INFO   | wrapper  | 2010/10/12 00:00:00 | The timer fell behind the system clock by 345499400ms.
INFO   | wrapper  | 2009/09/01 07:41:13 | The system clock fell behind the timer by 35050779900ms.
INFO   | jvm 1    | 2009/09/01 07:41:23 | The system clock fell behind the timer by 691041632ms.

Thank you for looking into this. Indeed, I set the date to year 2010 on that machine while testing some other bugzilla, however, no indexing seems to have taken place while the time was shifted.

SQL> select to_char(max(last_modified), 'YYYY-MM-DD HH24:MI:SS') from rhnIndexerWork ;

TO_CHAR(MAX(LAST_MO
-------------------
2009-09-01 09:31:34

SQL> 

So this should not be a problem.

Verified in stage, though I'd like to point out that the search results
seem a little fuzzy: I had two systems, one in room "west", the other
one in room "east", searching for room "east" returned both systems,
the one in east room in the first place with "east" value in bold.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html