Immediately reconnect when called on with closed socket. #174
Conversation
This makes chsk-reconnect!, when called on a closed socket, attempt to connect immediately. It retains the original behaviour of incrementing the backoff. There is one issue with this at present, which is that it can cause multiple sockets to be opened (if chsk-reconnect! is used repeatedly, or if the timer fires at exactly the same time, probably.) Considering adding a mutex "connecting?" to the state atom, but wanted to check that was sane first.
|
This should fix #167, @danielcompton |
|
I'd probably expect that forcing a reconnect would restart the backoff count from 0 again. What do you think? |
|
I don't really have strong feelings either way. I've thrown that in. Any thoughts on the reconnect mutex-y thing? Is there a better way of doing that than adding another bit to the state atom? |
|
Hi there, Sorry for not taking a look at this sooner. Will definitely get this sorted out for the next release (v1.8.0). |
ptaoussanis
force-pushed
the
master
branch
3 times, most recently
from
d6f2def
to
4016472
Compare
|
Hi Liam, Sorry for never getting this merged. Have taken a look and think it'd be better long-term to take a moment to properly refactor the reconnection logic to better support this use case. The current implementation is a big of a kludge. Your PR definitely helped move this along so again, thank you! Going to keep the original issue (#167) open until I have a fix up. Cheers :-) |
This makes chsk-reconnect!, when called on a closed socket,
attempt to connect immediately. It retains the original behaviour
of incrementing the backoff.
There is one issue with this at present, which is that it can cause
multiple sockets to be opened (if chsk-reconnect! is used repeatedly,
or if the timer fires at exactly the same time, probably.)
Considering adding a mutex "connecting?" to the state atom, but wanted
to check that was sane first.