client authentication with revoked cert results in server no response.

Trustin Lee tlee at redhat.com
Thu Apr 9 20:58:37 EDT 2009


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
>




More information about the netty-users mailing list