As far as I know, we don't have any load balancing enabled in this configuration.
-- Eric On Friday, April 3, 2015 at 5:58:44 PM UTC-4, Zachary Gramana wrote: > > 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/51d7c809-0b0d-47ca-a953-171cc4d0f4d4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
