client authentication with revoked cert results in server no response.

[Trustin Lee]

How's the CPU consumption?  Is it normal now?

It would be nice if you could provide me reproduceable code off the list.

— Trustin Lee, http://gleamynode.net/

On Fri, Apr 10, 2009 at 2:16 PM, huican ping <pinghuican at gmail.com> wrote:
> Hello Trustin,
>
> It seems not good.
>
> Now for the bad ssl handshake case, the client just stuck in waiting
> for the reply from server, but the server doesn't return anything
> after the handshake failed.
>
> For the normal case, it is still working.
>
> Not sure whether it is my setup problem here (but I don't think so).
>
> Huican
>
> On Thu, Apr 9, 2009 at 7:58 PM, Trustin Lee <tlee at redhat.com> wrote:
>> Hi Huican,
>>
>> Thanks for the detailed analysis.  I checked in the potential fix for
>> this issue.  Could you let me know if my fix works for you?  Revision
>> # is 1163.
>>
>> Cheers,
>>
>> — Trustin Lee, http://gleamynode.net/
>>
>> On Fri, Apr 10, 2009 at 9:00 AM, huican ping <pinghuican at gmail.com> wrote:
>>> Hello Trustin,
>>>
>>> Just steped through the code, and netty code FINALLY stuck in a loop
>>> in unwrap() with condition inNetBuf.hasRemaining()=true.
>>>
>>> private ChannelBuffer unwrap(
>>> // inside there is an infinite loop
>>> ...
>>>    case NEED_UNWRAP:
>>>        if (inNetBuf.hasRemaining()) {
>>>            break;
>>>        } else {
>>>            break loop;
>>>        }
>>> ....
>>> }
>>>
>>>
>>> More carefully, When the bad message comes in initially, it goes
>>> messageReceived(), some time later sshHandler.decode() goes into this
>>> unwrap() method. This time it goes out this inifite loop without
>>> problem.
>>>
>>> Because of handshake problem, after throwing SSLHandlshakeException, I
>>> close channel at exceptionCaught() in my httpHandler code. Some time
>>> later the netty code goes into closeOutboundAndChannel() method in
>>> SslHandler, it calls unwrap() method also. it did break out the
>>> infinite loop first time. Then evaluate engine.isInboundDone() is
>>> true, and it goes contenxt.sendDownstream(e).
>>>
>>> With this sendDownStream(e) call, the code goes into this unwrap()
>>> call again, and forever it stuck at the inNetBuf.hasRemaining() place.
>>>
>>> Hope this information is useful.
>>>
>>> Thanks
>>> huican
>>>
>>> On Thu, Apr 9, 2009 at 3:40 PM, huican ping <pinghuican at gmail.com> wrote:
>>>> This attachment is an un-collapsed yourkit stack for CPU usage.
>>>>
>>>>
>>>> On Thu, Apr 9, 2009 at 1:38 PM, huican ping <pinghuican at gmail.com> wrote:
>>>>> Hey Trustin,
>>>>>
>>>>> From the exceptionCaught method, I saw it is a SSLHandshakeException
>>>>> for the failed input messages, I then close() the channel, such as:
>>>>>    @Override
>>>>>    public void exceptionCaught(ChannelHandlerContext ctx,
>>>>> ExceptionEvent e) throws Exception
>>>>>    {
>>>>>       // blabbla
>>>>>        ctx.getChannel().close();
>>>>>    }
>>>>>
>>>>> These several failed messages caused CPU 100% usage. (Sorry, I was
>>>>> wrong in my original statement, which I said it was low).
>>>>>
>>>>> The yourkit showed me that CPU used at
>>>>> org.jboxx.netty.channel.AbstraceChannel.close().
>>>>> The new threadDump is attached also. This threadDump matches to the 3.1.0.BETA.
>>>>>
>>>>> Thanks a lot.
>>>>>
>>>>>
>>>>> On Thu, Apr 9, 2009 at 11:44 AM, huican ping <pinghuican at gmail.com> wrote:
>>>>>> Hello Trustin,
>>>>>>
>>>>>> I am really Sorry, my bad.
>>>>>> Just checked, and Actually the CPU usage is very high after I sent in
>>>>>> 4 input messages. So it must stuck at some loop.
>>>>>> After several failed messages (actually, 1st failed one cause CPU jump
>>>>>> to 40%, 2nd failed CPU to 80%,  3rd CPU 90%), it always keeps at 90%
>>>>>> level even there is no more messages in, FYI, the system has no other
>>>>>> heavy CPU consuming process running.
>>>>>>
>>>>>> I tried your revision 1160, and it is same as before. So please
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>