Spring cache backed by Couchbase : document id not user friendly

Couchbase Server
1

Hi There,

We have implemented Spring cache backed by couchbase server and uses java client library to connect to couchbase server. We use custom document keys and not use any key generator.

In our mac, ubuntu and windows environments (wherever we have couchbase server installed) we are viewing the documents Ids in readable format (something like “cache:…”). But in our CentOS cluster, the document IDs come in alphanumeric format. Is there any configuration that can control this behaviour? We use 4.5.0_2651 Community edition in centos.

Any help on making the Document IDs readable would be appreciated.

Thanks in Advance
Sethukumar

2

The cluster document viewer will interpret any keys as UTF-8 encoded strings. If your custom document key is also UTF-8, then you should be able to see it fine at the cluster. When you say it’s not readable, you do mean the document key, not the body, right?

3

Hi ingenthr,

Appreciate the quick response!
Yes it is the document ID or key that I’m talking about. The body (the value) is stored in binary format. In our development boxes (windows, mac, ubuntu) we are able to view and interpret the document IDs clearly. For creating views it is helpful. How do we make sure that the key is UTF-8 encoded, by the way? The way document key has been used is like the typical spring cache abstraction way:
@Cacheable(value = “myCache”, key = “#cacheKey”, unless = “#result == null”)
where the string cacheKey is a string passed to the java method on which I have applied the cacheable annotation. The format of document ID in readable format in my dev box look like ‘cache:myCache:some_specific_id’ whereas in the centOS environment it look like ‘1A5GD566SVVSGY2HQB…’

thanks

4

That’s unusual. I don’t know of a way to coerce it to something else. It might be a bug in our, or Spring’s, conversion from java.lang.String to the key.

@subhashni: do you think we can try to reproduce this with the info above, or would it be helpful if @sethunr can provide a sample that shows what’s happening?

@sethunr if you can put together a quick sample project, that may help us speed up figuring out what’s going on. Also, a possible workaround would be to pass a specifically coerced UTF-8 byte array with getBytes("UTF-8")? Internal to Java, Strings don’t actually have a defined representation, so something in the path there is mis-converting it I would think.

5

Hi @sethunr,

Spring couchbase cache doesn’t do more than apply the prefix of cache:myCache: based on the annotation for the cacheable you provided. Can you provide a code sample that reproduces this behavior.

6

HI @subhashni,

The interesting thing is that in almost all of our development environments (windws, ubuntu, mac) where we have couchbase server installed and used our application that implements cache represent the document IDs in readable format. Only on our centOS environment which is our QA and prod environment where we have this issue of document ID not being readable. Also it alternate between readable to unreadable without any predictable delay.
The code that we use is something like this (at this point of time I’m not able to create a new code sample that do not reveal our own code).
We have our service layer where we would like to apply caching and the service methods actually use the @Cacheable or @CachePut annotations where the return type of the method is actual type of object that we want to be cached. Of course the objects are serializable. At spring context level we use the couchbase java SDK to create the ouchbase environment, cluster abstractions, open connection to the bucket etc. We use the spring-data-couchbase-2.1.1.RELEASE, couchbase-spring-cache-2.1.1-SNAPSHOT along with.
From application code perspective, using the spring cache annotations is the only part we do in our code. Rest of the cache behaviour is sum total of all the libraries being used. Hope this helps.
Also I’m not sure whether an operating system level configuration can help this resolved.

thanks for the replies and appreciate it.

7

Which specific Centos version and glibc do you have? We may want to look further into this. Other than the UI artifact, is there any other effect?

8

CentOS release : 7.3.1611 (Core)
glibc : glibc-2.17-157.el7_3.1.x86_64

thanks

9

Somehow we are able to view the document IDs in readable format now. Not sure whether any configuration changes done by our network admin, if any, brought us this behaviour.

10

Hello there, Just curious to know weather were you at Couchbase able to make some finding or CentOS related configurations for this issue.