Opened 5 years ago
Last modified 5 years ago
#6127 new Bug
announcer slots are not properly accounted for
Reported by: | reardon | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | None Set |
Component: | Transmission | Version: | 2.92 |
Severity: | Normal | Keywords: | |
Cc: |
Description
Seems to be an old bug in multiscrape() [announcer.c]
The slotsAvailable accounting is wrong; slots are incremented but not decremented properly. It should be:
/* send the requests we just built */ for (i=0; i<request_count; ++i) { --announcer->slotsAvailable; scrape_request_delegate (announcer, &requests[i], on_scrape_done, announcer->session); }
Change History (2)
comment:1 Changed 5 years ago by cfpp2p
comment:2 Changed 5 years ago by cfpp2p
@reardon thanks for this too. With some care I was able to patch also so that I have a setting and can change slotsAvailable at session initialization, if the need for that ever occurs.
Note: See
TracTickets for help on using
tickets.
Over time then slotsAvailable might become so large that in theory we would always scrape (or announce) everything. But we have
which directly affects tierNeedsToScrape () Scrapes then should still spread out into batches. r12334 r12297
An example of problems although might be appearing here ticket:5300#comment:4
In theory exceeding 48 (MAX_CONCURRENT_TASKS) is possible.
Scrape and announce batch timings can become complicatedly randomized over time.