| 2011-02-11 14:10:25 |
Anthony Lenton |
bug |
|
|
added bug |
| 2011-02-11 14:12:48 |
Anthony Lenton |
description |
Our payment-notification-processor service currently checks the database for payments in the NotificationReceived state and processes those, every small amount of time. We could instead provide a dbus api to process just one payment, and have the payment-notification handler view in software-center-agent use that api to queue up the subscription for processing.
The processing itself should be done asynchronously from the dbus call itself (so that the call can return quickly to avoid blocking the payment notification handler response for long.
This change would reduce the total time spent waiting for the subscription to be completed, at the same time reducing our database workload. |
Our payment-notification-processor service currently checks the database for payments in the NotificationReceived state and processes those, every small amount of time. We could instead provide a dbus api to process just one payment, and have the payment-notification handler view in software-center-agent use that api to queue up the subscription for processing.
The processing itself should be done asynchronously from the dbus call itself (so that the call can return quickly to avoid blocking the payment notification handler response for long).
This change would reduce the total time spent waiting for the subscription to be completed, at the same time reducing our database workload.
|
|
| 2011-09-22 20:39:58 |
Anthony Lenton |
software-center-agent: status |
New |
Confirmed |
|
| 2011-09-22 20:40:01 |
Anthony Lenton |
software-center-agent: importance |
Undecided |
Low |
|
| 2012-03-16 14:01:21 |
Anthony Lenton |
summary |
Replace polling in payment-notification-processor with a dbus api |
Replace polling in payment-notification-processor with Celery tasks |
|
| 2012-03-16 14:02:30 |
Anthony Lenton |
description |
Our payment-notification-processor service currently checks the database for payments in the NotificationReceived state and processes those, every small amount of time. We could instead provide a dbus api to process just one payment, and have the payment-notification handler view in software-center-agent use that api to queue up the subscription for processing.
The processing itself should be done asynchronously from the dbus call itself (so that the call can return quickly to avoid blocking the payment notification handler response for long).
This change would reduce the total time spent waiting for the subscription to be completed, at the same time reducing our database workload.
|
Our payment-notification-processor service currently checks the database for payments in the NotificationReceived state and processes those, every small amount of time. We could instead a Celery task to process just one payment, and have the payment-notification handler view in software-center-agent use Celery to queue up the subscription for processing.
This change would reduce the total time spent waiting for the subscription to be completed, at the same time reducing our database workload. |
|
| 2012-03-16 14:02:37 |
Anthony Lenton |
software-center-agent: importance |
Low |
Medium |
|
| 2012-11-16 13:13:57 |
Dave Morley |
software-center-agent: assignee |
|
Anthony Lenton (elachuni) |
|
| 2012-11-16 15:14:20 |
Anthony Lenton |
software-center-agent: assignee |
Anthony Lenton (elachuni) |
|
|
| 2012-11-16 15:14:22 |
Anthony Lenton |
software-center-agent: importance |
Medium |
High |
|
