Strange issue: Could not decode snappy-compressed value

I tried to investigate the “timeout”…

I’ve set the addresses of the database servers directly in the hosts file of the app. server:

cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.42.226	fangst.dalsgaard-data.dk
192.168.42.211	db1.dalsgaard-data.dk db1
192.168.42.212	db2.dalsgaard-data.dk db2
192.168.42.213	sg1.dalsgaard-data.dk sg1

And a ping responds Ok:

[jda@ds3 ~]$ ping db1
PING db1.dalsgaard-data.dk (192.168.42.211) 56(84) bytes of data.
64 bytes from db1.dalsgaard-data.dk (192.168.42.211): icmp_seq=1 ttl=64 time=0.183 ms
64 bytes from db1.dalsgaard-data.dk (192.168.42.211): icmp_seq=2 ttl=64 time=0.178 ms
64 bytes from db1.dalsgaard-data.dk (192.168.42.211): icmp_seq=3 ttl=64 time=0.219 ms
[jda@ds3 ~]$ ping db2
PING db2.dalsgaard-data.dk (192.168.42.212) 56(84) bytes of data.
64 bytes from db2.dalsgaard-data.dk (192.168.42.212): icmp_seq=1 ttl=64 time=0.271 ms
64 bytes from db2.dalsgaard-data.dk (192.168.42.212): icmp_seq=2 ttl=64 time=0.182 ms
64 bytes from db2.dalsgaard-data.dk (192.168.42.212): icmp_seq=3 ttl=64 time=0.568 ms

So not sure that the network setup is the direct cause of the timeouts…

Ok @ingenthr , I now have a consistent case :slight_smile:

Situation: I have an email and I want to find the key for the user and then load the entire user. The user info is split into two documents:

  1. User that contains the “non-personal” info of the user
  2. Private that contains personal info. This makes it easier to control where the personal information goes (e.g. in the Sync.Gateway).

So first I search for any Private documents with the email address. If found then we have a key. We then use that key to lookup the User directly by using ...get("User:2124DEFEC111BA8FC1257ED20034B387") and if found we get thePrivatedocument directly by using…get(“User:Private:2124DEFEC111BA8FC1257ED20034B387”) - and we then combine the two documents into one User object in the code.

So with the above in mind this output should be clearer:

CouchbaseUserDAO.loadUser: Find by email: john@dalsgaard-data.dk
BaseCouchbaseDAO.getAllFromDb: Query=SELECT * FROM data WHERE type='Private' AND (lower(email)=lower('john@dalsgaard-data.dk'))
BaseCouchbaseDAO.getAllFromDb: Result from Query=N1qlQueryResult{status='success', finalSuccess=true, parseSuccess=true, allRows=[{"data":{"address":"Solbjergvej 42\r\nSolbjerg","cellphone":"40566308","city":"Høng","country":"DK","email":"john@dalsgaard-d
ta.dk","key":"2124DEFEC111BA8FC1257ED20034B387","name":"John Dalsgaard","parenttype":"User","password":"x5w77zZoW3","phone":"49141248","sex":"M","type":"Private","userkey":"2124DEFEC111BA8FC1257ED20034B387","zip":"4270"}}], signature={"*":"*"}, info=N1qlM
trics{resultCount=1, errorCount=0, warningCount=0, mutationCount=0, sortCount=0, resultSize=348, elapsedTime='6.388261ms', executionTime='6.284091ms'}, profileInfo={}, errors=[], requestId='016d8d47-7303-403a-8774-687df685a030', clientContextId='dcda9323-
4f2-4f0b-9176-4a1efe13cc4c'}
CouchbaseUserDAO.getKeyByEmail: Result={"data":{"zip":"4270","country":"DK","address":"Solbjergvej 42\r\nSolbjerg","city":"Høng","sex":"M","type":"Private","userkey":"2124DEFEC111BA8FC1257ED20034B387","password":"x5w77zZoW3","phone":"49141248","name":"Joh
 Dalsgaard","cellphone":"40566308","parenttype":"User","email":"john@dalsgaard-data.dk","key":"2124DEFEC111BA8FC1257ED20034B387"}}
CouchbaseUserDAO.loadUser: Found key: 2124DEFEC111BA8FC1257ED20034B387
CouchbaseUserDAO.loadUser: Find by direct key: User:2124DEFEC111BA8FC1257ED20034B387
CouchbaseUserDAO.loadUser: Found user doc. Get private doc: User:Private:2124DEFEC111BA8FC1257ED20034B387
Rest.handle: ERROR - java.lang.RuntimeException: Could not decode snappy-compressed value.
Rest.dumpRawExceptionData: ERROR - Exception: CouchbaseException - java.lang.RuntimeException: Could not decode snappy-compressed value.
   com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:369)
   com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageC...
   com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMes...
   com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessa...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstract...
   com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMes...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstract...
   com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerC...
   com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessa...
   com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDe...
   com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChann...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstract...
   com.couchbase.client.deps.io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler....
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstract...
   com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(Default...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abstra...
   com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelP...
   com.couchbase.client.deps.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(Abstract...
   com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:...
   com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEvent...
   com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java...
   com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
   com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEv...
   com.couchbase.client.deps.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRun...
   java.lang.Thread.run(Thread.java:811)

This is the code that fails:

	Util.info("Found user doc. Get private doc: " + getPrivateDocId(key));
-->	JsonDocument privDoc = getDb().get(getPrivateDocId(key));

And here is the output of the cbc cat command:

cbc cat User:Private:2124DEFEC111BA8FC1257ED20034B387 -U http://db1/data -u xxxxx -P yyyyy
User:Private:2124DEFEC111BA8FC1257ED20034B387 CAS=0x15bd8c734d220000, Flags=0x2000000, Size=339, Datatype=0x01(JSON)
{"address":"Solbjergvej 42\r\nSolbjerg","cellphone":"40566308","city":"Høng","country":"DK","email":"john@dalsgaard-data.dk","key":"2124DEFEC111BA8FC1257ED20034B387","name":"John Dalsgaard","parenttype":"User","password":"x5w77zZoW3","phone":"49141248","sex":"M","type":"Private","userkey":"2124DEFEC111BA8FC1257ED20034B387","zip":"4270"}

I just queried the document from the db admin panel (where the lookup by id works fine). The meta data is:

{
  "meta": {
    "id": "User:Private:2124DEFEC111BA8FC1257ED20034B387",
    "rev": "15-15bd8c734d2200000000000002000000",
    "expiration": 0,
    "flags": 33554432,
    "type": "json"
  },
  "xattrs": {
    "_sync": {
      "rev": "5-a5e4c60689b9662026bb4fb9f2ef1e5d",
      "sequence": 424079,
      "recent_sequences": [
        187871,
        424071,
        424074,
        424076,
        424079
      ],
      "history": {
        "revs": [
          "4-2565a10f9deddeece8201479ce81441a",
          "5-a5e4c60689b9662026bb4fb9f2ef1e5d",
          "1-92b7043cf752430e905306c52b043359",
          "2-7432f4999e86db5c881f69a70036dd7e",
          "3-1b3a53baf64c38677f9effeaebfe94b7"
        ],
        "parents": [
          4,
          0,
          -1,
          2,
          3
        ],
        "channels": [
          [
            "channel.2124DEFEC111BA8FC1257ED20034B387"
          ],
          [
            "channel.2124DEFEC111BA8FC1257ED20034B387"
          ],
          [
            "channel.2124DEFEC111BA8FC1257ED20034B387"
          ],
          [
            "channel.2124DEFEC111BA8FC1257ED20034B387"
          ],
          [
            "channel.2124DEFEC111BA8FC1257ED20034B387"
          ]
        ]
      },
      "channels": {
        "channel.2124DEFEC111BA8FC1257ED20034B387": null
      },
      "access": {
        "2124DEFEC111BA8FC1257ED20034B387": {
          "channel.2124DEFEC111BA8FC1257ED20034B387": 187871
        }
      },
      "cas": "0x0000224d738cbd15",
      "value_crc32c": "0x3adda133",
      "time_saved": "2019-08-23T14:17:52.235653954+02:00"
    }
  }
}

And this is consistent!

Please let me know what I can do to further help?

Thoughts:
This system has been migrated from another database - so in some places I guess it could be optimized. In this case I do the SELECT on the private doc to find it by email and after loading the user doc I load the private doc again. But as I understand it, a direct lookup is quick - so I haven’t bothered to do anything about it here…

This is also a development/test environment - so earlier versions of the sync. formula could also have done “funny” things to the data. I guess you may be able to detect if this is the issue by looking at the meta data. If this is the case then I could just start over from scratch with a fresh copy from the production database (but I want to do this right: Best way to clone a bucket to a demo environment?)

… and this stacktrace is for trying to load an image. Slightly different - but with line numbers for where it broke:

Caused by: com.ibm.jscript.InterpretException: Script interpreter error, line=1, col=9: Error calling method 'getSidebarImageRef(java.lang.String)' on java class 'dk.dtu.aqua.catchlog.bean.ArticleBean'
	at com.ibm.jscript.types.JavaAccessObject.call(JavaAccessObject.java:335)
	at com.ibm.jscript.types.FBSObject.call(FBSObject.java:161)
	at com.ibm.jscript.ASTTree.ASTCall.interpret(ASTCall.java:197)
	at com.ibm.jscript.ASTTree.ASTProgram.interpret(ASTProgram.java:119)
	at com.ibm.jscript.ASTTree.ASTProgram.interpretEx(ASTProgram.java:139)
	at com.ibm.jscript.JSExpression._interpretExpression(JSExpression.java:435)
	at com.ibm.jscript.JSExpression.access$1(JSExpression.java:424)
	at com.ibm.jscript.JSExpression$2.run(JSExpression.java:414)
	at java.security.AccessController.doPrivileged(AccessController.java:730)
	at com.ibm.jscript.JSExpression.interpretExpression(JSExpression.java:410)
	at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:251)
	at com.ibm.jscript.JSExpression.evaluateValue(JSExpression.java:234)
	at com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:222)
	at com.ibm.xsp.javascript.JavaScriptInterpreter.interpret(JavaScriptInterpreter.java:194)
	at com.ibm.xsp.binding.javascript.JavaScriptValueBinding.getValue(JavaScriptValueBinding.java:78)
	... 62 more
Caused by: com.couchbase.client.core.CouchbaseException: java.lang.RuntimeException: Could not decode snappy-compressed value.
	at com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:369)
	at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec$2.decode(MessageToMessageCodec.java:81)
	at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
	at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
	at com.couchbase.client.deps.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
	at com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
	at com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:312)
	at com.couchbase.client.deps.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:286)
	at com.couchbase.client.deps.io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
	at com.couchbase.client.deps.io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:335)
	at com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1304)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:356)
	at com.couchbase.client.deps.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:342)
	at com.couchbase.client.deps.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:921)
	at com.couchbase.client.deps.io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:135)
	at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:646)
	at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:581)
	at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:498)
	at com.couchbase.client.deps.io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
	at com.couchbase.client.deps.io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:131)
	at com.couchbase.client.deps.io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:811)
Caused by: java.lang.RuntimeException: Could not decode snappy-compressed value.
	at com.couchbase.client.core.endpoint.kv.KeyValueHandler.handleSnappyDecompression(KeyValueHandler.java:397)
	at com.couchbase.client.core.endpoint.kv.KeyValueHandler.decodeResponse(KeyValueHandler.java:949)
	at com.couchbase.client.core.endpoint.kv.KeyValueHandler.decodeResponse(KeyValueHandler.java:132)
	at com.couchbase.client.core.endpoint.AbstractGenericHandler.decode(AbstractGenericHandler.java:338)
	... 33 more
Caused by: com.couchbase.client.deps.org.iq80.snappy.CorruptionException: Invalid copy offset for opcode starting at 1
	at com.couchbase.client.deps.org.iq80.snappy.SnappyDecompressor.decompressAllTags(SnappyDecompressor.java:165)
	at com.couchbase.client.deps.org.iq80.snappy.SnappyDecompressor.uncompress(SnappyDecompressor.java:47)
	at com.couchbase.client.deps.org.iq80.snappy.Snappy.uncompress(Snappy.java:85)
	at com.couchbase.client.core.endpoint.kv.KeyValueHandler.handleSnappyDecompression(KeyValueHandler.java:395)
	... 36 more

Hey @jda

You can see from the code that Snappy decompression is only attempted if the datatype reported by the server indicates it’s Snappy compressed. But your cbc-cat detective work indicates it’s stored as non-Snappy.

What is your bucket’s Compression Mode setting? I’m wondering if a) it’s Active and the server is snappy-compressing on the fly and b) perhaps something’s going wrong here and that’s why it’s failing.

If it’s Active, could you try changing it to Passive and seeing if the issue is resolved? Passive means that if a document is stored compressed it will be sent compressed, but no active on-the-fly compression will be performed.

Hi @graham.pople

Thanks for responding.

I’ve tried to find the bucket’s compression mode setting - but haven’t been able to find it. The docs I found (SDK) seemed to be related to the Enterprise version. I’m using the Community Edition…

/John

Indeed, compression is available only in Enterprise Edition, where you can set levels. That makes this case all that more confusing. What should happen is the client (whether Java SDK or Sync Gateway) tries to negotiate snappy compression, the cluster will indicate it’s not supported, and the client won’t compress it.

The server also won’t compress it actively and it should not send any responses to the client indicating it is compressed.

So, what’s confusing here is how the client is receiving, occasionally, items that it says are compressed.

I believe you’re adding these images via Sync Gateway, correct? Sync Gateway does have the ability to manipulate metadata like the compressed bit directly. Perhaps there is something happening where that bit is being set and because you’re on community edition and compression cannot be negotiated, it just stores that way passing it on to other clients. @adamf or @borrrden, any thoughts on this possibility?

The only other though I have @jda, if it’s a transient issue, is that you turn the log level up to debug in a test environment where you can catch it. We could try with the log level at debug for the com.couchbase.client.core.endpoint.kv.KeyValueHandler package first.

Ok, interesting @ingenthr

I just tested that I had not by error downloaded and installed the Enterprise Edition of SG. But it seems Ok:

{
    "couchdb": "Welcome",
    "vendor": {
        "name": "Couchbase Sync Gateway",
        "version": "2.6"
    },
    "version": "Couchbase Sync Gateway/2.6.0(127;b4c828d) CE"
}

The way I handle the images (driven by the somewhat inconsistent handling of attachments in the server side SDK and CBL) is that I Base64Encode the image and put it in the document as pure text. And then on retrieval I decode it prior to showing the image. So I’m just saving the images as “normal” documents directly in the database (so not via Sync.Gateway).

I have initially synced the images to CBL - but I have changed that to only load the images on request directly via a call to a service on the server - simply to avoid the large data volume. So you may be able to see “signs” of this in the image document.

… and another thing @ingenthr

The consistent example above does not include an image. So I guess that indicates another problem - and thus the “Snappy” errors could just be symptoms of the real problem??

@ingenthr, I did some more investigation…

First I started my local dev server as my demo site (the one we are looking at here) is non-functional at the moment. The dev server is basically one local VM with my application server and a database server and sync.gateway server.

And to my big surprise it reported the same problems!!! I have hardly used this environment for the last two months so I shouldn’t have been able to break the data myself :slight_smile:

What has happened is that I have installed the latest JVM SDK before applying it to the other environments (to proof it didn’t break anything - and then deploy to the demo environment - and finally to the prod. environment).

Same goes for the sync. gateway, i.e. update the software to 2.6.0 in dev prior to the demo environment. The sync.gateway is not yet installed in the production environment as only the server side of the new version has been put into production (app not ready yet). So a potential cause could be version 2.6.0?

The only other thing I can think of is that I have code to generate indexes on the server. As it is a Community Edition I create say indexA via code. If there are more servers in the cluster (e.g. demo and prod) I create the indexes as indexA_1 and indexA_2 on their separate servers. This works fine…

Seeing that sync.gateway creates it’s own indexes, e.g. sg_access_x1, I decided to do the same for these indexes naming them sg_access_x (if one node) or sg_access_x_1 and sg_access_x_2 if there are two nodes. This way I would have a “complete” environment if one database node is down. However, sync.gateway checks on the names - so it just creates its “own” indexes again if they do not exist. So seeing this I have deleted these extra indexes again.

… just trying to sum up what changes I can identify since it worked.

@ingenthr, @borrrden, @graham.pople

I’ve found something!

Looking back at the release notes of the Java SDK I found that the Snappy aware code was introduced in 2.6.0. So I tried to install version 2.5.7 in my dev. environment - and now it works without failing!

AND it is in combination with Sync.Gateway 2.6.0 installed as I’m still running 2.7.9 in my prod. environment and don’t have the problem. But I think it is safest to downgrade that to 2.5.7 as well…

@jda

That would make sense, as the pre-Snappy SDK would not negotiate snappy support with the server during the initial HELLO, and so no documents will be sent with the snappy flag.

But as @ingenthr says above, a CE server should not offer snappy for negotiation anyway, regardless of the SDK version…

I think there’s enough evidence of something squiffy going on for someone (probably me) to try to replicate this here. I’ll try to find some time for it. In the mean-time, are you ok with the workaround for now of using a pre-2.6.0 client?

1 Like

Yep, as long as it works Ok - and doesn’t disturb the prod. environment then that is Ok.

Please note that the issue did not start immediately after updating SG and SDK - as I actually tested it prior to updating the next environment :slight_smile:

It works okay, yes. It may be possible to disable this negotiation at the 2.7 client (@graham.pople may know off the top of his head), but IIRC we just use the size tuneables.

If the environment or logs are still handy, it’d be useful to get the INFO level logging from the client after initial bootstrap. That may indicate what the server is saying in response to the client trying to negotiate compression. Even better, it’d be interesting to know if you still see this with the 6.5 Beta.

Also, even though it’s a bit early, I filed MB-36299 to track this and request the team see if there’s a likelihood the bit can be incorrectly set.

It may be possible to disable this negotiation at the 2.7 client

Ah, good thought. Yes this can be controlled with this system property:

System.getProperty(“com.couchbase.snappyEnabled”, “true”)

Please attach the cbcollect_info logs to the bug report

To the MB-36299?

To the MB-36299?

Ok, so just to try and get the overview here.

I have downgraded all my environments to use the Java SDK 2.5.7 - and it’s stable again.

I’ll be happy to take my dev. environment and reinstall the SDK 2.7.9 and provide you with the information that you need. However, I need a little help on exactly how to enable those settings and where to find the relevant output for you?

And are there any logs you want me to clear in advance to isolate the relevant info then please let me know as well.

I’m still a little new to Couchbase - but learning… :slight_smile:

Hi @jda
Thanks for your patience while we investigated this. The issue was tracked down to MB-34879, please see that ticket for details and resolution. Thank you for raising this and for your detailed bug report.

1 Like

Hi @graham.pople

Thanks for getting back to me on this. I don’t have access to the link you posted. Could you give the broader lines here?