Add an configuration option to choose the Spymemcached Memcached client
igorbolic opened this issue · 15 comments
Since the version 2.x.x the default Memcached client used within the library is XMemcached. Allow users to opt for Spymemcached fork which was used as default implementation with version 1.x.x.
Add an configuration option which will allow users to choose the underlying client implementation to use within their application.
Thank you for the effort on this! Another option fo the implementation would be picking up what class is available in the classpath and create the client from it, using Spring's @ConditionalOnClass.
@tomasAlabes Before going any further with this change, may I ask what is your use case / the reasons where you would use this option i.e. choosing Spymemcached (defaul in 1.x.x) instead of XMemcached (the default client from version2.x.x) ?
It would be helpful to customize the client for:
- Standardization, my team works with spymemcached so I have to stick with it (internal legal reasons too)
- Defining the client lets me provide a wrapper of the original one, to give it extra functionality, as a circuit breaker
@igorbolic did you have the time to look at this?
We are planing to finish it by Monday, next week. The plan is to release it with the version 1.4.0, where the default client is will remain to be the SpyMemcached. The decision was made in order not to further complicate the setup / configuration for the 2.x.x users (this might change in the next major release where we might include support for both clients: XMemcached & SpyMemcached).
Could you let me know what Spring Boot version are you using, is the the 2.x.x branch?
@tomasAlabes
Hi Tomas, 1.4.0-SNAPSHOT version has been deployed which supports Spring Boot 2.x.x (and all needed metrics changes).
Could you please check if everything works as expected with this updates so we could make a final release of 1.4.0 version.
If everything is ok, we'll release the 1.4.0 tomorrow. Thx
Oh, you're updating the old one? I thought you were adding the mc client configurability + fixes in the current one (2.1.2).
I will try it anyway and give you feedback
I can't seem to find the version
> Could not find io.sixhours:memcached-spring-boot-starter:1.4.0-SNAPSHOT.
Required by:
project :spring-app
> Could not find io.sixhours:memcached-spring-boot-autoconfigure:1.4.0-SNAPSHOT.
Required by:
project :spring-app
In order to use SNAPSHOT version the snapshot repo should be configured.
Check this for the example configuration.
Ok, I think it works the same as 2.1.2. I didn't see any fix for the dynamic metrics or being able to specify the memcached client. Idk if that was the goal.
Something that I found in both versions is that if I want to wrap the MemcachedCacheManager, I need to create it manually using the @EnableConfigurationProperties and then wrap it (instead of injecting it and then wrap it).
The idea here was to support Spring Boot 2.x.x for the people who wants to use Spymemcached as a client (we abandoned this client from 2.x.x version in favor of Xmemcached ). Not sure why do you need direct access to it. If you inject CacheManager you'll have all required functionality. Maybe if you give an example of usage (some code snippet).
At this moment we cannot say for sure if we will add support to choose between those two clients in the versions > 2.x.x.
If you are fine with Xmemcached under-the-hood, I suggest using the 2.x.x version. And we could close this issue. Otherwise we could release this one.
About the dynamic metrics, great idea and thanks for this, we will update this as a separate issue.
Before the dynamic metrics are introduced, as a temporary solution you can specify in the configuration spring.cache.cache-names the caches for which you would like to have the metrics (more details here).
Hi @sasabolic, thanks for the clarification.
- That would mean that you'd have to maintain 2 versions, or 1.x.x will lag behind on features/fixes
- For versions 2.x.x you can still leave Xmemcached as the default client. And leave Spring or the dev itself the opportunity to use spymemcached if they want
- In my case the cache names are a lot, so it would be hard to maintain. I have my own wrapper of the
MemcachedCacheManagerto workaround the dynamic metrics: gist - I'd like to do the same with the memcached client, I mentioned @igorbolic the benefits of having access to it (no matter the actual impl)
It would be helpful to customize the client for:
- Standardization, my team works with spymemcached so I have to stick with it (internal legal reasons too)
- Defining the client lets me provide a wrapper of the original one, to give it extra functionality, as a circuit breaker
If we cannot get aligned maybe is better to fork it myself, as I already have wrappers with some features and fixes I did. And I need access to the native client soon to add, resiliency to it (my priority is not switching to spymc but having access to the native client).
I was hoping for it to be more flexible, to enrich it from the outside without changing or replicating lib code. But it's ok if you think otherwise, is your lib after all
Thank you
@tomasAlabes, thanks for adding more details
Sure we are the admins for this library, but the main reason for publish it is to make peoples life easier, not for our personal usage
Main reason for our concern of adding support for to Spymemcached is that lot of people had issues with it the past (and the library has not been updated recently) and Xmemcached was shown as more mature in that sense.
But good point, if someone want's to use it despite all this concerns, why not allow it.
Hence we'll make adequate changes to support Spymemcached (instead of Xmememcached) in 2.2.0 version.
About the access to the native client, I don't see a reason why not expose it.