View Issue Details

IDProjectCategoryView StatusLast Update
0008885mantisbtemailpublic2012-08-26 16:17
ReporterEllerbrok Assigned Todregad  
PrioritynormalSeverityblockReproducibilitysometimes
Status closedResolutionduplicate 
Product Version1.1.0 
Summary0008885: 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 bugtracker_email_table and after that and no cron is running you deliver all mails to the configured mail server. BUT, sometimes, I don't know the reason, some of these mails remain in the bugtracker_email_table.

If that happens, the next change in Bugtracker, the next attempt to send new mails will (a) put it's own mails in the bugtracker_email_table, then (b) successfully send all of it's own mails from the database and then (c) try to send the remaing (old) mails.

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 bugtracker_email_table and after that the Bugtracker is working as usual. At least until the next mails remain behind in the database.

TagsNo tags attached.

Relationships

duplicate of 0012382 acknowledged Long emails aren't sent and make Mantis freeze 
has duplicate 0008950 closedgrangeway Emails are blocked in email_table Table and are sended a lot of time 
has duplicate 0013026 closedatrol Trying to sent Invalid email at each bug update 

Activities

vboctor

vboctor

2008-02-19 03:13

manager   ~0017105

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.

Ellerbrok

Ellerbrok

2008-02-19 04:03

reporter   ~0017107

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.

vboctor

vboctor

2008-02-19 04:11

manager   ~0017108

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:
http://technet.microsoft.com/en-us/library/bb742545.aspx

giallu

giallu

2008-02-19 04:42

reporter   ~0017109

I call that "self inflicted pain"...

Ellerbrok

Ellerbrok

2008-03-07 04:38

reporter   ~0017281

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?

vboctor

vboctor

2008-03-08 02:21

manager   ~0017291

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.

Ellerbrok

Ellerbrok

2008-04-24 03:45

reporter   ~0017675

After changing to the semi-cronjob-mode no more emails stuck. So I think we can consider this problem gone.

giallu

giallu

2008-04-24 04:06

reporter   ~0017677

Ok. thanks for letting us know

Ellerbrok

Ellerbrok

2008-05-19 09:13

reporter   ~0017875

Last edited: 2008-05-19 09:17

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.
Hopefully you can identify the mistake in this mails.

Best regards,
Marcel

2008-05-19 09:13

 

blocking_mails.sql (4,889 bytes)
swellnuts

swellnuts

2008-07-02 02:05

reporter   ~0018267

The user interface is working fine, but your background mail
sending script is not terminating.

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

Ellerbrok

Ellerbrok

2008-07-02 02:39

reporter   ~0018268

Hi swellnuts,

it's very easy. Just add a task to the Windows Task Scheduler that is executing
<i>{Path to your PHP installation}</i>\php-cgi.exe <i>{Path to your Bugtracker root}</i>\core\send_emails.php

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,
Marcel

swellnuts

swellnuts

2008-07-02 04:24

reporter   ~0018274

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.

giallu

giallu

2008-07-07 03:43

reporter   ~0018321

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.

sveyret

sveyret

2010-09-22 02:42

reporter   ~0026837

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.

dregad

dregad

2012-08-17 04:58

developer   ~0032596

Resolving this as duplicate of 0012382, even though this one is the older bug, the other one has a patch attached.