Return-Path: Delivered-To: apmail-ws-axis-c-user-archive@www.apache.org Received: (qmail 85803 invoked from network); 17 Jun 2005 11:53:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Jun 2005 11:53:24 -0000 Received: (qmail 82628 invoked by uid 500); 17 Jun 2005 11:53:23 -0000 Delivered-To: apmail-ws-axis-c-user-archive@ws.apache.org Received: (qmail 82608 invoked by uid 500); 17 Jun 2005 11:53:22 -0000 Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C User List" Reply-To: "Apache AXIS C User List" Delivered-To: mailing list axis-c-user@ws.apache.org Received: (qmail 82593 invoked by uid 99); 17 Jun 2005 11:53:22 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=HTML_40_50,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of PRESTONF@uk.ibm.com designates 195.212.29.134 as permitted sender) Received: from mtagate1.uk.ibm.com (HELO mtagate1.uk.ibm.com) (195.212.29.134) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jun 2005 04:53:21 -0700 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j5HANErU131184 for ; Fri, 17 Jun 2005 10:23:17 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5HANEAA285826 for ; Fri, 17 Jun 2005 11:23:14 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j5HANEZI007859 for ; Fri, 17 Jun 2005 11:23:14 +0100 Received: from d06ml068.portsmouth.uk.ibm.com (d06ml068.portsmouth.uk.ibm.com [9.149.38.194]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j5HANDvP007856 for ; Fri, 17 Jun 2005 11:23:13 +0100 In-Reply-To: <7A3E1242FA9989439AD1F9B2D71C287F06220BDA@sottmxs05.entrust.com> To: "Apache AXIS C User List" MIME-Version: 1.0 Subject: RE: Closing a secure channel X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Fred Preston Date: Fri, 17 Jun 2005 11:23:12 +0100 X-MIMETrack: Serialize by Router on D06ML068/06/M/IBM(Release 6.53HF484 | April 21, 2005) at 17/06/2005 11:23:13, Serialize complete at 17/06/2005 11:23:13 Content-Type: multipart/alternative; boundary="=_alternative 0038C65380257023_=" X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 0038C65380257023_= Content-Type: text/plain; charset="US-ASCII" Hi Bruce, You're right. Axis2 SSL was a bit of a mess and that's why it was dropped. It works, but is untidy and unfinished. Looking at the Axis2Transport code, the currently loaded channel will be deleted (and it's destructor called) when the Axis2Transport is deleted (i.e when the web service is deleted). The openConnection and closeConnection do very little in Axis2Transport and unfortunately do not communicate with the underlying channel. I was hoping that there might be a 'back door' to getting the channel object and then be able to call methods on it, but there is not... Just to recap, all of the channel close socket communication happens on the destructor (as it does in channel::~Channel()). This is missing from the SSL channel. Thus, when the web service is deleted, the Axis2Transport will delete the currently active channel (before being deleted itself). This will call the channel destructor and if it is an SSL channel nothing happens because the destructor is empty. This will leave the SSL library open causing memory leaks. The only solution to your problem is, if you have the OpenSSLChannel project, add 'closeSecureSocket();' to the empty destructor method and rebuild. Regards, Fred Preston. Bruce McHaffie 06/16/2005 04:24 PM Please respond to "Apache AXIS C User List" To: "'Apache AXIS C User List'" cc: Subject: RE: Closing a secure channel Hi Fred, thanks for the reply. That would work, except the destructor for the secure channel object (derived from Channel) is empty too. So when the channel object is destroyed in the transport destructor, the secure channel destructor gets called but doesn't do anything. So closeSSLChannel() doesn't get called when the transport object disappears. Neither does destroySSLChannelObject(), which is a shame because it would give my SSL library a chance to clean up after itself. In fact I'm not sure the SSL library gets unloaded at all. Or again, maybe I'm missing something. Bruce. PS: I'm looking at 1.5 now, but for this release I'm stuck with 1.4. -----Original Message----- From: Fred Preston [mailto:PRESTONF@uk.ibm.com] Sent: June 16, 2005 6:08 AM To: Apache AXIS C User List Subject: Re: Closing a secure channel Hi Bruce, You should now be using AXIS3 transport. The reason why the method is empty is because the socket was not closed until you deleted the web service which in turn would call the destructor on the transport object, closing and then deleting the channel object. Regards, Fred Preston. Bruce McHaffie 06/15/2005 08:30 PM Please respond to "Apache AXIS C User List" To: "'Apache AXIS C User List'" cc: Subject: Closing a secure channel A 1.4 question for you: in axis2/SecureChannel.cpp the close() method doesn't do anything. Shouldn't it at least close the connection that is opened in the open() method? For instance: void SecureChannel::close() { m_pSSLChannel->closeSSLChannel() } Or am I missing something here? Thanks, Bruce. --=_alternative 0038C65380257023_= Content-Type: text/html; charset="US-ASCII"
Hi Bruce,
        You're right.  Axis2 SSL was a bit of a mess and that's why it was dropped.  It works, but is untidy and unfinished.  Looking at the Axis2Transport code, the currently loaded channel will be deleted (and it's destructor called) when the Axis2Transport is deleted (i.e when the web service is deleted).  The openConnection and closeConnection do very little in Axis2Transport and unfortunately do not communicate with the underlying channel.  I was hoping that there might be a 'back door' to getting the channel object and then be able to call methods on it, but there is not...

Just to recap, all of the channel close socket communication happens on the destructor (as it does in channel::~Channel()).  This is missing from the SSL channel.  Thus, when the web service is deleted, the Axis2Transport will delete the currently active channel (before being deleted itself).  This will call the channel destructor and if it is an SSL channel nothing happens because the destructor is empty.  This will leave the SSL library open causing memory leaks.

The only solution to your problem is, if you have the OpenSSLChannel project, add 'closeSecureSocket();' to the empty destructor method and rebuild.

Regards,

Fred Preston.


Bruce McHaffie <bruce.mchaffie@entrust.com>

06/16/2005 04:24 PM
Please respond to "Apache AXIS C User List"

       
        To:        "'Apache AXIS C User List'" <axis-c-user@ws.apache.org>
        cc:        
        Subject:        RE: Closing a secure channel

       


Hi Fred, thanks for the reply. That would work, except the destructor for the secure channel object (derived from Channel) is empty too. So when the channel object is destroyed in the transport destructor, the secure channel destructor gets called but doesn't do anything. So closeSSLChannel() doesn't get called when the transport object disappears. Neither does destroySSLChannelObject(), which is a shame because it would give my SSL library a chance to clean up after itself. In fact I'm not sure the SSL library gets unloaded at all. Or again, maybe I'm missing something.

Bruce.
 
PS: I'm looking at 1.5 now, but for this release I'm stuck with 1.4.
 
-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com]
Sent: June 16, 2005 6:08 AM
To: Apache AXIS C User List
Subject: Re: Closing a secure channel

Hi Bruce,
       You should now be using AXIS3 transport.  The reason why the method is empty is because the socket was not closed until you deleted the web service which in turn would call the destructor on the transport object, closing and then deleting the channel object.

Regards,

Fred Preston.
Bruce McHaffie <bruce.mchaffie@entrust.com>

06/15/2005 08:30 PM
Please respond to "Apache AXIS C User List"

       
       To:        "'Apache AXIS C User List'" <axis-c-user@ws.apache.org>
       cc:        
       Subject:        Closing a secure channel

     



A 1.4 question for you: in axis2/SecureChannel.cpp the close() method doesn't do anything. Shouldn't it at least close the connection that is opened in the open() method? For instance:

void SecureChannel::close()
{
      m_pSSLChannel->closeSSLChannel()
}

Or am I missing something here?

Thanks,

Bruce.

--=_alternative 0038C65380257023_=--