Return-Path: Delivered-To: apmail-ws-axis-c-user-archive@www.apache.org Received: (qmail 88920 invoked from network); 5 Aug 2005 12:44:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Aug 2005 12:44:47 -0000 Received: (qmail 34294 invoked by uid 500); 5 Aug 2005 12:44:47 -0000 Delivered-To: apmail-ws-axis-c-user-archive@ws.apache.org Received: (qmail 34094 invoked by uid 500); 5 Aug 2005 12:44:45 -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 34076 invoked by uid 99); 5 Aug 2005 12:44:45 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2005 05:44:45 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_HELO_FAIL,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of PRESTONF@uk.ibm.com designates 195.212.29.137 as permitted sender) Received: from [195.212.29.137] (HELO mtagate4.uk.ibm.com) (195.212.29.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2005 05:44:35 -0700 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j75CigqQ129688 for ; Fri, 5 Aug 2005 12:44:42 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j75CigGM280820 for ; Fri, 5 Aug 2005 13:44:42 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j75CifK7001562 for ; Fri, 5 Aug 2005 13:44:41 +0100 Received: from d06ml068.portsmouth.uk.ibm.com (d06ml068.portsmouth.uk.ibm.com [9.149.38.194]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j75CifUX001559 for ; Fri, 5 Aug 2005 13:44:41 +0100 MIME-Version: 1.0 To: "Apache AXIS C User List" Subject: Fw: Closing a secure channel X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Fred Preston Date: Fri, 5 Aug 2005 13:44:20 +0100 X-MIMETrack: Serialize by Router on D06ML068/06/M/IBM(Release 6.53HF247 | January 6, 2005) at 05/08/2005 13:44:41, Serialize complete at 05/08/2005 13:44:41 Content-Type: multipart/alternative; boundary="=_alternative 0045A44480257054_=" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 0045A44480257054_= Content-Type: text/plain; charset="US-ASCII" Hi Bruce, Using your own SSL puts your problem too far out of scope for me to really know what is going on and to be able to provide useful support. It sounds like you are doing the right sort of things, but as I do not have your environment or bespoke transport/channel code I feel that there is not a lot more I can help you with at this time... Best regards, Fred Preston. Bruce McHaffie 07/25/2005 06:23 PM Please respond to "Apache AXIS C User List" To: "'Apache AXIS C User List'" cc: Subject: RE: Closing a secure channel Hi Fred, very sorry for not replying sooner. I bought a dog and then went on vacation, and then went to the JavaOne conference. :-) A1. Yes, I am using a different (not OpenSSL) library for this. I had to write an adapter layer to match your API. A2. Let me describe my application first: In my scenario the Axis client is being called by a multithreaded application. libaxis_cpp.so gets loaded once at startup, then multiple call objects are instantiated simultaneously on different threads (all pointing to the same web service). If the target protocol is https, then each call object loads my SSL channel module, which in effect is only loaded once, and passes in the socket it wants protected. Then the call objects start writing to and reading from their respective sockets. So, I guess what you say to avoid ("do not try to have simultaneous SSL communication on different threads") is exactly what I am doing :-(. But unlike OpenSSL, the SSL library I am using (from Entrust) does support multithreading. Am I right in thinking that the Axis client (and the Axis2 transport layer) supports multithreading against a single web service? If it does, then shouldn't I be able to use a threadsafe SSL library to set up multiple simultaneous SSL connections? Or am I just inviting problems with this design? As for the pool -- the issue for me was that when the call object passes data to the SSL library (or reads data from it), I need to know which instance is making the call. It would be nice if I could rely on the socket descriptor, but that is not passed in the call to SSLRead (or closeSSLChannel for that matter). So my workaround is to keep a list of thread IDs and open sockets in my SSL library. When a thread comes in to read or write I use the thread ID to fish out the correct socket descriptor. This list of socket descriptors indexed by thread IDs is what I call the "pool". Probably not a good term for it. As an aside I actually started out nailing up a single SSL connection and synchronizing access to it, but ran into problems with the Apache connector, which seemed unable to keep both sides of its connection (one to the client and one to the app server) alive. Also the socket==0 idea didn't work because the pSock variable I was holding onto gets released when the call is destroyed. Instead I changed the destructor of the SecureChannel class to close the channel. Bruce. -----Original Message----- From: Fred Preston [mailto:PRESTONF@uk.ibm.com] Sent: June 22, 2005 6:23 AM To: Apache AXIS C User List Subject: RE: Closing a secure channel Hi Bruce, Just reading your email. I'm having difficulty trying to get my head around your solution... I was wondering if you could explain in more detail the following bits:- 'my SSL library' Q1. Do you have your own SSLLibrary (i.e. different from OpenSSL?) 'socket == 0 on all existing connection objects (which I keep in a pool)' Q2. To have access to the socket (m_Sock) you need to have added code in channel.cpp/SecureChannel.cpp. In the base code, there can only be one socket open per instance of the channel object. Every time that Axis2Transport::flushOutput() is called, the open() method will be called in the channel instance (normal or secure). SecureChannel::open() ends up calling Channel::open() that will close down the previously open socket before creating a new socket of the appropriate type. Thus there is no need to keep a pool of sockets for a channel, because only one will ever be active. (Where are you keeping the 'pool' and what are connection objects?) If you have more than one web service active then you can have multiple instances of a channel object. Each object will have its own active socket. In this case you will have multiple active sockets. I believe that OpenSSL is not multi-threaded and requires mutexes. These have not been used on Axis2 so you will have to be careful that you do not try to have simultaneous SSL communication on different threads as this may lead to unexpected behaviour. Regards, Fred Preston. Bruce McHaffie 06/20/2005 03:38 PM Please respond to "Apache AXIS C User List" To: "'Apache AXIS C User List'" cc: Subject: RE: Closing a secure channel Thanks Fred. I will fix up the destructor. My original problem was that my SSL library didn't get notified when the channel closed a socket. I'm working around that now by testing for socket == 0 on all existing connection objects (which I keep in a pool) whenever openSSLConnection() gets called. It's not pretty, but seems to work so far. If you can think of a reason why this would fail embarassingly please let me know :-). Bruce. -----Original Message----- From: Fred Preston [mailto:PRESTONF@uk.ibm.com] Sent: June 17, 2005 6:23 AM To: Apache AXIS C User List Subject: RE: Closing a secure channel 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 0045A44480257054_= Content-Type: text/html; charset="US-ASCII"
Hi Bruce,
        Using your own SSL puts your problem too far out of scope for me to really know what is going on and to be able to provide useful support.  It sounds like you are doing the right sort of things, but as I do not have your environment or bespoke transport/channel code I feel that there is not a lot more I can help you with at this time...

Best regards,

Fred Preston.


Bruce McHaffie <bruce.mchaffie@entrust.com>

07/25/2005 06:23 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, very sorry for not replying sooner. I bought a dog and then went on vacation, and then went to the JavaOne conference. :-)
 
A1. Yes, I am using a different (not OpenSSL) library for this. I had to write an adapter layer to match your API.
 
A2. Let me describe my application first: In my scenario the Axis client is being called by a multithreaded application. libaxis_cpp.so gets loaded once at startup, then multiple call objects are instantiated simultaneously on different threads (all pointing to the same web service). If the target protocol is https, then each call object loads my SSL channel module, which in effect is only loaded once, and passes in the socket it wants protected. Then the call objects start writing to and reading from their respective sockets.
 
So, I guess what you say to avoid ("do not try to have simultaneous SSL communication on different threads") is exactly what I am doing :-(. But unlike OpenSSL, the SSL library I am using (from Entrust) does support multithreading. Am I right in thinking that the Axis client (and the Axis2 transport layer) supports multithreading against a single web service? If it does, then shouldn't I be able to use a threadsafe SSL library to set up multiple simultaneous SSL connections? Or am I just inviting problems with this design?
 
As for the pool -- the issue for me was that when the call object passes data to the SSL library (or reads data from it), I need to know which instance is making the call. It would be nice if I could rely on the socket descriptor, but that is not passed in the call to SSLRead (or closeSSLChannel for that matter). So my workaround is to keep a list of thread IDs and open sockets in my SSL library. When a thread comes in to read or write I use the thread ID to fish out the correct socket descriptor. This list of socket descriptors indexed by thread IDs is what I call the "pool". Probably not a good term for it.
 
As an aside I actually started out nailing up a single SSL connection and synchronizing access to it, but ran into problems with the Apache connector, which seemed unable to keep both sides of its connection (one to the client and one to the app server) alive.
 
Also the socket==0 idea didn't work because the pSock variable I was holding onto gets released when the call is destroyed. Instead I changed the destructor of the SecureChannel class to close the channel.
 
Bruce.
 
 
 
 
-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com]
Sent: June 22, 2005 6:23 AM
To: Apache AXIS C User List
Subject: RE: Closing a secure channel

Hi Bruce,
       Just reading your email.  I'm having difficulty trying to get my head around your solution...  I was wondering if you could explain in more detail the following bits:-

'my SSL library'
Q1. Do you have your own SSLLibrary (i.e. different from OpenSSL?)

'socket == 0 on all existing connection objects (which I keep in a pool)'
Q2. To have access to the socket (m_Sock) you need to have added code in channel.cpp/SecureChannel.cpp.  In the base code, there can only be one socket open per instance of the channel object.  Every time that Axis2Transport::flushOutput() is called, the open() method will be called in the channel instance (normal or secure).  SecureChannel::open() ends up calling Channel::open() that will close down the previously open socket before creating a new socket of the appropriate type.  Thus there is no need to keep a pool of sockets for a channel, because only one will ever be active. (Where are you keeping the 'pool' and what are connection objects?)  If you have more than one web service active then you can have multiple instances of a channel object.  Each object will have its own active socket.  In this case you will have multiple active sockets.  I believe that OpenSSL is not multi-threaded and requires mutexes.  These have not been used on Axis2 so you will have to be careful that you do not try to have simultaneous SSL communication on different threads as this may lead to unexpected behaviour.

Regards,

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

06/20/2005 03:38 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

     



Thanks Fred. I will fix up the destructor. My original problem was that my SSL library didn't get notified when the channel closed a socket. I'm working around that now by testing for socket == 0 on all existing connection objects (which I keep in a pool) whenever openSSLConnection() gets called. It's not pretty, but seems to work so far. If you can think of a reason why this would fail embarassingly please let me know :-).
 
Bruce.
 
-----Original Message-----
From: Fred Preston [mailto:PRESTONF@uk.ibm.com]
Sent: June 17, 2005 6:23 AM
To: Apache AXIS C User List
Subject: RE: Closing a secure channel


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 0045A44480257054_=--