session save path order matter? #1214
Assignees
Labels
Comments
|
Please fix the issue. |
michael-grunder
added a commit
that referenced
this issue
Nov 21, 2019
This commit modifies our weighted session selection algorithm by adding a scratch array so we can mark servers that we've picked but were unable to connect to. All we really do is treat any server that has failed as if it had a weight of zero meaning it'll never be picked. Addresses #1214
|
I've implemented a bit of experimental logic to try again if the first server we pick is down (and continue trying until we run out of servers to try). This does present a problem of what to do if a session is initially created on the second choice (because the first pick was down) and then that first server comes back up. We'd go looking for the session and not find it. |
Closed
|
@michael-grunder if I correctly understand it is not a bug that error is thrown when shard is not up. The main problem here is inconsistency when we swap servers in config so probably we can handle this and make it more predictable? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behaviour
Probably this is the intended behavior , but its not mentioned anywhere in docs!
session.save_path = "tcp://127.0.0.1:9501?database=2&timeout=3,tcp://127.0.0.1:6379?database=2&timeout=3"
With the above setting .. php throw a redis error if port 9501 is down .But if we reverse the server order then it works. That is is multiple servers are given the first ones in the list if down throws an error. But this does not happen if the last one is down
Actual behaviour
If there are multiple servers the error must be thrown only when all servers are down
I'm seeing this behaviour on
Steps to reproduce, backtrace or example script
; Load redis php extension
extension=redis.so
; Redis session store backend
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:9501?database=2&timeout=3,tcp://127.0.0.1:6379?database=2&timeout=3"
I've checked
developbranchThe text was updated successfully, but these errors were encountered: