[erlang-questions] YAWS with SSL Connections Problem
Chih - Wei Yu [ MTN - Innovation Centre ]
yu_c@REDACTED
Tue Oct 20 10:20:46 CEST 2009
Hi Tomas,
Thank you for your response. But with the enoproxysocket error, will it cause a buildup of these IDLE 'connections' that we're seeing on the box?
$ netstat -an | grep IDLE | more
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
*.* *.* 0 0 49152 0 IDLE
$ netstat -an | grep IDLE | wc -l
1699
Cause after we restart the runtime, the ssl_esock process is restarted and the above is cleared.
The ulimit for file descriptors is set to 4096 but even if this is increased I think we will still have the same problem as the IDLEs continuous to build up.
Is there any other solution perhaps that we can try?
Regards,
Chih-Wei Yu
-----Original Message-----
From: Tomas Abrahamsson [mailto:tomas.abrahamsson@REDACTED]
Sent: Tuesday, October 20, 2009 9:45 AM
To: Chih - Wei Yu [ MTN - Innovation Centre ]
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] YAWS with SSL Connections Problem
> We're running YAWS (1.75)(Erlang 12B-5) with SSL and there was a
> stage where we ran out of file descriptors. Now what seems to be is
> that ssl_esock process is using up all the descriptors.
I don't remember exactly about reasons for usage of
large number of file descriptors, though it is possible
to raise the number of file descriptors a process can
use, see the ulimit command (and on Solaris, also
documentation for the /etc/system file, where you can
raise the hard limits). It might possibly have
something to do with your second question:
> The following is also seen in the nohup.out
> =ERROR REPORT==== 19-Oct-2009::16:08:41 ===
> SSL accept failed: enoproxysocket
> The OS we're running on is Solaris 10.
We've seen enoproxysocket on Solaris 10 with the old
ssl implementation[1]. Not on Solaris 9 or 8 and not on
Linux. IIRC, we've seen it under both light and heavy
load.
The high-level reason is that the Erlang side and the
ssl_esock gets out of sync with each other.
The low-level details are that the Erlang side opens a
TCP connection to the ssl_esock, then sends a
proxy_join command for that tcp-connection to the
ssl_esock's stdin, but on Solaris 10, the ssl_esock
discovers these two events in the opposite order, gets
confused, and responds with the enoproxysocket error.
The net result is that the SSL connection will be
unusable, the Erlang side can't use it since it's
received an error response from ssl_esock, and the
ssl_esock doesn't know what to do with it. It seems
this can happen both when accepting incoming SSL
connections and when making an outgoing SSL connection.
The ssl_esock code hasn't changed from R12B-4 to R13B02-1,
it seems (except for copyright notices), so just
upgrading to a newer Erlang version won't automatically
solve your problem, unfortunately.
______
[1] The old ssl-implementation, i.e: an Erlang-side and
the C-side ssl_esock, as opposed to the new_ssl which
does all the SSL protocol handling in Erlang, see the
ssl documentation for further details, espcially the
{ssl_imp,new} option.
BRs
Tomas
NOTE: This e-mail message is subject to the MTN Group disclaimer see http://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
More information about the erlang-questions
mailing list