I could replicate this only when the address was indeed used by some other
process.

If the address was available and poor credentials are configured, the error
message printed is that credentials cannot be loaded:

S:\>bin\globus-start-container.bat
[JWSCORE-114] Failed to start container: [JWSCORE-200] Container failed to
initi
alize [Caused by: [JWSSEC-250] Failed to load certificate/key file. Certificate
"X:\etc\containercert.pem" and key is "X:\etc\containerkey.pem" [Caused by:
[JGL
OBUS-7] Failed to load credentials. [Caused by: X:\etc\containercert.pem (The
sy
stem cannot find the file specified)]]]

Was the port number available ?

Any updates on this? I could not replicate the issue.

Full stack trace of the error:

debian% globus-start-container -nosec  -debug
. Caused by java.lang.IllegalArgumentException: Port number out of range: 8080
        at org.globus.net.PortRange.setPort(PortRange.java:155)
        at org.globus.net.PortRange.free(PortRange.java:149)
        at
org.globus.wsrf.container.ServiceDispatcher.closeServerSocket(ServiceDispatcher.java:804)
        at
org.globus.wsrf.container.ServiceDispatcher.stop(ServiceDispatcher.java:734)
        at
org.globus.wsrf.container.ServiceContainer.close(ServiceContainer.java:309)
        at
org.globus.wsrf.container.ServiceContainer.<init>(ServiceContainer.java:219)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
        at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
        at
org.globus.wsrf.container.ServiceContainer.createContainer(ServiceContainer.java:166)
        at
org.globus.wsrf.container.ServiceContainer.main(ServiceContainer.java:518)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:114)
        at
org.globus.bootstrap.ContainerBootstrap.main(ContainerBootstrap.java:40)
[JWSCORE-114] Failed to start container:  [Caused by: Port number out of range:
8080]

My theory is that the container is started with default port (8080), but
invalid creds. If the default port is not in the tcp port range, the container
fails when closing the port with the exception. Not sure whether the container
should be upset about a port not in the range if it's explicitly selected or
not.

Patch that hides the exception, showing the true error message:
http://www-unix.mcs.anl.gov/~bester/patches/java-port-range-error.diff

Joe

I see the issue now: the container is started up on default port even if it is
not in the port range. I'll add a check to see if default port is in port range
and if not, use a random port from the port range.

Fix committed to trunk. If port range is enabled and default port is not in
range, a random free port from with in range is chosen.
Thanks Joe!

Sorry, I am using 4.2.1, and a variation on this bug is still haunting me.

Despite starting the container with "-p 8443" and an active port range outside
that, if there are no containerkey nor containercert files, the container fails
to start, with the INCORRECT error message about an illegal port range instead
of a certificate problem.

Please re-open the bug.