Allow me to step into this thread and my appology for not
being able to go over this thread completely from its initial
point.
I also want to make sure I understand the process you
described in your message as I described below as follows:
C ---- S --------------------- TIBCO/MW
|
|{ssl}
|
+-- SOAP/S
C: Client
S: Your Server
TIBCO/MW: TIBCO rendezvous middleware
SOAP/S: SOAP Server
Excluding all other concerns such as Reliability, et al. and
only focusing on the Performance as well as Problem solving
parts, we should take this as an architectural issue.
1) The "S" must be able to balnace the loads, a.k.a., load
balancing, in both Software and Hardware. The same can be
applied to all other Servers in either standalone or environment
mode. The decision can be made depends on the varuous
factors based on the Requirements
2) The SSL connection is very expensive in terms of computing
process and cost a major performace issue which usually lead
to the unacceptable result. Thus, you may allocate a seperate
resource, e.g., a host, cluster, or so from the hardware standpoint,
to handle the SSL connections. We call it "SSL/S" just for our
conveience and the security between your S and SSL/S is a seperate
issue so that I will not cover here. But can be done in a simple
way -- talk to your Sys/Net Admin.
Returning from a little digression, your S simply forward the
SOAP request message to the SSL/S and wait for the response.
The performace intensive process, i.e., the chunk of SSL connections,
are handled between SSL/S and SOAP/S.
If that can be a working solution, you may still face the
performace issue between SSL/S and SOAP/S. But that can
be solved throught the dynamic load balancing -- which should
be viewed as an architectual issue as well. One of techniques
I used in a similar situation is to create a seperate socket with
a higher priority that monitors the server's slave sockets and
returns the status of those sockets. But that can be done in a
various ways depend on the scope.
Otherwise, your test folks need to create a specific test case
to specifiy when the problem happened, including the #s of
processes, threads, sockets, etc. while monitoring the hardware/
network usage. So if the problem remains while the hardware/
network resources are available, you can narrow down the
problem in the app. level.
Hope this helps,
Pae
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 03, 2003 2:36 AM
Subject: Memo: Re: Timeout on SSL sockets
> Scott,
>
> Thanks. Actually I have downloaded the source code of 2.3.1 and change it
> myself before. As I said, it works - most of the time.
>
> Let me give you more background on my problem. My program is server
process
> which subscribes real time data through TIBCO rendezvous middleware. When
> the server receives a data event update, it will do some processing on it
> and then send a SOAP message to another server in SSL. As the socket read
> is a blocking call, a thread is created to do it so that the main thread
> can still handle subsequent data update. To improve performance, I have
> also used the Apache thread pool library.
>
> It works well until I do a stress test. The SOAP receiving server has
> severe performance problem and delayed replies to my SOAP message. My
> message sending threads are being blocked and so more and more threads is
> allocated to handle subsequent data updates from the middleware - finally
> all threads are busy and the thread pool can no longer give me free
> threads.
>
> Then, I look at the SSLUtils source code and made similar changes as you
> did. It works well at the beginning - the socket read timeout if my
> receiving server does not reply within a time period. However, as volume
> grows, it does not work and again hold up my threads.
>
> I started to wonder if the read timeout doesn't get triggered because my
> server is too busy but I have no way to prove it. At this point I am in
> fact getting stuck on this problem. :(
>
> Any idea/help is greatly appreciated..
>
> Thanks.
>
> Billy
>
>
>
>
>
>
> "Scott Nichol" <[EMAIL PROTECTED]> on 03 Sep 2003 01:11
>
> To: <[EMAIL PROTECTED]>
> cc:
>
>
>
> Our Ref: Your Ref:
>
>
>
> Subject: Re: Timeout on SSL sockets
>
>
> I have committed the change to SSLUtils. You can get it in the next
> nightly build, or grab the source from CVS, e.g. at
>
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-soap/java/src/org/apache/so
ap/util/net/SSLUtils.java?rev=HEAD&content-type=text/plain
> .
>
> Scott Nichol
>
> Do not send e-mail directly to this e-mail address,
> because it is filtered to accept only mail from
> specific mail lists.
> ----- Original Message -----
> From: "Scott Nichol" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, September 02, 2003 11:17 AM
> Subject: Re: Re: Timeout on SSL sockets
>
>
> There are two different places for timeouts, socket connections and socket
> reads. Prior to JDK 1.4, there was no way to set the timeout for socket
> connections, because the Socket constructor also established the
> connection. Starting with JDK 1.4, there is also a default constructor
> that does not establish the connection, and a separate connect method with
> a timeout parameter. Timeouts for socket reads are set by setSoTimeout,
> which has been around since early JDKs.
>
> Apache SOAP has called setSoTimeout for some time. Version 2.3.1 calls
it.
> Only the nightly build of Apache SOAP leverages the ability of JDK 1.4 to
> timeout the connect. If you are using JDK 1.3.x, you can 'hang' on the
> connection, although I would not continue for an infinite amount of time,
> as TCP/IP would normally stop trying to establish the connection after a
> few SYNs are sent.
>
> In looking at the code, it appears as if read timeouts are not set before
> handshaking, which probably makes it possible to hang indefinitely during
> the handshake. I will make changes to SSLUtils to set read timeouts
before
> handshaking.
>
> Scott Nichol
>
> Do not send e-mail directly to this e-mail address,
> because it is filtered to accept only mail from
> specific mail lists.
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, September 02, 2003 8:31 AM
> Subject: Memo: Re: Timeout on SSL sockets
>
>
> > I have tried this before and it seems to work only for HTTP but not
> HTTPS.
> >
> > When looking at the source code in SSLUtils, I found the timeout is set
>
> after the SSL handshaking and I suspect that's the reason why it doesn't >
> work. I've modified the code to set the timeout before handshaking and it
> > works - most of the time. For some cases it doesn't work.
> >
> > Actually does anyone how the timeout is implemented? Would the timeout
> > mechanism be not working if my program (which is a multi-thread one) is
>
> extremely busy?
> >
> > Billy
> >
> >
> >
> >
> > To: [EMAIL PROTECTED]
> > cc:
> >
> >
> >
> > Our Ref:
> > Your Ref:
> > Subject: Re: Timeout on SSL sockets
> >
> >
> >
> > I believe you can set the SO_TIMEOUT with Apache SOAP 2.3.1
> >
> > In HTTPUtils, I see this:
> >
> > if (timeout > 0) // Should be redundant but not every JVM
> > likes this
> > s.setSoTimeout(timeout);
> >
> > ... where the SO_TIMEOUT is set after creating the socket ( be it SSL or
> > non-SSL ).
> >
> >
> > [EMAIL PROTECTED] wrote:
> >
> > >Hi all,
> > >
> > >I want to have a timeout mechanism when my program send a SOAP message
> to
> > a
> > >server using SSL. It does not work in my version (2.3.1) of Apache SOAP
> > (my
> > >program waits indefinitely if the server do not respond). I have
browsed
> > >the nightly builds and found a fix there but it requires JDK 1.4.x.
> > >
> > >Anyone know if a fix exists for JDK 1.3.x?
> > >
> > >Thanks.
> > >
> > >Billy
> > >
> > >************************************************************
> > >The Hongkong and Shanghai Banking Corporation Limited
> > >whose registered address is 1 Queen's Road Central, Hong Kong
> > >************************************************************
> > >
> > >
> > >
> > >
> > >
> > >**********************************************************************
> > >This E-mail is confidential. It may also be legally privileged.
> > >If you are not the addressee you may not copy, forward, disclose
> > >or use any part of it. If you have received this message in error,
> > >please delete it and all copies from your system and notify the
> > >sender immediately by return E-mail.
> > >
> > >Internet communications cannot be guaranteed to be timely,
> > >secure, error or virus-free. The sender does not accept liability
> > >for any errors or omissions.
> > >**********************************************************************
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Jesus M. Salvo Jr.
> > Mobile Internet Group Pty Ltd
> > (formerly Softgame International Pty Ltd)
> > M: +61 409 126699
> > T: +61 2 94604777
> > F: +61 2 94603677
> >
> > PGP Public key:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0BA5348
> >
> >
> >
> >
> >
> >
*************************************************************************
> > This message originated from the Internet. Its originator may or
> > may not be who they claim to be and the information contained in
> > the message and any attachments may or may not be accurate.
> >
> **************************************************************************
> >
> >
> >
> >
> > ************************************************************
> > The Hongkong and Shanghai Banking Corporation Limited
> > whose registered address is 1 Queen's Road Central, Hong Kong
> > ************************************************************
> >
> >
> > **********************************************************************
> > This E-mail is confidential. It may also be legally privileged.
> > If you are not the addressee you may not copy, forward, disclose
> > or use any part of it. If you have received this message in error,
> > please delete it and all copies from your system and notify the
> > sender immediately by return E-mail.
> >
> > Internet communications cannot be guaranteed to be timely,
> > secure, error or virus-free. The sender does not accept liability
> > for any errors or omissions.
> > **********************************************************************
> >
> >
>
>
>
> *************************************************************************
> This message originated from the Internet. Its originator may or
> may not be who they claim to be and the information contained in
> the message and any attachments may or may not be accurate.
> **************************************************************************
>
>
>
>
> ************************************************************
> The Hongkong and Shanghai Banking Corporation Limited
> whose registered address is 1 Queen's Road Central, Hong Kong
> ************************************************************
>
>
>
>
>
> **********************************************************************
> This E-mail is confidential. It may also be legally privileged.
> If you are not the addressee you may not copy, forward, disclose
> or use any part of it. If you have received this message in error,
> please delete it and all copies from your system and notify the
> sender immediately by return E-mail.
>
> Internet communications cannot be guaranteed to be timely,
> secure, error or virus-free. The sender does not accept liability
> for any errors or omissions.
> **********************************************************************
>
