ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
long delay on issue update after upgrading from 2.2.0 to 3.0.0 (Bug #897)
Description
Today I finally upgraded from Chiliproject 2.2.0 to 3.0.0.
It seems everything went fine, but since doing the upgrade I'm getting a very long delay (~1 min) when updating issues.
Example log entry:
Processing IssuesController#update (for <requesting ip> at 2012-02-16 20:18:18) [PUT]
Parameters: {"authenticity_token"=>"<token>", "_method"=>"put", "controller"=>"issues", "commit"=>"OK", "notes"=>"<notes>", "action"=>"update", "send_notification"=>"1", "id"=>"503", "issue"=>{"due_date"=>"", "parent_issue_id"=>"", "start_date"=>"2012-02-16", "assigned_to_id"=>"3", "status_id"=>"1", "lock_version"=>"3", "priority_id"=>"4", "subject"=>"<subject>", "custom_field_values"=>{"2"=>"0", "3"=>"0"}, "done_ratio"=>"0", "tracker_id"=>"4", "estimated_hours"=>"", "fixed_version_id"=>"", "category_id"=>"", "description"=>"Test des Captchas nach Upgrade"}, "time_entry"=>{"comments"=>"", "activity_id"=>"", "hours"=>""}, "attachments"=>{"1"=>{"description"=>""}}}
Sending email notification to: emailaddress1
Sending email notification to: emailaddress2
Sending email notification to: emailaddress3
Sending email notification to: emailaddress4
Sending email notification to: emailaddress5
Sending email notification to: emailaddress6
Sending email notification to: emailaddress7
Sending email notification to: emailaddress8
Sending email notification to: emailaddress9
Sending email notification to: emailaddress10
Redirected to https://<server>/redmine/issues/503
Completed in 71571ms (DB: 28) | 302 Found [https://<server>/redmine/issues/503]
It seems to me, that the delay is connected to sending the notification emails.
My email address is the first in line and I'm getting the notification email in acceptable time.
Using chiliproject 2.2.0 emails got send together:
Sending email notification to: emailaddress1, emailaddress2, ... Redirected to https://<server>/redmine/issues/487 Completed in 8127ms (DB: 30) | 302 Found [https://<server>/redmine/issues/487]
Any ideas why chiliproject is sending separate emails now or what could cause the delay, if it isn't the sending of emails?
Associated revisions
Queries can be marked as 'For all projects'. Such queries will be available on all projects and on the global issue list (#897, closes #671).
Only admin users can create/edit queries that are public and for all projects.
Note: this change does not allow to save a query from the global issue list. You have to be inside a project but then you can mark the query as 'For all projects'.
git-svn-id: http://redmine.rubyforge.org/svn/trunk@1311 e93f8b46-1217-0410-a6f0-8f06a7374b81
Global queries can be saved from the global issue list (follows r1311 and closes #897).
git-svn-id: http://redmine.rubyforge.org/svn/trunk@1312 e93f8b46-1217-0410-a6f0-8f06a7374b81
History
Updated by Enno Gröper at 2012-02-16 09:12 pm
Looking at the changes in mailer.rb it seems like the change is by intention.
The problem is the delay when interacting with our smtp server.
For me this is fixed by using sendmail instead of smtp as delivery_method.
This way the local MTA is buffering the emails:
Completed in 1840ms (DB: 73) | 302 Found [https://<server>/redmine/issues/500]
I'm not sure if it is normal to have some delay when interacting with the smtp server.
Perhaps it's just our infrastructure here (which I have no control over).
If you think this is not an issue, please feel free to decline the ticket.
Updated by Felix Schäfer at 2012-03-01 01:11 am
Hi Enno,
Yes, the change from "one e-mail for everyone" to "each his e-mail" was intentional for different reasons, the biggest being that MTAs would drop the e-mail for everyone if one address was invalid. Other benefits are that we can start customizing the e-mails more, e.g. set the language to the one selected by the user instead of the language of the user that "caused" the e-mail.
Back to your problem: the delay probably comes from the e-mails being sent sequentially and some latency of your outgoing MTA, this can indeed be mitigated/avoided by either using a local spool/sendmail or using the async_smtp adapter which shouldn't block on sending e-mails.
Closing this as it's probably caused by the network/MTA, if anyone else has a similar problem not caused by network or MTA latency, feel free to reopen.
- Category set to Mail Sending
- Status changed from Open to Closed