You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Stephen Bartell <sn...@gmail.com> on 2013/04/14 06:53:45 UTC
Fwd: EventSource periodically dumps db contents.
I meant to post this in @dev...
Begin forwarded message:
> From: Stephen Bartell <sn...@gmail.com>
> Subject: EventSource periodically dumps db contents.
> Date: April 12, 2013 12:45:06 AM PDT
> To: "user@couchdb.apache.org" <us...@couchdb.apache.org>
>
> Hi all, I've been playing around with EventSource _changes and theres something that doesn't quite make sense.
>
> I'm doing all this from Chrome console on OSX localhost couch@1.3.
>
> 1)
> var connectionSource = new EventSource('/cdb/connection/_changes?feed=eventsource')
>
> 2)
> var connresults = []
>
> 3)
> var connListener = function (e) {
> connresults.push(JSON.parse(e.data))
> }
>
> 4)
> connectionSource.addEventListener('message', connListener, false)
>
> I make sure not to trigger any changes on connection database while I set up a second source.
> `connresults` is empty at this point. As I expect.
>
> 5)
> var endpointsSource = new EventSource('/cdb/endpoints/_changes?feed=eventsource')
>
> 6)
> var epresults = []
>
> 7)
> var epListener = function (e) {
> epresults.push(JSON.parse(e.data))
> }
>
> 8)
> endpointsSource.addEventListener('message', epListener, false)
>
> Heres the bug.
> No changes were triggered on __either__ database.
> `connresults` is loaded with _all_docs of connection database.
> `epresults` is loaded with the _all_docs of the endpoints database.
>
> And over time, these numbers multiply. For example, connections db really only 233 docs in it and endpoints database really only has 10 docs in it. But over the course of writing this email, `connresults` has 1872 things in it and `epresults` has 60 things in it.
>
> It seems like right after I add that second source, something crashes and both sources begin dumping periodically.
>
> Thanks,
> Stephen
Re: EventSource periodically dumps db contents.
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Apr 17, 2013 at 11:16 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> continuous mode isn't supported by all browsers.
^^ What Benoit said. To make it even clearer, it's that browsers don't
make it easy to stream results. You make an XHR request and you get a
full response. ES makes it easier for the application to get the
changes as they come in.
Re: EventSource periodically dumps db contents.
Posted by Robert Newson <rn...@apache.org>.
Hi Stephen,
feed=eventsource just changes the format of the continuous response,
nothing else changes. It might have been a clearer api to have chosen
feed=continuous&format=eventsource but that didn't happen. In code
terms, we run through the same places as feed=continuous.
B.
On 18 April 2013 07:16, Benoit Chesneau <bc...@gmail.com> wrote:
> continuous mode isn't supported by all browsers.
>
> - benoit
>
> On Thu, Apr 18, 2013 at 7:28 AM, Stephen Bartell <sn...@gmail.com> wrote:
>> Thanks for the summary Robert. That clears it all up :)
>>
>> Ok so now I'm going to risk looking like a tool. Besides the underlying mechanism, what is the difference between eventsource and continuous? In other words, what does ES bring to the table that continuous does not? I was originally excited about event source because for some reason i had it in my head that multiple event source subscriptions would use the same connection, thus circumventing the open connection limits on browsers.
>>
>> Best
>> Stephen
>>
>> On Apr 17, 2013, at 4:31 AM, Robert Newson <rn...@apache.org> wrote:
>>
>>> Setting timeout and heartbeat to the same value is going to lead to
>>> exactly what you're seeing.
>>>
>>> The timeout setting is how long, without an event, the connection will
>>> stay open.
>>>
>>> The heartbeat setting is how long to wait, without an event, before
>>> sending a newline character to keep the connection from timing out.
>>>
>>> What you're seeing is that the timeout happens before the heartbeat,
>>> since both are happening approximately simultaneously.
>>>
>>> Just set heartbeat=5000 and rely on the timeout default of 1 minute,
>>> or specify timeout to whatever multiple of heartbeat you find useful
>>> (as long as it's more than one).
>>>
>>> Summary: timeout == heartbeat is not going to keep the connection alive.
>>>
>>> B.
>>>
>>>
>>>
>>>
>>>
>>> On 17 April 2013 10:29, Stephen Bartell <sn...@gmail.com> wrote:
>>>> Ok heres a test script. Have a couch serving localhost:5984 in admin party mode.
>>>>
>>>> git clone https://github.com/snbartell/couch-es-test.git
>>>> cd couch-es-test
>>>> npm install
>>>> node index.js
>>>>
>>>> My theory of a second source crashing couch was wrong.
>>>>
>>>> I think I know whats going on. My script above acts just like the browser does. When the `timeou`t is reached and `heartbeat` !== `timeout`, the EventSource module (whether its the browser or the node package) will restart the feed. This is why every `timeout` ms the feed __appears__ to by dumping all the docs since `since`.
>>>>
>>>> curling works fine. Try this after running the above script and leaving the test db in place. I expect this behavior.
>>>> curl "http://localhost:5984/source1/_changes?since=2&feed=continuous&timeout=5000&heartbeat=5000"
>>>>
>>>> So then it comes to using this in Chrome console. If you go to the couch you ran the script against, open the console, and paste the following:
>>>> var source1 = new EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
>>>>
>>>> Watch the Network panel. It looks like EventSource does not pass the query params. I'm probably being an idiot and not calling it correctly. I googled around and couldn't find the api. Does someone have a link?
>>>>
>>>> Still though, if I call EventSource without `timeout` and `heartbeat`, then couchdb will use the defaults of 60000 each. Then, with `timeout` === `heartbeat`, the connection should be kept alive, right?
>>>>
>>>> Thanks guys,
>>>>
>>>> Stephen
>>>>
>>>>
>>>> On Apr 16, 2013, at 11:17 PM, Stephen Bartell <sn...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>>
>>>>>> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>>>>>>
>>>>>>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>>>>>>
>>>>>>
>>>>>> Hi Stephen,
>>>>>>
>>>>>> Can you provide a clear way to reproduce what you're doing and the
>>>>>> result you're expecting. It's not clear for me right now if you :
>>>>>
>>>>> Yep, Im actually working on it now :)
>>>>>
>>>>>>
>>>>>> 1. the reauest results when giving the since parameter without any
>>>>>> changes , did you try using curl?
>>>>> no. I only did it from the browser console.
>>>>>
>>>>>> 2. If it's a javascript error
>>>>> nope. its a couch thing.
>>>>>
>>>>>> 3. ?
>>>>>>
>>>>>> - benoit
>>>>>
>>>>
>>
Re: EventSource periodically dumps db contents.
Posted by Benoit Chesneau <bc...@gmail.com>.
continuous mode isn't supported by all browsers.
- benoit
On Thu, Apr 18, 2013 at 7:28 AM, Stephen Bartell <sn...@gmail.com> wrote:
> Thanks for the summary Robert. That clears it all up :)
>
> Ok so now I'm going to risk looking like a tool. Besides the underlying mechanism, what is the difference between eventsource and continuous? In other words, what does ES bring to the table that continuous does not? I was originally excited about event source because for some reason i had it in my head that multiple event source subscriptions would use the same connection, thus circumventing the open connection limits on browsers.
>
> Best
> Stephen
>
> On Apr 17, 2013, at 4:31 AM, Robert Newson <rn...@apache.org> wrote:
>
>> Setting timeout and heartbeat to the same value is going to lead to
>> exactly what you're seeing.
>>
>> The timeout setting is how long, without an event, the connection will
>> stay open.
>>
>> The heartbeat setting is how long to wait, without an event, before
>> sending a newline character to keep the connection from timing out.
>>
>> What you're seeing is that the timeout happens before the heartbeat,
>> since both are happening approximately simultaneously.
>>
>> Just set heartbeat=5000 and rely on the timeout default of 1 minute,
>> or specify timeout to whatever multiple of heartbeat you find useful
>> (as long as it's more than one).
>>
>> Summary: timeout == heartbeat is not going to keep the connection alive.
>>
>> B.
>>
>>
>>
>>
>>
>> On 17 April 2013 10:29, Stephen Bartell <sn...@gmail.com> wrote:
>>> Ok heres a test script. Have a couch serving localhost:5984 in admin party mode.
>>>
>>> git clone https://github.com/snbartell/couch-es-test.git
>>> cd couch-es-test
>>> npm install
>>> node index.js
>>>
>>> My theory of a second source crashing couch was wrong.
>>>
>>> I think I know whats going on. My script above acts just like the browser does. When the `timeou`t is reached and `heartbeat` !== `timeout`, the EventSource module (whether its the browser or the node package) will restart the feed. This is why every `timeout` ms the feed __appears__ to by dumping all the docs since `since`.
>>>
>>> curling works fine. Try this after running the above script and leaving the test db in place. I expect this behavior.
>>> curl "http://localhost:5984/source1/_changes?since=2&feed=continuous&timeout=5000&heartbeat=5000"
>>>
>>> So then it comes to using this in Chrome console. If you go to the couch you ran the script against, open the console, and paste the following:
>>> var source1 = new EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
>>>
>>> Watch the Network panel. It looks like EventSource does not pass the query params. I'm probably being an idiot and not calling it correctly. I googled around and couldn't find the api. Does someone have a link?
>>>
>>> Still though, if I call EventSource without `timeout` and `heartbeat`, then couchdb will use the defaults of 60000 each. Then, with `timeout` === `heartbeat`, the connection should be kept alive, right?
>>>
>>> Thanks guys,
>>>
>>> Stephen
>>>
>>>
>>> On Apr 16, 2013, at 11:17 PM, Stephen Bartell <sn...@gmail.com> wrote:
>>>
>>>>
>>>> On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>>
>>>>> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>>>>>
>>>>>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>>>>>
>>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> Can you provide a clear way to reproduce what you're doing and the
>>>>> result you're expecting. It's not clear for me right now if you :
>>>>
>>>> Yep, Im actually working on it now :)
>>>>
>>>>>
>>>>> 1. the reauest results when giving the since parameter without any
>>>>> changes , did you try using curl?
>>>> no. I only did it from the browser console.
>>>>
>>>>> 2. If it's a javascript error
>>>> nope. its a couch thing.
>>>>
>>>>> 3. ?
>>>>>
>>>>> - benoit
>>>>
>>>
>
Re: EventSource periodically dumps db contents.
Posted by Stephen Bartell <sn...@gmail.com>.
Thanks for the summary Robert. That clears it all up :)
Ok so now I'm going to risk looking like a tool. Besides the underlying mechanism, what is the difference between eventsource and continuous? In other words, what does ES bring to the table that continuous does not? I was originally excited about event source because for some reason i had it in my head that multiple event source subscriptions would use the same connection, thus circumventing the open connection limits on browsers.
Best
Stephen
On Apr 17, 2013, at 4:31 AM, Robert Newson <rn...@apache.org> wrote:
> Setting timeout and heartbeat to the same value is going to lead to
> exactly what you're seeing.
>
> The timeout setting is how long, without an event, the connection will
> stay open.
>
> The heartbeat setting is how long to wait, without an event, before
> sending a newline character to keep the connection from timing out.
>
> What you're seeing is that the timeout happens before the heartbeat,
> since both are happening approximately simultaneously.
>
> Just set heartbeat=5000 and rely on the timeout default of 1 minute,
> or specify timeout to whatever multiple of heartbeat you find useful
> (as long as it's more than one).
>
> Summary: timeout == heartbeat is not going to keep the connection alive.
>
> B.
>
>
>
>
>
> On 17 April 2013 10:29, Stephen Bartell <sn...@gmail.com> wrote:
>> Ok heres a test script. Have a couch serving localhost:5984 in admin party mode.
>>
>> git clone https://github.com/snbartell/couch-es-test.git
>> cd couch-es-test
>> npm install
>> node index.js
>>
>> My theory of a second source crashing couch was wrong.
>>
>> I think I know whats going on. My script above acts just like the browser does. When the `timeou`t is reached and `heartbeat` !== `timeout`, the EventSource module (whether its the browser or the node package) will restart the feed. This is why every `timeout` ms the feed __appears__ to by dumping all the docs since `since`.
>>
>> curling works fine. Try this after running the above script and leaving the test db in place. I expect this behavior.
>> curl "http://localhost:5984/source1/_changes?since=2&feed=continuous&timeout=5000&heartbeat=5000"
>>
>> So then it comes to using this in Chrome console. If you go to the couch you ran the script against, open the console, and paste the following:
>> var source1 = new EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
>>
>> Watch the Network panel. It looks like EventSource does not pass the query params. I'm probably being an idiot and not calling it correctly. I googled around and couldn't find the api. Does someone have a link?
>>
>> Still though, if I call EventSource without `timeout` and `heartbeat`, then couchdb will use the defaults of 60000 each. Then, with `timeout` === `heartbeat`, the connection should be kept alive, right?
>>
>> Thanks guys,
>>
>> Stephen
>>
>>
>> On Apr 16, 2013, at 11:17 PM, Stephen Bartell <sn...@gmail.com> wrote:
>>
>>>
>>> On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>>
>>>> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>>>>
>>>>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>>>>
>>>>
>>>> Hi Stephen,
>>>>
>>>> Can you provide a clear way to reproduce what you're doing and the
>>>> result you're expecting. It's not clear for me right now if you :
>>>
>>> Yep, Im actually working on it now :)
>>>
>>>>
>>>> 1. the reauest results when giving the since parameter without any
>>>> changes , did you try using curl?
>>> no. I only did it from the browser console.
>>>
>>>> 2. If it's a javascript error
>>> nope. its a couch thing.
>>>
>>>> 3. ?
>>>>
>>>> - benoit
>>>
>>
Re: EventSource periodically dumps db contents.
Posted by Robert Newson <rn...@apache.org>.
Setting timeout and heartbeat to the same value is going to lead to
exactly what you're seeing.
The timeout setting is how long, without an event, the connection will
stay open.
The heartbeat setting is how long to wait, without an event, before
sending a newline character to keep the connection from timing out.
What you're seeing is that the timeout happens before the heartbeat,
since both are happening approximately simultaneously.
Just set heartbeat=5000 and rely on the timeout default of 1 minute,
or specify timeout to whatever multiple of heartbeat you find useful
(as long as it's more than one).
Summary: timeout == heartbeat is not going to keep the connection alive.
B.
On 17 April 2013 10:29, Stephen Bartell <sn...@gmail.com> wrote:
> Ok heres a test script. Have a couch serving localhost:5984 in admin party mode.
>
> git clone https://github.com/snbartell/couch-es-test.git
> cd couch-es-test
> npm install
> node index.js
>
> My theory of a second source crashing couch was wrong.
>
> I think I know whats going on. My script above acts just like the browser does. When the `timeou`t is reached and `heartbeat` !== `timeout`, the EventSource module (whether its the browser or the node package) will restart the feed. This is why every `timeout` ms the feed __appears__ to by dumping all the docs since `since`.
>
> curling works fine. Try this after running the above script and leaving the test db in place. I expect this behavior.
> curl "http://localhost:5984/source1/_changes?since=2&feed=continuous&timeout=5000&heartbeat=5000"
>
> So then it comes to using this in Chrome console. If you go to the couch you ran the script against, open the console, and paste the following:
> var source1 = new EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
>
> Watch the Network panel. It looks like EventSource does not pass the query params. I'm probably being an idiot and not calling it correctly. I googled around and couldn't find the api. Does someone have a link?
>
> Still though, if I call EventSource without `timeout` and `heartbeat`, then couchdb will use the defaults of 60000 each. Then, with `timeout` === `heartbeat`, the connection should be kept alive, right?
>
> Thanks guys,
>
> Stephen
>
>
> On Apr 16, 2013, at 11:17 PM, Stephen Bartell <sn...@gmail.com> wrote:
>
>>
>> On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>>>
>>>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>>>
>>>
>>> Hi Stephen,
>>>
>>> Can you provide a clear way to reproduce what you're doing and the
>>> result you're expecting. It's not clear for me right now if you :
>>
>> Yep, Im actually working on it now :)
>>
>>>
>>> 1. the reauest results when giving the since parameter without any
>>> changes , did you try using curl?
>> no. I only did it from the browser console.
>>
>>> 2. If it's a javascript error
>> nope. its a couch thing.
>>
>>> 3. ?
>>>
>>> - benoit
>>
>
Re: EventSource periodically dumps db contents.
Posted by Stephen Bartell <sn...@gmail.com>.
Ok heres a test script. Have a couch serving localhost:5984 in admin party mode.
git clone https://github.com/snbartell/couch-es-test.git
cd couch-es-test
npm install
node index.js
My theory of a second source crashing couch was wrong.
I think I know whats going on. My script above acts just like the browser does. When the `timeou`t is reached and `heartbeat` !== `timeout`, the EventSource module (whether its the browser or the node package) will restart the feed. This is why every `timeout` ms the feed __appears__ to by dumping all the docs since `since`.
curling works fine. Try this after running the above script and leaving the test db in place. I expect this behavior.
curl "http://localhost:5984/source1/_changes?since=2&feed=continuous&timeout=5000&heartbeat=5000"
So then it comes to using this in Chrome console. If you go to the couch you ran the script against, open the console, and paste the following:
var source1 = new EventSource('/source1/_changes?feed=eventsource&timeout=5000&heartbeat=5000')
Watch the Network panel. It looks like EventSource does not pass the query params. I'm probably being an idiot and not calling it correctly. I googled around and couldn't find the api. Does someone have a link?
Still though, if I call EventSource without `timeout` and `heartbeat`, then couchdb will use the defaults of 60000 each. Then, with `timeout` === `heartbeat`, the connection should be kept alive, right?
Thanks guys,
Stephen
On Apr 16, 2013, at 11:17 PM, Stephen Bartell <sn...@gmail.com> wrote:
>
> On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>>
>>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>>
>>
>> Hi Stephen,
>>
>> Can you provide a clear way to reproduce what you're doing and the
>> result you're expecting. It's not clear for me right now if you :
>
> Yep, Im actually working on it now :)
>
>>
>> 1. the reauest results when giving the since parameter without any
>> changes , did you try using curl?
> no. I only did it from the browser console.
>
>> 2. If it's a javascript error
> nope. its a couch thing.
>
>> 3. ?
>>
>> - benoit
>
Re: EventSource periodically dumps db contents.
Posted by Stephen Bartell <sn...@gmail.com>.
On Apr 16, 2013, at 11:13 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>>
>> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>>
>
> Hi Stephen,
>
> Can you provide a clear way to reproduce what you're doing and the
> result you're expecting. It's not clear for me right now if you :
Yep, Im actually working on it now :)
>
> 1. the reauest results when giving the since parameter without any
> changes , did you try using curl?
no. I only did it from the browser console.
> 2. If it's a javascript error
nope. its a couch thing.
> 3. ?
>
> - benoit
Re: EventSource periodically dumps db contents.
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Apr 17, 2013 at 7:55 AM, Stephen Bartell <sn...@gmail.com> wrote:
>
> But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
>
Hi Stephen,
Can you provide a clear way to reproduce what you're doing and the
result you're expecting. It's not clear for me right now if you :
1. the reauest results when giving the since parameter without any
changes , did you try using curl?
2. If it's a javascript error
3. ?
- benoit
Re: EventSource periodically dumps db contents.
Posted by Stephen Bartell <sn...@gmail.com>.
On Apr 14, 2013, at 7:18 AM, Robert Newson <rn...@apache.org> wrote:
> Hi Stephen,
>
> Are you passing a since=N parameter when you reconnect to the changes
> feed? The feed=eventsource is, I think, only changing the format of
> our changes feed to suit the EventSource spec, it doesn't change the
> fundamentals.
I'll do some specific tests for all cases.
But for what I was doing, no, I wasn't specifying since. I would expect the fundamentals to be the same as well. What I was see is that even without `since` given, no changes would come through until that second source was added. Once the second source is added, then all sources periodically dump.
> B.
>
> On 14 April 2013 00:53, Stephen Bartell <sn...@gmail.com> wrote:
>> I meant to post this in @dev...
>>
>> Begin forwarded message:
>>
>>> From: Stephen Bartell <sn...@gmail.com>
>>> Subject: EventSource periodically dumps db contents.
>>> Date: April 12, 2013 12:45:06 AM PDT
>>> To: "user@couchdb.apache.org" <us...@couchdb.apache.org>
>>>
>>> Hi all, I've been playing around with EventSource _changes and theres something that doesn't quite make sense.
>>>
>>> I'm doing all this from Chrome console on OSX localhost couch@1.3.
>>>
>>> 1)
>>> var connectionSource = new EventSource('/cdb/connection/_changes?feed=eventsource')
>>>
>>> 2)
>>> var connresults = []
>>>
>>> 3)
>>> var connListener = function (e) {
>>> connresults.push(JSON.parse(e.data))
>>> }
>>>
>>> 4)
>>> connectionSource.addEventListener('message', connListener, false)
>>>
>>> I make sure not to trigger any changes on connection database while I set up a second source.
>>> `connresults` is empty at this point. As I expect.
>>>
>>> 5)
>>> var endpointsSource = new EventSource('/cdb/endpoints/_changes?feed=eventsource')
>>>
>>> 6)
>>> var epresults = []
>>>
>>> 7)
>>> var epListener = function (e) {
>>> epresults.push(JSON.parse(e.data))
>>> }
>>>
>>> 8)
>>> endpointsSource.addEventListener('message', epListener, false)
>>>
>>> Heres the bug.
>>> No changes were triggered on __either__ database.
>>> `connresults` is loaded with _all_docs of connection database.
>>> `epresults` is loaded with the _all_docs of the endpoints database.
>>>
>>> And over time, these numbers multiply. For example, connections db really only 233 docs in it and endpoints database really only has 10 docs in it. But over the course of writing this email, `connresults` has 1872 things in it and `epresults` has 60 things in it.
>>>
>>> It seems like right after I add that second source, something crashes and both sources begin dumping periodically.
>>>
>>> Thanks,
>>> Stephen
>>
Re: EventSource periodically dumps db contents.
Posted by Robert Newson <rn...@apache.org>.
Hi Stephen,
Are you passing a since=N parameter when you reconnect to the changes
feed? The feed=eventsource is, I think, only changing the format of
our changes feed to suit the EventSource spec, it doesn't change the
fundamentals.
B.
On 14 April 2013 00:53, Stephen Bartell <sn...@gmail.com> wrote:
> I meant to post this in @dev...
>
> Begin forwarded message:
>
>> From: Stephen Bartell <sn...@gmail.com>
>> Subject: EventSource periodically dumps db contents.
>> Date: April 12, 2013 12:45:06 AM PDT
>> To: "user@couchdb.apache.org" <us...@couchdb.apache.org>
>>
>> Hi all, I've been playing around with EventSource _changes and theres something that doesn't quite make sense.
>>
>> I'm doing all this from Chrome console on OSX localhost couch@1.3.
>>
>> 1)
>> var connectionSource = new EventSource('/cdb/connection/_changes?feed=eventsource')
>>
>> 2)
>> var connresults = []
>>
>> 3)
>> var connListener = function (e) {
>> connresults.push(JSON.parse(e.data))
>> }
>>
>> 4)
>> connectionSource.addEventListener('message', connListener, false)
>>
>> I make sure not to trigger any changes on connection database while I set up a second source.
>> `connresults` is empty at this point. As I expect.
>>
>> 5)
>> var endpointsSource = new EventSource('/cdb/endpoints/_changes?feed=eventsource')
>>
>> 6)
>> var epresults = []
>>
>> 7)
>> var epListener = function (e) {
>> epresults.push(JSON.parse(e.data))
>> }
>>
>> 8)
>> endpointsSource.addEventListener('message', epListener, false)
>>
>> Heres the bug.
>> No changes were triggered on __either__ database.
>> `connresults` is loaded with _all_docs of connection database.
>> `epresults` is loaded with the _all_docs of the endpoints database.
>>
>> And over time, these numbers multiply. For example, connections db really only 233 docs in it and endpoints database really only has 10 docs in it. But over the course of writing this email, `connresults` has 1872 things in it and `epresults` has 60 things in it.
>>
>> It seems like right after I add that second source, something crashes and both sources begin dumping periodically.
>>
>> Thanks,
>> Stephen
>