Opened 2 years ago
Closed 2 years ago
#2292 closed defect (fixed)
Setting read timeout on streaming sockets doesn't work
| Reported by: | Zlatin Balevsky | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | 0.9.36 |
| Component: | streaming | Version: | 0.9.35 |
| Keywords: | Cc: | ||
| Parent Tickets: | Sensitive: | no |
Description
I'm initializing an I2PSocketManager with the following code:
socketManager.getDefaultOptions().setReadTimeout(60000) socketManager.getDefaultOptions().setConnectTimeout(30000)
The connect timeout is respected, but the read timeout is not. Read() calls from the input stream are still blocked a few minutes after the last read.
Eventually, after about 5 minutes they return -1.
Subtickets
Change History (2)
comment:1 Changed 2 years ago by
comment:2 Changed 2 years ago by
| Milestone: | undecided → 0.9.36 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
I put the FIXMEs in 3 years ago when working on related fixes. Guess I was waiting to see if anybody needed it. OP reports that the throw works. Checking that in with some minor logging cleanups and changes to the javadocs. Will see if it messes up any clients. In ae1b00093a9943ec720362270f1d7d69b900c741 0.9.35-19
Note: See
TracTickets for help on using
tickets.
After further investigation, the timeout is respected but the read call returns 0. That in turn confuses upper layers.
A quick fix is to throw a SocketTimeoutException (there are several FIXME's in the code regarding that)