Thanks again Dormando for your quick inputs on this issue.
The protocol we are using is Text. Below is the code of
ConnectionFactoryBuilder and other parts in setting and retrieving the data:
--------------------------------------------------------------------------------------------------
ConnectionFactory connectionFactory = new ConnectionFactoryBuilder()
.setProtocol(ConnectionFactoryBuilder.Protocol.TEXT)
.setLocatorType(ConnectionFactoryBuilder.Locator.ARRAY_MOD)
.build();
MemcachedClient memcachedClientObj = new
MemcachedClient(connectionFactory,nodesList);
// Setting data
OperationFuture<Boolean> operationCode = client.set(userRequest.toString(),
CACHE_EXPIRE_TIME, userData);
// Retrieving data
GetFuture<Object> asyncFirstCall=client.asyncGet(userRequest.toString());
OperationStatus oppstatus= asyncFirstCall.getStatus();
if(oppstatus.getMessage().toString().equals("END"))
userResponse=asyncFirstCall.get(15,TimeUnit.SECONDS);
--------------------------------------------------------------------------------------------------
The data stored in memcached will be either string/class bytelist as
object. Let me know if there is anything that looks fishy in the above code.
It would be of great help if you could recommend any existing
implementations(like open source projects/code) which I can use as
reference.
On Tuesday, February 20, 2018 at 2:38:33 AM UTC+5:30, Dormando wrote:
>
> 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+...@googlegroups.com <javascript:>.
> > 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.
