jerbo128,

actually a zipped copy of your SpamFilter activity log for 6/5/06, may be trimmed from 11am to 2pm, could hopefully help us finding out why those connections still show up.

For the record I noticed this again on my install. I hadn't checked it for a while, and there were stuck connections going back days (possible more than a week). I'm running 3.0.1.558 and as I wasn't aware of any cure just restarted the SF service.

We have recently found an issue with connections steadily increasing in the following specific case.

1. Using MySQL and the MyISAM database type (InnoDB is fine, it does not cause the problem).
2. The MySQL database is being backed up using the :Lock All Tables" execution method.
3. The database backup process takes several minutes to complete.

Under the scenario above, MySQL will place a write lock on all tables, preventing any application from making DB updates. This will prevent SpamFilter to add new records. We have safety features that timeout the update process in case the SQL update take too long. However, due to a "missing feature" (i.e. a bug....) in the MySQL ODBC driver, the timeout function is not implemented correctly.
This causes SpamFilter to wait indefinetly until the lock is removed. The connection thread thus will not terminate until the email has been inserted in the database, and this will cause the number of incoming connections thread to increase steadily, until the lock is lifted. But if the backup process takes several minutes to complete, this may cause the "Too many connections" limit to be reached.

It is to be noted that the problem occurs only in the specific scenario above. If the MySQL database is unavailable for any other reason (DB is down, non-existent tables, incorrect permissions for example), SpamFilter will immediately see the DB connectivity issues and will simply continue processing emails without quarantining them.

We've just uploaded build 3.0.1.571 that addresses this problem and prevents it from occurring. This did require major changes to how quarantined emails are processed, so, while testing has shown no issues, it is to note that this *is* a pre-release build, and as such, may not be as stable as an official release.

FYI:  I am running Ms Access - and for the record have not had any more of these "stuck connections"  in the past week.

jerbo128

I'm seeing stuck connections again. ATM SF is running at 98% CPU. There are 24 Stuck connections from yesterday between 22:19:52 and 22:22:33 BST (3 minute period). They are stuck in either QUIT, QUEUEING EMAIL or RCPT TO.

I have another 3 stuck from today, at 15:02:57, 11:16:40 & 11:26:57. In NOOP, and PROCESSING DATA... Even though none of the IPs show in a netstat.

I've zipped and emailed an hours worth of logs for you from yesterday.

Regards,
Lyndon.


Edited by lyndonje

Thanks to everyone for their logs. Unfortunately as of today we still have not been able to reproduce the problem.

We did however completely rewrite the procedure that checks for idle connections and diisconnects them. We're going in a bit blind as we don't know the cause, but we've tried to forsee as many scenarios as possible.

A new pre-release build (3.0.1.573) is available in the registered user area to attempt one more shot at adressing this.

So far so good.... no stuck connections yet.

I've just checked that I'm running 3.0.2.573 and I am.

I've just logged into the registered area and can now only see:

   SF2.6.3.487.zip
   SF2.7.1.535.zip
   SF3.0.1.560.zip
   SF3.0.1.561.zip
   SF3.0.1.567.zip
   SF3.0.2.571.zip

Roberto, where has it gone? Must have been there before for me to download...?


Edited by LogSat

My .573 had locked up once as well but I was going to see if it happened again. Too bad it happened at 4:00am and my monitoring system was able to page me and wake me up.

Will load up 575 tonite and keep my fingers crossed.

Bad news, running 3.0.2.575 I have 6 stuck connections.

Have emailed you further details.

Hi mikek, out of interest do you use the 'Authorized To' filter?

If so, are the stuck connections to recipients that are either covered by *@domain or not listed in your Authorised To file?

I might be way off here, so don't want to cloud things or lead people down the wrong path, but thats what I have noticed on these recent stuck connections.


Edited by lyndonje

You may not have seen my edited comment at 4:19, I added:

If so, are the stuck connections to recipients that are either covered by *@domain or not listed in your Authorised To file?

I might be way off here, so don't want to cloud things or lead people down the wrong path, but thats what I have noticed on these recent stuck connections.

No, all my recent stuck connections are to users which are listed individually in the authorized-to list.

18 stuck connections in the last 24 hours. sorry to say that looks to me like it even got worse with .575

Edited by mikek