Thanks for the follow-up. BTW, which ARR load balancing algorithm are you using?
On Friday, April 3, 2015 at 5:02:55 AM UTC-7, Eric Levine wrote: > > We may have found the fix, which was to set the Application Request > Routing's "Response buffer threshold" to 0. It was set to something like > 256KB by default, and our theory is that IIS was waiting for that buffer to > fill instead of sending the heartbeats to the client. Since we made the > change, everything appears to be working as expected. > > On Thursday, April 2, 2015 at 2:41:21 PM UTC-4, Eric Levine wrote: >> >> Jens, >> >> Thank you for bringing up the question about network topology, it helped >> us to narrow down the problem. We switched over to a direct Sync Gateway >> connection, and no longer observe this issue. The culprit is likely a >> setting in the IIS Application Request Routing module that is causing the >> issue. I'll post an update once that is figured out. >> >> -- >> Eric Levine >> >> On Thursday, April 2, 2015 at 1:23:34 PM UTC-4, Eric Levine wrote: >>> >>> We are creating a bunch of documents through the Sync Gateway's REST >>> API. If we wait more than 5 minutes, then create more documents through >>> the REST API, the changes aren't synced to the client. In the Sync Gateway >>> logs, we see the documents being created, and the client making the request >>> for the changes feed, but we do not see the follow up requests for the >>> client to retrieve the documents. >>> >>> Here is our setup: >>> >>> - The server is a physical machine in our office, and has pretty >>> good specs (at least quad core and 8GB memory). It is running Windows >>> Server 2012, IIS, Couchbase, and the Sync Gateway. IIS is acting as a >>> reverse proxy to the Sync Gateway, using URL rewrite rules. We are >>> running >>> the Sync Gateway as a Windows Service that was setup through NSSM >>> <https://nssm.cc/>, >>> - The client is connecting to our office WiFi >>> >>> I'll make a follow up post shortly with a more detailed log capture. >>> >>> -- >>> Eric Levine >>> >>> On Thursday, April 2, 2015 at 11:38:06 AM UTC-4, Jens Alfke wrote: >>>> >>>> >>>> On Apr 2, 2015, at 8:14 AM, Eric Levine <[email protected]> wrote: >>>> >>>> We are using the .Net version of CBL, and it stops receiving changes >>>> from the Sync Gateway if there is 5 minutes or more of inactivity. When I >>>> look at the Sync Gateway logs, I see that the Pull Replicator sets the >>>> heartbeat query parameter to 5 minutes when it requests the changes feed. >>>> The status of the pull replicator doesn't change from idle, and it >>>> doesn't >>>> fire a changed event at that time. >>>> >>>> >>>> Well, it wouldn’t fire any event if there’s inactivity. Are you talking >>>> about a situation where, *after* >5 minutes of inactivity, the gateway >>>> does have a change but the client doesn’t receive it? Can you describe the >>>> sequence of events (and what gets logged on either side) in more detail? >>>> >>>> Also, please describe the network topology between SG and CBL — in >>>> particular any proxies/gateways/load-balancers (especially ones from cloud >>>> services like AWS, which are known for terminating ‘idle’ sockets.) >>>> >>>> —Jens >>>> >>>> -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/29a3f6bf-80df-41e7-a2d5-d3ca8d35799b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
