Technical Blog Post
Abstract
SI won't come up (McAfee interatction)
Body
If you use McAfee's ePolicy Administrator, you may run into an instance where SI will not come up.
The services will appear to be up, however, you are unable to connect to the SI dashboard, the port
is not listening for web requests.
In noapp.log, you could see this error:
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE java.net.BindException: Address already in use: JVM_Bind
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at java.net.PlainSocketImpl.socketBind(Native Method)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at java.net.ServerSocket.bind(ServerSocket.java:319)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at java.net.ServerSocket.<init>(ServerSocket.java:185)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at java.net.ServerSocket.<init>(ServerSocket.java:141)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at javax.net.ssl.SSLServerSocket.<init>(SSLServerSocket.java:84)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.<init>(SSLServerSocketImpl.java:79)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:64)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.jetty.security.SslSocketConnector.newServerSocket(SslSocketConnector.java:409)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.jetty.bio.SocketConnector.open(SocketConnector.java:73)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.jetty.AbstractConnector.doStart(AbstractConnector.java:272)
[2010-03-19 14:33:49.077] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.jetty.bio.SocketConnector.doStart(SocketConnector.java:147)
[2010-03-19 14:33:49.093] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
[2010-03-19 14:33:49.093] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.jetty.Server.doStart(Server.java:233)
[2010-03-19 14:33:49.093] ALL 000000000000 GLOBAL_SCOPE at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
[2010-03-19 14:33:49.093] ALL 000000000000 GLOBAL_SCOPE at com.sterlingcommerce.woodstock.noapp.WebServerStartThread.run(WebServerStartThread.java:63)
[2010-03-19 14:33:49.093] ALL 000000000000 GLOBAL_SCOPE at java.lang.Thread.run(Thread.java:595)
The line numbers might be different, but what's happening is SI's SSL web server is unable to bind to
its assigned port. This is due to the McAfee ePolicy agent listening on the port first.
This would commonly occur if your base port is 8080, as McAfee's ePolicy agents listen on port 8081,
by default. (This is the same port as the SSL port for SI, when the base port is 8080.)
Fortunately, you can fix this one of two ways:
1) Change the listening port for McAfee ePolicy agent wakeup. You'll need to contact your ePolicy admin
to make this change.
2) Change the SI SSL port (8081) as outlined in this knowledge base article:
You really only need to change references to port 8081. Make a note which port you use, however, to avoid
future port conflicts.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SS3JSW","label":"IBM Sterling B2B Integrator"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
UID
ibm11121565