Kbase P109313: AdminServer does not start after applying 10.0B03 service pack
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/03/2010 |
|
Status: Verified
SYMPTOM(s):
AdminServer does not start after applying 10.0B03 service pack
Following messages appear in admserv.log file:
[AdminServer] Failed to create RMI registry on localhost:<n>
Failed RMI setup.. (8539)
[*UnexpectedError*] * recorded as exception #<n> in file ads0.exp.
Following exception is logged in the ads0.exp file:
Exception at <date/time>: java.rmi.server.ExportException
Message (throw): RegistryManager: Failed to start RMI registry thread
Message (excp): Port already in use: <n>; nested exception is:
java.net.BindException: Address already in use
The port on which the AdminServer should listen is not in use just before running proadsv -start.
AdminServer may just start just fine at times.
FACT(s) (Environment):
OpenEdge 10.0B
CHANGE:
Installed 10.0B03 Service Pack
CAUSE:
Bug# OE00120945
CAUSE:
Timing issue associated with the code that checked to see if the port for the AdminServer was in use prior to starting the RMI Registry.
On fast machines, the RMI Registry would start prior to Progress completing the check of port availability associated with the port the AdminServer was being started on.
FIX:
I. Fixed in 10.0B04 and 10.1A
The following workarounds could be used until time permits use of the fix mentioned above.
Workarounds:
1. Start up the AdminServer from the command line by adding the "-interactive true" option:
proadsv -start -interactive true
Note: Starting the AdminServer in this manner will keep the telnet session (under UNIX) or the Command Prompt session (under Windows) busy for the entire time that the AdminServer is up and running.
If using Fathom and performing remote monitoring, the workaround of -interactive true may not be recommended. This is because the AdminServer started in this fashion, bypasses the startup of the sonic container. Therefore your remote monitoring will not work. The remote machine being monitored will be offline.
2. Slow down the machine where the problem is occurring on. Because the problem is due to a timing issue, another workaround is to "slow down" the machine while the AdminServer is starting up; for example, try to launch the copy of a large file and start the AdminServer at the same time. It's been observed that in these cases, the AdminServer will probably start up correctly.
3. Occasionally, rebooting the machine has worked around the problem.