alphazero / jredis Goto Github PK

Java Client and Connectors for Redis

Home Page: http://code.google.com/p/jredis/

License: Apache License 2.0

Java 100.00%

jredis's Introduction

(This README is mainly addressing the project structure and build.  For information
about JRedis, please see the RELEASE-NOTES.) 

----------------------------------------------------------
BUILD
----------------------------------------------------------

* Requirements:

- maven 

Project uses Maven 2 as the build management system.  You
will need maven to conveniently build and package the 
project jars.

Project master is built on Mac OS X 10.5 using maven 2.0.9.

* howto

Project is not yet using assemblies, but is a multi-module
maven build with master POM in root directory (where you 
found this document).

Each module has its own pom, but you will need to run maven
with specific goals at the level of a major sub-module.  As
of now (intial release alpha.0-04152009) that translates to
a 'Core' and an 'Examples'.  

If you wish to use JRedis only you will need the product of
the Core-RI (reference implementation).  

If you wish to run benchmarks + use JRedis, you will also 
need to build the Core-BENCHMARK.

Simplest thing to do is to run maven with goal package at
the Core module level.  This will initiate and build each
module in Core:

API - The specifications, which are mostly interfaces.
RI - The reference implementation, which is you will use.
BENCH - The benchmark classes
ALL - A convenience virtual module that will build a 
unified jar of all modules besides itself in Core.

On command line in ~/core/., issue:

   mvn install

This will compile, test, package, and install JRedis
core artifacts in your local repository and create a 
set of jars in each core module's 'target' directory.

The pom of the Core as well as the super pom in the root
folder use a source attachment plugin, so a source jar 
will also be created for each module.  

The poms of core-ri, core-bench, and core-all use a 
include dependencies mechanism which will build, besides
the individual module's jar, an aggregate unified jar of
the module's classes + the classes of any dependency it
has declared.  (Only install goal will do this -- package
goal will simply create the module's own jar file(s)).

For example, issuing mvn install from core will create
in module core-bench's target directory the class and
source jars for the BENCH module + a single jar containing
all dependencies, which for BENCH are 'API' and 'RI'.

The build system uses a structured naming convention 
which results in longish names, but it is very effective.
(You can obviously simply change the jar names when you
deploy to your application's lib or jvm classpath as you
see fit.)

The super pom in project root will initiate the same for
all modules of JRedis, which as of now are CORE, and
EXAMPLES.  (Same considerations apply here.)


   **** IMPORTANT NOTE REGARDING UNIT TEST ****

Running unit tests is absolutely critical to a sane process
for developing JRedis, given that it is subject to a very
demanding refactoring regime (as it is a work in progress).

That means testing is critical for the master copy and
accordingly ALL poms in the project require SUCCESSFUL 
tests after compile before continuing.

   **** REDIS MUST BE RUNNING ON LOCALHOST *****

So, as tests on a connector without a server are fairly
pointless, this project will NOT build unless you have 
your localhost (6379) Redis server running.

   **** BUILD USES PASSWORD 'jredis' ****

If you do not have password set on your redis, no 
worries. 

If you do, the build will fail, unless you do one
of the following:

1) Change the password in core/pom.xml to match your
password in redis.conf

2) Alternatively tell maven to skip tests:

   mvn -Dmaven.test.skip=true install


  **** REMEMBER:  TESTS WILL FLUSH DBS 13 AND 10 *****

-

04-21-09

jredis's People

Contributors

Stargazers

Watchers

Forkers

kryton jabley tongxiaojun parag bryonjacob kleinsch graemerocher ypai cwolfinger liqweed jlavallee beatty gv0tch0 yestech webron dumbyme rcohen danielzhang n2uitive jlopez alonbl akbertram jackingod zhangdongly livery swissbanker tfredrich revskill10 jekey vijaykramesh alpha8 bjhanfeng dineshmalhar tottichen bitted sshortman zhbigbin suyear damnhe madhanram triompha kapilgangwar zhangyouzhi live0717 kuguobing doczhivago doctoraldisaster fourfireliu boywsk yangfei2012 vniu aztangnanjing rosaline bmanojkumar chakra-coder chinalongganhu misunwork techedge01 demonpark yaoqi simonjhy tianshangjun austinkwang ttgive luozy happylzq binape sb33060418 gshlsh17 jnan77 51blb dut-wenchao boonyachengdu iloveyou416068 softliumin kingtaro01 leasyzhang iloseyou cvsher yisun1900 swolflin zrbsprite wx7614140 sobolsigizmund fty628 devernul dirtyman javascriptextjs jaehyok pandening yanghongkjxy vlanzeng yuanjungod xujeff huchanghuan yinhe402 changmingivy ivanmao yejq jing-312

jredis's Issues

freezes in getKeyBytes

hi.

I'm a newbie to redis, and the client, but thought I'd mention this bug/problem i've got when running the client with 8 threads.

for low traffic it's fine, but it seems to get into a CPU-bound loop when all 8 threads are using the client (HEAD as of 1-2 days ago).

2009-05-21 21:52:00
Full thread dump Java HotSpot(TM) 64-Bit Server VM (11.0-b16 mixed mode):

"Attach Listener" daemon prio=10 tid=0x0000002ae3826000 nid=0x46f9 runnable [0x0000000000000000..0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" prio=10 tid=0x0000002ae2774000 nid=0x4663 waiting on condition [0x0000000000000000..0x000000004022ada0]
java.lang.Thread.State: RUNNABLE

"Thread-10" prio=10 tid=0x0000002ae27a4800 nid=0x4682 runnable [0x0000000041b43000..0x0000000041b43d30]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:93)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-9" prio=10 tid=0x0000002ae27a6c00 nid=0x4680 runnable [0x0000000041a42000..0x0000000041a42bb0]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:93)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-8" prio=10 tid=0x0000002ae208e000 nid=0x467e runnable [0x0000000041941000..0x0000000041941c30]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:119)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-7" prio=10 tid=0x0000002ae208d000 nid=0x467d runnable [0x0000000041840000..0x0000000041840ab0]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.set(JRedisSupport.java:260)
at org.jredis.ri.alphazero.JRedisSupport.set(JRedisSupport.java:267)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:135)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-6" prio=10 tid=0x0000002ae20fa400 nid=0x467c runnable [0x000000004173f000..0x000000004173fb30]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:93)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-5" prio=10 tid=0x0000002ae20bc400 nid=0x467b runnable [0x000000004163e000..0x000000004163edb0]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:93)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"Thread-4" prio=10 tid=0x0000002ae2084400 nid=0x4679 runnable [0x000000004153d000..0x000000004153de30]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.lpush(JRedisSupport.java:941)
at org.jredis.ri.alphazero.JRedisSupport.lpush(JRedisSupport.java:948)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:130)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"MaintThread" daemon prio=10 tid=0x0000002adee0e400 nid=0x4678 waiting on condition [0x000000004143c000..0x000000004143ccb0]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.danga.MemCached.SockIOPool$MaintThread.run(SockIOPool.java:1492)

"Thread-2" prio=10 tid=0x0000002ae2083c00 nid=0x4676 runnable [0x000000004133b000..0x000000004133bd30]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jredis.ri.alphazero.JRedisSupport.getKeyBytes(JRedisSupport.java:1108)
at org.jredis.ri.alphazero.JRedisSupport.exists(JRedisSupport.java:923)
at com.aol.relegence.feedproc.QTwitterThread.addToRedis(QTwitterThread.java:93)
at com.aol.relegence.feedproc.QTwitterThread.run(QTwitterThread.java:224)

"MySQL Statement Cancellation Timer" daemon prio=10 tid=0x0000002ae20b8c00 nid=0x4673 in Object.wait() [0x000000004123a000..0x000000004123abb0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000002a9ea4c590> (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:485)
at java.util.TimerThread.mainLoop(Timer.java:483)
- locked <0x0000002a9ea4c590> (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:462)

"RMI TCP Accept-0" daemon prio=10 tid=0x0000002ae254e000 nid=0x4671 runnable [0x0000000041038000..0x0000000041038ab0]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x0000002a9ea4cc40> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:34)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
at java.lang.Thread.run(Thread.java:619)

"RMI TCP Accept-13097" daemon prio=10 tid=0x0000002ae24cd800 nid=0x4670 runnable [0x0000000040f37000..0x0000000040f37b30]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x0000002a9ea4d298> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
at java.lang.Thread.run(Thread.java:619)

"RMI TCP Accept-0" daemon prio=10 tid=0x0000002ae24cbc00 nid=0x466f runnable [0x0000000040e36000..0x0000000040e36db0]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked <0x0000002a9ea4d860> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
at java.lang.Thread.run(Thread.java:619)

"Low Memory Detector" daemon prio=10 tid=0x0000002ae2003c00 nid=0x466e runnable [0x0000000000000000..0x0000000000000000]
java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=10 tid=0x0000002ae2000c00 nid=0x466d waiting on condition [0x0000000000000000..0x0000000040c33540]
java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x0000002adf08e400 nid=0x466c waiting on condition [0x0000000000000000..0x0000000040b325c0]
java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x0000002adf08c400 nid=0x466b runnable [0x0000000000000000..0x0000000040a32840]
java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x0000002adf06e400 nid=0x466a in Object.wait() [0x0000000040931000..0x0000000040931c30]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000002a9ea52338> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x0000002a9ea52338> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x0000002adf067000 nid=0x4669 in Object.wait() [0x0000000040830000..0x0000000040830ab0]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000002a9ea12fb0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x0000002a9ea12fb0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x0000002adeeb0800 nid=0x4668 runnable

"GC task thread#0 (ParallelGC)" prio=10 tid=0x000000004011cc00 nid=0x4664 runnable

"GC task thread#1 (ParallelGC)" prio=10 tid=0x000000004011e400 nid=0x4665 runnable

"GC task thread#2 (ParallelGC)" prio=10 tid=0x0000000040120000 nid=0x4666 runnable

"GC task thread#3 (ParallelGC)" prio=10 tid=0x0000000040121800 nid=0x4667 runnable

"VM Periodic Task Thread" prio=10 tid=0x0000002ae2538000 nid=0x4672 waiting on condition

JNI global references: 644

isConnected() on interface level

It would be nice to have a way to check if the JRedis interfaces are connected to the server. I am implementing consistent hashing over multiple servers, but I don't have a way in the client to check if the server is present. I extended some classes now to delegate to org.jredis.ri.alphazero.connection.ConnectionBase.isConnected(), but it would be nice if that is already in jredis itself

redis 2.0 compliance

Hi, when can we expect a version that works with the Redis 2.0 stable?

thanks!

Expecting status code for size/count

I am experiencing this exception while using the keys() method

-- JREDIS -- BUG: serviceRequest() -- ProviderException: Bug? Expecting status code for size/count
-- JREDIS -- INFO: serviceRequest() -- closing connection ...
org.jredis.ProviderException: Bug? Expecting status code for size/count
at org.jredis.ri.alphazero.protocol.SynchProtocol$SynchMultiLineResponseBase.readControlLine(SynchProtocol.java:410)
at org.jredis.ri.alphazero.protocol.SynchProtocol$SynchBulkResponse.read(SynchProtocol.java:488)
at org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:138)
at org.jredis.ri.alphazero.JRedisClient.serviceRequest(JRedisClient.java:155)
at org.jredis.ri.alphazero.JRedisSupport.keys(JRedisSupport.java:1022)
at com.chikka.tron.JredisClient.main(JredisClient.java:83)

JRedis redis = new JRedisClient("localhost", 6379);
...
line 83 : redis.keys();

null reference on reconnect

On reconnect, SynchConnection checks status and reference is null.

Infinitive loop on reconnect (disconnect errors)

Sometime it happens that jredis falls into infinitive loop of throwing errors on disconnect method:

JREDIS: while attempting reconnect: Factual error in method ConnectionBase.disconnect() [file: ConnectionBase.java line:384 - package: org.jredis.ri.alphazero.connection]

Only way to stop this and release CPU resources (it consumes a lot of CPU time) is to restart server. Also when there are some problems with connection sometimes connection isn't used any more but there are many HeartbeatJinn threads.

Quick solution can be to use
if (isConnected()) { // body of the disconnect method }
instead of
Assert.isTrue (isConnected(), IllegalStateException.class);

Add LIMIT option to the ZRANGEBYSCORE command

JredisService connection reset handling

JRedisService does handle idle connection resets but doesn't consider the number of connections configured before - only uses one connection after reconnect.

invalid pom.xml configuration

It seems the configuration of the maven poms is incorrect.
After doing a mvn install inside core, executing mvn install inside the root folder gives:

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.jredis:jredis-extensions-api:jar:1.0-rc2

Reason: Cannot find parent: org.jredis:jredis-extensions for project: org.jredis
:jredis-extensions-api🫙1.0-rc2 for project org.jredis:jredis-extensions-api:
jar:1.0-rc2

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.jredis
:jredis-extensions for project: org.jredis:jredis-extensions-api:jar:1.0-rc2 for
project org.jredis:jredis-extensions-api:jar:1.0-rc2
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:421)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:295)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find parent
: org.jredis:jredis-extensions for project: org.jredis:jredis-extensions-api:jar
:1.0-rc2 for project org.jredis:jredis-extensions-api:jar:1.0-rc2
at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
efaultMavenProjectBuilder.java:1377)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def
aultMavenProjectBuilder.java:820)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi
leInternal(DefaultMavenProjectBuilder.java:505)
at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave
nProjectBuilder.java:197)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:626)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:504)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:577)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:577)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:408)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.jredis:jr
edis-extensions' not found in repository: System is offline.

org.jredis:jredis-extensions:pom:a.0-SNAPSHOT

for project org.jredis:jredis-extensions
at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo
sitory(DefaultMavenProjectBuilder.java:602)
at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D
efaultMavenProjectBuilder.java:1373)
... 19 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: System
is offline.

org.jredis:jredis-extensions:pom:a.0-SNAPSHOT

    at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De

faultArtifactResolver.java:187)
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De
faultArtifactResolver.java:74)
at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo
sitory(DefaultMavenProjectBuilder.java:555)
... 20 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Apr 19 17:58:37 EEST 2011
[INFO] Final Memory: 3M/92M
[INFO] ------------------------------------------------------------------------

Missing Support for SPOP

It appears neither the JRedis nor JRedis interfaces support this command. http://code.google.com/p/redis/wiki/SpopCommand

Null pointer exception in SynchConnection

Thanks to Nick Kleinschmidt for the catch:

"we're having a few sporadic NullPointerExceptions that are giving our ops guy headaches. Here's the trace:

at org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:152)
at org.jredis.ri.alphazero.JRedisService.serviceRequest(JRedisService.java:179)
at org.jredis.ri.alphazero.JRedisSupport.get(JRedisSupport.java:716)

I'm pretty sure it's exceptions that're getting thrown without a cause, so trying to get the localized message throws a NPE. "

pooling support & logging

Seems the current master has removed JRedisService and thus support for pooling. Would it be possible to bring it back?
Additionally (maybe unrelated) would it be possible to programmatically disable logging since currently I keep getting for each connection (which means each operation w/o pooling):

  Apr 27, 2011 7:35:59 PM org.jredis.ri.alphazero.support.Log log
  INFO: WARNING: heartbeat is disabled.

It's not only annoying but actually it slows down the application as it has to wait for the console to reply....

DEL should allow deletion of multiple key

For any Redis > 1.n DEL allows multiple keys spec'd in the same request.
(Thanks to @al3xander)

SynchProtocol bulk reply read of the terminating CRLF bytes

(Thanks to Andrew Budarevsky of Yota.ru)

Code in SynchProtocol.readBulkData(..) is defective as it assumes that the terminating bytes of CRLF are immediately available in buffer. Under some situations the stream only has the immediate initial byte available and the routine will throw an exception.

Merge support for multi-bulk request and hash operations

As discussed in our email previously. Could you please merge my changes for multi-bulk requests and hash operations found here:

http://github.com/graemerocher/jredis/commits/master

Thanks
Graeme

add support for pub/sub

Seems that JRedis does not provide any support for pub/sub. Are there any plans to support this in the near future?

AsyncConnection does not attempt to reconnect

We're using the AsyncConnection. If the redis server is set to timeout idle clients, this causes the client using the AsyncConnection to start failing.

-- JREDIS -- ERROR: StreamBufferRequest.write(): SocketException on write: Broken pipe
-- JREDIS -- ERROR: ClientRuntimeException: socket exception
org.jredis.ClientRuntimeException: socket exception
at org.jredis.ri.alphazero.protocol.ProtocolBase$StreamBufferRequest.write(ProtocolBase.java:311)
at org.jredis.ri.alphazero.connection.AsynchConnection$RequestProcessor.run(AsynchConnection.java:167)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:109)
at org.jredis.ri.alphazero.protocol.ProtocolBase$StreamBufferRequest.write(ProtocolBase.java:306)
... 2 more

JRedis Ignores Empty List Elements

Problem:

When a list contains an empty element ("" rather than null)
JRedis returns a null for this element but fails to consume
the \r\n thus scrambling up subsequent elements and other
responses. JRedis should consume the 2 white spaces and
return an empty string (or zero element byte[]).

Test Case:

JRedisService jrs = new JRedisService(host_ip, basePort + 7, null, 0, 1);

String key = "key";
String val0 = "";
String val1 = "v";      

// it is illegal to push a null
try {
    byte[] nullBytes = null;
    jrs.rpush(key, nullBytes);
    fail("it is illegal to push a null");
}
catch (Exception e) {
    assertTrue("we expect an error", true);
}
jrs = new JRedisService(host_ip, basePort + 7, null, 0, 1);

try {
    jrs.flushall();
    jrs.rpush(key, val0.getBytes("UTF-8"));
    jrs.rpush(key, val1.getBytes("UTF-8"));
    List<String> list = DefaultCodec.toStr(jrs.lrange(key, 0, -1));
    assertEquals(val0, list.get(0));
    assertEquals(val1, list.get(1));
}
catch (Exception e) {
    throw new FatalError(e.getMessage(), e);
    //fail(e.getMessage());
}

Solution:

core/ri/src/main/java/org/jredis/ri/alphazero/protocol/SynchProtocol.java

public void read(InputStream in)
    throws ClientRuntimeException, ProviderException {

.....etc.....
if(size > 0)
datalist.add (super.readBulkData(in, size));
else {
// OLD code returns null
// but does not consume the CR LF
//
//datalist.add(null);

        // NEW code which consumes the CR LF
        // and returns null
        // however returning null is not expected
        // because it is impossible to push null
        //
        //super.readBulkData(in, size);
        //datalist.add (null);

        // the only reasonable response is to return
        // an empty string or rather
        // consume the CR LF and return empty array of byte[]
        datalist.add (super.readBulkData(in, size));
    }
}

}
catch (IllegalArgumentException bug){
.....etc.....

zero length keys corrupts bulk data read stream for subsequent reads

Synch protocol is not handling zero length bulk data correctly. The CRLF following the $0 is not read and subsequent reads from stream are out of wack.

View the original report *

JRedisService support for reconnects

I am expecting connection issues while working with redis thought JRedisService. It just says that the used connection is not connected:

Apr 18 23:12:54 tomcat12 tomcat-jqc-app: : Not connected!
Apr 18 23:12:54 tomcat12 tomcat-jqc-app: : org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:122)
Apr 18 23:12:54 tomcat12 tomcat-jqc-app: : org.jredis.ri.alphazero.JRedisService.serviceRequest(JRedisService.java:179)
Apr 18 23:12:54 tomcat12 tomcat-jqc-app: : org.jredis.ri.alphazero.JRedisSupport.set(JRedisSupport.java:379)
Apr 18 23:12:54 tomcat12 tomcat-jqc-app: : org.jredis.ri.alphazero.JRedisSupport.set(JRedisSupport.java:383)

Previously it was working normal and happens after some time. I've checked the source codes and think this can be caused by 2 ways:

The connection wasn't open previously. I've checked and everything is fine here.
The connection was closed by some thread and JRedisService serves it as a new for future clients. E.g. in SynchConnection I can see that we close the connection in case of exception during serviceRequest() such as: ProviderException, RuntimeException. Looks reasonable that if we want to use this connection for other requests (as it happens in JRedisService) in future, we shouldn't close it in that way. Or make sure to return open connection in JRedisService (maybe in kind of option, e.g. reconnectAutomaticly).

My proposal is to check that JRedisService returns the open connection. And if it's closed, do the automatic reconnect.

missing redis operations

Some hash operations and set/zset intersection are still not available in Redis. Issue 24 seems to add support for it.
The following ops are missing:
set/get/resetConfig
shutdown
multi/exec/watch/unwatch
persist
setEx
get/setBit
get/setRange
strLen
bL/bRPop
linsert
bRPopLPush
L/RpushX
zInterStore
zRangeWithScore
zRangeByScoreWithScore
zRevRangeWithScore
zUnionStore
hIncrBy/hMGet/hMSet/hSet/hSetNX

add support for 2.2 (new unified request protocol)

Can the support for latest redis release 2.2.2 be added?

I have modified the code in ProtocolBase to support the new unified request protocol http://redis.io/topics/protocol by just replacing the method createRequest by following:

public Request createRequest(Command cmd, byte[]... args) throws ProviderException, IllegalArgumentException {

    ByteArrayOutputStream buffer = createRequestBufffer (cmd);

    try {
        int argsCount = 1;
        if(args != null) {
            argsCount += args.length;
        }
        buffer.write(COUNT_BYTE);
        buffer.write(Convert.toBytes(argsCount));
        buffer.write(CRLF);

        buffer.write(SIZE_BYTE);
        buffer.write(Convert.toBytes(cmd.bytes.length));
        buffer.write(CRLF);
        buffer.write(cmd.bytes);
        buffer.write(CRLF);

        for(int s=0; s<args.length; s++){
            buffer.write(SIZE_BYTE);
            buffer.write(Convert.toBytes(args[s].length));
            buffer.write(CRLF);
            buffer.write(args[s]);
            buffer.write(CRLF);
        }
    } catch (Exception e) {
        throw new ProviderException("Problem writing to the buffer" + e.getLocalizedMessage());
    }
    return createRequest(buffer);
}

As of now it seems to be working fine at least for Synch Connection. Please check and incorporate if fine.

java.util.concurrent.ExecutionException: Provider ExceptionBug? Expecting status code for size/count

Environment:

RHEL5
Sun Java "1.6.0_20"
Redis 1.2.6
JRedis 1.0RC2

I intermittently see this problem in my application logs. Once this starts to happen, I usually have to restart the app server.

Unable to get value back from redis under key <jmhahqy> Provider ExceptionBug?Expecting status code for size/count
java.util.concurrent.ExecutionException: Provider ExceptionBug?  Expecting status code for size/count
    at org.jredis.ri.alphazero.connection.PendingRequest.checkStatus(PendingRequest.java:112)
    at org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:146)
    at org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:26)
    at org.jredis.ri.alphazero.JRedisFutureSupport$FutureByteArray.get(JRedisFutureSupport.java:1391)
    at org.jredis.ri.alphazero.JRedisFutureSupport$FutureByteArray.get(JRedisFutureSupport.java:1379)

Telnetting to the redis server shows that I can get the value of the key just fine.

info
$404
redis_version:1.2.6
arch_bits:64
multiplexing_api:epoll
uptime_in_seconds:1980869
uptime_in_days:22
connected_clients:4
connected_slaves:1
used_memory:4908261
used_memory_human:4.68M
changes_since_last_save:4310
bgsave_in_progress:0
last_save_time:1294229241
bgrewriteaof_in_progress:0
total_connections_received:45
total_commands_processed:66962953
role:master
db0:keys=221,expires=219

get jmhahqy
$6
border

Java client code:

/* initialisation code */
ConnectionSpec connectionSpec = DefaultConnectionSpec.newSpec(host, port, 0, null);
connectionSpec.isReliable(true);
redis = new JRedisAsynchClient(connectionSpec);
...
/* Usage */
Future<byte[]> result = redis.get(key);

try {
    return new String(result.get(timeout, TimeUnit.MILLISECONDS), "utf-8");
} catch (UnsupportedEncodingException e) {
    log.fatal("Unable to convert to UTF-8?");
} catch (TimeoutException e) {
    log.warn("Unable to get value back from redis under key <" + key + "> in " + timeout + "ms");
} catch (InterruptedException e) {

    /* Presumably the application is unloading? */
    log.warn("Unable to get value back from redis under key <" + key + "> " + e.getMessage());
} catch (ExecutionException e) {

    /* Something bad happened. */
    log.error("Unable to get value back from redis under key <" + key + "> " + e.getMessage(), e);
}

return null;

I got RuntimeException when try using DefaultCodec.decode volatile key

I set the value like this:
jredis.set(key,value);
jredis.expire(key, expiretime_seconds);

and when I try to get the value like this:
String value = DefaultCodec.decode(jredis.get(key));

it said :

java.lang.RuntimeException: Error decoding byte[] data to instantiate java object - data at key may not have been of this type or even an object
org.jredis.ri.alphazero.support.DefaultCodec.decode(DefaultCodec.java:218)

so is it a bug or I made someting wrong when I set or get the volatile value? thank you very much~

by the way,I use the lastest jredis source(compile it in eclipse myself) and redis 1.2.6

jreids ZINTERSTORE , ZUNIONSTORE wrong result

zinterstore can set up weight params , but when i set { 2 , 3 } as weights for two zset ,it return wrong result

REDIS OFFICE Examples
redis> ZADD zset1 1 "one"
(integer) 1redis> ZADD zset1 2 "two"
(integer) 1redis> ZADD zset2 1 "one"
(integer) 1redis> ZADD zset2 2 "two"
(integer) 1redis> ZADD zset2 3 "three"
(integer) 1redis> ZUNIONSTORE out 2 zset1 zset2 WEIGHTS 2 3
(integer) 3redis> ZRANGE out 0 -1 WITHSCORES

"one"
"5"
"three"
"9"
"two"
"10"

mytestcode:

public void testJREDIS() {
Jedis ir = new Jedis("192.168.105.218");
ir.del("testZUNIONSTORE1");
ir.del("testZUNIONSTORE2");
ir.del("testZUNIONSTOREout");

    ir.zadd("testZUNIONSTORE1", 1, "ONE");
    ir.zadd("testZUNIONSTORE1", 2, "TWO");
    ir.zadd("testZUNIONSTORE2", 2, "ONE");
    ir.zadd("testZUNIONSTORE2", 4, "TWO");
    String[] keys = new String[2];
    keys[1] = "testZUNIONSTORE1";
    keys[0] = "testZUNIONSTORE2";

    ZParams Op_params = new ZParams();
    Op_params.aggregate(ZParams.Aggregate.SUM);
    Op_params.weights(new int[]{2,3});
    ir.zunionstore("testZUNIONSTOREout", Op_params, keys);

    Map <String ,Double> scores1 = new LinkedHashMap<String,Double>();
    scores1.put("ONE", 8.0 = 1*2 + 2*3);    //jredis return 7 = 1*3 + 2*2
    scores1.put("TWO", 16.0 = 2*2 + 4*3); //jredis return 14 = 2*3 + 4*2

    assertEquals(scores1,ir.zrangeWithScores("testZUNIONSTOREout", 0, -1));
    ir.del("testZUNIONSTORE1");
    ir.del("testZUNIONSTORE2");
    ir.del("testZUNIONSTOREout");

}

RPOPLPUSH command problem.

In the process of building jredis with maven, the unit test generated many errors.
So, I tried out to find the reason and found it.

In the source file of core/api/src/main/java/org/jredis/protocol/Command.java,
the request type of RPOPLPUSH command is like the below.
In the below, the request type of it is KEY_VALUE. That is the cause of the problem.

RPOPLPUSH (RequestType.KEY_VALUE, ResponseType.BULK)

The RPOPLPUSH command must have two arguments of KEY_KEY type.
So, the above line must be replaced with the following line.

RPOPLPUSH (RequestType.KEY_KEY, ResponseType.BULK)

Thank you..

Support for Redis 2.0

When do you plan to support Redis 2.0? Some commands like MULTI/EXEC command are really useful.

Bug? Expecting status code for size/count

When running this code:

@Test
public void keys() throws Exception {
    final JRedisService jredis = new JRedisService(DefaultConnectionSpec.newSpec(url, port, 10, credentials), 1);
    jredis.keys("foobar:*");
}

I get the following output:

-- JREDIS -- BUG: serviceRequest() -- ProviderException: Bug?  Expecting status code for size/count
-- JREDIS -- INFO: serviceRequest() -- closing connection ... 
org.jredis.ProviderException: Bug?  Expecting status code for size/count
at org.jredis.ri.alphazero.protocol.SynchProtocol$SynchMultiLineResponseBase.readControlLine(SynchProtocol.java:410)
at org.jredis.ri.alphazero.protocol.SynchProtocol$SynchBulkResponse.read(SynchProtocol.java:488)
at org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:138)
at org.jredis.ri.alphazero.JRedisService.serviceRequest(JRedisService.java:179)
at org.jredis.ri.alphazero.JRedisSupport.keys(JRedisSupport.java:1022)

Using redis-cli to try the same, works just fine.

Redis server is 1.2.6

UR.2 -with-dependencies jars have duplicate classes

For example, jredis-core-ri-a.0-SNAPSHOT-jar-with-dependencies.jar has 1 copy of the "api" code (the dependency), but 2 copies of all the "ri" classes.

Wrong assertion in SortSupport.java line 50

Assert.inRange(to, from, Long.MAX_VALUE, "to in LIMIT clause (when from=" + from + ")", ClientRuntimeException.class);

This assertion checking range [from, to], but realy getting range [from, from+to]. So command LIMIT(0, 5) getting 5 elements, command LIMIT(5, 5) getting next 5 elements, but command LIMIT(10, 5) throw exception: org.jredis.ClientRuntimeException: exceeds valid range :{to in LIMIT clause (when from=10)} in method SortSupport.LIMIT() [file: SortSupport.java line:50 - package: org.jredis.ri.alphazero.support]

MGET semantics are awkward

mget(String key, String ... otherKeys) is awkward to use and should be changed to a simpler mget(String ... keys). This would be true for any similar methods in the API specs.

(Thanks to @al3xander for highlighting this).

Reconnect doesn't work in update-08132009

Doesn't work as advertised.

JRedisClient leaving connection open after calling quit

I am running redis 1.2.6 and jredis 1.0.rc2

Start redis server, then monitor the open clients/connections by running redis-stat. Run the example code below. Notice how the client gets cleaned up but the connection remains open.

JRedisClient client = new JRedisClient(redisHost, redisPort);
byte[] resource = client.get(key);
client.quit();

org.jredis.ri.alphazero.support.Convert is way, way, way to slow.

Awesome I hit save by mistake.. one sec real report incoming =)

Occasional exception: org.jredis.connector.ConnectionReset: Connection re-established but last request not processed: in.read returned -1

This is the trace:

[11-09-16 18:56:25.016] {http://*:8080-18} org.jredis.connector.ConnectionReset: Connection re-established but last request not processed:  in.read returned -1
                                                at org.jredis.ri.alphazero.connection.SyncConnection.serviceRequest(SyncConnection.java:138)
                                                at org.jredis.ri.alphazero.JRedisClient.serviceRequest(JRedisClient.java:151)
                                                at org.jredis.ri.alphazero.JRedisSupport.lrange(JRedisSupport.java:1218)
                                                at in.fileit.fileitin.OpPost.getKeyPosts(OpPost.java:360)
                                                at in.fileit.fileitin.OpPost.getPosts(OpPost.java:408)
                                                at in.fileit.fileitin.ServletIndex.doGet(ServletIndex.java:26)
                                                at javax.servlet.http.HttpServlet.service(HttpServlet.java:119)
                                                at javax.servlet.http.HttpServlet.service(HttpServlet.java:96)
                                                at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:109)
                                                at in.fileit.fileitin.FilterDataSource.doFilter(FilterDataSource.java:58)
                                                at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:89)
                                                at com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:156)
                                                at com.caucho.server.webapp.AccessLogFilterChain.doFilter(AccessLogFilterChain.java:95)
                                                at com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:287)
                                                at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:811)
                                                at com.caucho.network.listen.TcpSocketLink.dispatchRequest(TcpSocketLink.java:1186)
                                                at com.caucho.network.listen.TcpSocketLink.handleRequest(TcpSocketLink.java:1148)
                                                at com.caucho.network.listen.TcpSocketLink.handleRequestsImpl(TcpSocketLink.java:1132)
                                                at com.caucho.network.listen.TcpSocketLink.handleRequests(TcpSocketLink.java:1055)
                                                at com.caucho.network.listen.TcpSocketLink.handleAcceptTask(TcpSocketLink.java:903)
                                                at com.caucho.network.listen.AcceptTask.doTask(AcceptTask.java:74)
                                                at com.caucho.network.listen.ConnectionTask.runThread(ConnectionTask.java:97)
                                                at com.caucho.network.listen.ConnectionTask.run(ConnectionTask.java:80)
                                                at com.caucho.network.listen.AcceptTask.run(AcceptTask.java:59)
                                                at com.caucho.env.thread.ResinThread.runTasks(ResinThread.java:164)
                                                at com.caucho.env.thread.ResinThread.run(ResinThread.java:130)

This is happening on random basis. I am using the latest jredis from trunk ( 2c58286 ) and using Redis 2.2.12.

memory leak with HeartbeatJinn

if the JRedisClient fails to connect to the server every connection attempt leaves a HeartbeatJinn in memory.

Because a ClientRuntimeException is thrown and the Thread will remain in the memory because nobody will stop it.

Connection re-established but last request not processed

When I updated the jredis , I got the error when JRedisService reconnected .

The Exception info is as follow:

ERROR - -1 read count in readLine() while reading response line.
ERROR - PROBLEM: serviceRequest() -- ClientRuntimeException => Unexpected EOF (read -1) in readLine. Command: ZCARD
org.jredis.connector.ConnectionReset: Connection re-established but last request not processed: Unexpected EOF (read -1) in readLine. Command: ZCARD
at org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:154)
at org.jredis.ri.alphazero.JRedisService.serviceRequest(JRedisService.java:180)
at org.jredis.ri.alphazero.JRedisSupport.zcard(JRedisSupport.java:872)

Add STORE option to the SORT command

Missing whitespace in SORT BY function

public Sort BY(String pattern) { bySpec = Command.Options.BY.name() + WSPAD + pattern; return this; }

this function should also append a whitespace after the pattern like the GET function

zscore() fails with IllegalArgumentException when redis's ZSCORE returns nil

Hi all

So I've noticed a problem in zscore() method:

public double zscore(String key, byte[] member) throws RedisException {
    byte[] keybytes = null;
    if((keybytes = getKeyBytes(key)) == null) 
        throw new IllegalArgumentException ("invalid key => ["+key+"]");

    double resvalue = 0;
    try {
        BulkResponse bulkResponse = (BulkResponse) this.serviceRequest(Command.ZSCORE, keybytes, member);
        resvalue = Convert.toDouble(bulkResponse.getBulkData());
    }
    catch (ClassCastException e){
        throw new ProviderException("Expecting a ValueResponse here => " + e.getLocalizedMessage(), e);
    }
    return resvalue;
}

In "resvalue = Convert.toDouble(bulkResponse.getBulkData())" getBulkData() can return null and cause convention fail.

Maybe add check and return 0 in this case?

jredis artifiacts not hosted in public maven repository

Is there any way that jreids 1.0 RC2 can be published to a public maven repository?

Nathan

Construct clients (JRedisClient, JRedisService) without immediate connect

It would be nice to be able to create clients without Exceptions when the Redis Server is not available. I can not start my web application and initialize a client class for singleton usage at startup when the server is not available.

The org.jredis.ri.alphazero.connection.ConnectionBase has a constructor with a boolean connectImmediately, but this is not inherited by the subclasses. I added these constructors to the connection classes to be able to create a client and connect at a later stage.

For Example I added this
public AsynchConnection(ConnectionSpec connectionSpec, boolean isShared, boolean connectImmediately)
throws ClientRuntimeException, ProviderException {
super(connectionSpec, connectImmediately);
}

This is a quick solution, but it would be even nicer if the Service code deals with the case that the Redis Server is not available.

full binary support

Currently JRedis provides binary support for values but not for keys. Since Redis 2.0 uses binary-safe strings, such a feature will help greatly for storing data in binary format.

Build Failure

I'm trying to build the latest from master, but getting failed tests. I'm using an older version of Redis, but I couldn't find a minimum version requirement in the JRedis docs, so not sure if that's causing the problem.

My environment looks like the following:

Apache Maven 3.0.2 (r1056850; 2011-01-08 16:58:10-0800)
Java version: 1.6.0_24, vendor: Apple Inc.
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac"
Redis 2.0.3

What other information can I include to help diagnose this issue?

Thanks!

JRedis: specifying encoding for String opterations

JRedis client = new JRedis();
client.set("key", "நாஇன் நல்லவன் இல்லை subhash"); // text in Tamil


// Later:
String out = new String(client.get("key")); // This corrupted text

I am getting corrupted text because my PRO system is running:

file.encoding = ANSI_X3.4-1968

When I pass -Dfile.encoding=utf-8 when starting my app-server, the application is working fine. Is it possible to specify encoding using any API method?

can't call "sadd" sequentially

JRedis client = new JRedisClient("host-name", port);
client.sadd("a", "AAA");
client.sadd("b", "BBB");

-- JREDIS -- ERROR: Error response for SADD => ERR unknown command 'AAA'
Exception in thread "main" Exception on [SADD] => ERR unknown command 'AAA'
at org.jredis.ri.alphazero.connection.SynchConnection.serviceRequest(SynchConnection.java:169)
at org.jredis.ri.alphazero.JRedisClient.serviceRequest(JRedisClient.java:155)
at org.jredis.ri.alphazero.JRedisSupport.sadd(JRedisSupport.java:259)
at org.jredis.ri.alphazero.JRedisSupport.sadd(JRedisSupport.java:269)
at test.Main.main(Main.java:73)
Java Result: 1

when jredis support transaction operaction

Exception using jredisPipeline

This is happenening when i am doing multigets /gets /sets after the socket timeout exception happens.

The socket timeout is happening when i am setting a lot of keys in a tight loop using JredisPipelineService.

Above two are happening concurrently and this is what i am seeing in the logs.

Here's the stack trace.

on pendingResponse.get()
at
org.jredis.ri.alphazero.connection.SynchPipelineConnection.serviceRequest(S ynchPipelineConnection.java:
92)
at
org.jredis.ri.alphazero.JRedisPipelineService.serviceRequest(JRedisPipeline Service.java:
96)
at
org.jredis.ri.alphazero.JRedisSupport.mget(JRedisSupport.java:983)
at
com.kaboodle.core.cache.impl.JredisCacheServiceImpl.mget(JredisCacheService Impl.java:
133)
Caused by: java.util.concurrent.ExecutionException: Provider Exception
at
org.jredis.ri.alphazero.connection.PendingRequest.checkStatus(PendingReques t.java:
112)
at
org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:
134)
at
org.jredis.ri.alphazero.connection.PendingRequest.get(PendingRequest.java:
26)
at
org.jredis.ri.alphazero.connection.SynchPipelineConnection.serviceRequest(S ynchPipelineConnection.java:
80)
... 67 more
Caused by: org.jredis.ProviderException: Bug? Expecting status code
for size/count
at org.jredis.ri.alphazero.protocol.SynchProtocol
$SynchMultiLineResponseBase.readControlLine(SynchProtocol.java:410)
at org.jredis.ri.alphazero.protocol.SynchProtocol
$SynchMultiBulkResponse.read(SynchProtocol.java:544)
at org.jredis.ri.alphazero.connection.PipelineConnectionBase
$ResponseHandler.run(PipelineConnectionBase.java:230)
... 1 more

add support for hashes

Hashes are one of the big features added in Redis 2.0 but JRedis does not support them unfortunately (and neither does any of the JRedis forks that I've looked at)...

auto-detect version compliance

It may be helpful for new users who don't use the correct version of Redis with JRedis.

Spec is simply to issue INFO on connect and matching of "version" element to RI spec'd baseline. Should throw RedisException to indicate user level error. The INFO should be sent after the optional AUTH/SELECT on connect.

Low priority as it has limited shelf life and only helps new users.