openerp-india team mailing list archive

[nrumprecht <1231282@xxxxxxxxxxxxxxxxxx>]

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