-
Notifications
You must be signed in to change notification settings - Fork 136
/
RELEASE-NOTES.txt
233 lines (162 loc) · 9.22 KB
/
RELEASE-NOTES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
~!! n o ' r o o z !!~
-------------------------------------------------------------------------
n o ' r o o z R E L E A S E N O T E S
-------------------------------------------------------------------------
JREDIS SPECIFICATION AND REFERENCE IMPLEMENTATION
[updated on 04-21-09]
* About
This is the initial (alpha.0) release of JREDIS, (code named "no'rooz").
Work on this began around the Persian New Year (No'Rooz, meaning New Day)
and has continued since then almost to the exclusion of nearly everything
else.
* Redis compliance
The specification and the implementation in this release comply with the
the latest redis development release specification as of 04-21-09 and
tested against the build of the REDIS server from the github repository.
* Structure
JREDIS is composed of a Reference and a reference Implementation, under
a unified top-level packages. (A single jar build is provided in this
release, which can be included in your classpath and simply utilized.)
Further Java artifacts include testing, benchmarking, and example source
directories. All these, and the core, can be found under the java
directory. To build JREDIS, you will only need to compile the files
under ~/java/src/.
* Included features
This initial revision includes a complete functioning Synchronous
connector for REDIS. (Asynchronous connection and pipelining support are
on the immediate TODO shortlist.) The initial release connection only
supports (for now) a use case scenario of create, continuously use, and
discard. Enhanced connection maintenance and transparent re-connect are
also on the immediate TODO list for the initial revision. This connector
is exposed for use as org.jredis.ri.alphazero.JRedisClient and you simply
need to instantiate and immediately use it to connect to your localhost
REDIS server. This is a synchronous mode connection, with blocking
semantics for JRedis API, and is intended for use strictly in a synchronized
request/reply manner. To achieve concurrent connections, simply create
a client instance per thread. (See the benchmark classes for examples.)
A queuing synchronous mode connector suitable for use in containers is
on the drawing board. (If you can not wait for this, you may hack your
own by placing a JRedis facade in front of a combination of classes from
java.util.concurrent and using a pool of JRedisClients behind the scenes.)
If you elect to do this, do note that connections to Redis are effectively
stateful and you can not trivially use a connection to serve the requests
of multiple requesters (threads) IFF you use commands such as SELECT.
Beyond that, JREDIS as of now supports basic Java serialization and you
can use your Java objects as 'values' for String, Set, and List keys in
REDIS. And of course, the JRedis interface has been designed to provide
flexibility and 'native' REDIS access, so you can always send whatever
byte[] that you want (which is probably more efficient if you already
have externalization means for your Java classes).
* Requirements
REDIS:
Obviously you will need a REDIS server to use JREDIS! JREDIS is fully
compliant with all documented REDIS beta-0.09 commands, and also supports
EXPIRE. JREDIS as of now does NOT support the earlier 0.08 versions
but structurally is able to handle a multiplicity of REDIS versions,
and you should be able to create your own variant of ProtocolHandler
to interact with earlier (obsolete) versions of REDIS.
JAVA:
JREDIS has no external dependencies at this time. The alpha.0 release
has been developed using Java 6 to utilize enhanced reporting afforded
by the compiler to implementations of Java interfaces. However, JRE 6
or any of its features or libraries are not a fundamental requirement
and this release has the incompatible usage instances commented out to
allow for use with JRE 5.x and above.
Please note that while this software may or may not work under JDK 1.4.x
or earlier, it is simply *not* a goal for this project to support these
earlier version of Java, as that would adversely constrain the options
in both the expression of JRedis semantics and an effective implementation.
TESTS:
Test source files and classes clearly require TestNG library ,
but these test artifacts are not included in the drop-in jar so JUnit is
not a requirement for using JRedis.
BUILD:
JREDIS was built on Eclipse 3.4, on Apple's Mac OS X 10.5 running JVM1.6.
The JREDIS core software itself can be built simply using jacav and jar
That said, the current release uses structured Maven 2 poms to build
the project and execute the tests.
* Status
This software is a *work in progress* and subject to change. Careful
consideration has been given to the concerns and requirements of the end-
user of this software to minimize the impact of (certain) changes to
the code-base as development continues, to extend functionality, to
enhance performance, and to address the feedback of its user community.
That said, this is working code that has been tested and stressed, and
minimally provides a viable and versatile interface between Java systems
and the REDIS database. Coding to the specification artifacts will
minimize, but will not eliminate, any impact of the un-going developments.
Rough edges are to be expected, and your patience appreciated while this
release makes the necessary transition to maturity.
And finally, *all the usual caveats regarding software apply: So
to repeat from the license terms, JREDIS is distributed on an "AS IS"
BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* Performance
The performance characteristics of this intial JREDIS No'Rooz implementation
are acceptable. In developing a connector for a system such as REDIS, there
are a few performance bottle necks which are inevitable. Based on intial
educated guesses and a few recent insights gained through the use of a
profiling tool, every attempt has been made to optimize the performance of
this initial revision. Nevertheless (and thankfully), there remain many
areas for further enhancement of the included sychronous connector (JRedis-
Client).
a) Network IO
This release has a known bottleneck that can be addressed, and will be
likely after the work on the Asynchronous connection has reached the same
level of development as the initial synchronous connection in the initial
release. While it is expected that a blocking network client would be io-
bound to a significant degree, this is actually not that bad in this release.
The wip Asynch connection (still using stream sockets, and not yet NIO),
has been clocked at anywhere from 100,000 to 175,000 PING/INCRs on a single
non-blocking connection to a localhost REDIS. (These are relative numbers
but a reference point is that the REDIS redis-bench program clocks at around
34K/sec for the same). The work on this was stopped to get this release
prepared and resumption of work is a high priority as it was way too much
fun!
b) java.lang.String
The worst offender, and an inescapable one at that, is the String class of
Java, as far as performance hotspots are concerned. On one hand, it is
great to have a Unicode character string implementations that allows JREDIS
to use (as tested) Russian, Chinese, and Farsi, keys in storing information
in REDIS, nevertheless, the performance hit of conversion of (typical) ASCII
strings to byte[] required for the protocol are quite annoying:
Given that String is a final class, little short of caching can be done
about it. (Any suggestions addressing this is greatly appreciated.)
c) data conversion and byte shoveling.
The current implementation makes every attempt to minimize the allocation
of byte[] buffers, and subsequent copying of bytes from one array to another,
but in some cases there is nothing than can be done about it.
Also, some attempts have been made to optimize conversion from numbers to
byte[] and back, to avoid a visit to the dreaded String.getBytes <g>. The
current (hack) solution will cost a few hundred Ks of RAM per classloader
but its probably worth it.
* Documentation
Documentation is a priority item. In the interim please refer to the java
api docs. If you are not familiar with the REDIS command set, you are
certainly encouraged to read the Command reference and get to know the
REDIS vocabulary. The main critical interfaces exposed by JREDIS is the
JRedis interface which is a near analog of the redis command set.
The overall connector design itself is documented as a ~UML diagram image
capture.
* Updates
Updates about JREDIS specification and reference implementation
will be posted at:
JREDIS project site:
http://code.google.com/p/jredis/
and
REDIS Google newsgroup:
http://groups.google.com/group/redis-db
+spontanous updates will also be posted to twitter under
http://twitter.com/SunOf27
* Feedback
Your feedback is welcomed and appreciated. Please direct your
questions, suggestion, comments, concerns, and complaints to
the above public forums, or directly to me @
alphazero@sensesay.net
Most specially, information regarding bugs, performance, and
usability issues, will be highly appreciated.
/ Enjoy!
~ Dedicated to my lovely parents, Kiyou and Farideh. ~
Joubin
04-12-09
Fairfax Station, NoVA