client authentication with revoked cert results in server no response.
Trustin Lee
tlee at redhat.com
Fri Apr 10 14:18:06 EDT 2009
I have made a small change to my fix so that unwrap can be called at
least once. Rev # is 1174.
I want to fix this problem asap, so please help me by responding asap. :-)
— Trustin Lee, http://gleamynode.net/
On Sat, Apr 11, 2009 at 2:37 AM, huican ping <pinghuican at gmail.com> wrote:
> 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
>>
>
> _______________________________________________
> 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