rconn01/spymemcached

Automatically exported from code.google.com/p/spymemcached

spymemcached's Issues

Test failure: NPE on shutdown of the constructor test

Not clear why there's a shutdown here, but it shouldn't work.  Needs to be
fixed before I can release.

    [junit] Testcase: testConnFactoryWithoutConns took 0.001 sec
    [junit]     Caused an ERROR
    [junit] null
    [junit] java.lang.NullPointerException
    [junit]     at
net.spy.memcached.MemcachedClient.shutdown(MemcachedClient.java:1292)
    [junit]     at
net.spy.memcached.MemcachedClient.shutdown(MemcachedClient.java:1265)
    [junit]     at
net.spy.memcached.MemcachedClientConstructorTest.tearDown(MemcachedClientConstru
ctorTest.java:23)
    [junit] 
    [junit] TEST net.spy.memcached.MemcachedClientConstructorTest FAILED

Original issue reported on code.google.com by [email protected] on 9 May 2008 at 6:28

unexpected incr

i'm using spymemcached2.2; windowsxp via memcached.exe.

it seems that the way spymemcached stores ints, and the way that the
memcached server interprets ints is different.

    int  o= (Integer)c.get("iz");// 0
    long v= c.incr("iz", 1);     // 1
    int  n= (Integer)c.get("iz");// 49

the server's incr turns the number 0 into a string '0001', but doesn't
alter the stored value's flags.  when spymemcached reads the value it still
sees it marked as int, but interprets the ascii value of "1" as the value
integer value 49.

the following example using strings shows how the server stores and
manipulates ints:

    c.set( "iz", 0, "0" );
    String o= (String)c.get("iz"); // "0"
    long   v= c.incr("iz", 1);     // 1
    String n= (String)c.get("iz"); // "1"

it might be worth having a way to adjust the transcoder behavior to choose
between a "server compatibility" mode and the current "optimized storage" mode.

Original issue reported on code.google.com by [email protected] on 24 Jan 2009 at 10:49

Document logging

I need to document how to configure logging.  People keep asking.

Original issue reported on code.google.com by [email protected] on 12 May 2008 at 5:43

Memcache Server Unreachable - Client locks up

What version of the product are you using? On what operating system?
2.2 / Windows XP

Tell me more...
In testing I ran a client against 4 memcached servers using the Ketema 
connection factory and the default buffer and queue sizes.  I went in 
killed one of the memcached servers and the client immediately became 
unresponsive and generated an endless loop of the following log entries:

009-01-30 13:28:59.625 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=/192.168.181.229:11212, #Rops=0, 
#Wops=1978, #iq=0, topRop=null, 
topWop=net.spy.memcached.protocol.ascii.StoreOperationImpl@748a5d, 
toWrite=0, interested=0}
java.net.ConnectException: Connection refused: no further information
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:252
)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:184
)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1298)
2009-01-30 13:28:59.625 WARN net.spy.memcached.MemcachedConnection:  
Closing, and reopening {QA sa=/192.168.181.229:11212, #Rops=0, #Wops=1978, 
#iq=0, topRop=null, 
topWop=net.spy.memcached.protocol.ascii.StoreOperationImpl@748a5d, 
toWrite=0, interested=0}, attempt 11.
2009-01-30 13:29:00.828 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting {QA sa=/192.168.181.229:11212, #Rops=0, #Wops=1980, #iq=0, 
topRop=null, 
topWop=net.spy.memcached.protocol.ascii.StoreOperationImpl@748a5d, 
toWrite=0, interested=0}
2009-01-30 13:29:01.828 INFO net.spy.memcached.MemcachedConnection:  
Connection state changed for sun.nio.ch.SelectionKeyImpl@667f17
2009-01-30 13:29:01.843 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=/192.168.181.229:11212, #Rops=0, 
#Wops=1982, #iq=0, topRop=null, 
topWop=net.spy.memcached.protocol.ascii.StoreOperationImpl@748a5d, 
toWrite=0, interested=0}
java.net.ConnectException: Connection refused: no further information
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)

I would expect retries to occur over a certain period of time and then 
eventually an operation timeout.  However, in this case the client just 
went in an endless loop.

Original issue reported on code.google.com by [email protected] on 30 Jan 2009 at 8:47

Need an async incr/decr interface

This is a bit complicated as this requires multiple calls as currently
defined.  Packaging them up into a single future could be tricky.

In many cases, people are likely not even interested in the response, so
making them wait for it is extra-pointless.

Original issue reported on code.google.com by [email protected] on 19 Mar 2008 at 4:52

JSON Transcoder

There's talk of cross-platfrom transcoding.  JSON is a possibility.

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 5:59

option to disable failover.

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

Spymemcached version no 2.2
OS : Ubuntu 8.04

Tell me more...

when one of initialized servers is down, is there an option **not** to
fallback on fail over and return a null. So that till the cache server is
up, the load would be on DB. This will ensure that we would never get a
stale information. 

This is needed, considering following scenario.

I have Two memcahe Servers Server1 and Server2. I have (Key1,Object1) which
got cached on Server1. Now if suppose due to some reason Server1 goes down,
the SpyMemcahedClient tries connect to Server2, and we end up Caching
(Key1,Object1) on Server2.

Now after sometime Server1 comes up, and SpyMemcahedClient now conects to
Server1. now Suppose a new value is set for Key1 say (Key1,Object2). now if
again Server1 goes down, SpyMemcahedClient while doing a get for Key1 will
try connecting to Server2, and end up returning stale content Object1.

--
Regards
Surya Chaitanya Tamada

Original issue reported on code.google.com by [email protected] on 22 Jan 2009 at 1:12

Support append

Apparantly append went into the text protocol when I was paying attention
to binary.  We need a binary implementation as well.

Original issue reported on code.google.com by [email protected] on 17 Apr 2008 at 6:50

Enter one-line summary

What steps will reproduce the problem?
1.
2.
3.

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.

Original issue reported on code.google.com by [email protected] on 28 Jul 2006 at 5:52

TCPMemcachedNodeImpl Queues overflow

Using spymemcached version 2.0.1. 
Runtime environment is: Linux 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:22:39 EST
2006 i686 i686 i386 GNU/Linux

Using the spymemcached memcached api library, during our high load tests
we've observed all three of the queues in TCPMemcachedNodeImpl overflow,
resulting in "Queue Full" exceptions. Both the calling MemcachedClient
users (our servlet processing threads) and the background Spymemcached
thread/loop experience this, and fail/break. Once the Spymemcached thread
breaks all the queues back up since there is nothing to process/empty them
and everything using the memcached lib breaks.

I've downloaded the source and added some customization to deal with each
of the three BlockingQueue's. I can contribute the code if you like Dustin,
as we don't really WANT to have a custom version of your API we have to
maintain, just say so.

-Our fix to prevent overflows for writeQ is rather straight forward, just a
small change to the copyInputQueue() method.
-Our fix for readQ is more complex, as the code path(s) to the
transitionWriteItem() method is more complex and tied up in the IO channel
behavior. 
-Our fix for inputQueue is rather simple, but perhaps the most open to
debate - nearly all MemcachedClient public methods in our branch can now
throw an IOException if there is no room to enqueue on inputQueue, allowing
our servlet handlers to determine if they want to sleep/ignore/etc,. when
that condition happens.

----

Even with these changes, we still have Queue Full issues, which we are now
trying to address by the creation of multiple MemcachedClient objects...not
so much for the fact we will have "larger" queues, as for the fact we will
have more Spymemached background threads to get scheduled. 

We are running in tomcat, so we have to have a lot of servlet handler
threads. So the Spymemcached thread is, even on a multicore box, basically
getting cpu starved.

It's something like 200 servlet processing threads, 2 spymemcached threads
currently. The reason we have to have so many servlet processing threads is
because tomcat will just flat out reject requests if there isn't an
available servlet handler thread rather than queuing the requests.

Obviously creating more MemcachedClient objects is not a clean solution,
but I thought I'd put the general problem out there for you to noodle on.

Original issue reported on code.google.com by [email protected] on 6 May 2008 at 11:03

CancelledKeyException while handling IO with a downed server

I've configured two memcached and let one of them  shutdown during a 
loop of get keys. I can see some INFO logs telling it's attempting to 
reconnect. But when I put the failed memcached back, the app hangs 
and stops to print any logs. This can be happened on both sync and 
async get.

environment: windows xp/java1.5/memcached-2.0.jar

Original issue reported on code.google.com by [email protected] on 13 Mar 2008 at 7:30

Suggestion for OperationTimeoutExceptions

Using version 2.1

Sometimes I run into OperationTimeoutExceptions on gets.
It would be great if it was possible to find out which node was causing the
timeouts (e.g. via e.getMessage()?) directly from the exception (without
running in debug mode).

Original issue reported on code.google.com by [email protected] on 26 Jun 2008 at 5:31

Server connection status notification to the application.

I am using 2.0.2 client on RHEL and have one issue.

We have two TOMCAT servers in production and will have memcached running on
both. 
case 1. when one servers goes down client uses the other active one.(works
fine)
case 2. when both the servers goes down then we are disabling cache and
fetching data from database.(works fine)
case 3. When atleast one of the servers comes back is there any way for the
client to get notified about it. So that we can enable caching.

I could not find any solution for the above problem in case 3. so changed
the client implementation to have a broadcaster and added two more classes
as listeners. Applications who requires a notification should subscribe to
the events and hence will get the notifications.
I am not sure how to do this with the current implementation.
If there is a better way then let me know other wise I would like to
contribute to this.

Regards,
Paul.

Original issue reported on code.google.com by [email protected] on 5 May 2008 at 7:12

Test failure: BinaryClientTest fails on a graceful shutdown

This seems to be spurious failure as it's actually part of ProtocolBaseCase
so it happens in four different protocols (ascii and binary over ipv4 and
ipv6).  That it happens at all needs to block 2.1


    [junit] Testcase: testGracefulShutdown took 0.295 sec
    [junit]     Caused an ERROR
    [junit] Failed getting bulk values
    [junit] java.lang.RuntimeException: Failed getting bulk values
    [junit]     at
net.spy.memcached.MemcachedClient.getBulk(MemcachedClient.java:918)
    [junit]     at
net.spy.memcached.MemcachedClient.getBulk(MemcachedClient.java:935)
    [junit]     at
net.spy.memcached.ProtocolBaseCase.testGracefulShutdown(ProtocolBaseCase.java:46
2)
    [junit] Caused by: java.util.concurrent.ExecutionException:
java.lang.RuntimeException: Cancelled
    [junit]     at
net.spy.memcached.MemcachedClient$BulkGetFuture.get(MemcachedClient.java:1367)
    [junit]     at
net.spy.memcached.MemcachedClient$BulkGetFuture.get(MemcachedClient.java:1326)
    [junit]     at
net.spy.memcached.MemcachedClient.getBulk(MemcachedClient.java:913)

Original issue reported on code.google.com by [email protected] on 9 May 2008 at 6:31

Add a layer between auto-transcoding and raw packet handling.

Add a middle layer that allows people to handle their own data and flag
handling.  Blair Zajac has a use case where each request may need a
separate transcoder.

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 5:52

State Indicators

 * getAvailableServers()
 * getUnavailableServers()

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 5:57

Can I add new server without restart clients ?

I've tested basic features with spy memcached 2.1.

I want to know whether it is possible or not.

Suppose the following scenario

1. I start to service with 2 machines(servlet engine and memcached runs on
each machine).
2. I decide to add more servers.

In my short understanding, I have to change client's server list and
restart clients.
It means I have to stop service.

Is there any solutions without stopping service ?

Original issue reported on code.google.com by [email protected] on 28 Jun 2008 at 2:27

Provide Maven artifacts

With the (IMHO unnecessary from looking at the source) dependency on the 
spytools library, it's not really trivial to put the client into a maven 
repository.  A large % of projects use Maven for portable builds and 
dependency management.

It would be nice to have a version of this library available in a Maven 
repository, ideally with clear and simplified dependencies.

Original issue reported on code.google.com by ryan.daum on 18 Jan 2009 at 4:25

Extract interface for MemcachedClient

We need a factory for get instances and a proper interface for talking to
the lower level stuff.

Configuration is getting a bit gross, and I'd like to do some things that
aren't possible without abstracting (replication, for example).

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 5:40

Long and Int transcoders use incorrect flags

The long and int transcoders use flags that are incompatible with those of
the default transcoder.  This will likely lead to confusion.

Original issue reported on code.google.com by [email protected] on 9 Mar 2008 at 7:56

Immediate reconnection failure on localhost prevents further reconnection attempts

I'm using version 2.1.0 of the client on Solaris 10 x86, JVM 1.6.0_02. I have a 
test harness for 
reconnection behavior in my app; it starts memcached, starts a thread to issue 
dummy gets and 
sets, waits a little while, kills the memcached, waits one second, starts 
another memcached on 
the same port, and checks whether MemcachedClient#getUnavailableServers is 
empty (there is a 
single server per MemcachedClient instance). It's not working, even when I run 
continuous traffic 
against the client for 60 seconds, 58 or so of which are after restarting 
memcached. It always 
shows the server as being unavailable, no matter how long I wait.

 From turning on the debug logs, I see one reconnection attempt after 100 ms; this fails in 
MemcachedConnection#attemptReconnects, line 376, at the SocketChannel#connect 
call, with java.net.ConnectException: Connection refused. Not surprising, since 
the new memcached isn't 
started yet. However, it doesn't seem to queue a new reconnection attempt in 
response to this 
error: subsequent log messages show "Selecting with delay of 0ms", and I don't 
see any further 
reconnection attempts. 

Stack trace:

java.net.ConnectException: Connection refused
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:464)
at 
net.spy.memcached.MemcachedConnection.attemptReconnects(MemcachedConnection.java
:376)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:188)
at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1259)

I've attached the log4j log, too.

Looking through the attemptReconnects method, it's clearly an async call to 
SocketChannel#connect, which as the Javadocs point out, can return immediately: 
"If the 
connection is established immediately, as can happen with a local connection, 
then this method 
returns true". Indeed, attemptReconnects handles the success case, but there is 
no exception 
handler at this point to call queueReconnect, as there is in 
handleIO(SelectionKey). It looks like 
one needs to be added. I am running memcached on the same machine and 
connecting to 
127.0.0.1, so it makes sense that it would be taking the 'local connection' 
path.

I'll be happy to work up a patch, but it might take me a little while to get 
this Buildr thing (that is 
how it's built, isn't it?) going in my environment.

Original issue reported on code.google.com by [email protected] on 5 Jun 2008 at 1:49

Attachments:

• test-11213.log

option to make the MemcachedClient thread a daemon

The memcached client object cannot be disconnected and reused.

An option to daemonize the thread would help for webapps -- right now
tomcat won't shut down because the memcached client thread is still running.

Cheers,
-Daniel

Original issue reported on code.google.com by [email protected] on 2 Apr 2008 at 2:57

Double shutdown fails with NPE

java.lang.NullPointerException
       at sun.nio.ch.EPollSelectorImpl.wakeup(EPollSelectorImpl.java:170)
       at
net.spy.memcached.MemcachedConnection.shutdown(MemcachedConnection.java:472)

Original issue reported on code.google.com by [email protected] on 4 Mar 2008 at 12:09

Suggestion: API to propagate memory full error if running memcached in -M mode

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

Tell me more...
I would like to suggest a new feature where the API user would be informed
when memcached's memory is exhausted (when it runs in -M mode).

Thanks

Original issue reported on code.google.com by [email protected] on 8 Jan 2009 at 8:07

MemcachedClient as Interface...

Using 2.1rc3...

I supposed this might present a backwards-compatibility issue, so maybe
this needs to go into the 3.0 stream...

But, since MemcachedClient is marked as a final class, I am unable to mock
it (with EasyMock, at least) to test the consumers of the MemcachedClient...

Could we break it into Interface & Implementation?  I can work on doing
this in the trunk and submit it if you'd like...  I just wanted to get some
feedback before working on it... 

Original issue reported on code.google.com by [email protected] on 27 May 2008 at 9:47

Check set size before sending.

Verify an object is of reasonable size (<1MB) before sending.

This will help with a few types of errors that have sprung up in normal use.

Original issue reported on code.google.com by [email protected] on 1 Oct 2008 at 10:48

Changelog

I'm sorry, but i didnt found any changelog between memcached 2.1 and 2.2
versions. Is there any improvements or bugfixes?

Thank you!

Original issue reported on code.google.com by [email protected] on 12 Jan 2009 at 6:06

CancelledKeyException

HI,

i have two memcache servers and i am setting all key-values in both 
memcache servers..
sometimes i get following exception


ERROR [STDERR] (Memcached IO over {MemcachedConnection 
to /10.38.43.22:11211} - SHUTTING DOWN (informed client)) 
java.nio.channels.CancelledKeyException
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at sun.nio.ch.SelectionKeyImpl.ensureValid
(SelectionKeyImpl.java:55)
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at sun.nio.ch.SelectionKeyImpl.readyOps
(SelectionKeyImpl.java:69)
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at java.nio.channels.SelectionKey.isWritable
(SelectionKey.java:294)
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:264)
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:182)
2009-01-21 06:44:54,001 ERROR [STDERR] (Memcached IO over 
{MemcachedConnection to /10.38.43.22:11211} - SHUTTING DOWN (informed 
client))    at net.spy.memcached.MemcachedClient.run
(MemcachedClient.java:1259)


Thanx in advance for d reply

Original issue reported on code.google.com by [email protected] on 23 Jan 2009 at 9:23

Is MemcachedClient thread safe

Hi, thanks for this nice lib and api.

I have one question.
Can I create one new MemcachedClient, and use it everywhere?

Thanks!

Best regards!
Jiming 

Original issue reported on code.google.com by [email protected] on 2 May 2008 at 3:37

setMulti method

It would be helpful to improve performance if we had a putMulti(keys)
function (similar to the getMulti(keys) method that exists already ;)

Original issue reported on code.google.com by [email protected] on 19 Nov 2008 at 9:27

incr/decr not working as expected

Hi,

I'm having problems using the incr() / decr() methods of the
MemcachedClient - they basically do not what they promise.

Please see attached Test class and output to reproduce.


- memcached-2.0.jar
- spy.jar (2.4)

Cheers,
Mischa

Original issue reported on code.google.com by [email protected] on 27 Mar 2008 at 6:59

Attachments:

• MemcachedTest.java
• testoutput.txt

IllegalStateException: Queue full

spymemcache 2.1 on WinXP 
memcached 1.2.6 on Ubuntu 8.0.4, 1 instance

When I test executing mc.set(x,y) or mc.get(x) for a large times, e.g 
30000+, an exception would be thrown sometimes:

java.lang.IllegalStateException: Queue full
         at java.util.AbstractQueue.add(AbstractQueue.java:64) 

Original issue reported on code.google.com by [email protected] on 5 Nov 2008 at 6:41

the decodeLong method in the TranscoderUtils class return wrong values

If call the incr method to increment a counter this method return the new
value of the counter but if I perform a get on the incremented counter than
i get a different value.

Original issue reported on code.google.com by [email protected] on 12 Dec 2008 at 2:27

Make sure hashes are computed over UTF-8 bytes

From Blair Zajac:

I suggest having the k.getBytes() here:

                       case CRC32_HASH:
                               // return (crc32(shift) >> 16) & 0x7fff;
                               CRC32 crc32 = new CRC32();
                               crc32.update(k.getBytes());
                               rv = (crc32.getValue() >> 16) & 0x7fff;
                               break;

and here:

               md5.reset();
               md5.update(k.getBytes());
               return md5.digest();

use getBytes("UTF-8").

Original issue reported on code.google.com by [email protected] on 15 Apr 2008 at 4:30

Hibernate memcached client

Hibernate uses second level cache. it serialized the object and stored data
in the cache. 
Memcached would be the nature fit as the hibernate second level cache provider.
Implementation is simple and the implementation of the ehcache provider can
be used as reference.

I will attached my implementation here as reference here. I have put some
explanation in my blog:
http://hankliblog.blogspot.com/2008/02/memcached-as-hibernate-second-cache.html

Original issue reported on code.google.com by [email protected] on 7 Apr 2008 at 11:34

Attachments:

• MemcachedHibernateCacheProvider.java
• MemcachedCache.java

Unit test for delete(String, int) fails

Using:
memcached-2.0.2.jar
spy.jar vers. 2.4

apt-show-versions memcached
memcached/hardy uptodate 1.2.2-1

java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)


The following test fails for me:

  @Test
  public void testSetAndFutureDelete()
  {
    String key = RandomStringUtils.randomAlphabetic(20);
    String value = RandomStringUtils.randomAlphabetic(20);
    mcc.set(key, value);
    assertTrue(mcc.get(key).equals(value));
    int when = 20; // delete in 20 seconds
    mcc.delete(key, when);
    // fails - entry already gone, causing NPE!
    assertTrue(mcc.get(key).equals(value)); 
  }

The javadocs do not state if the "when" parameter should be in seconds but
I was just assuming that this is the case since all other expiry values
work like that.

Any idea what is going wrong here?

Original issue reported on code.google.com by [email protected] on 12 May 2008 at 2:29

MemcachedClient.mutate method never returns

There's a problem in exceptional cases wherein an incr can get stuck.  This
may be demonstrated by the following code:

public static void main(String[] args) throws Exception {

    MemcachedClient cache = new
MemcachedClient(AddrUtil.getAddresses("localhost:11211"));

    for (int i=0; i < 1000; i++) {
        cache.incr("test", 1, 1);
        Thread.sleep(100);
    }

    cache.shutdown();
}

Original issue reported on code.google.com by [email protected] on 19 Mar 2008 at 4:09

hit an IO Thread is not running assertion

What version of the product are you using? On what operating system?
I'm running the 2.1 client on RHEL4. 

Tell me more...

We just recently saw this in some of our standard test runs. It isn't clear
how the thread ever would've gotten out of the is running state.

I suppose we will now need to catch this sort of thing and throw away the
client and replace it. 

Any ideas what's going on?

 Cause0: java.lang.AssertionError: IO Thread is not running.
 Cause0-StackTrace: 
        at
net.spy.memcached.MemcachedClient.checkState(MemcachedClient.java:236)
        at net.spy.memcached.MemcachedClient.addOp(MemcachedClient.java:249)
        at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:658)
        at net.spy.memcached.MemcachedClient.asyncGet(MemcachedClient.java:670)
        at
common.cache.ntc.MemcachedClientAdapter.get(MemcachedClientAdapter.java:72)
        at
common.cache.ntc.MemcachedCacheClient.get(MemcachedCacheClient.java:138)
...

Original issue reported on code.google.com by kevinoliver on 15 Sep 2008 at 4:46

Add some reasonably long and configurable absolute time limits.

Node failures currently cause indefinite client hangs as there's
effectively an infinite timeout.  I should make this a finite timeout with
autocancellation to deal with failures.

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 5:56

Whalin compatibile transcoder

There've been many requests for transcoders compatible with other clients.
 One compatible with the Whalin client would be quite desirable.

Original issue reported on code.google.com by [email protected] on 2 Mar 2008 at 6:01

getStats() starts to fail after a few hours of use

We are using memcached client 1.2 on 64 bit Centos. Connecting to memcached
1.2.6

After upgrading to 1.2 the getStatus() method has started failing after few
hours of use with the following exception:

2008-09-04 06:38:24.750 INFO net.spy.memcached.MemcachedConnection: 
Reconnecting due to exception on {QA sa=/10.0.8.2:11211, #Rops=1, #Wops=0,
#iq=0,
topRop=net.spy.memcached.protocol.ascii.MutatorOperationImpl@77353e5d,
topWop=null, toWrite=0, interested=1}
java.lang.NumberFormatException: For input string: "18446744073709542381"
        at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
        at java.lang.Long.parseLong(Long.java:415)
        at java.lang.Long.<init>(Long.java:671)
        at
net.spy.memcached.MemcachedClient$9.receivedStatus(MemcachedClient.java:1043)
        at
net.spy.memcached.protocol.ascii.MutatorOperationImpl.handleLine(MutatorOperatio
nImpl.java:46)
        at
net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.java
:132)
        at
net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:300)
        at
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:262)
        at
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:182)
        at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1259)

telnetin to the memcached server(s) and getting the stats manually returns
sensible data, not the huge number which cases the exception in parsing it
into a Long.

Original issue reported on code.google.com by [email protected] on 4 Sep 2008 at 2:48

Performance tweak when creating md5 digest

Using:
memcached-2.0.2.jar
spy.jar vers. 2.4

In HashAlgorithm.computeMd5() the MessageDigest gets created for every
call. I guess this can reduce performance. Creating the digest in a static
way during initialization of the class and synchronizing on md5 during
reset(), update() and digest() might help to improve performance. 

Original issue reported on code.google.com by [email protected] on 13 May 2008 at 3:57

set() a Integer to zero; incr() by 1; get() returns 49 as the value

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

Tell me more...

MemcachedClient mc = new MemcachedClient(...);
IntegerTranscoder it = new IntegerTranscoder();
Integer temp_int = null;

// set to zero
mc.set("some_key", 86400, new Integer(0), it);

// retrieve it to see if it worked
temp_int = (Integer) mc.get("some_key", it);
System.out.println(temp_int.intValue()); // <<-- ok so far (outputs "0")

// increment it
System.out.println(mc.incr("some_key", 1)); // << -- outputs "1"

// fetch it again to see if it worked
temp_int = (Integer) mc.get("some_key", it);
System.out.println(temp_int.intValue()); // <<-- bad (outputs "49")

Original issue reported on code.google.com by [email protected] on 24 Dec 2008 at 3:30

Divide by zero error when MemcachedClient has no nodes

The java api yacks a "java.lang.ArithmeticException: / by zero" error if
the MemcachedClient is started with no servers.

The MemcachedClient constructor should fail-fast if the List or Array of
InetSocketAddresses is empty.

I realize this is a "well don't do that" type error, but a divide by zero
on our first get/set isn't fun to troubleshoot at first glance :)

Adding the following checks to the Memcached constructor would prevent this
error...
  assert addrs != null  : "InetSocketAddress list cannot be null";
  assert !addrs.isEmpty() : "InetSocketAddress list cannot be empty";

Original issue reported on code.google.com by [email protected] on 25 Mar 2008 at 1:19

get() timeout results in broken server connection

memcachedclient 2.1, 64 bit Centos, connecting to memcached 1.2.6

If a plain MemcachedClient get() throws a TimeoutException:

2008-09-03 10:29:32.532::WARN:  EXCEPTION
net.spy.memcached.OperationTimeoutException: Timeout waiting for value
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:771)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:784)
        <clip... >
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for
operation
        at
net.spy.memcached.MemcachedClient$OperationFuture.get(MemcachedClient.java:1437)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:764)

then the memcached client connection to the server is in an unusable state.
All get() and put() operations fail. 

This has happened a couple of times when a GC has taken more than 1000ms
triggering the default 1000ms timeout.

Original issue reported on code.google.com by [email protected] on 4 Sep 2008 at 2:55

[deleted issue]

[deleted issue]

BinaryMemcachedNodeImpl throws exception with simple set/get

OS: Linux 5.2
Server: Memcached 1.2.6 and 1.3(http://danga.com/memcached/dist/memcached-
1.3.0.tar.gz)
Client: spymemcached 2.2
JRE: Java 1.6
Memcached launch commant: /usr/local/bin/memcached -u nobody -d -p 11211

Code:
------------------------------------------------------
MemcachedClient mem = new MemcachedClient(
                new BinaryConnectionFactory(),
                AddrUtil.getAddresses("10.180.140.206:13000"));
try {
    mem.set("Luciakey", 3600, "Luciavalue");
} catch (Exception e) {
    e.printStackTrace();
}
String result = (String)mem.get(key);
System.out.println(result);
------------------------------------------------------


Exception:
------------------------------------------------------
2009-01-13 14:39:37.321 INFO net.spy.memcached.MemcachedConnection:  Added 
{QA sa=/10.194.132.206:13000, #Rops=0, #Wops=0, #iq=0, topRop=null, 
topWop=null, toWrite=0, interested=0} to connect queue
2009-01-13 14:39:37.336 INFO net.spy.memcached.MemcachedConnection:  
Connection state changed for sun.nio.ch.SelectionKeyImpl@171732b
2009-01-13 14:39:37.352 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=/10.194.132.206:13000, #Rops=11, 
#Wops=4, #iq=2, 
topRop=net.spy.memcached.protocol.binary.StoreOperationImpl@fa9cf, 
topWop=net.spy.memcached.protocol.binary.StoreOperationImpl@55571e, 
toWrite=0, interested=5}
java.io.IOException: An existing connection was forcibly closed by the 
remote host
    at sun.nio.ch.SocketDispatcher.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
    at sun.nio.ch.IOUtil.read(IOUtil.java:206)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
    at net.spy.memcached.MemcachedConnection.handleReads
(MemcachedConnection.java:303)
    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:264)
    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:184)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1298)
2009-01-13 14:39:37.352 WARN net.spy.memcached.MemcachedConnection:  
Closing, and reopening {QA sa=/10.194.132.206:13000, #Rops=11, #Wops=4, 
#iq=36, topRop=net.spy.memcached.protocol.binary.StoreOperationImpl@fa9cf, 
topWop=net.spy.memcached.protocol.binary.StoreOperationImpl@55571e, 
toWrite=0, interested=5}, attempt 0.
2009-01-13 14:39:37.352 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@fa9cf
2009-01-13 14:39:37.352 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@18fef3d
2009-01-13 14:39:37.352 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@a3bcc1
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1bd4722
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1891d8f
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@f3d6a5
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@911f71
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1a73d3c
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@a56a7c
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1f20eeb
2009-01-13 14:39:37.368 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@b179c3
2009-01-13 14:39:37.461 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting {QA sa=/10.194.132.206:13000, #Rops=0, #Wops=40, #iq=0, 
topRop=null, 
topWop=net.spy.memcached.protocol.binary.StoreOperationImpl@55571e, 
toWrite=0, interested=0}
2009-01-13 14:39:37.461 INFO net.spy.memcached.MemcachedConnection:  
Connection state changed for sun.nio.ch.SelectionKeyImpl@e2eec8
2009-01-13 14:39:37.461 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting due to exception on {QA sa=/10.194.132.206:13000, #Rops=40, 
#Wops=0, #iq=0, 
topRop=net.spy.memcached.protocol.binary.StoreOperationImpl@55571e, 
topWop=null, toWrite=0, interested=1}
java.io.IOException: An existing connection was forcibly closed by the 
remote host
    at sun.nio.ch.SocketDispatcher.read0(Native Method)
    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25)
    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
    at sun.nio.ch.IOUtil.read(IOUtil.java:206)
    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
    at net.spy.memcached.MemcachedConnection.handleReads
(MemcachedConnection.java:303)
    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:264)
    at net.spy.memcached.MemcachedConnection.handleIO
(MemcachedConnection.java:184)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1298)
2009-01-13 14:39:37.461 WARN net.spy.memcached.MemcachedConnection:  
Closing, and reopening {QA sa=/10.194.132.206:13000, #Rops=40, #Wops=0, 
#iq=0, topRop=net.spy.memcached.protocol.binary.StoreOperationImpl@55571e, 
topWop=null, toWrite=0, interested=1}, attempt 0.
2009-01-13 14:39:37.461 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@55571e
2009-01-13 14:39:37.461 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@aa9835
2009-01-13 14:39:37.461 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1eec612
2009-01-13 14:39:37.461 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@10dd1f7
2009-01-13 14:39:37.461 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@53c015
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@67ac19
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@53ba3d
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@e80a59
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1ff5ea7
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@9f2a0b
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1813fac
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@7b7072
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@136228
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@913750
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1c672d0
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@19bd03e
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@84abc9
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@2a340e
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@bfbdb0
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@3e86d0
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1050169
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@19fcc69
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@253498
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@9fef6f
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@209f4e
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1bac748
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@17172ea
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@12f6684
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@f38798
2009-01-13 14:39:37.477 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@4b222f
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@b169f8
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@929206
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@b0f13d
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@ae000d
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@1855af5
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@169e11
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@e39a3e
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@a39137
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.StoreOperationImpl@92e78c
2009-01-13 14:39:37.493 WARN 
net.spy.memcached.protocol.binary.BinaryMemcachedNodeImpl:  Discarding 
partially completed op: 
net.spy.memcached.protocol.binary.GetOperationImpl@9fbe93
Exception in thread "main" java.lang.RuntimeException: Exception waiting 
for value
    at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:763)
    at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:778)
    at trail.main(trail.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.intellij.rt.execution.application.AppMain.main
(AppMain.java:90)
Caused by: java.util.concurrent.ExecutionException: 
java.lang.RuntimeException: Cancelled
    at net.spy.memcached.MemcachedClient$OperationFuture.get
(MemcachedClient.java:1493)
    at net.spy.memcached.MemcachedClient$GetFuture.get
(MemcachedClient.java:1539)
    at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:758)
    ... 7 more
Caused by: java.lang.RuntimeException: Cancelled
    ... 10 more
2009-01-13 14:39:37.571 INFO net.spy.memcached.MemcachedConnection:  
Reconnecting {QA sa=/10.194.132.206:13000, #Rops=0, #Wops=0, #iq=0, 
topRop=null, topWop=null, toWrite=0, interested=0}
2009-01-13 14:39:37.571 INFO net.spy.memcached.MemcachedConnection:  
Connection state changed for sun.nio.ch.SelectionKeyImpl@1858610

Original issue reported on code.google.com by [email protected] on 13 Jan 2009 at 6:53

Downloadable JavaDOC

Can you provide the API JavaDOC in the download section for each release?
The current link to the JavaDoc works but some of the entries time out when
you try to load them. I've been trying for the past few days to view some
entries and they won't load.

Original issue reported on code.google.com by [email protected] on 18 Apr 2008 at 3:19

Protocol header changes after the fourth meeting

The python tests are all written, just need to write a bunch of java code.

Original issue reported on code.google.com by [email protected] on 19 Apr 2008 at 8:05

Support prepend

Prepend also went in.

Original issue reported on code.google.com by [email protected] on 17 Apr 2008 at 6:50