nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Web Daemon was unable to contact Servlet Engine

System

It seems that approximately every other reboot of the Windows 2000 SP2 TeamSite 5.5.2SP2a server, I get this error message. Running the script and iwreset does not help. If I reboot again, it often seems to help.

I know about the support articles on this issue, but I am wondering if there is any more information - for instance *why* I have to run iwwebd_conf.ipl.

The service reports that it has started successfully.
The hostname and IP do not change.
The server has not been disconnected from the network, it has just been rebooted.

As a separate issue, in this environment, under normal conditions, for about 20 seconds after the Tomcat service is started (such as through the control panel or with iwreset -ui), the system continues to report this message, then refresh the browser and it goes away. Is that normal?

Does anyone have a similar issue? How can I avoid rebooting twice in a row?

Find more posts tagged with

Comments

Gregg Faus

I too was experiencing this same problem after upgrading to SP2. Usually I can find the reason in one of the logs. I then stumbled upon a post on DevNet that suggested that you change the default OpenAPI RMI ports. This setting is in:
$iw-home/iwopenapi/openapi.cfg. I change these lines:

# OPENAPI.rmi_port_number_min: 6767
# OPENAPI.rmi_port_number_max: 6777
OPENAPI.rmi_port_number_min: 13024
OPENAPI.rmi_port_number_max: 13083

I've rebooted fives times now without getting the unable to contact Servlet Engine msg.

- gf

Migrateduser

Thanks. This seemed to work at first (two reboots without a failure, which is unusal), but I just brought it up and it wasn't working again (which is usual).

Migrateduser

John,

Did you ever find a solution for this?

Sebouh

Migrateduser

Had the same problem, did the same thing.
Increased the ports by 50.
But it didn't work.
However, I took these additional steps.
1. Rebooted the box after I made the change.
2. Stopped World Wide Web Publishing Service
3. Restarted the Interwoven Web Daemon and Servlet Engine (which restarted UI Admin).
4. Made sure it started by checking the servlet_err.log file.
5. Restarted the World Wide Web Publishing Service

The only problem I have is that I have to stop IIS and restart the Interwoven services everytime I reboot the box.

Migrateduser

I finally isolated what was causing this.

It looks like port 1099 was in use after the server booted and OpenAPI won't start until the port clears.

One workaround is to change the port used by OpenAPI per this KB article https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=49039. Another is to change the port of the other application using port 1099. The latter did not work for us since it appears that after the server boots up another server opens a NETBIOS connection (port 139) to the TeamSite server's port 1099 which prevents OpenAPI from starting. I noticed this by typing NETSTAT -an from the command line.

As a matter of fact, even though the browser service is stopped on my TeamSite server it still appears to maintain lists of domain controllers on my network after TeamSite services start up. Typing NBTSTAT -c shows this list of domain controllers. With TeamSite services stopped this doesn't happen. Any way, one of these server connections was the culprit. The easiest solution I've found to clear this after a server boot is to do the following:

1) Type NBTSTAT -R from the command line to clear the Remote Cache Name Table.
2) Restart the Interwoven Servlet Engine service (which also restarts Interwoven UI Admin)

That's it.

Edited by Sebouh on 04/22/03 06:45 AM (server time).

tiroth

It seems likely that Sebouh has identified the root cause; at any rate, we often see this behavior and simply restarting the servlet engine after the machine (and Teamsite) have come up solves the problem 100% of the time for us.

Migrateduser

Interesting, just restarting the service does not work for us (but the service does not give an error; it seems to start but TeamSite says it can't make the connection).