RE: Closing a secure channel
Title: Message
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.sogets 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, theneach call objectloadsmy SSL channel module,
which in effect is only loaded once, andpasses in the socketit wants
protected.Then the call objects start writing to and reading from their
respectivesockets.
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
Iright in thinking that the Axis client (and the Axis2 transport layer)
supports multithreading against a single web service? Ifit does, then
shouldn't Ibe able to use athreadsafe SSL libraryto set up
multiple simultaneous SSL connections? Or am I just inviting problems with this
design?
As for
the pool -- the issue for mewas that when the call
objectpassesdata to the SSL library (or reads data fromit), 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
ofthread 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.
Thislist ofsocket descriptorsindexed 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:[EMAIL PROTECTED] Sent: June 22, 2005 6:23
AMTo: Apache AXIS C User ListSubject: RE: Closing a
secure channelHi
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
[EMAIL PROTECTED]
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 M
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 [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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.
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 [EMAIL PROTECTED]
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.
RE: Closing a secure channel
Title: Message
Hi
Fred, thanks for the reply. That would work, except the destructor forthe
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 toclean 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:[EMAIL PROTECTED] Sent: June 16, 2005 6:08
AMTo: Apache AXIS C User ListSubject: 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
[EMAIL PROTECTED]
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.
