Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code

Issue 29323363: Issue 2868 - Don't pull the notification repo when parsing (Closed)

Created:
Aug. 7, 2015, 6:34 a.m. by Felix Dahlke
Modified:
Aug. 7, 2015, 7:05 p.m.
CC:
Wladimir Palant
Visibility:
Public.

Description

Issue 2868 - Don't pull the notification repo when parsing We need to keep it up-to-date on the infrastructure side, see: https://issues.adblockplus.org/ticket/2869

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+0 lines, -1 line) Patch
M sitescripts/notifications/parser.py View 1 chunk +0 lines, -1 line 0 comments Download

Messages

Total messages: 10
Felix Dahlke
Aug. 7, 2015, 6:39 a.m. (2015-08-07 06:39:03 UTC) #1
Sebastian Noack
If you only want to prevent multiple threads from concurrently running hg pull, how about ...
Aug. 7, 2015, 7:58 a.m. (2015-08-07 07:58:06 UTC) #2
Felix Dahlke
On 2015/08/07 07:58:06, Sebastian Noack wrote: > If you only want to prevent multiple threads ...
Aug. 7, 2015, 12:55 p.m. (2015-08-07 12:55:38 UTC) #3
mathias
On 2015/08/07 12:55:38, Felix Dahlke wrote: > The main downside I see is that sitescripts ...
Aug. 7, 2015, 1:17 p.m. (2015-08-07 13:17:32 UTC) #4
Sebastian Noack
As I said, it was just a suggestion, I'm not convinced of myself yet. But ...
Aug. 7, 2015, 1:36 p.m. (2015-08-07 13:36:25 UTC) #5
mathias
On 2015/08/07 13:36:25, Sebastian Noack wrote: > As I said, it was just a suggestion, ...
Aug. 7, 2015, 1:44 p.m. (2015-08-07 13:44:09 UTC) #6
Sebastian Noack
Well, the idea was to avoid having an additional cronjob to update the repository, by ...
Aug. 7, 2015, 2:08 p.m. (2015-08-07 14:08:17 UTC) #7
mathias
LGTM (although I was not a reviewer in this ticket before, I now somehow ended ...
Aug. 7, 2015, 2:37 p.m. (2015-08-07 14:37:21 UTC) #8
Sebastian Noack
Acquiring a lock, to check/set a variable, compared to calling a subprocess that will cause ...
Aug. 7, 2015, 3:06 p.m. (2015-08-07 15:06:12 UTC) #9
Felix Dahlke
Aug. 7, 2015, 7:02 p.m. (2015-08-07 19:02:27 UTC) #10
On 2015/08/07 15:06:12, Sebastian Noack wrote:
> Acquiring a lock, to check/set a variable, compared to calling a subprocess
that
> will cause network IO, certainly doesn't add any measurable overhead. But
sure,
> if we get that subprocess completely out of this code path, that would
certainly
> remove some overhead. Though I think it probably doesn't matter too much here,
> as we (have to) rely on heavy caching anyway, to make this perform somehow. As
> far as I understood it, the problem merely was that we have to avoid running
too
> many concurring "hg pull" subprocesses during cache warm up. So simply not
> calling "hg pull" if it is already running seemed an adequate solution. I also
> listed some advantages above. But Maybe I miss some point. However, either
way,
> I don't care too much how this issue is tackeled. So if everybody is happy
with
> doing so in infrastructure fine with me. LGTM.

Alright, I'd prefer to go with that one for the sake of progress. To clarify:
What I meant is that removing the hg pull here and moving it to infrastructure
_increases_ entanglement between sitescripts and infrastructure. But I suppose
we shouldn't tackle that general issue on a higher level, not with this
particular issue here.

Powered by Google App Engine
This is Rietveld