Recent Ingeniux issues and actions

Thursday, May 10

I Installed version 5.250 on webserver2. Barbara and I subsequently tested the current Macintosh client against this version and found that a significant number of our issues were resolved.

The design-time server was serving the admin client to all users. Recycling the app pools in IIS restored the serving of the author client.

Thursday, May 17

I performed the stop IIS – delete dependency graphs – start IIS – full site publish sequence. The entiresitepub folder contains 8218 objects.

Friday May 18

The CMS was sluggish in responding to page check out and in. There was an error on the server, which I restarted.

Week of May 21

System continues to be unresponsive at times. Simply restarting IIS seems to resolve the issue.

May 24

Some pages were returning a 500 error on the live site. Restoring from the backup on webserver2 was ineffective as the same errors were replicated there. The error-clearing sequence mentioned above resolved the issue, although it took somewhat more than an hour to fully resolve.

Banner Modifications

This week 2 modification were to scripts running Banner.  These modifications were necessary to hide the password passed to gurjobs, fgractg, and forappl when listing the process list from the OS command prompt.

System crashed

The CMS server responded to client connections with the following error:

An error occurred while retrieving the root node of the tree.
Error starting session:
Not enough storage is available to complete the operation.

After clicking okay the this error appeared:

Microsoft JScript runtime error “800a136f”
‘name’ is null or not an object
/upsweb/assignment_list.asp, line 69

At 0945, I:

  1. stopped IIS
  2. stopped PeerSync service
  3. deleted depgraph files
  4. restarted IIS
  5. performed a full publish
  6. restarted PeerSync service

System running okay, publishing is in process. I think the errors were symptomatic and not necessarily accurate; however, I’m logging them here in case they recur.

Cascade Web Unplanned Downtime

Cascade Web came down 3/26 at 4:40pm following a restart of the Apache server to restore the use of Banner and Famis to the camano server which had been running on a backup server since Friday.  Cascade Web was unable to start following this reboot and remained down until 10:30pm. 

Other components of the Application Server including Discoverer and Portal remain down as of 8:15am on 3/27.