Closed yu-hailong closed 2 years ago
@tangyang9464 @imp2002 please review
LGTM! Thanks.
It may be that server setting up the timeout not zero, it means after one period connection is disposed or closed. I'm not sure if a connect which is in subscribe will be closed by server, it's a guess.
Solution is set timeout on server to 0.
And Resubscribe is necessary, when an exception is thrown just like this or when redis is restart. Thank you for Issue and PR.
For product redis server, timeout = 0 is not good, because maybe some bugs cause redis's link increase until resource exhaust。
and maybe some nework problem problem cause redis-connect down。
so I think, some method should be considered while sub-connect is closed
@yu-hailong plz fix:
Merging #30 (87a05c5) into master (519931b) will decrease coverage by
4.78%
. The diff coverage is50.00%
.
@@ Coverage Diff @@
## master #30 +/- ##
==========================================
- Coverage 94.44% 89.65% -4.79%
==========================================
Files 3 3
Lines 54 58 +4
Branches 3 3
==========================================
+ Hits 51 52 +1
- Misses 1 4 +3
Partials 2 2
Impacted Files | Coverage Δ | |
---|---|---|
src/main/java/org/casbin/watcher/SubThread.java | 73.68% <50.00%> (-12.99%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 519931b...87a05c5. Read the comment docs.
:tada: This PR is included in version 1.4.1 :tada:
The release is available on:
v1.4.1
Your semantic-release bot :package::rocket:
Fix: https://github.com/jcasbin/redis-watcher/issues/29