Hey,

I believe what you're seeing, however I'm telling you how this happens.
There hasn't ever been a server-side bug where a key gets set to the wrong
value. It's possible, if the protocol is corrupted, for garbage data to
end up in a value, and only with the ascii protocol. Though you said you
were using spymemcached, so maybe that's on the binprot...

I'll add a caveat because your dev environment is running a fork of
ancient code :) I'd feel much more comfortable stating the server is good
if you were on a recent version.

If you can reproduce it with the dev environment, I would absolutely focus
on it there. Try a different client if you can, or a different version of
spy, or otherwise change the environment until it stops happening.

IE; you may be using spymemcached wrong (if binprot, reusing opaque
values, missing locks, etc). it's very hard to tell without the code,
since so many things can go wrong which look like this.

On Mon, 19 Feb 2018, Praveen wrote:

> Thanks Dormando for your prompt responses on this.I really appreciate it.
>
> The server running on docker is on top of alphinelinux.
> I am able to reproduce the issue in local dev environment but I am not much 
> worried in local dev as it is used only for development and Unit Testing.
>
> Keys will have only alphanumerics and _,-. We don't have keys other than this 
> combination.
>
> I agree on this higher level issue but the problem for me here is different. 
> In my case I don't think the issue is due to setting the wrong value to the
> key. Scenario is like, initially I will get correct value for the key but 
> later on, the returned data for the same key will be different. And the issue
> occurrence is not predictable, some times due to many parallel calls to 
> service, wrong data will be returned and sometimes data returned by memcached 
> is
> correct though the amount of calls is more or less.
>
> Even though the issue occurrence is rare/not frequent the impact will be huge.
> I am not aware of the desync protocol. I need to check this.
>
> Let me know your thoughts on this Dormando.
>
> Regards,
> Praveen
>
> On Monday, February 19, 2018 at 3:01:02 PM UTC+5:30, Dormando wrote:
>       Hey,
>
>       Oh, we don't actually support windows. That might be an old fork/port. 
> Is
>       the server running in docker on top of linux?
>
>       Are you reproducing the issue in your local dev environment?
>
>       like I said before; most likely you need to examine the kind of keys
>       you're setting. Make sure they're only [a-zA-z0-9_-.]-ish, or you can
>       cause the protocol to desync.
>
>       It can also be a higher level issue in your app; accidentally setting 
> the
>       wrong value to that key. There haven't been any server bugs which can
>       cross wires like that.
>
>       On Sun, 18 Feb 2018, Praveen wrote:
>
>       > Thank you for your thoughts on this Dormando.
>       >
>       > I need to check with my team for the version in the docker container 
> but in my local dev environment memcached version is 1.4.5_4_gaa7839e
>       where the OS
>       > is Windows 7 and I am running my app in Eclipse.
>       >
>       > Once key1 returns wrong data then the same incorrect data i.e., 123 
> will be returned even if I try to telnet directly memcached. I need to
>       clear and
>       > build the cache again to resolve  issue.
>       > Key format "guid_text_v1". Ex: 
> 23111a7e-8abb-4e39-b5cd-c1eeeb06b386_abc_v1
>       >
>       > Logic in my app is simple, if there is some data associated with the 
> key in memcached then get the data from memcached else call the
>       respective service
>       > for the data and store the same in local memcached.I am not sure what 
> could be the issue in the client code.
>       >
>       > Are there any special instructions I need to follow to resolve this 
> issue?
>       >
>       > Regards,
>       > Praveen
>       >
>       > On Sunday, February 18, 2018 at 12:31:27 AM UTC+5:30, Dormando wrote:
>       >       Just out of curiosity; what version of the server are you 
> running?
>       >
>       >       This is always an issue with your client code.
>       >
>       >       1) if you telnet directly to memcached and run "get key1", does 
> it return
>       >       abc or 123?
>       >
>       >       2) if abc, then you might have an ordering issue or invalid 
> characters in
>       >       your keys (\n, space, etc)
>       >
>       >       3) if 123, probably the same glitch but might narrow down which 
> code you
>       >       should look at on your end.
>       >
>       >       On Sat, 17 Feb 2018, Praveen wrote:
>       >
>       >       >
>       >       > What could be the reason for memcached to return wrong value?
>       >       >
>       >       >
>       >       > Ex: Key1 -> "abc"; key2 -> "123". 
>       >       >
>       >       > When I am trying to retrieve data for Key1, data returned is 
> 123 instead of abc. This happens in my local environment(application
>       on
>       >       Windows machine with
>       >       > memcached-win64) and also in dev server(docker container with 
> alphinelinux).
>       >       >
>       >       >
>       >       > I am storing String value as Object in memcache in my Java 
> application with spymemcached client version 2.9.1. 
>       >       >
>       >       > In docker container I increased the size of memcached to 1024 
> MB from 512 MB but no luck. This happens randomly and I am not sure
>       when this
>       >       happens. If I
>       >       > clear the complete cache then everything works fine.
>       >       >
>       >       >
>       >       > Did anyone face similar issue? If yes, how was this resolved? 
> It would be of great help if someone sheds some light on this.
>       >       >
>       >       >
>       >       > Thanks in Advance, 
>       >       >
>       >       > Praveen
>       >       >
>       >       > --
>       >       >
>       >       > ---
>       >       > You received this message because you are subscribed to the 
> Google Groups "memcached" group.
>       >       > To unsubscribe from this group and stop receiving emails from 
> it, send an email to memcached+...@googlegroups.com.
>       >       > For more options, visit https://groups.google.com/d/optout.
>       >       >
>       >       >
>       >
>       > --
>       >
>       > ---
>       > You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>       > To unsubscribe from this group and stop receiving emails from it, 
> send an email to memcached+...@googlegroups.com.
>       > For more options, visit https://groups.google.com/d/optout.
>       >
>       >
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to