Bug? Openfire Http Binding blocks port although it is disabled


as you can see in the following log, Openfire opens the port given under “HTTP Binding” -> “Clients can connect to this server using HTTP binding.” even if it is disabled:

./logs/warn.log:2008.03.07 08:01:30 failed SelectChannelConnector@

Therefore I was not able to start a webserver on that port up to the time I changed the port 8080 to a really not used port.

To do this I enabled that feature, changed the port and disabled it once again.

A workaround is to start the other server first since Openfire does only log a warning in that case.

Please solve this issue.



Try this, stop the openfire server and start again , or Connecting the server with some other than 8080 port in http bind.

We just encountered the same problem. After a DB upgrade, we started Openfire before Confluence, and then Confluence failed to start, because Openfire had taken port 8080. The workaround suggested in the original posting worked, but I agree it seems unfriendly to lock up a port for a disabled featured. Since the feature seems to be disabled by default, how about at least assigning it a less-commonly-used port, e.g. 8482?


I tried looking into this issue and was not able to reproduce it. If you disable httpbind, the system property httpbind.enable is set to false. This prevents the httpBindServer from starting up at openfire startup…

Could you check your system properties to see if that setting is there?

Also, I believe that setting the port to -1 is not sufficent to prevent this…


httpbind.enabled is present and set to false, but this did not prevent the port from being acquired at startup. The following stack might help:

[org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:95)] Error starting HTTP bind service
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
at org.mortbay.jetty.nio.SelectChannelConnector.open(SelectChannelConnector.java:2 11)
at org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.jav a:309)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.mortbay.jetty.Server.doStart(Server.java:228)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:92)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startHTTPBindListeners(Conn ectionManagerImpl.java:505)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:134)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:52)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:106)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:507)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :46)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:985)

Our Openfire server has not been updated in quite awhile (version 3.4.1), so maybe the issue has been fixed in the version you were testing.

Erm, I am not sure what is up. I tried some more testing and couldn’t reproduce with 3.6.0 … Sorry, hopefully somebody more clever than I responds.

Note, that the default httpbind port was later changed to 7070 after 3.4.1