Cory Winter wrote:
> Hi,
>
> On Tue, Jan 09, 2001 at 09:20:04AM -0800, Geoff Thorpe wrote:
> > On Tue, 9 Jan 2001, Cory Winter wrote:
> >
> > > Anyway, I'm wondering if users are also expected to make the info callbacks
> > > thread safe? Don't get me wrong, I realize that this may sound like a stupid
> > > question but really, are the callbacks themselve thread safe? I'm at my wits
> > > end over what the problem is.
> >
> > Generally speaking, OpenSSL's thread safety covers synchronising access to
> > OpenSSL-internal state, eg. internal tables, lists, etc (the error
> > stack(s), internal SSL_SESSION cache being good examples). Externally
> > however, a caller cannot expect all OpenSSL "objects" to be inherently
> > thread-safe ... to do so would require OpenSSL to put locking throughout
> > the library and would degrage performance significantly. In particular, if
> > you wish to use SSL objects across threads, you should synchronise access
> > to them yourself. Perhaps this is the problem?
>
> I realize this. I had already done this. Actually I think I may have found
> the source of the problem but not the reason. After searching the mailing
> list I found someone who was experiencing a similar problem. ie. heavy load,
> resulting in "bad mac decode" and "invalid parameter" messages in the error
> queue. The work-around was to not use SSL_SESSION_CACHE_BOTH but just
> SSL_SESSION_CACHE_SERVER. (the default I believe) Anyway, after doing this,
> my app seems to be fine once more.
>
> Does anyone know why this fixes the problem?
>
No I don't know how to fix the problem but I am looking REALLY hard to fix some
problem that
may very well be related. We have some kind of problem, when using threads, that
occur after running steady for 50 minutes (30 sometimes) during 100% load. Suddenly
everything just breaks down (SEGV etc.)
Without threads we have never observed any problems.
I have seen code that may explain why your code is running better with
SSL_SESSION_CACHE_SERVER, it is in the routine ssl_update_cache.
There is a test for when to call SSL_CTX_flush_session that checks if a counter for
"good" session has
reach 255. But the problem is that if you are using CACHE_BOTH then the client
sess_connect_god is
used even if you are not using any SSL_connect's at all. This implies that
SSL_CTX_flush_session
will not be called (at least not from that point) if you use SSL_SESS_CACH_BOTH and
not use SSL_connect.
Correct me if i am wrong:
void ssl_update_cache(SSL *s,int mode)
...
/* auto flush every 255 connections */
i=s->ctx->session_cache_mode;
if ((!(i & SSL_SESS_CACHE_NO_AUTO_CLEAR)) &&
((i & mode) == mode))
{
if ( (((mode & SSL_SESS_CACHE_CLIENT)
?s->ctx->stats.sess_connect_good
:s->ctx->stats.sess_accept_good) & 0xff) == 0xff)
{
SSL_CTX_flush_sessions(s->ctx,time(NULL));
}
}
}
/Tony
begin:vcard
n:Rogvall;Tony
tel;cell:+46 709 390 183
tel;home:+46 8 574 00 306
tel;work:+46 8 545 55 027
x-mozilla-html:FALSE
url:http://www.bluetail.com
org:Alteon WebSystems
adr:;;S:t Eiksgatan 44;Stockholm;;SE-112 34;Sweden
version:2.1
email;internet:[EMAIL PROTECTED]
x-mozilla-cpt:;29952
fn:Tony Rogvall
end:vcard
