You could easily develop an http-to-memcached proxy to allow this. All the
partitioning logic could exist in the memcache client embedded in your
proxy. This might make some sense because then you would not have to
implement the partitioning logic into your clients. I would say the answer
to the
Hi dormando,
I would love to see this change. One thing that would be great to have is
support for multiple tokens for the purpose of key rotation. If there are
roles, one could just assign 2 equivalent roles with different tokens, but
in the absence of roles as you mentioned just having the abil
ng a reload mechanism but shouldn't be too messy, I guess?
>
> On Mon, 16 Apr 2018, John Reilly wrote:
>
> > Hi dormando,I would love to see this change. One thing that would be
> great to have is support for multiple tokens for the purpose of key
> rotation. If
> >
You might have better luck on the spymemcached mailing list
spymemcac...@googlegroups.com (
https://groups.google.com/forum/#!forum/spymemcached)
The vulnerability appears to only impact log4j 2.x, not 1.2.x.
Regards,
John
On Wed, Oct 17, 2018 at 6:00 PM Deepthi Komatineni
wrote:
>
> We in our
Hi all,
I was just thinking it would be great to be able to cache the most used
items in a local cache on the client side and I think this would be
possible if there was a way for the client to send a request to get a key,
but only if the cas value is not the same as the cas token of the value I
al
kind of sucks but you'd only do this when it would reduce
> the number of requests back to origin anyway :)
>
> I'm hoping to get metaget in mainline ASAP. Been hunting around for
> feedback :) Should be finishing up the code very soon, with merge once a
> bit more confident
of which would do what you want, but lets just take a quick
> look at your workload first so you don't end up with something more
> complicated and slower :) I'm not sure I can get the flags to make sense
> but I'll try.
>
> On Sat, 21 Sep 2019, John Reilly wrote:
>
>
On Mon, Sep 23, 2019 at 1:48 PM dormando wrote:
> Gotcha. Thanks a ton for reaching out and putting up with my questions :)
>
Not at all :) - thank you for all your work on memcached.
mget/mset/mdelete will certainly be a great addition.
> One other thing mget might get you here is an easy pro
There is probably a xmemcached mailing list that would be better for this
question, but I suspect it is because mcrouter does not support the binary
protocol (which your client trying to use).
On Fri, Jul 24, 2020 at 3:34 PM saravanakumar rajendran <
saravanakumarr...@gmail.com> wrote:
> We have
If you are doing this in Java, you can use ehcache server. Actually, your
clients don't need to be java based. The last time I looked there were no
clients for doing the partitioning of requests to servers. I think there is
a diagram and description of this scenario on the ehcache web site. I'm
+1
On Wed, Oct 7, 2009 at 1:23 PM, Nelz wrote:
>
> As a user of Dustin's client, I corroborate what he said. It really is
> the best Java client around.
>
> - Nelz
>
> On Wed, Oct 7, 2009 at 11:46, Dustin wrote:
> >
> >
> > On Oct 7, 11:36 am, sudo wrote:
> >> Which java client is most stable
Hi,
It doesn't have to be one or the other. Sometimes it makes sense to use
both memcached and an in-process cache. The in-process cache will be
faster, but you then have to think about memory usage and cache consistency.
If you have some keys which are fetched more frequently than most, it may
Hi,
java.util.concurrent.ConcurrentHashMap exists in 1.5 so it should run with
1.5 unless I missed something. Are you sure that you are using a 1.5 jre?
Cheers,
John
On Fri, Nov 20, 2009 at 1:33 AM, Kitutech wrote:
> :( is nothing good :( the application that have it in this tomcat
> require
; It was introduced in 1.6
>
>
>
>
> On Fri, Nov 20, 2009 at 11:04 AM, John Reilly wrote:
>
>> Hi,
>>
>> java.util.concurrent.ConcurrentHashMap exists in 1.5 so it should run with
>> 1.5 unless I missed something. Are you sure that you are using a 1.5 jre?
&
14 matches
Mail list logo
