-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update KeysScan.md #2780
Update KeysScan.md #2780
Conversation
Found through trial and error that not providing the database results in a timeout.
Before we jump into changes, can we understand the problem? I cannot reproduce a problem here: using StackExchange.Redis;
using System;
using System.Linq;
var muxer = ConnectionMultiplexer.Connect("127.0.0.1:6379");
var db = muxer.GetDatabase();
db.StringSet("foo", "foo");
db.StringSet("bar", "bar");
var server = muxer.GetServers().Single();
Console.WriteLine("sync...");
foreach (var key in server.Keys(pattern: "*"))
{
Console.WriteLine(key);
}
Console.WriteLine("async...");
await foreach (var key in server.KeysAsync(pattern: "*"))
{
Console.WriteLine(key);
} outputs sync...
bar
foo
async...
bar
foo At the code level, from here, not supplying a database means the default is applied, which via So: what is the context here? Can we try to get a repro? If there is a problem, I'd rather fix the code than the docs, since the docs aren't wrong. Anything relevant in the server you're connecting to here? or maybe (speculating) the problem is the pattern application itself. Note that redis does not have an efficient way of filtering keys by pattern - you're essentially walking the entire keyspace chunk by chunk, which can take time. If you're looking for something that has very few matches in a huge database, it can take a lot of round trips to find the first match, due to how I suspect that the problem here has nothing to do with specifying the database. |
The other possible cause of a timeout here is if the server is low-version (or we cannot determine the version), and we therefore use As a side note: both |
In this case I tried it with a timeout of 10000 and 30000, the minute I
gave it the default database nos it connected immediately. Else it times
out. The Stackexchange Redis sdk version is 2.8 running on windows 2022
server and Redis version is 7.2.5 running on wsl2. The documentation says
it automatically uses SCAN under the hood from what I understand.
Cheers, Japjit
…On Tue, Aug 27, 2024 at 12:39 AM Marc Gravell ***@***.***> wrote:
The other possible cause of a timeout here is if the server is low-version
(or we cannot determine the version), and we therefore use KEYS instead
of SCAN, and the database is large; this is massively disruptive to the
server, which is why KEYS is largely considered deprecated with SCAN
replacing it.
As a side note: both KEYS and SCAN should only really be used for
administrative purposes like keyspace analysis - it should *not* be used
for routine database operations. For any scenario where a user might use
KEYS/SCAN for *routine* operations: there are usually *much* better
options, that might require some minor rework to how you are storing data.
—
Reply to this email directly, view it on GitHub
<#2780 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALZFM7XMHWG6XHZHEIVKTTZTRJPBAVCNFSM6AAAAABNFFZKW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJSGE3DSMRYGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Indeed it should (prefer Additionally, it would be useful to see the result of |
To echo: I'm very hesitant to assume that the problem here is the |
My apologies, I withdraw my PR. I cant reproduce it now. After much ado I
went back and omitted the database parameter and ended up with getting the
data back. It must have been a networking glitch on my side as I was
running two parallel server. Sorry again.
Cheers, Japjit
…On Tue, Aug 27, 2024 at 7:09 AM Marc Gravell ***@***.***> wrote:
To echo: I'm *very* hesitant to assume that the problem here is the
database parameter. I try not to rule out anything, but I guess I'd
really like to be sure first - ideally with some kind of repro. My initial
investigation suggests that omitting the database here *should* correctly
apply the default database, which defaults to zero, so the change suggested
*should* make no difference.
—
Reply to this email directly, view it on GitHub
<#2780 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALZFM6BTEXC372PQ6MYOSLZTSXFLAVCNFSM6AAAAABNFFZKW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGEYDEMRXG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Just one final note what was interesting was that I could connect to
database.get but couldnt not to server.key till I gave it the default
database. Not sure why that was the case. After it started working it kept
working. Potential initialization issue? but obviously can't reproduce it
any more.
Cheers, Japjit
…On Tue, Aug 27, 2024 at 7:40 AM Japjit Tulsi ***@***.***> wrote:
My apologies, I withdraw my PR. I cant reproduce it now. After much ado I
went back and omitted the database parameter and ended up with getting the
data back. It must have been a networking glitch on my side as I was
running two parallel server. Sorry again.
Cheers, Japjit
On Tue, Aug 27, 2024 at 7:09 AM Marc Gravell ***@***.***>
wrote:
> To echo: I'm *very* hesitant to assume that the problem here is the
> database parameter. I try not to rule out anything, but I guess I'd
> really like to be sure first - ideally with some kind of repro. My initial
> investigation suggests that omitting the database here *should*
> correctly apply the default database, which defaults to zero, so the change
> suggested *should* make no difference.
>
> —
> Reply to this email directly, view it on GitHub
> <#2780 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AALZFM6BTEXC372PQ6MYOSLZTSXFLAVCNFSM6AAAAABNFFZKW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJTGEYDEMRXG4>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
If this recurs, I'd be interested in helping investigate - I'm not saying "there was never a problem" - I'm simply saying "it almost certainly wasn't anything to do with the |
Closing this out for now to tidy up, but happy to follow-up if we see it again :) |
Found through trial and error that not providing the database results in a timeout.