Seeing an odd issue with Sync Gateway 1.2.1. Let’s say I have two clients listening to the changes feed (continuous), where client A is on the admin port (4985) and client B is on the public port authenticated with a session ID. Another client C updates three different documents in a row within milliseconds of each other, only one document of which has a channel set for which client B is subscribed (that is, client B should only get the change line for one of the three documents). The issue is that while client A (on the admin port) always gets all three document changes, client B only sometimes gets the single change that the channeled doc changed. Other times it gets nothing at all until some other, later change comes along, whatever it might be, at which point the Sync Gateway puts out the change lines for both the new doc that was changed (that gave it a “kick”) and the original doc that was missed earlier.
What pieces of information would be the most useful to help debug this issue? Any immediate thoughts? Thank you!
Sorry for the delay. I wish I could provide reproducible steps, but for now I was able to extract the relevant parts of the logs. Please find attached (3.4 KB) two cases for comparison, where the public port user only has access to the doc ending in “bmt_from_server” (channel assignment of entity_demo). In the “BatchChangesResultingInFeedUpdate.txt” log note that the document corresponding to sequence #4091 gets sent to both * (admin) and entity_demo (user) channel subscriptions, whilst in the “BatchChangesResultingInFeedFailure.txt” log the document corresponding to sequence #4081 only gets sent to the * (admin) channel subscription. Specifically, note in the former:
12:45:55.036073 2016-11-02T12:45:55.036-04:00 Changes+: Sending seq:4091 from channel * ... 12:45:55.036073 2016-11-02T12:45:55.036-04:00 Changes+: Sending seq:4091 from channel entity_demo
But in the latter:
12:37:49.032073 2016-11-02T12:37:49.032-04:00 Changes+: Sending seq:4081 from channel *
Also curious is that it notices the appropriate channel assignments in the doc in both instances:
The only appreciable difference I was able to observe is that in the cases when the changes feed was properly updated to the feed on the public port, the cache received a duplicate:
12:45:55.036073 2016-11-02T12:45:55.036-04:00 Cache: Received #4091 after 1844ms ("demo_ac86a003-7f24-403e-9406-afcc8a03bc30_bmt_from_server" / "94-462bd0b1b553b8e315f82c73ccd066a2") 12:45:55.036073 2016-11-02T12:45:55.036-04:00 Cache+: Ignoring duplicate of #4091
Please let me know what additional information I might be able to provide.
Also, completely anecdotally, it seems as though the following configuration for the database seems to help: "cache": { "enable_star_channel": false },
Can you upload the relevant log excerpts to a gist? I’m not able to access the versions uploaded to this thread.
Based on the snippets you embedded in your post, it looks like the document is being added to the appropriate channel caches in both cases (the Cache: #… ==>) logging.
The missing entry (Changes+: Sending seq:4091 from channel entity_demo) is just another symptom of the problem (the document isn’t being sent to the user), and not the underlying cause.