Normal and Longpoll

[Yaron Goland]

Right now the Java mobile code when set in continuous mode on a pull request will have the change tracker first make a request to _changes with feed=normal and then will make subsequent requests with feed=longpoll.

As part of a PR I want to submit I changed this behavior so that continuous requests will always start off with feed=longpoll.

Is there an actual need to start with normal and then switch to longpoll or is it safe to just start with longpoll?

Comments?

        Thanks,

                Yaron

[Jens Alfke]

> On Sep 23, 2014, at 3:01 PM, Yaron Goland <yar...@microsoft.com> wrote:
>
> Is there an actual need to start with normal and then switch to longpoll

Yes; otherwise if there are no new changes, you don't find out that fact — the longpoll just gets no response at all until an indefinite amount of time later when a change does occur. That prevents the replicator from changing its state to 'idle'.

—Jens

[Yaron Goland]

So just to be clear I believe you are saying that:

Time 0 - User issues _changes with feed = normal and since = 0 and gets back a changes feed with sequence ID 1.
Time 1 - A different user sneaks in, makes a change on the server and now sequence ID is 2.
Time 2 - The user issues a _changes request with feed = longpoll and since = 1

If I understand what you are saying below the server will not in fact immediately return the changes since ID 1? It will wait until ID = 3 and only then return something?

________________________________________
From: mobile-c...@googlegroups.com <mobile-c...@googlegroups.com> on behalf of Jens Alfke <je...@couchbase.com>
Sent: Tuesday, September 23, 2014 3:06 PM
To: mobile-c...@googlegroups.com
Cc: Traun Leyden
Subject: Re: Normal and Longpoll

> On Sep 23, 2014, at 3:01 PM, Yaron Goland <yar...@microsoft.com> wrote:
>
> Is there an actual need to start with normal and then switch to longpoll

Yes; otherwise if there are no new changes, you don't find out that fact -- the longpoll just gets no response at all until an indefinite amount of time later when a change does occur. That prevents the replicator from changing its state to 'idle'.

--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 mobile-couchba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/505B621C-CC30-457E-BE40-8262B5C3F852%40couchbase.com.
For more options, visit https://groups.google.com/d/optout.

[Jens Alfke]

No; the scenario I mean is much more common. It looks like:

- Pull replicator starts up, sets state=active
- Client sends a _changes request with since=12345 (i.e. the last sequence it got from the server) and feed=longpoll
- Server has no changes since 12345, so it doesn't send any response
- Nothing happens on the client side, so state remains active
- Replicator sits idle for an indefinite time with the state still 'active', which is wrong.

By changing the feed to 'normal' for the first request, the response comes back immediately. If it's empty, the replicator knows it's already caught up and can quickly change its state to idle.

—Jens

[Yaron Goland]

Makes sense. We could fix this by just flipping to idle as soon as we get back the response header from the server if there is no immediate body but one thing at a time. I'll put back in the 'normal' then 'longpoll' logic and submit the PR.

Thanks,

Yaron

________________________________________
From: mobile-c...@googlegroups.com <mobile-c...@googlegroups.com> on behalf of Jens Alfke <je...@couchbase.com>

Sent: Tuesday, September 23, 2014 3:20 PM

To: mobile-c...@googlegroups.com
Cc: Traun Leyden
Subject: Re: Normal and Longpoll

No; the scenario I mean is much more common. It looks like:

--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 mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/7C6849C0-4BAF-4A9D-83A2-600B89111BC3%40couchbase.com.

[Jens Alfke]

On Sep 23, 2014, at 3:25 PM, Yaron Goland <yar...@microsoft.com> wrote:

Makes sense. We could fix this by just flipping to idle as soon as we get back the response header from the server if there is no immediate body but one thing at a time.

No, it doesn't make sense to switch to idle as soon as you get the response header, because you still don't know if you're caught up or not. You might be about to receive a response with changes in it, as soon as the next TCP packet arrives.

I assume you're worried about the performance of sending the extra request. If so, you'd be better off implementing WebSocket support on the server side, since it's more efficient (comparable to the continuous feed.)

—Jens

[Yaron Goland]

Hum... now I'm confused.

Let's imagine that the code was written as:

1. Make a longpoll request

2. If within 1 second of receiving the response header no body has been sent down then call client.changeTrackerCaughtUp

3. Keep waiting on longpoll

4. When something does come in then call changeTrackerReceivedChange

What's the harm?

And while there is a perf component to my interest my real concern is making sure I actually understand the code.

    Thanks,

            Yaron

---

From: mobile-c...@googlegroups.com <mobile-c...@googlegroups.com> on behalf of Jens Alfke <je...@couchbase.com>

Sent: Tuesday, September 23, 2014 3:40 PM

To: mobile-c...@googlegroups.com
Cc: Traun Leyden
Subject: Re: Normal and Longpoll

--
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 mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/27D8A07C-6565-49CC-A31D-2B5DD82842A6%40couchbase.com.

[Jens Alfke]

> On Sep 23, 2014, at 4:02 PM, Yaron Goland <yar...@microsoft.com> wrote:
>
> What's the harm?

It seems like added complexity (including the timer) for no significant gain.
Plus, the replicator code is complex enough that I don't change anything in it lightly.

—Jens

[Yaron Goland]

It's funny because the reason I wanted to do this was to make the code simpler because it meant that the mode argument would become 'final'.

But thanks for answering, I just wanted to check that I understand how Change Tracker is doing it's thing. Please note that the PR I submitted (https://github.com/couchbase/couchbase-lite-java-core/pull/284) works exactly along the lines you described. All I changed was cleaning up the arguments and making the code itself thread safe.

Yaron
________________________________________

From: mobile-c...@googlegroups.com <mobile-c...@googlegroups.com> on behalf of Jens Alfke <je...@couchbase.com>

Sent: Tuesday, September 23, 2014 10:03 PM

To: mobile-c...@googlegroups.com
Cc: Traun Leyden
Subject: Re: Normal and Longpoll

> On Sep 23, 2014, at 4:02 PM, Yaron Goland <yar...@microsoft.com> wrote:
>
> What's the harm?

--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 mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/75B405A4-3A11-45C7-B60B-5985FD0A62ED%40couchbase.com.