Best unofficial Apache Server developers community
Username
Forgot password?
Sign in with Twitter account
Sign in with Facebook account
List archives

Re: Issue 197 in redis: Inconsistent? Handling of whitespace in keys, at least in redis-cli

Re: Issue 190 in redis: ZINTERRANGE
(31 lines)
Re: Issue 198 in redis: Memory grows up and not freed after big multi/exec
(15 lines)
Aug 27, 2010
Redis
Redis
Updates:
	Status: Verified

Comment #3 on issue 197 by antirez: Inconsistent? Handling of whitespace
in  
keys, at least in redis-cli
http://code.google.com/p/redis/issues/detail?id=197

This is now completely fixed, since Redis 2.0:


redis> set "any kind of key\n" foo
OK
redis> get "any kind of key\n"
"foo"

Closing :)
Salvatore





Reply
Tags: redisfixedcompletely
Similar Threads
Issue 312 in redis: redis-server hanging when being populated with keys-values w/expire with VM enab
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 312 by themig.adx: redis-server hanging when being populated
with  
keys-values w/expire with VM enabled
http://code.google.com/p/redis/issues/detail?id=312

What steps will reproduce the problem?
1. Start redis-server with
    vm-enabled yes
    vm-max-memory 2147483648
    vm-page-size 32
    vm-pages 134217728
    etc
2. From a standalone executable issue commands in a loop that will do the 

following:
    getset random_key random_value
    expire random_key 2592000
3. When the server gets across boundary of its virtual machine (2 G)it  
stops responding to cli and to "redis-stat vmstat" with about 48% CPU busy
 
on our LINUX system, probably falling into a loopwhole of VM swapping.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.






Re: Issue 132 in redis: Comment at the top of utils/redis-copy.rb applies to redis-sha1.rb
Updates:
	Status: Done

Comment #1 on issue 132 by antirez: Comment at the top of  
utils/redis-copy.rb applies to redis-sha1.rb
http://code.google.com/p/redis/issues/detail?id=132

done, thanks





Re: Issue 91 in redis: Inconsistent behavior on key type modification
Updates:
	Status: WontFix

Comment #2 on issue 91 by antirez: Inconsistent behavior on key type  
modification
http://code.google.com/p/redis/issues/detail?id=91

(No comment was entered for this change.)





Re: Issue 151 in redis: The order of keys
Updates:
	Status: WontFix

Comment #1 on issue 151 by antirez: The order of keys
http://code.google.com/p/redis/issues/detail?id=151

keys will return keys in random order for design. To take ordered elements
 
please take a look at sorted sets.

Cheers,
Salvatore





Issue 311 in redis: speed enhancement to keys *
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 311 by dsrthorne: speed enhancement to keys *
http://code.google.com/p/redis/issues/detail?id=311

This is a diff against 1.2.1.  The problem I encountered is that keys *  
isn't optimized and is a very common thing in our environment.  This
change  
sped up the unit tests by 1.5-2.5s, and gave us much more notable benefits
 
in production.  The change involved moving the if (pattern[0] == '*'
&&  
pattern[1] == '\0') outside of the while loop, so it is not evaluated for 

each key or before the other kind of glob pattern matching.

diff --git a/redis.c b/redis.c
index d2491a1..abd165a 100644
--- a/redis.c
+++ b/redis.c
@@ -3243,12 +3243,17 @@ static void keysCommand(redisClient *c) {
      di = dictGetIterator(c->db->dict);
      addReply(c,lenobj);
      decrRefCount(lenobj);
-    while((de = dictNext(di)) != NULL) {
-        robj *keyobj = dictGetEntryKey(de);

-        sds key = keyobj->ptr;
-        if ((pattern[0] == '*' && pattern[1] == '\0') ||
-            stringmatchlen(pattern,plen,key,sdslen(key),0)) {
+    //
+    // match on the general common case before while loop to prevent
+    // this conditional from being run for each key
+    // and/or before any other glob pattern match attempt
+    //
+    if (pattern[0] == '*' && pattern[1] == '\0') {
+        while((de = dictNext(di)) != NULL) {
+            robj *keyobj = dictGetEntryKey(de);
+
+            sds key = keyobj->ptr;
              if (expireIfNeeded(c->db,keyobj) == 0) {
                  if (numkeys != 0)
                      addReply(c,shared.space);
@@ -3258,6 +3263,22 @@ static void keysCommand(redisClient *c) {
              }
          }
      }
+    else {
+        while((de = dictNext(di)) != NULL) {
+            robj *keyobj = dictGetEntryKey(de);
+
+            sds key = keyobj->ptr;
+            if (stringmatchlen(pattern,plen,key,sdslen(key),0)) {
+                if (expireIfNeeded(c->db,keyobj) == 0) {
+                    if (numkeys != 0)
+                        addReply(c,shared.space);
+                    addReply(c,keyobj);
+                    numkeys++;
+                    keyslen += sdslen(key);
+                }
+            }
+        }
+    }
      dictReleaseIterator(di);
      lenobj->ptr = sdscatprintf(sdsempty(),"$%lu\r\n",keyslen+(numkeys
?  
(numkeys-1) : 0));
      addReply(c,shared.crlf);







Re: Issue 212 in redis: Interactive redis-cli crashes when issuing a command after period of inactiv
Updates:
	Status: Verified

Comment #3 on issue 212 by pcnoordhuis: Interactive redis-cli crashes when
 
issuing a command after period of inactivity
http://code.google.com/p/redis/issues/detail?id=212

Reconnecting when the connection has timed out in interactive mode is
fixed  
in both 2.0 and master.





Re: Issue 167 in redis: Dissapointing responsiveness of Redis when using append only file mode
Comment #2 on issue 167 by antirez: Dissapointing responsiveness of Redis 

when using append only file mode
http://code.google.com/p/redis/issues/detail?id=167

updates about this:

1) With the current Linux kernel it is not possible to flush on a
different  
thread, as write(2) will block anyway in the main thread. This sucks but I
 
don't think this is going to get fixed in little time.
2) We have now in Redis master an option so that fsync(2) is not called  
when there is a background saving/log-rewrite operation in progress. It's
a  
trick... but works.
3) All this is highly dependent on the file system used and the mount  
options.
4) "fsync none" is a trivial way to completely fix this problem but the  
drawback is that up to 30 seconds of logs can be lost.
5) fsync always is now optimized, it is still very very slow but much  
faster than before.

I'm leaving this open as it's an open problem but I don't think there are 

very good way to fix this at the moment, still with the latest changes we 

mitigated the problem enough. Currently when very low latency is required
a  
two box setup with a saving slave may be the best option.





Issue 300 in redis: redis-check-dump shows an overflowed value with huge .rdb.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 300 by hatemogi: redis-check-dump shows an overflowed value with
 
huge .rdb.
http://code.google.com/p/redis/issues/detail?id=300

What steps will reproduce the problem?
1. make a huge dump.rdb file.
2. run redis-check-dump with that file.
3. I see an overflowed value in the result.

What is the expected output? What do you see instead?

I see below

$ ls -la data/dump.rdb
-rw-rw-r--  1 dante dante 11853271020 Aug  5 15:24 data/dump.rdb
$ ./redis-check-dump data/dump.rdb
==== Processed 9971202 valid opcodes (in -1031630877 bytes)  

Re: Issue 106 in redis: Incorrect parsing of redis.conf save parameters
Updates:
	Status: Accepted

Comment #1 on issue 106 by antirez: Incorrect parsing of redis.conf save  
parameters
http://code.google.com/p/redis/issues/detail?id=106

yep not cool at all, accepted. I've some plan to rewrite most of the  
configuration file parsers and for sure sanity checks including parameters
 
types and limits will be supported as well.





Re: Issue 97 in redis: Ubuntu 9.10 /etc/init.d/redis-server [stop|restart] does not force a sync to
Updates:
	Status: Verified

Comment #4 on issue 97 by antirez: Ubuntu 9.10 /etc/init.d/redis-server  
[stop|restart] does not force a sync to disk
http://code.google.com/p/redis/issues/detail?id=97

this is now fixed (as Chris suggested)





Re: Issue 168 in redis: Feature Request] redis-cli needs a auth-option
Updates:
	Status: Verified

Comment #3 on issue 168 by antirez: Feature Request] redis-cli needs a  
auth-option
http://code.google.com/p/redis/issues/detail?id=168

This was fixed indeed (see the -a option of redis-cli)





Re: Issue 179 in redis: redis-cli fails after error in multi/exec
Updates:
	Status: Verified

Comment #1 on issue 179 by antirez: redis-cli fails after error in  
multi/exec
http://code.google.com/p/redis/issues/detail?id=179

Fixed in redis master,

Cheers,
Salvatore





Re: Issue 137 in redis: redis.php: rpop and lpop method should not have $value parameter
Updates:
	Status: WontFix

Comment #1 on issue 137 by antirez: redis.php: rpop and lpop method should
 
not have $value parameter
http://code.google.com/p/redis/issues/detail?id=137

please use Predis or Rediska PHP Redis libs! The old PHP lib is
deprecated.

Cheers,
Salvatore





Issue 296 in redis: redis-cli does not handle EOF in monitor mode correctly
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 296 by bjarni.runar: redis-cli does not handle EOF in monitor  
mode correctly
http://code.google.com/p/redis/issues/detail?id=296

What steps will reproduce the problem?
1. run redis-cli in monitor mode
2. killall redis-server

What is the expected output? What do you see instead?

redis-cli should exit, as the server is no longer running. It does not,  
instead it spews infinite newlines.


What version of the product are you using? On what operating system?

redis 2.0.0rc3


Please provide any additional information below.

Patch attached, fixes the issue.

Attachments:
	redis-cli-newlines.patch  798 bytes





Re: Issue 275 in redis: Deviation in CRLF-handling in HGET, HMGET
Updates:
	Status: Verified

Comment #3 on issue 275 by pcnoordhuis: Deviation in CRLF-handling in
HGET,  
HMGET
http://code.google.com/p/redis/issues/detail?id=275

This is caused by support for the old protocol, where the last argument
for  
H* commands should be a bulk argument. Obviously, in H* commands more than
 
only the last argument may be a bulk argument (such as the key itself, the
 
fields and the values). When talking to Redis this way, Redis sees the  
inline commands and suspects only the last argument is a multi bulk.  
Previously, when the inline command had a last bulk argument, but the  
length was not properly specified, it just continued. This was fixed  
yesterday in issue #146 (  
http://code.google.com/p/redis/issues/detail?id=146 ), so issuing the same
 
commands as you mentioned in your issue report will result in an error.





Re: Issue 162 in redis: need a redis-cli command to close all connection
Comment #1 on issue 162 by antirez: need a redis-cli command to close all 

connection
http://code.google.com/p/redis/issues/detail?id=162

can't find a valid use case for this ;) Care to explain?

Cheers,
Salvatore





Re: Issue 111 in redis: read-only redis.conf option
Comment #1 on issue 111 by antirez: [FEATURE REQUEST] read-only redis.conf
 
option
http://code.google.com/p/redis/issues/detail?id=111

not a bad idea indeed... I'll think a bit more about it but sounds cool





Issue 308 in redis: BLPOP/BRPOP incorrectly handling fractional timeouts
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 308 by tjdziuba: BLPOP/BRPOP incorrectly handling fractional  
timeouts
http://code.google.com/p/redis/issues/detail?id=308

What steps will reproduce the problem?
1. Make sure "foo" "bar" and "baz" are non-existent keys.
2. BLPOP "foo" "bar" "baz" 0.1

What is the expected output? What do you see instead?
The call should block for 0.1 seconds and then return (nil)
Instead, the call blocks indefinitely

What version of the product are you using? On what operating system?
2.0.0-rc4

uname -a
Linux gonzo 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010 

x86_64 GNU/Linux


Please provide any additional information below.
I suspect that the timeout parameter is being rounded down to the nearest 

integer.






Re: Issue 147 in redis: redis-cli should be able to connect to slave
Updates:
	Status: Invalid

Comment #4 on issue 147 by antirez: redis-cli should be able to connect to
 
slave
http://code.google.com/p/redis/issues/detail?id=147

(No comment was entered for this change.)





Re: Issue 128 in redis: Redis doesn't save on SIGTERM
Updates:
	Status: Verified

Comment #5 on issue 128 by antirez: Redis doesn't save on SIGTERM
http://code.google.com/p/redis/issues/detail?id=128

fixed in Redis master