View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008885 | mantisbt | public | 2008-02-13 03:06 | 2012-08-26 16:17 | |
Reporter | Ellerbrok | Assigned To | dregad | ||
Priority | normal | Severity | block | Reproducibility | sometimes |
Status | closed | Resolution | duplicate | ||
Product Version | 1.1.0 | ||||
Summary | 0008885: Sending emails blocks the whole Tracker | ||||
Description | When a user makes changes to a bug, or reports a new bug or does anything that involves sending mails to other Bugtracker users the whole Bugtracker locks up. Is comes into a "Waiting for server..." state and never returns from it. (I really waited a long time!) | ||||
Steps To Reproduce | I investigated the problem a bit and found a reason why this is so, but only a very dirty workaround. You put all mails into the If that happens, the next change in Bugtracker, the next attempt to send new mails will (a) put it's own mails in the And then while trying to send the first of the old, remaining mails the function $mail->Send() in function email_send( $p_email_data ) in line 797 in the email_api.php never returns. I always have to manually remove all mails from | ||||
Tags | No tags attached. | ||||
Is there a reason why you don't go with the cronjob approach? It would be interesting to check the protocol log of your email server and see what happens when Mantis attempts to send the emails that are stuck. |
|
Hi Victor, we aren't using the cronjobs because our Apache/MySql is running on a Windows 2003 Server. And as far as I know there is no Cron available. Same to the protocol I think. |
|
Do you use the local Smtp server or do you use your ISP's email server? As for the cronjob, you should use Windows Task Scheduler: |
|
I call that "self inflicted pain"... |
|
I changed the mail sending to a cron-like way using the Windows Task Scheduler and then closely I watched the behaviour untill now. It seems that there are no more blocking mails. So for my purposes this issue can be closed. But why doesn't this work well without the scheduler? |
|
I guess in order to understand this, we need to see why emails sometimes get stuck and then later go through. We will need protocol logs to be able to do that. |
|
After changing to the semi-cronjob-mode no more emails stuck. So I think we can consider this problem gone. |
|
Ok. thanks for letting us know |
|
Sorry to reopen this, but meanwhile I idenfiied two mails that, if inserted into the mail-table are blocking the system. The user interface is working fine, but your background mail sending script is not terminating. After deleting this mails everything works fine. Inserting again blocks again. Best regards, |
|
2008-05-19 09:13
|
|
Ellerbrok, Where is this "background mail sending script" ? And I'd be interested to see how to configured Windows Task Scheduler for this purpose - I am in the same boat, and have started on another tack: 0008561:0018266 |
|
Hi swellnuts, it's very easy. Just add a task to the Windows Task Scheduler that is executing The "core\send_emails.php" should be part of your installtion. In your other task you complain about missing documentation. Hmm well, I found it at the first glance. Here it comes: http://www.mantisbt.org/wiki/doku.php/mantisbt:setting_up_mail_queuing Best regards, |
|
Fantastic thanks a bunch. I'll get right on it. WRT documentation, currently, there is:
I humbly request that the task of collection all relevent information into 1 documentation source be given a higher priority. |
|
Just to clarify this documentation issue; the official documentation is at: http://www.mantisbt.org/manual The other sources you mention serves different purposes and are going (sooner or later) to be integrated into the official documentation. |
|
Hi, I just wanted to tell you I faced the same problem, and this was due to my company's SMTP server which do not accept big e-mails. Maybe the problem is the same for you. I opened a ticket (0012382) and gave a patch for that. |
|
Resolving this as duplicate of 0012382, even though this one is the older bug, the other one has a patch attached. |
|