A few issues with ejabberd

I'm running ejabberd on redhat, running enterprise 3.

I've been seeing some problems with the installation, and I'm hoping someone here
might have some ideas about possible causes.
We're running it with an external authentication script (written in Perl), which
looks up user credentials from a postgres database.

1- Reasonably frequently, ejabberd will stop authenticating clients. The log files
show the client connecting, but that's it:
=INFO REPORT==== 2005-01-11 11:36:25 ===
I(<0.237.0>:ejabberd_listener:141): ({sslsocket,5,<0.30333.0>}) Accepted SSL connection {{192,168,0,40},1066} -> {{192,168,0,9},6501}

=INFO REPORT==== 2005-01-11 11:36:31 ===
I(<0.237.0>:ejabberd_listener:141): ({sslsocket,9,<0.30367.0>}) Accepted SSL connection {{192,168,0,40},1067} -> {{192,168,0,9},6501}

=INFO REPORT==== 2005-01-11 11:36:36 ===
I(<0.237.0>:ejabberd_listener:141): ({sslsocket,11,<0.30396.0>}) Accepted SSL connection {{192,168,0,40},1068} -> {{192,168,0,9},6501}

I'm wondering if ejabberd is somehow losing it's connection to the auth script? `ps`
shows the script is still resident in memory, so I'm not sure if this is the case, or
if something else is at work here.

2- File descriptors in 'ssl_esock' - I'm finding that the ssl_esock process does not
appear to be freeing up file descriptors correctly. From memory, each SSL connection uses
up 3 descriptors / process, so I'd expect this problem to be occuring when we hit 300
concurrent users. The thing is...at the moment, our user database only has about 10 users in
it, so I'm guessing that when someone logs off, the descriptors assigned to the connection
are not being freed, hence the ssl process hitting it's limit.
Has anyone else seen any similar behaviour?

Is anyone out there using ejabberd in a large system, with multiple servers?

Thanks,

James