ankurgupta8907 / jmemcache-daemon Goto Github PK

What steps will reproduce the problem?
1. start jmemcached (cli or core)
2. send lots of set, gets and add operations to it via tcp until cpu load is 
saturized.

What is the expected output? What do you see instead?
I expect that jmemcached processes all operations sent just like under low 
load. But what I see instead are some IndexOutOfBoundsExceptions thrown 
regularly (at about ~1% of the memcached operations).


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

Please provide any additional information below.

The exception is thrown in netty's skipBytes(int length) method. This is 
invoked in MemcachedFrameDecoder.decode() like follows:

buffer.skipBytes(minFrameLength + minDelimLength);

Unfortunately readableBytes() is not checked in advance. It looks like the 
issue occurs in case the arrival of the CR+LF sequence is handled by two 
separate invocations of MemcachedFrameDecoder.decode(ChannelHandlerContext ctx, 
org.jboss.netty.channel.Channel channel, ChannelBuffer buffer).

I have attached a patch to illustrate the issue, please review whether this is 
the best way to fix it.

This seems to indicate inproper resource cleanup from the byte buffer block 
storage option.

Essentially after a few test runs with a cache storage of 32m, the JVM runs 
out of heap.

What steps will reproduce the problem?
1. Run the jmemcache-daemon on the windows platform 

What is the expected output? What do you see instead?
On some of the restarts, the port is not released:
Caused by: org.jboss.netty.channel.ChannelException: Failed to bind to:
0.0.0.0/0.0.0.0:11211
        at
org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:291)
        at
com.thimbleware.jmemcached.MemCacheDaemon.start(MemCacheDaemon.java:85)
        at
com.informiam.platform.cache.service.CacheDaemon.initialize(CacheDaemon.java:48)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProces
sor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:297)
        at
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProces
sor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.j
ava:250)
        at
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProces
sor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:
144)
        ... 61 more
Caused by: java.net.BindException: Address already in use: bind
        at sun.nio.ch.Net.bind(Native Method)



What version of the product are you using? On what operating system?
This is happening on .8 version deployed on Geronimo 

1. In binary mode, any form of get() on a key that is not present returns the 
empty string (""), rather than null. 

2. In binary mode, compareAndSet() ignores the cas value and always does the 
set.

Confirmed 1) and 2) with both spymemcached and xmemcached clients, and 
jmemcached-daemon versions .9 and 1.0.0.

1) and 2) not present using ascii mode with spymemcached

1) not present using ascii mode with xmemcached. xmemcached gets cas errors in 
ascii mode in general against both jmemcache-daemon and real memcached servers.

Upgrade to most recent Netty release

Please, follow these steps to reproduce the error:

0. Unzip the attached file.
1. Run the server: java -jar ./3rdparty/jmemcached-cli-0.8-main.jar -l
<host> -p <port> -v
2. Run the first test: java -Xms100m -Xmx1000m -classpath
"./bin;./3rdparty/memcached-2.3.1.jar" org.mcpolu. issue3 .test1
<host> <port>

I get the following trace:

2009-06-24 22:28:01.737 INFO net.spy.memcached.MemcachedConnection:  Added
{QA s
a=localhost/127.0.0.1:11311, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null,
toWrite=0, interested=0} to connect queue
2009-06-24 22:28:01.752 INFO net.spy.memcached.MemcachedConnection:  Connection
state changed for sun.nio.ch.SelectionKeyImpl@95c083
2009-06-24 22:28:02.735 INFO
net.spy.memcached.transcoders.SerializingTranscoder
:  Compressed java.util.HashMap from 2879038 to 739793
Exception in thread "Memcached IO over {MemcachedConnection to
localhost/127.0.0
.1:11311}" java.lang.OutOfMemoryError: Java heap space
        at
net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(Operat
ionImpl.java:112)
        at
net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection
.java:361)
        at
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.ja
va:305)
        at
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.ja
va:192)
        at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1444)
Exception in thread "main" net.spy.memcached.OperationTimeoutException: Timeout
waiting for value
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:840)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:855)
        at org.mcpolu.issue3.test1.main(test1.java:25)
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for
operatio
n
        at
net.spy.memcached.MemcachedClient$OperationFuture.get(MemcachedClient
.java:1656)
        at
net.spy.memcached.MemcachedClient$GetFuture.get(MemcachedClient.java:
1708)
        at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:833)
        ... 2 more

The server throws the same exception over and over again, just as described
in Issue1. This is the trace I get:

        at
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.exc
eptionCaught(MemcachedResponseEncoder.java:45)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(
SimpleChannelUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(
SimpleChannelUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(Fram
eDecoder.java:206)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:60
7)
        at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWo
rker.java:577)
        at
org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326
)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handle
AcceptedSocket(NioServerSocketPipelineSink.java:140)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventS
unk(NioServerSocketPipelineSink.java:79)
        at org.jboss.netty.channel.Channels.write(Channels.java:898)
        at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream
(OneToOneEncoder.java:76)
        at org.jboss.netty.channel.Channels.write(Channels.java:878)
        at org.jboss.netty.channel.Channels.write(Channels.java:826)
        at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:23
6)
        at
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.exc
eptionCaught(MemcachedResponseEncoder.java:45)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(
SimpleChannelUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(
SimpleChannelUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)
        at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(Fram
eDecoder.java:206)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(S
impleChannelUpstreamHandler.java:129)

3. Run the second test: java -Xms100m -Xmx1000m -classpath
"./bin;./3rdparty/memcached-2.3.1.jar;./3rdparty/mail.jar" org.mcpolu.
issue3.test2 <host> <port>

I get the following trace:

2009-06-24 22:33:41.433 INFO net.spy.memcached.MemcachedConnection:  Added
{QA s
a=localhost/127.0.0.1:11311, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null,
toWrite=0, interested=0} to connect queue
2009-06-24 22:33:41.457 INFO net.spy.memcached.MemcachedConnection:  Connection
state changed for sun.nio.ch.SelectionKeyImpl@191d8c1
2009-06-24 22:33:42.492 INFO org.mcpolu.issue3.Base64Transcoder: 
Compressed jav
a.util.HashMap from 2879038 to 986392
2009-06-24 22:33:43.023 INFO net.spy.memcached.MemcachedClient:  Shut down
memca
ched client

In the first test, a big Java Object is serialized, then compressed
and sent to the server. When retrieved, the byte stream appears to be
infinite, and the client runs out of memory. It could be related to Issue2.
In the second test, the same big Java Object is serialized, compressed
and finally encoded using Base64. When retrieved, I can successfully
Base64 decode it, then uncompress it and finally recreate the Object.

This appears to be the same problem that was present in jmemcached v0.7
(see http://code.google.com/p/spymemcached/issues/detail?id=73 for
details). In jmemcached v0.8 it works over the text protocol. However, it
fails if the binary protocol is used.

When the series of 'sets' execute in the testBulkGet method of the 
integration test during binary protocol mode, the set command fails with an 
exception on the client side:

java.lang.NullPointerException
    at 
net.spy.memcached.MemcachedClient$1.receivedStatus(MemcachedClient.java:281)
    at 
net.spy.memcached.protocol.binary.OptimizedSetImpl.finishedPayload(Optimized
SetImpl.java:133)
    at 
net.spy.memcached.protocol.binary.OperationImpl.readFromBuffer(OperationImpl
.java:133)
    at 
net.spy.memcached.protocol.binary.OptimizedSetImpl.readFromBuffer(OptimizedS
etImpl.java:19)
    at 
net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:3
62)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:306)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:193)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1458)

See java.lang.NumberFormatException error randomly for get/set action.

The attached log is showing even get same key multi times, server side may 
throw an error of java.lang.NumberFormatException

We've use same memcached client with jmemcache-daemon 0.5 for several years, so 
I don't think this is a client side issue.


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

version 1.0, OS: Mac OS X 10.6.8


Please provide any additional information below.

What steps will reproduce the problem?
1. create dummy project
2. add jmemcached 0.9.1 with netty 3.2.*
3. run daemon
4. store and get a value (echo -ne "set foo 0 0 3\r\nbar\r\nget foo\r\n" | nc 
localhost 11211)

What is the expected output? What do you see instead?
i expected VALUE foo 0 3\r\nbar\r\nEND\r\n but i got ERROR\r\n

What version of the product are you using? On what operating system?
0.9.1 and netty 3.2.*


Please provide any additional information below.

there is an exception thrown.

8228 [New I/O server worker #1-1] ERROR 
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder - error
java.lang.NoSuchMethodError: org.jboss.netty.buffer.ChannelBuffer.writeByte(B)V
    at com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.messageReceived(MemcachedResponseEncoder.java:82)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
    at com.thimbleware.jmemcached.protocol.MemcachedCommandHandler.handleGets(MemcachedCommandHandler.java:274)
    at com.thimbleware.jmemcached.protocol.MemcachedCommandHandler.messageReceived(MemcachedCommandHandler.java:157)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
    at com.thimbleware.jmemcached.protocol.text.MemcachedCommandDecoder.processLine(MemcachedCommandDecoder.java:149)
    at com.thimbleware.jmemcached.protocol.text.MemcachedCommandDecoder.messageReceived(MemcachedCommandDecoder.java:63)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299)
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349)
    at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
    at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:636)

Running the test suite with the block store enabled (see params in 
AbstractCacheTest) triggers failure for the CAS test:

2009-11-08 13:51:45.508 INFO net.spy.memcached.MemcachedConnection:  
Connection state changed for sun.nio.ch.SelectionKeyImpl@16dcf7b
Exception in thread "Memcached IO over {MemcachedConnection to 
localhost/127.0.0.1:1040}" java.lang.AssertionError: CAS was less than zero:  
0
    at 
net.spy.memcached.MemcachedClient$5.gotData(MemcachedClient.java:770)
    at 
net.spy.memcached.protocol.ascii.BaseGetOpImpl.handleRead(BaseGetOpImpl.java
:97)
    at 
net.spy.memcached.protocol.ascii.OperationImpl.readFromBuffer(OperationImpl.
java:108)
    at 
net.spy.memcached.MemcachedConnection.handleReads(MemcachedConnection.java:3
62)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:306)
    at 
net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:193)
    at net.spy.memcached.MemcachedClient.run(MemcachedClient.java:1458)

What steps will reproduce the problem?
1. clone project from google-code
2. build with maven
3. run cli-daemon
4. open connection, send request, close connection before answer

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

current snapshot on ubuntu


the cli-daemon stops working. after printing java.io.IOException: Broken pipe. 
sometimes it took several of these requests to cause the effect.

Great work on the daemon. I am actually using it to implement generic servers 
over the memcached protocol, but not as a 
cache server. Sort of like Twitter's kestrel. There are a few things that would 
really help in terms of being able to extend 
the platform.

1. In MemCacheDaemon.java create the pipeline factories in a protected method 
that can be overridden. That way we can 
then override certain things in the pipeline construction.

2. Similarly in the ChannelPipelineFactory classes the construction of the 
different parts of the pipeline could be protected 
method calls. createCommandDecoder, createCommandHandler, 
createResponseEncoder. That way the command handler 
can easily be overridden.

3. In MemcachedCommandHandler break message received into parts. A protected 
method for each of the commands. In 
my case, I have a long running (>1 second) process I want to run in a thread 
for the get, and then put the message on the 
async channel.

My main goal is to be able to process get requests in a thread and put 
responses on the async channel. This is b/c some of 
the operations we need to execute can be long running processes. I guess 
another extension point would be to add this 
capability to the framework itself. An option for "threaded" mode in which 
operations are executed in Executor jobs and 
results are put back on the channel.

I don't mind making some changes and submitting as diffs if you are open to 
that?

memcached has bytes_read/bytes_written stats.

We ought to collect similar stats. We could accumulate these in the frame 
decoder stage.

I use 1.0.0 of jmemcache-daemon together with xmemcache-client 1.4.3.

What steps will reproduce the problem?
1. start embedded server
2. put and delete some elements (optional)
3. retrieve (deleted/non-exisiting) element

I expect to get a NULL value instead of an empty string.
When using real memcached, I get NULL in this case.

What steps will reproduce the problem?
1. clone current snapshot
2. compile and run the daemon
3. send lots of requests to jmemcached, so the cpu load is saturized

What is the expected output? What do you see instead?
I expect all requests are processed fine. I see some Nullpointer Exceptions 
caused by 
com.thimbleware.jmemcached.protocol.text.MemcachedCommandDecoder.processLine()

What version of the product are you using? On what operating system?
0.9.3.SNAPSHOT on Debian Linux 2.6.26-2-amd64

Please provide any additional information below.

The local variable "Op op;" in this method is not checked for !=null. When op 
is set (see "op = Op.FindOp(parts.get(0));" ). The surrounding try catch is not 
effective. FindOp does not throw an Exception, but returns null.

Recent results from 0.10-SNAPSHOT using memslap 1.0 show jmemcached very 
favourably for text protocol support -- basically showing equivalent total 
per-byte throughput and 80% of transactions-per-second of the native 
version.. 

This issue is to formally capture and write up the results of testing with 
memslap and place them on the wiki. This should include:

  * Graphs showing different configurations: different # of threads, 
concurrency settings, different physical machines.
  * Explanation of the numbers.

What steps will reproduce the problem?
1. install memslap from libmemcached 0.37 (or from bzr)
2. run with the -B flag against jmemcached

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

Expected output should be complete benchmark; actual result is:

Client side:

Failed to write, and not due to blocking.
Failed to write, and not due to blocking.

Server side:

SEVERE: error
com.thimbleware.jmemcached.protocol.exceptions.MalformedCommandException: 
binary request payload is invalid, magic byte incorrect
    at 
com.thimbleware.jmemcached.protocol.binary.MemcachedBinaryCommandDecoder.dec
ode(MemcachedBinaryCommandDecoder.java:102)

This is an issue to capture the requirement to implement UDP protocol 
support.

Issue occurs only in current version. It was working with 0.8.

set creates a new unique-id for a cacheelement, but cas does not. so for every 
cacheelement set with cas, the unique-id is always 0.

To reproduce connect with telnet and do the following:

> set foo 0 0 3
> bar
< STORED
> gets foo
< VALUE foo 0 3 3984
< bar
< END
> cas foo 0 0 3 3984
> baz
< STORED
> gets foo
< VALUE foo 0 3 0              <-- it's 0, ok if it would happen just once
< baz
< END
> cas foo 0 0 3 0
> wup
< STORED
> gets foo
< VALUE foo 0 3 0              <-- oops, there it is again
< wup
< END


The attached patch fixes it issue.

if a buffer endwith "\r" not end with "\r\n",the line 
"buffer.skipBytes(minFrameLength + minDelimLength);" will throw a exception.

if (frameLength >= 0 && frameLength < minFrameLength ) {
minFrameLength = frameLength;
foundDelimiter = MemcachedResponseEncoder.CRLF;
}
should be changed 

if (frameLength >= 0 && frameLength < minFrameLength &&     
buffer.readableBytes() >= frameLength + 2) {
minFrameLength = frameLength;
foundDelimiter = MemcachedResponseEncoder.CRLF;
}

When running jmemcached in verbose mode the keys are printed like this:

5745 [New I/O server worker #7-2] INFO 
com.thimbleware.jmemcached.protocol.MemcachedCommandHandler - GET 
com.thimbleware.jmemcached.Key@7d35722a

To improve this Key should get a toString implementation, e.g.:

diff -r fcecde1e3e7a core/src/main/java/com/thimbleware/jmemcached/Key.java
--- a/core/src/main/java/com/thimbleware/jmemcached/Key.java    Tue Feb 08 
11:14:45 2011 -0500
+++ b/core/src/main/java/com/thimbleware/jmemcached/Key.java    Sat Apr 23 
15:40:31 2011 +0200
@@ -37,5 +37,9 @@
         return hashCode;
     }

+    @Override
+    public String toString() {
+        return new String( bytes.array() );
+    }

 }

In jmemcache-core:1.0.0 there appears to be a small bug in handling expiration 
times.

According to the "Expiration times" section of the memcache protocol 
documentation, an expiration value of 2592000 should translate into an 
expiration of 30 days from the time the relevant element is inserted.  Any 
expiration value larger than 2592000 should be treated as a Unix timestamp.

jmemcache-core:1.0.0 treats an expiration value of 2592000 as a Unix timestamp. 
 Memcached and other implementations on the other hand behave as described in 
the protocol.

The fix seems to be a simple replacement of a "<" to a "<=" in 
MemcacheCommandDecoder and MemcacheBinaryCommandDecoder.

I've attached an archive with a test project and a patch against the 
jmemcached-parent-1.0.0 tag.

What is the expected output? What do you see instead?
An MBean(s) exposed via JMX that allows monitoring the following attributes:
# Total connection count 
(com.thimbleware.jmemcached.protocol.MemcachedCommandHandler.total_conns)
# Current connection count 
(com.thimbleware.jmemcached.protocol.MemcachedCommandHandler.curr_conns)
# get-commands count
# set-commands count
# get-commands hits
# get-commands misses

What version of the product are you using? On what operating system?
jmemcached-core-1.0.0 on CentOS and Ubuntu

Please provide any additional information below.
I already implemented the cache statistics for a cache that I plugged in to the 
MemCacheDaemon, but I have no way of reaching the connections stats. You can 
see the implementation here: http://code.google.com/p/pajamas-proxy/

If you need help, I'm happy to help with this, or even implement it myself - 
feel free to contact me.

I have released a new version that offers LRU eviction with marginal overhead. 
It also has 
native support for weighted values, which replaces your SizedItem 
customization. I would 
appreciate any feedback if you do a performance analysis after the upgrade.

What steps will reproduce the problem?
1. Check out revision 7955b41be5
2. Run `mvn clean test`

What is the expected output? What do you see instead?
All tests run without an error.
Two tests fail

What version of the product are you using? On what operating system?
1. Revision 7955b41be5
2. mvn -v
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_13
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.7" arch: "x86_64" Family: "mac"

Please provide any additional information below.

--------------------------------------------------------------------------
-----
Test set: com.thimbleware.jmemcached.test.SpyMemcached23IntegrationTest
--------------------------------------------------------------------------
-----
Tests run: 16, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.69 sec <<< 
FAILURE!
testBinaryCompressed[0](com.thimbleware.jmemcached.test.SpyMemcached23Integratio
nTest)  
Time elapsed: 0.526 sec  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space
    at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:232)
    at java.lang.StringCoding.encode(StringCoding.java:272)
    at java.lang.String.getBytes(String.java:947)
    at 
net.spy.memcached.transcoders.BaseSerializingTranscoder.encodeString(BaseSeriali
zingTranscod
er.java:171)
    at 
net.spy.memcached.transcoders.SerializingTranscoder.encode(SerializingTranscoder
.java:102)
    at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:262)
    at net.spy.memcached.MemcachedClient.add(MemcachedClient.java:555)
    at 
com.thimbleware.jmemcached.test.SpyMemcached23IntegrationTest.testBinaryCompress
ed(SpyM
emcached23IntegrationTest.java:108)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java
:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
    at org.junit.runners.Suite.runChild(Suite.java:115)
    at org.junit.runners.Suite.runChild(Suite.java:23)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)

testBinaryCompressed[1](com.thimbleware.jmemcached.test.SpyMemcached23Integratio
nTest)  
Time elapsed: 0.617 sec  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space
    at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:232)
    at java.lang.StringCoding.encode(StringCoding.java:272)
    at java.lang.String.getBytes(String.java:947)
    at 
net.spy.memcached.transcoders.BaseSerializingTranscoder.encodeString(BaseSeriali
zingTranscod
er.java:171)
    at 
net.spy.memcached.transcoders.SerializingTranscoder.encode(SerializingTranscoder
.java:102)
    at net.spy.memcached.MemcachedClient.asyncStore(MemcachedClient.java:262)
    at net.spy.memcached.MemcachedClient.add(MemcachedClient.java:555)
    at 
com.thimbleware.jmemcached.test.SpyMemcached23IntegrationTest.testBinaryCompress
ed(SpyM
emcached23IntegrationTest.java:108)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java
:44)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
    at org.junit.runners.Suite.runChild(Suite.java:115)
    at org.junit.runners.Suite.runChild(Suite.java:23)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
    at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:220)

What steps will reproduce the problem?
1. send request where \r\n gets split because of mtu

What is the expected output? What do you see instead?
request is decoded correctly

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

Please provide any additional information below.
seems like an error in MemcachedCommandDecoder.eol()

check for readableBytes() >= MIN_BYTES_LINE is wrong.
it should be readbleBytes() - pos >= MIN_BYTES_LINE

The current storage relies on One Big Lock around the entire cache. This 
strategy puts a cap on concurrent accesses to the cache, making one write 
block all readers.

There are better data structures that could be used; for example the 
ConcurrentLinkedHashMap project here on google code.   However, this piece 
of code would require extensive modification to support the locked-delayed-
deletes functionality of memcache.

This task is quite far reaching; it really means refactoring the call chain 
from 
the protocol handler down to move the locking/cas/delayed-delete support 
further down.

What steps will reproduce the problem?
1. Start jmemcache-daemon on Windows 2004, JDK 1.6.0_12 (-server -Xmx1600M)
2. Use spymemcached 1.2.8 and call memcachedClient.set(key) and then
memcachedClient.get(key).
3. spymemcached's client will return null

What is the expected output? What do you see instead?
After a while, jmemcache-daemon will start throwing what-appears-to-be the
same exception over and over again:

        at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236)
        at
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.exceptionCaugh
t(MemcachedResponseEncoder.java:45)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.ja
va:206)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:607)
        at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:5
77)
        at
org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSoc
ket(NioServerSocketPipelineSink.java:140)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServ
erSocketPipelineSink.java:79)
        at org.jboss.netty.channel.Channels.write(Channels.java:898)
        at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEn
coder.java:76)
        at org.jboss.netty.channel.Channels.write(Channels.java:878)
        at org.jboss.netty.channel.Channels.write(Channels.java:826)
        at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236)
        at
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.exceptionCaugh
t(MemcachedResponseEncoder.java:45)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.ja
va:206)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:607)
        at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:5
77)
        at
org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSoc
ket(NioServerSocketPipelineSink.java:140)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServ
erSocketPipelineSink.java:79)
        at org.jboss.netty.channel.Channels.write(Channels.java:898)
        at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEn
coder.java:76)
        at org.jboss.netty.channel.Channels.write(Channels.java:878)
        at org.jboss.netty.channel.Channels.write(Channels.java:826)
        at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:236)
        at
com.thimbleware.jmemcached.protocol.text.MemcachedResponseEncoder.exceptionCaugh
t(MemcachedResponseEncoder.java:45)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChann
elUpstreamHandler.java:155)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.ja
va:206)
        at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChanne
lUpstreamHandler.java:129)
        at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:607)
        at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:5
77)
        at
org.jboss.netty.channel.socket.nio.NioWorker.write(NioWorker.java:326)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSoc
ket(NioServerSocketPipelineSink.java:140)
        at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServ
erSocketPipelineSink.java:79)
        at org.jboss.netty.channel.Channels.write(Channels.java:898)
        at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEn
coder.java:76)

What version of the product are you using? On what operating system?
- spymemcached 1.2.8 on Windows XP with JDK 1.6.0_14
- jmemcache-daemon 0.7 on Windows 2003 with JDK 1.6.0_12

Please provide any additional information below.

I hope that's enough.  I can provide more information or do more testing if
necessary.

What steps will reproduce the problem?
1. Start a daemon in binary mode
2. Using xmemcached, do a get() on two values, then set these two values
3. Fetch these two values, using another get().

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

* I expect to see both values in the cache
* Instead, I only get one value

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

* xmemcache 1.4.2
* jmemcache-daemon 1.0.0 (also tested with 1.0.1-SNAPSHOT)


Please provide any additional information below.

This bug happens due to the way cork() and uncork() is used in 
MemcachedBinaryResponseEncoder. The cork() call is made with the opaque value, 
but when the final response is made, we only look at the opaque value from the 
current command to uncork any responses, leaving the responses with a different 
opaque value behind in corkedBuffers.

Attach please find a testcase.jar which includes a full maven project to verify 
that the bug exists, as well as a proposed patch.

I tried to use jmemcached from Java memcached client 
(https://github.com/gwhalin/Memcached-Java-Client) and get an error.

Java memcached client send the cas request with extra blank such as:
--------
cas name 32 0 5       1
value
--------

jmemcached seems to split the request by ' '. Therefore it throws 
NumberFormatException because it tries to parse the empty string as a number.
--------
20:59:42.360 [New I/O server worker #1-1] ERROR 
c.t.j.p.t.MemcachedResponseEncoder - error
java.lang.NumberFormatException: For input string: ""
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) ~[na:1.6.0_20]
    at java.lang.Long.parseLong(Long.java:431) ~[na:1.6.0_20]
    at java.lang.Long.valueOf(Long.java:525) ~[na:1.6.0_20]
    at com.thimbleware.jmemcached.protocol.text.MemcachedCommandDecoder.processLine(MemcachedCommandDecoder.java:121) ~[jmemcached-core-0.8.jar:na]
    at com.thimbleware.jmemcached.protocol.text.MemcachedCommandDecoder.messageReceived(MemcachedCommandDecoder.java:55) ~[jmemcached-core-0.8.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:350) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201) ~[netty-3.2.3.Final.jar:na]
    at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46) [netty-3.2.3.Final.jar:na]
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_20]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_20]
    at java.lang.Thread.run(Thread.java:619) [na:1.6.0_20]
--------

It might be a problem of Java memcached client. However the original memcached 
can process this request correctly. Therefore, I think jmemcached  should 
accept the format which is not strict.

Invoking a "gets" after "add" (with spymemcached 2.5) fails with jmemcached 
0.9.1, while doing a "gets" after a "set" is fine.

The attached test shows this behavior.

I'm just working at a new feature of memcached-session-manager 
(http://code.google.com/p/memcached-session-manager) where I really need this 
handling and I'm running all integration tests with jmemcached (which is great 
software btw!). Therefore it's somehow urgent to me.

If I can help with s.th. please let me know!

Thx && cheers,
Martin

If set  key is Chinese ,get diffrent key (Chinese) will output same value.
'发大水" AND "太阳日" will output the same value.

LRUCacheStorageDelegate had removed in 0.9, what is the replacement?