1 Reply Latest reply: Mar 27, 2009 6:38 PM by kabi.patt RSS

    oberr.cgi?status=500 errmsg=ErrEngineDown after LDAP reindexing

      I am using OAM 7.0.4 on windows server with iPlanet LDAP as database. Everything was running fine till I loaded 100k users to do a performance testing.

      I added 100k test users via ldap import and reindexed it afterwards. When all these activities were going on, I forgot to shut down the CoreId and Access Server(s) connecting to this ldap. After everything is done I restarted all the components and all started gracefully. No error or suspicious log during this time.

      However, on accessing /identity/oblix I am getting "oberr.cgi?status%3D500%20errmsg%3DErrEngineDown" on the URL.

      I checked all servers and they seems running fine. Here are the precise log entries when I hit /identity/oblix/ .

      1. Log from iPlanet :-
      [27/Mar/2009:16:02:34] failure ( 2032): for host trying to GET /identity/oblix/, Oblix NetPoint reports: The NetPoint WebGate plug-in is unable to contact any NetPoint Access Servers.

      2. Log from Webgate hosted on
      2009/03/27@21:02:34.895000 2032 3300 ACCESS_GATE ERROR 0x0000151A \Oblix\coreid\palantir\webgate\src\isresrcprotected_event_handler.cpp:129 "Failure to connect to Access Server" HTTPStatus^500 Error^majorCode = 3[FatalError], minorCode = 0[EngineDown], StatusMsg = , GSN = 0, needInfo = NONE

      3. Log from AccessServer hosted on
      2009/03/27@21:06:10.567000 2808 2552 NET ERROR 0x00002104 \Oblix\coreid\palantir\netlib\src\obsocket.cpp:658 "Error performing socket operations" raw_code^10038

      There is no new log entries in CoreId, Webpass, PolicyManager and LDAP created for this event. I think, the log made in the AccessServer (point# 3) has nothing to do with this one, since I used to see these before. Not sure what went wrong. I just install a fresh set of components pointing to the same LDAP, it works fine. Any idea how to recover ?
        • 1. Re: oberr.cgi?status=500 errmsg=ErrEngineDown after LDAP reindexing
          I found the solution for this one. It was nothing to do with the LDAP re-indexing.

          Recently I defined the Access-Server-Clusters and assigned it to all the existing webgate. I removed the individual AccessServer association available from each webgate after associating to the cluster. I did it from PolicyManager admin screens. That cluster to webgate association process wiped out the existing Access-Server value from respective webgate.lst file (loacated at ..\NetPoint\WebGate\access\oblix\apps\webgate). so the webgate was not able to find any AccessServer to connect. I manually added existing access server value in webgate.lst and now I am able to access the /identity/oblix .