Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 8424 invoked from network); 29 Nov 2005 01:05:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 Nov 2005 01:05:28 -0000 Received: (qmail 84056 invoked by uid 500); 29 Nov 2005 01:05:28 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 83777 invoked by uid 500); 29 Nov 2005 01:05:26 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 83754 invoked by uid 99); 29 Nov 2005 01:05:26 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 17:05:26 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.198 as permitted sender) Received: from [64.233.184.198] (HELO wproxy.gmail.com) (64.233.184.198) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2005 17:06:09 -0800 Received: by wproxy.gmail.com with SMTP id 68so1928605wri for ; Mon, 28 Nov 2005 17:04:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=IsThUS7eOYfTpJMhsN1Ik8VoIwWN+AlH8xWy2mwx+dchscuUaR8QAFIn5brkQYUe0/g2HtPpBH3uGzFnH9NVaIXB+i9yWdL0GmyCWe/RkFEnaZxtt8iR7VwkIXD0HBG7YkOM8WBf/hhFBxoKrWoTyU7OBPAfMy9VtAVkSHjTy1Q= Received: by 10.54.143.1 with SMTP id q1mr9098057wrd; Mon, 28 Nov 2005 17:04:17 -0800 (PST) Received: by 10.54.127.2 with HTTP; Mon, 28 Nov 2005 17:04:16 -0800 (PST) Message-ID: <768dcb2e0511281704s399d662l@mail.gmail.com> Date: Tue, 29 Nov 2005 10:04:16 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: [mina] running code after ssl handshake In-Reply-To: <438B6903.90405@pandora.be> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42311_24350515.1133226256750" References: <43838591.8040403@pandora.be> <768dcb2e0511221428g3e263c4fo@mail.gmail.com> <438B6903.90405@pandora.be> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_42311_24350515.1133226256750 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Maarten, 2005/11/29, Maarten Bosteels : > > Before I read your reply I had naively modified the 0.8.1 version of > SSLHandler in a similar way: > I added the following code: > > initialHandshakeComplete =3D true; > + try { > + session.setAttribute("SSL_HANDSHAKE_COMPLETE", > Boolean,TRUE) > + nextFilter.sessionOpened(session); > + } catch (Exception e) { > + log.error ("calling nextFilter.sessionOpened() failed"= , > e); > + } > return; > > Thus I abuse the sessionOpened event for notification. And my event > handler checks the session attribute to see if hanshake is complete. > > public void sessionOpened(ProtocolSession session) throws Exception { > if (session.getAttribute("SSL_HANDSHAKE_COMPLETE") =3D=3D null) { > doThis(session); > } else { > doThat(session); > } > } It will work fine IMHO, but you'll have to do some work when you migrate to 1.0. :) But when I create a lot of simultaneous connections, it sometimes happens > that the session attribute is already set when the first sessionOpened ev= ent > > is checking it, resulting in two calls to doThis() and no call to > doThat(). Hmm this might be a bug. Another person reported this issue today. I'll try to figure it out. Do you see a better solution based on mina-0.8.1 ? > Do you see any other gaping holes in my approach ? I think it is not a bad solution. It will work, and there'll be no gapping holes. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_42311_24350515.1133226256750 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Maarten,

2005/11/29, Maarten Bos= teels <m.bosteels@pandora.be>:
Before I read your reply I had naively modified the 0.8.1 version of SSLHandler in a similar way:
I added the following code:

            &nb= sp; initialHandshakeComplete =3D true;
+            try&nbs= p;  {
+            &n= bsp;  session.setAttribute("SSL_HANDSHAKE_COMPLETE", Boolean,TRUE)
+            &n= bsp;   nextFilter.sessionOpened(session);
+            &n= bsp; } catch (Exception e) {
+            &n= bsp;     log.error ("calling nextFilter.sessionOpe= ned() failed", e);
+            &n= bsp; }
            &nb= sp; return;

Thus I abuse the sessionOpened event for notification. And my event handler checks the session attribute to see if hanshake is complete.

  public void sessionOpened(ProtocolSession session) throws Exception = {
    if (session.getAttribute("SSL_HANDSHAKE_COMPLETE&qu= ot;) =3D=3D null) {
      doThis(session);
    } else {
      doThat(session);
    }
  }

But when I create a lot of simultaneous connections, it sometimes happens that the session attribute is already set when the first sessionOpened event
is checking it, resulting in two calls to doThis() and no call to doThat().

Hmm this might be a bug.  Another perso= n reported this issue today.  I'll try to figure it out. 
Do you see a better solution based on mina-0.8.1 ?
Do you see any other gaping holes in my approach ?

I = think it is not a bad solution.  It will work, and there'll be no gapp= ing holes. :)

Trustin
--
what we call human natu= re is actually human habit
--
http://gleamynode.net/ ------=_Part_42311_24350515.1133226256750--