Can you add an assert within client.set or asyncGet if there're any
newlines, spaces, etc in userRequest?
Sorry, missed your response last week :(
On Tue, 20 Feb 2018, Praveen wrote:
> 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 [email protected].
> > > > 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 [email protected].
> > > 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 [email protected].
> > 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
