I think you're supposed to read to the point where it says queues stuff
in memory before sending to the server and extrapolate that writing to
the queue too fast is a bad thing.
On Sun, 17 Oct 2010, Shi Yu wrote:
Kelvin.
This is year 2010 and computer programs should not be that fragile.
And
On Oct 16, 9:28 pm, Shi Yu shee...@gmail.com wrote:
MapString,String map1 = new HashMapString,String();
MapString,String map2 = new HashMapString,String();
MapString,String map3 = new HashMapString,String();
You're loading at least four million strings into two
Hi Dustin. I have to go on my work now so I probably wont spend any
time on this issue. Please, before you suggest, try some experiment to
load more than 6 million records using the same API. I would be happy
to hear how you do that. I now fully rely on Whalin's API, it can
handle 14 million
On Oct 16, 11:11 pm, Kelvin Edmison kel...@kindsight.net wrote:
while trying to re-create this problem and point out the various errors in
his code, I found that, in his test case, if I did not call Future.get() to
verify the result of the set, the spyMemcached client leaked memory. Given
On Oct 16, 11:24 pm, Shi Yu shee...@gmail.com wrote:
Kelvin.
This is year 2010 and computer programs should not be that fragile.
And I believe my code is just a fast simple toy problem trying to find
out why I failed too many times in my real problem. Before I post my
problem, I checked and
On Oct 16, 11:51 pm, Shi Yu shee...@gmail.com wrote:
Hi Dustin. I have to go on my work now so I probably wont spend any
time on this issue. Please, before you suggest, try some experiment to
load more than 6 million records using the same API. I would be happy
to hear how you do that. I now
Thanks Dustin, marked and will try again.
On Sun, Oct 17, 2010 at 2:38 AM, Dustin dsalli...@gmail.com wrote:
On Oct 16, 11:51 pm, Shi Yu shee...@gmail.com wrote:
Hi Dustin. I have to go on my work now so I probably wont spend any
time on this issue. Please, before you suggest, try some
Is it ever possible that your compute takes longer than your timeout?
no, the return value of memcache.delete(lock + x) is true.
On 10/17/10 6:07 AM, Tobias wrote:
Is it ever possible that your compute takes longer than your timeout?
no, the return value of memcache.delete(lock + x) is true.
But wouldn't that also be true if another process found the expired lock and set
a new one?
--
Les Mikesell
hi all
xmemcached is an open-source memcached client for java,i am pleased
to announce the release of Xmemcached version 1.2.6.1,it is a minor
version fixed bugs.if you use maven ,you cloud use it as
dependency
groupIdcom.googlecode.xmemcached/groupId
10 matches
Mail list logo
