for non ascii top keys are displayed with BIN_ prefix so user will not able to copy/paste the string and retrieve the key

Aleksey Kondratenko added a comment - 07/Aug/12 2:27 PM There's no way as of now to 'properly' display 'binary' hot keys. BIN_<base64> format for non ascii keys was implemented by me very long time ago. I'm ok with changing that, but I need 'yes we desperately need this fixed' first.

Dipti Borkar added a comment - 13/Aug/12 8:55 AM Aliaksey, not sure I understand. Is the key non-ascii? Has this been the behavior even for 1.8.X ? What are the options we have to improve the user experience here?

Aleksey Kondratenko added a comment - 13/Aug/12 11:35 AM We had this since 1.0.3 days. Really early. If key is not ascii, I'll do BIN_<base64>. Do you think we need to fix this at all ?

Ketaki Gangal added a comment - 05/Oct/12 6:07 PM Re-opening this issue.

Ketaki Gangal added a comment - 05/Oct/12 6:10 PM Same Data exists on source and destination. But we see different representation on the Source v/s Destination ends. The source displays the correct keys,while for some reason - the key is encoded in all binary 0s and more on the destination. Unpack on the data - "BIN_AAAAAAAAAAAAAAAAAAAAAQAGwR/K3og shows number of \00\00 ..

Chiyoung Seo added a comment - 07/Oct/12 4:02 PM Ketaki, Please assign it to the person who is involved in top key management and display. ep-engine just stores a key as it is and doesn't make any changes in the format.

Junyi Xie added a comment - 08/Oct/12 3:47 PM IMO It does not help anybody by kicking the ball back and forth. I did some debugging in ns_server, and now it looks to me a bug within hot key management either in memcached or ns_server. The key generated by mcsoda is all ASCII encoded and all keys can be shown correctly on UI at source side. The reason we saw the keys like BIN_XXXX at destination side is because there are keys whose character is not within the range [16#20, 16#7F] and thus it is encoded as "BIN" ++ base64:encode_to_string(Key) By some tracing in module hot_keys_keeper, looks like we put some non-key data as a key into the top key list, see the dump below. The "[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,9,45],  [{ops,0.0}]}" is apparently not a valid key since all keys starts with "XDCR-" [xdcr:debug,2012-10-08T12:34:18.696, n_1@127.0.0.1 :<0.1960.0>:hot_keys_keeper:keys_updater_body:186]xdcr-junyi: all local key is [{"default",                                 [{"XDCR-e0cf1f47118daebc",[{ops,0.0}]},                                  {"XDCR-d554f7bb7be44a72",[{ops,0.0}]},                                  {"XDCR-66368270ffd51418",[{ops,0.0}]},                                  {[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,9,45],                                   [{ops,0.0}]},                                  {"XDCR-e94550c93cd70fe7",[{ops,0.0}]},                                  {"XDCR-67d16d00201083a2",[{ops,0.0}]},                                  {"XDCR-df263d996281d984",[{ops,0.0}]},                                  {"XDCR-63923f49e5241343",[{ops,0.0}]},                                  {"XDCR-7eabe3a1649ffa2b",[{ops,0.0}]},                                  {"XDCR-9b698eb3105bd825",[{ops,0.0}]}]}] The top key list above comes from memcached in this function. grab_bucket_topkeys(BucketName) ->     {ok, RawKeys} = ns_memcached:topkeys(BucketName),     [{K, [{ops, aggregate_key_ops(V)}]} || {K,V} <- RawKeys]. Hand over to bucket engine owner, assume bucket-engine manages the top key list.

Perry Krug added a comment - 18/Dec/12 5:39 AM -Are these keys actually user-data or something we are creating as part of the XDCR? -If they are use data, are we actually changing the name/format of the key as it comes into the destination side? Is the key still available via its "correct" name on the destination?

Trond Norbye added a comment - 18/Dec/12 7:31 AM Do we have a testcase that reproduce the problem?

Trond Norbye added a comment - 18/Dec/12 7:31 AM Do we have a testcase that reproduce the problem?

Junyi Xie added a comment - 18/Dec/12 3:59 PM It is fairly easy to reproduce. Setup 2 clusters on locally, create a unidirectional XDCR, load some data by mcsoda to source cluster with prefix like "XDCR", on the destination UI you would see those BIN_XXXXX keys.  

Karen Zeller added a comment - 28/Mar/13 5:54 PM Removing documentation tag until the information that should be documented is identified. Also need to know what guide impacted, if any.

Trond Norbye added a comment - 02/Apr/13 2:35 AM Where can I get that mcsoda tool you're refering to? I tried to reproduce this with "pillowfight" from libcouchbase without any success..

Junyi Xie added a comment - 02/Apr/13 9:38 AM it is in testrunner/lib/perf_engines for example, you can load bucket with 500k items by: lib/perf_engines/mcsoda.py localhost:12001 doc-gen=0 doc-cache=0 ratio-creates=1 ratio-sets=1 ratio-deletes=0 min-value-size=1,3 max-items=500000 exit-after-creates=1 prefix=XDCR

Trond Norbye added a comment - 03/Apr/13 1:49 AM http://review.couchbase.org/#/c/25456/1

Thuan Nguyen added a comment - 03/Apr/13 2:01 AM Integrated in github-bucket-engine #75 (See [ http://qa.hq.northscale.net/job/github-bucket-engine/75/ ])      MB-6144 : Some packages used incorrect offsets (Revision 0992a55308dd3cb1996cd7ba95328ea3ae6569a4)      Result = SUCCESS Trond Norbye : Files : * bucket_engine.c

Thuan Nguyen added a comment - 03/Apr/13 3:26 AM Integrated in github-bucket-engine #76 (See [ http://qa.hq.northscale.net/job/github-bucket-engine/76/ ])      MB-6144 : fixed typo (Revision 2a797a8d97f421587cce728f2e6aa2cd42c8fa26)      Result = SUCCESS Trond Norbye : Files : * bucket_engine.c

Maria McDuff added a comment - 05/Apr/13 12:54 PM pls verify in new build of 2.0.2