client authentication with revoked cert results in server no response.
huican ping
pinghuican at gmail.com
Fri Apr 10 13:37:07 EDT 2009
Hello Trustin,
Also currently i have problem to generate a test code because lack of time.
Try 1171.
Now CPU is low, but:
The message doesn't go down to to our http handler, e.g,
exceptionCaught() there not get called, probably no exception was
throw?. (initially, for first 4 client requests, I got ssh error
back).
Now nothing was replied to client, and the client is just stuck
waiting for reply back from server for ever.
Our pipeline:
=============
pipeline.addLast("SslEngine", new SslHandler(engine));
pipeline.addLast("decoder", new HttpRequestDecoder());
pipeline.addLast("encoder", new HttpResponseEncoder());
pipeline.addLast("handler", httpHandler);
For part of ssl dump:
=====================
***
New I/O server worker #1-3, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertP
xception: unable to find valid certification path to requested target
New I/O server worker #1-3, SEND TLSv1 ALERT: fatal, description =
certificate_unknown
New I/O server worker #1-3, WRITE: TLSv1 Alert, length = 2
I noticed the ssl handler breaks the unwrap method at this place at
its last time:
boolean inboundDone = engine.isInboundDone();
if (inboundDone) {
break;
}
On Fri, Apr 10, 2009 at 12:53 AM, Trustin Lee <tlee at redhat.com> wrote:
> I removed a sanity check code which might be causing this problem. Rev 1169.
>
> — Trustin Lee, http://gleamynode.net/
>
>
>
> On Fri, Apr 10, 2009 at 2:47 PM, Trustin Lee <tlee at redhat.com> wrote:
>> 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
>>>
>>
>
> _______________________________________________
> 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