spymemcached
kiviljc / spymemcached Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/spymemcached
Automatically exported from code.google.com/p/spymemcached
spymemcached
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
Prepend also went in.
Original issue reported on code.google.com by [email protected]
on 17 Apr 2008 at 6:50
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* getAvailableServers()
* getUnavailableServers()
Original issue reported on code.google.com by [email protected]
on 2 Mar 2008 at 5:57
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
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
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
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:
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
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
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
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
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
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
[deleted issue]
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
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
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
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
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
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:
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
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
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:
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.