It would appear that you want a thread-safe priority queue. The priority will be based on the time when each URL should be fetched. When you have a task to fetch a URL, you'll put it into the queue. You'll have a thread pool to service the tasks in the queue. You'll probably want to adjust the exact number on some statistics about 1) how long each URL takes to fetch on average, and 2) how many URLs you have to fetch in a given time.
For example, if you average 3 seconds to fetch the data for one URL, and one URL to fetch every second, then you obviously need at least three threads to come reasonably close to keeping up. Less obviously, you'll probably want to compute the variance (or standard deviation) of the traffic, to get an idea of how many threads you'll need to handle bursts. Alternatively, you can adjust the number dynamically, based on demand over the next few seconds.
You'll probably want to include a repetition interval in the definition of a task, along with number of (consecutive?) times that task has failed. After N repetitions, you simply won't put that task back int the run queue (or, alternatively, you might schedule it to be tried at longer intervals, and possibly only when the system is otherwise idle).
Offhand, it sounds to me like you're probably over-estimating the number of threads involved unless most of those URLs end up a lot closer to the 2 minute interval than the 1 hour interval. If we assume roughly random distribution, we get something like one URL to fetch every ~1.8 seconds. At that rate, one thread may easily be adequate.