Public bug reported:
Crons from the ir.cron are started by the method _run_jobs_multithread in the
ir_cron Module. This method creates an own postgres cursor and sets an exlusive
lock on the job row to prevent that the job is startet twice. This cursor is
than given as arg to the job thread. This would be safe if the job would not
make a commit on the cursor, cause in that case the exclusive lock on the table
row is released.
The email queue job calls the method process_email_queue wich uses the method
send to send all mails, altough it uses the method send with the arg
auto_commit=True, wich does a cursor commit() wich releases the lock on the
table.
In our case the following happens:
10:00:00 process_email_queue is startet and row is locked, email(ID 1) beginns
to send
10:00:01 email(ID 1) is sent, cr.commit, email(ID 2) is sent with a large
attachment.
10:00:02 run_event_scheduler wakes up cron, process_email_queue is startet
again as next start time has not been changed and the row isnt locked anymore,
as the process has a new cursor and email(ID 2) hasnt been sent, it is sent
again.
The solution would be to use an extra cursor if using the send method in
mail/mail_message.py with autocommit=True.
kind regards,
Nils
** Affects: openobject-addons
Importance: Undecided
Status: New
** Description changed:
- Crons from the ir.cron are started by the method _run_jobs_multithread in the
ir_cron Module.
- This method creates an own postgres cursor and sets an exlusive lock on the
job row to prevent
- that the job is startet twice. This cursor is than given as arg to the job
thread. This would be
- safe if the job would not make a commit on the cursor, cause in that case the
exclusive lock on the table
- row is released.
+ Crons from the ir.cron are started by the method _run_jobs_multithread in the
ir_cron Module. This method creates an own postgres cursor and sets an exlusive
lock on the job row to prevent that the job is startet twice. This cursor is
than given as arg to the job thread. This would be safe if the job would not
make a commit on the cursor, cause in that case the exclusive lock on the table
row is released.
The email queue job calls the method process_email_queue wich uses the method
send to send all mails, altough it uses the method send with the arg
auto_commit=True, wich does a cursor commit() wich releases the lock on the
table.
In our case the following happens:
- 10:00:00 process_email_queue is startet and row is locked, email(ID 1)
beginns to send
+ 10:00:00 process_email_queue is startet and row is locked, email(ID 1)
beginns to send
10:00:01 email(ID 1) is sent, cr.commit, email(ID 2) is sent with a large
attachment.
10:00:02 run_event_scheduler wakes up cron, process_email_queue is startet
again as next start time has not been changed and the row isnt locked anymore,
as the process has a new cursor and email(ID 2) hasnt been sent, it is sent
again.
The solution would be to use an extra cursor if using the send method in
mail/mail_message.py with autocommit=True.
kind regards,
Nils
--
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/1231282
Title:
Email Scheduler runs twice and Mails are sent twice in OpenERP 6.1
Addons rev(7250)
Status in OpenERP Addons (modules):
New
Bug description:
Crons from the ir.cron are started by the method _run_jobs_multithread in the
ir_cron Module. This method creates an own postgres cursor and sets an exlusive
lock on the job row to prevent that the job is startet twice. This cursor is
than given as arg to the job thread. This would be safe if the job would not
make a commit on the cursor, cause in that case the exclusive lock on the table
row is released.
The email queue job calls the method process_email_queue wich uses the method
send to send all mails, altough it uses the method send with the arg
auto_commit=True, wich does a cursor commit() wich releases the lock on the
table.
In our case the following happens:
10:00:00 process_email_queue is startet and row is locked, email(ID 1)
beginns to send
10:00:01 email(ID 1) is sent, cr.commit, email(ID 2) is sent with a large
attachment.
10:00:02 run_event_scheduler wakes up cron, process_email_queue is startet
again as next start time has not been changed and the row isnt locked anymore,
as the process has a new cursor and email(ID 2) hasnt been sent, it is sent
again.
The solution would be to use an extra cursor if using the send method
in mail/mail_message.py with autocommit=True.
kind regards,
Nils
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/1231282/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~openerp-india
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-india
More help : https://help.launchpad.net/ListHelp
