Bug 485820 - System Search: Isn't reindexing when system data is modified
System Search: Isn't reindexing when system data is modified
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: John Matthews
Preethi Thomas
:
Depends On:
Blocks: 457073
  Show dependency treegraph
 
Reported: 2009-02-16 15:58 EST by John Matthews
Modified: 2009-09-16 18:19 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:31:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Matthews 2009-02-16 15:58:46 EST
Description of problem:
Search Server is not reindexing the data of an already registered system after it's data is modified.  Example:  Updating the "room" location under System Details.
 

Version-Release number of selected component (if applicable):
Satellite-5.3.0-RHEL5-re20090206.1-i386-embedded-oracle.iso

How reproducible:
always

Steps to Reproduce:
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".

Actual results:
No matches found


Expected results:
Match found

Additional info:
Comment 1 John Matthews 2009-02-16 16:10:13 EST
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".
Comment 2 Preethi Thomas 2009-03-03 15:21:31 EST
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".
Comment 3 Jan Pazdziora 2009-09-01 08:36:20 EDT
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.
Comment 4 John Matthews 2009-09-01 09:27:40 EDT
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.
Comment 5 Jan Pazdziora 2009-09-01 09:43:15 EDT
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.
Comment 6 Milan Zazrivec 2009-09-09 05:18:48 EDT
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.
Comment 7 Brandon Perkins 2009-09-10 15:31:58 EDT
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

Note You need to log in before you can comment on or make changes to this bug.