Closed GoogleCodeExporter closed 9 years ago
Thank you for the report. I'll try to reproduce the error.
Could you please check if the error also occurs with xmemcached provider?
Original comment by ragno...@gmail.com
on 24 Sep 2013 at 9:44
Thanks. We're actually using some Spy-specific functionality (JMX monitoring),
so I can't easily swap one for the other right now. I'm pretty swamped right
now with something else, but when I get some time, I'll do what's needed to
verify with xmemcached.
Original comment by null.poi...@gmail.com
on 24 Sep 2013 at 9:34
I was able to reproduce the issue
Original comment by ragno...@gmail.com
on 25 Sep 2013 at 7:57
Fix is available in trunk.
If it possible please build SSM from trunk and test it.
I'm also considering modifying spymemcached-provider to wrap all
RuntimeExceptions into TimeoutException or CacheException.
Original comment by ragno...@gmail.com
on 25 Sep 2013 at 9:53
Thank you so much! I've built SSM trunk locally, and can confirm the fix.
Catching all runtime errors during the cache operations makes sense to me.
Caching should always be optional, and I can't think of any scenarios when that
should be violated, regardless of how loudly the cache client says otherwise.
For now, I've shoved the build into our Nexus repository. How long might I
expect before a fixed version is available from Maven central?
I'm glad you were able to get a repro so quickly. It was easy for me to repro
in one particular environment for me, but I still can't get the timing right on
my local machine.
BTW, I spent some time today trying to get a repro with the xmemcached client.
Doing that made me realize how many contortions I've gone to in my Spring
wiring, to get access to the actual spy client (MemcachedClientIF). I need
access to it for some bulk CASMutator operations outside of SSM. If you find
an easy way to expose that client (either through the CacheClientFactory, or
via a Spring @Resource), that would be great. Alternatively, maybe it makes
more sense to let people inject their own pre-built client into SSM somehow.
Original comment by null.poi...@gmail.com
on 26 Sep 2013 at 12:04
I'm glad that it works.
Frankly speaking I haven't even tried to reproduce the issue in the same way as
you noticed it because timeout exceptions are non-deterministic and depend on
environment. Instead I've temporary modified SSM code to throw RuntimeException
from generateByKeysFromResult method to simulate your issue. It was enough to
find a reason of the issue.
Both ideas to expose the client in easy way or let people inject their own
pre-build client are good. Unfortunately the second one won't work with one of
SSM features: runtime node switching in this case SSM factory need to create a
new client using a new IP address. Instead I can provide a hook that will allow
to register listener on post initialize phase of memcached client. What do you
think?
Regarding the SSM release time. If above features are not something that you
must have then I think I'll find a time to release SSM at the weekend. The
release will contain only the fix.
Original comment by ragno...@gmail.com
on 26 Sep 2013 at 5:24
Personally, I'd say this bug warrants a release fairly soon. Everything else
was just feature requests, and I'll be happy if you get to them in a couple
months, if at all. If you can manage a new version this weekend, that would be
fantastic, but otherwise I can work from trunk for now.
Ironically, one of the big reasons I was interested in being able to inject my
own client was so I could mock it to throw timeout errors like you did. I
don't think I'd ever want to inject a client outside of a test situation
though. Maybe you can provide a way to inject test/mock clients, with the
documented caveat that it won't deal with node switching in that case?
Getting at the actual Spy/X-client instance via your factory would be super
useful though. As it stands, I had to copy your factory, and put it in a
com.google package, so I could access a sealed/package-protected constructor
for one of the client wrapper classes.
Original comment by null.poi...@gmail.com
on 26 Sep 2013 at 7:17
The fix has been released in 3.2.1. The release is available in central maven
repository.
Original comment by ragno...@gmail.com
on 30 Sep 2013 at 5:02
Original issue reported on code.google.com by
null.poi...@gmail.com
on 23 Sep 2013 at 7:13