It is exciting to be able to announce the immediate availability of the beta release of Openfire 4.8.0!
It has been 667 days ago since we released the 4.7.0. That was the last time that a release was made from the same source code branch. And, that shows: we have closed almost 180 issues against this release! I’ll reserve the details for a blogpost on the 4.8.0 (non-beta) release, but some of the highlights are:
We’ve dropped support for Java 8. The minimum requirement is Java 11 now
A complete reimplementation of the asynchronous network stack, increasing stability and performance
All known TLSv1.3 issues were resolved
This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!
We are looking for your help!
Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org.
Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).
If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org) to see if there are any issues.
We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat. We are always looking for volunteers interested in helping out with Openfire development!
For other release announcements and news follow us on X / Twitter and Mastodon.
180 is only the things we’ve done since 4.7.5 came out.
The number of changes on the 4.8 branch since we released 4.7.0 would be well into the hundreds!
Absolutely. The upgrade process typically involves nothing more than running the installer for your platform again. See Openfire: Upgrade Guide for details.
All normal caveats apply: ensure that you have backups prior to performing the update, etc, but generally speaking, the process of updating is very easy.
Thanks for all the updates in this release. We were looking forward to the websocket improvements.
Has anyone else run into SSL issues like the one listed below ? Oddly enough happens to our iOS clients but not our Android ones. Version of Java (>=11) does not seem to matter. We were upgrading from 4.6.4 and even tried the keystore from prior installation unsuccessfully.
2023.12.14 21:39:35.856 ESC[30mTRACEESC[m [nioEventLoopGroup-5-1]: org.jivesoftware.openfire.nio.NettyConnection - Peer does not offer certificates in session: LocalClientSession{address=xyz.com/6ab6b587-1fc5-4f91-8a0e-5a340cd57887, streamID=2nt12nobtx, status=CONNECTED, isEncrypted=true, isDetached=false, serverName='xyz.com', isInitialized=false, hasAuthToken=false, peer address='69.181.110.152', presence='
<presence type="unavailable"/>'}
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:560) ~[?:?]
at org.jivesoftware.openfire.nio.NettyConnection.getPeerCertificates(NettyConnection.java:143) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.net.SASLAuthentication.getSASLMechanismsElement(SASLAuthentication.java:270) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.net.SASLAuthentication.getSASLMechanisms(SASLAuthentication.java:242) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.net.StanzaHandler.tlsNegotiated(StanzaHandler.java:493) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.net.StanzaHandler.initiateSession(StanzaHandler.java:135) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:112) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.nio.NettyConnectionHandler.channelRead0(NettyConnectionHandler.java:142) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at org.jivesoftware.openfire.nio.NettyConnectionHandler.channelRead0(NettyConnectionHandler.java:50) [xmppserver-4.8.0-beta.jar:4.8.0-beta]
at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) [netty-handler-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346) [netty-codec-4.1.100.Final.jar:4.1.100.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318) [netty-codec-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
at io.netty.handler.traffic.AbstractTrafficShapingHandler.channelRead(AbstractTrafficShapingHandler.java:506) [netty-handler-4.1.100.Final.jar:4.1.100.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) [netty-transport-4.1.100.Final.jar:4.1.100.Final]
:
Hi @Naveen_Sanjeeva! The stack trace that you’re copying is not an error, or even an issue. Note that the level on which this event was logged is TRACE which is the lowest/least important level possible.
What is happening here is that Openfire tries to find the TLS certificates offered by the client, and this client does not offer any. This is perfectly reasonable. I would even assume that this is the case for most clients. TLS certificates offered by a client are needed only when the client tries to authenticate with client certificates (commonly referred to as ‘mutual authentication’ or SASL EXTERNAL). It is somewhat similar to some high-security websites that require you to install a client certificate in your browser.
While continuing to try 4.8.0 in a more loaded environment, we are noticing a continuous increase in RSS while the heap itself is not growing by much. The java process eventually dies. Nothing conclusive from examining the process state using jcmd (VM.native_memory summary). Any thoughts on how to troubleshoot this?
Hi Guus - Thanks for the pointers. We are still investigating this and have had no luck with the various recommendations for similar RSS growth issues. We tried this on both Ubuntu 22.04 (JDK 21) and Ubuntu 20.04 (JDK 11/JDK 17) with similar results under load (< 1500 concurrent connections). Please share the system configuration that’s used for testing your releases of Openfire.
This starts to sound more like a generic Java/OS issue than anything Openfire-specific. Depending on configuration, it could be reasonable for the JVM to claim (a lot) more memory from the OS than what it’s currently using. The difference between 800Mb and 10Gb is quite large, though…