Opened on 01/19/2016 at 03:28:22 PM

Closed on 05/03/2016 at 07:57:59 AM

#3540 closed defect (fixed)

Error for automatic filter list updates

Reported by: Caro Assignee: matze
Priority: P1 Milestone:
Module: Infrastructure Keywords:
Cc: fred, sporz, arthur Blocked By: #286
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by Caro)

For me EasyList does sometimes noch get automatically updated. I get an error message right next to the filter list?

Failed to load resource: net::ERR_NAME_NOT_RESOLVED…&platformVersion=47.0.2526.111&lastVersion=201601180921&downloadCount=4%2B 
Adblock Plus: Downloading URL failed (synchronize_connection_error)
Download address:…&platformVersion=47.0.2526.111&lastVersion=201601180921&downloadCount=4%2B
Channel status: -1
Server response: 0

Attachments (2)

Screenshot developer tool abp extension.PNG (88.4 KB) - added by Caro on 01/19/2016 at 03:28:54 PM.
error-pings.png (10.3 KB) - added by matze on 05/03/2016 at 07:45:47 AM.
Clients with 5 cosectuive errors Apr/04 - May/02

Download all attachments as: .zip

Change History (11)

Changed on 01/19/2016 at 03:28:54 PM by Caro

comment:1 Changed on 01/19/2016 at 04:14:12 PM by matze

  • Cc fred added
  • Description modified (diff)
  • Priority changed from P4 to P3
  • Ready set

Looks like there are some issues with the DNS "balancing", again. I suppose it's related to the currently ongoing migration to a new balancing scheme and hope it will vanish afterwards. We'll see.

comment:2 Changed on 01/20/2016 at 11:28:58 AM by Caro

  • Description modified (diff)

comment:3 Changed on 03/14/2016 at 10:00:06 AM by matze

  • Priority changed from P3 to P1

The issue's severity seems to increase, there are more frequent but still quite short events. We now get reports from users of other browsers, i.e. Chrome, as well:

This webpage is not available


The server at can't be found, because the DNS lookup failed.

I did not yet manage to capture any malformed records. The logs of the interval-based monitoring I've set up before did not catch any bad records yet. It seems like the respective browser's cache prolongs the use of empty ones occasionally delivered by our DNS provider, but unfortunately also the manual checks after noticing (on affected machines) do not reveal any actual issues either.

comment:4 Changed on 03/14/2016 at 10:02:31 AM by sporz

  • Cc sporz added

comment:5 Changed on 03/14/2016 at 10:40:36 AM by arthur

  • Cc arthur added

comment:6 Changed on 03/14/2016 at 12:41:52 PM by matze

  • Blocked By 261 added

comment:7 Changed on 03/14/2016 at 12:42:30 PM by matze

  • Blocked By 286 added; 261 removed

comment:8 Changed on 04/28/2016 at 01:19:29 AM by matze

  • Owner set to matze

Changed on 05/03/2016 at 07:45:47 AM by matze

Clients with 5 cosectuive errors Apr/04 - May/02

comment:9 Changed on 05/03/2016 at 07:57:59 AM by matze

  • Resolution set to fixed
  • Status changed from new to closed

The newly established traffic management (#286) seems to improve the situation. Together with more resources to handle traffic peaks introduced recently issues like this one should become quite rare. Still, it will most likely re-occur whenever one of our up-links is over-loaded.

Our client applications are build to handle these outages and usually simply re-try the operation later, hence this is not considered being a severe issue. Nonetheless we are working on improved monitoring (i.e. #3981), in order to earlier discover and tackle bottlenecks in the future.

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from matze.
Note: See TracTickets for help on using tickets.