Filedownloader: Long delay before download starts.

Created on 2 May 2017  路  1Comment  路  Source: lingochamp/FileDownloader

Before download actually starts there is a delay. For some files download starts almost immediately. But for others this delay each time is very long (20sec - 60sec). This makes me think that it is something specific to the file itself that causes different delay time. Also I've noticed the bigger file size - the bigger delay.

What can cause delay up to 60 seconds before FileDownloader starts reporting progress?

question

Most helpful comment

Thanks for your very good question, there are three reasons for this:

1. Start task first time

If it is the first time to strat one task without FileDownloadService is alive, the starting will trigger starting the FileDownloadService and wait for it launched asynchronously, and as default FileDownloadService is running on the :filedownloader process, so it has to initiate the new process make the delay longer. ( if you want the FileDownloadService host on the main process, please set process.non-separate=true on filedownloader.properties )

2. Waiting for started and connected

before progress callback there are several callbacks: pending -> started -> connected. then the delay up to 60 seconds maybe occured on duration between started to connected or pending to started.

  • pending to started: if you start one task and FileDownloadService is running, you will receive pending callback immediately which means it enqueue successfully, but you will not receive started immediately, why? because as default FileDownloader only allow tree tasks running simultaneously, so if before the task enqueue there are more than tree tasks enqueued, the task has to wait for them, and if turn to the task, it will receive started callback. ( if you want more than tree tasks running simultaneously you can download.max-network-thread-count=[number] on filedownloader.properties )
  • started to connected: if your task is started which means the task is executed now, so we will restore breakpoint from the database and try to connect the Url, this time you will need to wait the first time Url connection, so how long you will receive connected after started callback depends on how long the first time Url connection needed.

3. progress callback frequency

You can ref here more about this.

there are two ways to control the progress callback frequency, which will really affect the callback progress even the first time progress callback.

  • BaseDownloadTask#setCallbackProgressTimes: on this method controls the maximum callback the count of progress during the entire of downloading, so the duration of progress depends on how much bytes downloaded, so it depends on the downloading speed if downloading speed slow you receive progress callback will delay.
  • BaseDownloadTask#setCallbackProgressMinInterval: on this method controls the minimum time interval between each callback of progress, so if you set the value too long, the callback will delay or even missing.

>All comments

Thanks for your very good question, there are three reasons for this:

1. Start task first time

If it is the first time to strat one task without FileDownloadService is alive, the starting will trigger starting the FileDownloadService and wait for it launched asynchronously, and as default FileDownloadService is running on the :filedownloader process, so it has to initiate the new process make the delay longer. ( if you want the FileDownloadService host on the main process, please set process.non-separate=true on filedownloader.properties )

2. Waiting for started and connected

before progress callback there are several callbacks: pending -> started -> connected. then the delay up to 60 seconds maybe occured on duration between started to connected or pending to started.

  • pending to started: if you start one task and FileDownloadService is running, you will receive pending callback immediately which means it enqueue successfully, but you will not receive started immediately, why? because as default FileDownloader only allow tree tasks running simultaneously, so if before the task enqueue there are more than tree tasks enqueued, the task has to wait for them, and if turn to the task, it will receive started callback. ( if you want more than tree tasks running simultaneously you can download.max-network-thread-count=[number] on filedownloader.properties )
  • started to connected: if your task is started which means the task is executed now, so we will restore breakpoint from the database and try to connect the Url, this time you will need to wait the first time Url connection, so how long you will receive connected after started callback depends on how long the first time Url connection needed.

3. progress callback frequency

You can ref here more about this.

there are two ways to control the progress callback frequency, which will really affect the callback progress even the first time progress callback.

  • BaseDownloadTask#setCallbackProgressTimes: on this method controls the maximum callback the count of progress during the entire of downloading, so the duration of progress depends on how much bytes downloaded, so it depends on the downloading speed if downloading speed slow you receive progress callback will delay.
  • BaseDownloadTask#setCallbackProgressMinInterval: on this method controls the minimum time interval between each callback of progress, so if you set the value too long, the callback will delay or even missing.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

asdf19910719 picture asdf19910719  路  4Comments

seransaca picture seransaca  路  5Comments

Jeffin21 picture Jeffin21  路  4Comments

techGay picture techGay  路  3Comments

valmeeki001 picture valmeeki001  路  3Comments