client authentication with revoked cert results in server no response.

[huican ping]

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
>