View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002358 | GNUnet | transport service | public | 2012-05-15 15:18 | 2012-06-02 19:15 |
| Reporter | Matthias Wachs | Assigned To | Matthias Wachs | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.9.3 | ||||
| Summary | 0002358: Transport service uses 100% CPU when FAST_RECONNECTING | ||||
| Description | When peer disconnects transport tries a fast reconnect This is not rate limited so so it uses 100% CPU | ||||
| Tags | No tags attached. | ||||
| has duplicate | 0002357 | closed | Matthias Wachs | Creating new TCP session for peer ... |
|
|
Fast reconnect requires an address suggestion from ATS. ATS should not suggest the same address again; but ATS currently doesn't know that. We used to have a mechanism to "temporarily" block out addresses so that we would not re-try them too often. Obviously, one question is where such a mechanism should live. IMO ATS is the most natural fit. Right now, the only way to "block" an address in ATS is to block it "forever". Some kind of way to block an address for a while (possibly with exponential back-off, which we might reset if the connection actually goes up) should be added. |
|
|
ATS address suggestion blocking implemented in 21536. Fixes this issue |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-15 15:18 | Matthias Wachs | New Issue | |
| 2012-05-15 15:18 | Matthias Wachs | Status | new => assigned |
| 2012-05-15 15:18 | Matthias Wachs | Assigned To | => Matthias Wachs |
| 2012-05-15 16:48 | Christian Grothoff | Priority | normal => high |
| 2012-05-15 16:48 | Christian Grothoff | Target Version | => 0.9.3 |
| 2012-05-16 02:08 | Christian Grothoff | Note Added: 0005908 | |
| 2012-05-16 14:13 | Christian Grothoff | Relationship added | has duplicate 0002357 |
| 2012-05-16 18:51 | Matthias Wachs | Note Added: 0005920 | |
| 2012-05-16 18:51 | Matthias Wachs | Status | assigned => resolved |
| 2012-05-16 18:51 | Matthias Wachs | Resolution | open => fixed |
| 2012-06-02 19:15 | Christian Grothoff | Status | resolved => closed |
