Running Netty 3.3.1-Final Secure Chat example out of the box gives error "Client/Server mode not yet set."

Question

I'm running the Netty 3.3.1 Secure Chat example out of the box and it is erroring out. It appears to be the Client that is having the problem--an error that reads "Client/Server mode not yet set."

I read the documentation on SSLHandler that says, "If isIssueHandshake is false (default) you will need to take care of calling handshake by your own. In most situations were SslHandler is used in 'client mode' you want to issue a handshake once the connection was established. if setIssueHandshake is set to true you don't need to worry about this as the SslHandler will take care of it. "

I tried setting setIssueHandshake to true in the client before the sslHandler.handshake method was called, but that did not change/fix the error.

Any guesses?

Thank you for any assistance for this netty newbie!

This is the client output:

Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream INFO: [id: 0x00c2a132] OPEN Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream INFO: [id: 0x00c2a132, /127.0.0.1:3082 => localhost/127.0.0.1:8443] BOUND: /127.0.0.1:3082 Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler handleUpstream INFO: [id: 0x00c2a132, /127.0.0.1:3082 => localhost/127.0.0.1:8443] CONNECTED: localhost/127.0.0.1:8443 Mar 2, 2012 10:25:27 AM securechat.SecureChatClientHandler exceptionCaught WARNING: Unexpected exception from downstream. java.lang.IllegalStateException: Client/Server mode not yet set. at com.sun.net.ssl.internal.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:609) at com.sun.net.ssl.internal.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:667) at org.jboss.netty.handler.ssl.SslHandler.handshake(SslHandler.java:358) at securechat.SecureChatClientHandler.channelConnected(SecureChatClientHandler.java:54) at securechat.SecureChatClientHandler.handleUpstream(SecureChatClientHandler.java:43) at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:61) at org.jboss.netty.handler.ssl.SslHandler.channelConnected(SslHandler.java:1202) at org.jboss.netty.channel.Channels.fireChannelConnected(Channels.java:227) at org.jboss.netty.channel.socket.nio.NioWorker$RegisterTask.run(NioWorker.java:786) at org.jboss.netty.channel.socket.nio.NioWorker.processRegisterTaskQueue(NioWorker.java:250) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:192) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)

This is the server output:

INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] OPEN Mar 2, 2012 10:25:27 AM securechat.SecureChatServerHandler handleUpstream INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] BOUND: /127.0.0.1:8443 Mar 2, 2012 10:25:27 AM securechat.SecureChatServerHandler handleUpstream INFO: [id: 0x01893efe, /127.0.0.1:3082 => /127.0.0.1:8443] CONNECTED: /127.0.0.1:3082

Answer 1

Thank you trustin. It seems that "This issue has been fixed in 3.4.0.Alpha1." is not correct.

sslEngine.setUseClientMode(true);

It worked again on 4.1.33.Final.

Answer 2

It's a known bug in the example. If you take a look into SecureChatClientPipelineFactory.java, you'll see that the line that calls SSLEngine.setUseClientMode(true) has been commented out by mistake. Please uncomment it and then it will work. This issue has been fixed in 3.4.0.Alpha1.