Hi Trustin,<br><br>Thanks for the insight into the reason(s) for the errors. I guess you might be correct, I am closing the connections from the handler (if read timeouts occur). That might be the cause of these exceptions, I will try to re-test it without the timeouts.<br>
<br>I do observe timeouts in my logs, however I am yet to figure out as to why these timeouts occur in the first place. My clients are configured to send a heartbeat message every 20 seconds and ReadTimeout timer is configured to 60 seconds, so timeouts should not occur in the first place. <br>
<br>Will keep you updated with my investigations, meanwhile switching to the latest Netty! :)<br><br>Thanks for the great work!<br><br>Regards,<br><br>Virat<br><br><div class="gmail_quote">On Thu, Jun 18, 2009 at 7:43 PM, "ÀÌÈñ½Â (Trustin Lee)" <span dir="ltr"><<a href="mailto:trustin@gmail.com">trustin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I did some Googling and found that the exception you mentioned is raised<br>
here in SSLEngineImpl.java:<br>
<br>
case Record.ct_change_cipher_spec:<br>
if ((connectionState != cs_HANDSHAKE<br>
&& connectionState != cs_RENEGOTIATE)<br>
|| inputRecord.available() != 1<br>
|| inputRecord.read() != 1) {<br>
fatal(Alerts.alert_unexpected_message,<br>
<div class="im"> "illegal change cipher spec msg, state = "<br>
</div> + connectionState);<br>
}<br>
...<br>
<br>
connectionState '6' means 'cs_CLOSED', which means:<br>
<br>
1) Server closed the connection (i.e. you called Channel.close() by<br>
yourself),<br>
2) Client closed the connection, or<br>
3) SSLEngine has shut itself down due to some prior fatal error during<br>
communication.<br>
<br>
The case 2 cannot occur in this problem because the client cannot send<br>
the 'change_cipher_spec' message to the closed connection.<br>
<br>
If the case 3 is true, you should have get a prior exception. Did you?<br>
You might want to set a global breakpoint for 'SSLException' to make<br>
sure no prior exception was raised.<br>
<br>
If the case 1 is true, it means the client sent the 'change_cipher_spec'<br>
message while you try to close the channel, consequently initiating SSL<br>
closure. Could you let me know if the exception is raised when you call<br>
Channel.close()?<br>
<br>
There is possibility that the SSL message has been corrupted for some<br>
reason, but I'm not sure this is the case considering the exception<br>
message you're getting is always same.<br>
<br>
HTH,<br>
<font color="#888888">Trustin<br>
</font><div><div></div><div class="h5"><br>
On 2009-06-18 ¿ÀÈÄ 10:06, "ÀÌÈñ½Â (Trustin Lee) wrote:<br>
> I tried to reproduce the problem with the following test code. Can you<br>
> reproduce the problem with it?<br>
><br>
> public class Tester {<br>
><br>
> public static void main(String[] args) throws IOException {<br>
><br>
> SSLContext.setDefault(SecureChatSslContextFactory.getClientContext());<br>
> Socket s =<br>
> SSLSocketFactory.getDefault().createSocket("127.0.0.1", 9080);<br>
><br>
> InputStream in = s.getInputStream();<br>
> OutputStream out = s.getOutputStream();<br>
><br>
> byte[] msg = new byte[] { 'H','E', 'L', 'L', 'O', 0x04 };<br>
><br>
> for (int i = 0;; i ++) {<br>
> if (i % 1000 == 0) {<br>
> System.out.println(i);<br>
> }<br>
> out.write(msg);<br>
><br>
> //for (;;) {<br>
> // int c = in.read();<br>
> // if (c == 0x04 || c < 0) {<br>
> // break;<br>
> // }<br>
> //}<br>
> }<br>
> }<br>
> }<br>
><br>
> Please note that I used the bogus context factory which is provided with<br>
> the Netty SecureChat example. I'm testing against Netty trunk on<br>
> Windows (no access to Solaris at the moment.)<br>
><br>
> Please feel free to modify the tester and let me know if you succeeded<br>
> to reproduce the problem.<br>
><br>
> Thanks,<br>
> Trustin<br>
><br>
> On 2009-06-18 ¿ÀÈÄ 9:41, Virat Gohil wrote:<br>
>> Hi Trustin,<br>
>><br>
>> some more information about my setup:<br>
>><br>
>> I have about 3000 NE (Client), which connect to the server. The<br>
>> connections are persistent, i.e the connections are never meant to be<br>
>> closed. you may keep the connections open forever. and send a message<br>
>> from the client every 20 seconds.<br>
>><br>
>> As soon as the client's connection is accepted (i.e TCP handshake is<br>
>> finished), the client will start sending the messages from its queue, on<br>
>> an average the queue size would be 5 messages. so you may want to<br>
>> replicate this behavior as well.<br>
>><br>
>> E.g:<br>
>> 1. Client connects to the server.<br>
>> 2. Client sends Message M1, waits for the server to acknowledge the<br>
>> message (timeout is 5 secs).<br>
>> 3. if the server fails to acknowledge the message within 5 seconds, then<br>
>> the client re-sends the same message. Else sends the next message.<br>
>> 4. The acknowledgment from server to client is at application level, you<br>
>> may replicate by echoing the same message.<br>
>><br>
>> I am running Sun Solaris 10, with Sun's hotspot JVM 1.5.<br>
>><br>
>> Please let me know if you need more information on my setup.<br>
>><br>
>> Thanks,<br>
>><br>
>> Virat<br>
>><br>
>> I will either find a way or make one.<br>
>><br>
>><br>
>> On Thu, Jun 18, 2009 at 6:04 PM, "ÀÌÈñ½Â (Trustin Lee)"<br>
>> <<a href="mailto:trustin@gmail.com">trustin@gmail.com</a> <mailto:<a href="mailto:trustin@gmail.com">trustin@gmail.com</a>>> wrote:<br>
>><br>
>> Do I need to keep handshaking making a new connection every time for 20<br>
>> minutes, or just keep the connection open and keep sending messages?<br>
>><br>
>> On 2009-06-18 ¿ÀÈÄ 8:45, Virat Gohil wrote:<br>
>> ><br>
>> > Hi All,<br>
>> ><br>
>> > I am getting the following exception after about 20 minutes of<br>
>> running time<br>
>> > using my server:<br>
>> ><br>
>> > EXCEPTION: javax.net.ssl.SS<br>
>> > LException: illegal change cipher spec msg, state = 6<br>
>> > javax.net.ssl.SSLException: illegal change cipher spec msg, state = 6<br>
>> > at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown<br>
>> > Source)<br>
>> > at<br>
>> com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)<br>
>> > at<br>
>> com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)<br>
>> > at<br>
>> com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(Unknown<br>
>> > Source)<br>
>> > at<br>
>> com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(Unknown<br>
>> > Source)<br>
>> > at<br>
>> com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(Unknown Source)<br>
>> > at javax.net.ssl.SSLEngine.unwrap(Unknown Source)<br>
>> > at<br>
>> > org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:699)<br>
>> > at<br>
>> > org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:445)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:244)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:184)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:87)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:344)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:331)<br>
>> > at<br>
>> > org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:303)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:255)<br>
>> > at<br>
>> > org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:176)<br>
>> > at<br>
>> ><br>
>> org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:49)<br>
>> > at<br>
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown<br>
>> > Source)<br>
>> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown<br>
>> > Source)<br>
>> > at java.lang.Thread.run(Unknown Source)<br>
>> ><br>
>> > I am attaching an example server along with this email, the<br>
>> clients may send<br>
>> > any random string with ascii char (0x04) as delimiter.<br>
>> ><br>
>> > <a href="http://n2.nabble.com/file/n3104250/NioServer.tar.bz2" target="_blank">http://n2.nabble.com/file/n3104250/NioServer.tar.bz2</a> NioServer.tar.bz2<br>
>> ><br>
>> > Kindly suggest a solution or cause to this issue.<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> > Virat<br>
>><br>
>><br>
>> --<br>
>> — Trustin Lee, <a href="http://gleamynode.net/" target="_blank">http://gleamynode.net/</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> netty-users mailing list<br>
>> <a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a> <mailto:<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
>><br>
>><br>
>><br>
>> ------------------------------------------------------------------------<br>
>><br>
>> _______________________________________________<br>
>> netty-users mailing list<br>
>> <a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
><br>
><br>
><br>
> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> netty-users mailing list<br>
> <a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
<br>
<br>
--<br>
— Trustin Lee, <a href="http://gleamynode.net/" target="_blank">http://gleamynode.net/</a><br>
<br>
</div></div><br>_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
<br></blockquote></div><br>