Open cfloisand opened 4 years ago
snej
commented
4 years ago Unfortunately those logs aren't useful — they're just very low-level info about bytes being transferred over the socket. If you turn on "Sync" logging (sorry, I'm not familiar with the details of the Android API) you'll get more useful information.
Also, please post lengthy logs as a link to a gist, otherwise issues become very difficult to read through. Thanks!
cfloisand
commented
4 years ago Thanks for the tips, @snej . I have reproduced the issue capturing verbose logging. Here is the full output.
One thing that sticks out to me is that the web socket connection is getting closed with the message "Connection reset by peer." This is followed by closing both the SQLite and CB databases before opening it again. Is this normal?
bmeike
commented
4 years ago Tracked in https://issues.couchbase.com/browse/CBL-608
bmeike
commented
4 years ago We've just addressed an issue that seems related to this one: https://issues.couchbase.com/browse/CBL-623. If you have time to build and try from master, we'd be interested to know if you can still reproduce this.
cfloisand
commented
4 years ago Great. I don't have time immediately to build from master and verify, I'm afraid, but let me see what kind of time I have in a week or two.
Thanks.
cfloisand
commented
4 years ago We've just addressed an issue that seems related to this one: https://issues.couchbase.com/browse/CBL-623. If you have time to build and try from master, we'd be interested to know if you can still reproduce this.
I managed to find some time to do this, but unfortunately the issue persists. I pulled down the repo, built it from master, and imported the new 2.7.0 AAR into our project, and I was able to reproduce the issue.
Here is the verbose log for this new build. As before, the Blob file itself is not found as seen at the end of the log.
bmeike
commented
4 years ago Tracking in https://issues.couchbase.com/browse/CBL-904
bmeike
commented
4 years ago I've made no progress on this. I haven't ever seen it and we do not have reports about similar issues from other customers. I will leave it open but, without more information, it is going to be very difficult to move forward.
marknelissen
commented
4 years ago We might have a related issue, although not much info to contribute at this point, since we can't reproduce it ourselves, only our clients can. So we don't have access to device logs, only sync gateway logs.
Until recently, we used the couchbase lite android 2.0 version. Sometimes, the images that were transmitted were only partial, meaning only e.g. the top half of the image was visible on the sync gateway. However, when the same image was read from the database on the local device that added it, then the content was complete. The only fix was to reattach the image to the document and resync to get the full image.
Now that we upgraded to the 2.7.1 version of the android library, we are starting to see documents with attached images that are not transmitted at all. The same fix as previous allows for the document to be uploaded.
During the sync, we see these kinds of errors of the sync gateway logs (not sure if this is truly related, since we also have other traffic during the sync):
Error during downloadOrVerifyAttachments for doc dd9e1a02-46ab-48e4-a618-b9343bb369ad/1-aeb3ad011bf386cda5b1425a276846ba268b6f73: 400 Incorrect data sent for attachment with digest: sha1-EXNYlOQTTeouQ/Fud6xQ+wnu8h4= -- rest.(*blipSyncContext).Logf() at blip_sync.go:262
SyncMsg: c:[61450caf] #32: Type:rev --> 400 Incorrect data sent for attachment with digest: sha1-EXNYlOQTTeouQ/Fud6xQ+wnu8h4= Time:5.058535828sWe are running the latest sync gateway version, 2.7.3.
bmeike
commented
4 years ago @marknelissen Are you using Crashlytics? Any chance you can get the logcat from around the time of the problem?
marknelissen
commented
4 years ago We do use Bugsnag, but unfortunately, there is no crash, so nothing is transmitted, and even then, it does not contain the logcat logs.
We don't have physical access to the device, and the client doesn't have the knowledge or means to retrieve it.
Do you know of a tool to remotely retrieve the logcat? Do know that we are using React Native, this might complexify things.
bmeike
commented
4 years ago Retrieving logs from a customer device is hard. That's why Crashlytics is now Google... ;-P
I'm surprised that you aren't getting an exception in the app, when the error occurs. That's interesting.
The more info you can provide, the better chance I have of chasing this down: Android versions, hardware, anything you have that might be significant. There's just so little to go on, at this point.
Hello,
I have been experiencing an intermittent issue with Blobs in the past few days. We have recently upgraded to Couchbase 2.6.2 in one of our Android products from Couchbase 1.4, and occasionally when a new document with a Blob (Attachment) is added to the database, the following exception is thrown by Couchbase.
I have a PUSH_AND_PULL replicator with a document listener on it to monitor document replications in continuous mode. When the document with the Blob is added from another device, Couchbase begins pulling down the data on this device that I'm seeing the error on, but the
replication(DocumentReplication)callback is not called for it once the data pull has finished. When the pull of a document containing a Blob is successful, thereplicationcallback is always called.When I then navigate to the page containing this image attachment (Blob), Couchbase returns the document (so the actual document does exist in the local database on the device), but when
getContent()is called on the Blob object, the exception seen above is thrown. Furthermore, the Blob returns a non-zero size and the correct MIME type. The image I'm testing with is only ~7 MB. As I mentioned, this is an intermittent issue, so the problem is not specific to this or any other image, because they work about 70% of the time or so.Here are the logs printed out while Couchbase is pulling the data:
In addition to the above exception, the following error appears in the log
WebSocketListener.onFailure() response -> null: java.io.EOFException. I don't know if this is related or a possible cause or not.Finally, when checking the list of Attachments in the .cblite2 directory, the .blob file that it's looking for is not there. Somehow it looks like the database is getting into a state where the document with the Blob exists in the database, but the actual Blob itself does not get created in the Attachments directory of the .cblite2 database.
Please let me know if I can provide any other info on this issue.