Comet issues in the tutorial

[Andrew Ledvina]

This is a separate issue than the one I was having with Mitsulin
fataling. The issue I ran into was going through the tutorial, in the
section when you hook up the event stream to the live page so that you
can see the model creation events show up. Creating a greeting works
just fine, it shows up in the other browser (Awesome by the way). But
as soon as you delete a greeting, the long-polling basically shuts
down; you no longer will see any live create updates. I have no idea
why this is.

Second, I tried to implement live deletes as well by having a second
javascript function running on the delete queues and having a second
endpoint pull_deletes/:timestamp, which works perfectly as long as you
don't mix deletes and creates. That is, if you just delete stuff, they
will show up live in the other browser. If you just create stuff, it
will show up live in the other browser. If you do one then the other,
no further live updates will occur until you hit refresh in the other
browser. Any thoughts on why this occurs?

I understand that adding another long polling function is maybe not
the best way to go about this, but I am really curious why the first
issue arises. Walking through the code I cannot seem to figure out
where this would occur. If it would be helpful I could post the tail
of the server log to see the info reports, but I will just tell you,
after a delete, there are no longer any calls to /pull/xxx. I thought
this might be a Javascript issue, but that I am thinking now that it
is not. It might be an issue with the server not being able to have
two simultaneous connections to the same client. I mean not that this
should be undoable, but rather that maybe somewhere in the server
implementation it just tries to avoid this for security reasons or
something. I haven't tested this across multiple nodes, only locally
on one machine, so I thought it might just be an issue with having the
creates and the updates on the same machine. However, that would suck
because that would eliminate a lot of cool use cases and so I don't
believe that is the problem (i.e. chat wouldn't work).

[Evan Miller]

Hi Andrew,

Falco mentioned in another thread that he avoided a similar problem by
putting the two Comet end-points in different controllers. I think the
issue might be browser-related since browsers implement rules about
how many open connections you can have to a particular server (maybe
URL?) at one time.

To support many kinds of updates, I think the right approach is to
just use one Comet connection for each user and funnel all of a user's
updates into that user's BossMQ channel. So the BossNews callback
should push updates to each connected user's channel, rather than to
one generic channel. Does that make sense? It will require a bit of
work, but I think having a separate connection for each type of update
won't scale from the browser's perspective.

Evan

--
Evan Miller
http://www.evanmiller.org/

[Andrew Ledvina]

Right I agree that a different channel for each update is not
scaleable. I was just trying to make a sort of proof of concept of the
live create and delete page. The bug as I am seeing it can be repro'd
as follows:

1) Open greeting/live in one browser, and greeting/list in another
window
2) Observe that creating messages in greeting/list results in updates
to appear in greeting/live
3) Delete one message on the greeting/list page
4) Add a message via the greeting/list page
5) Observe that the connection is terminated on the live page

I did some Javascript debugging (console.log(...)) and it appears that
the doing step 3 and 4 results in the listen_for_events function to
receive an error response with no data in the responseText which
therefore skips the success field and so the listen_for_events
function is not called again. You can hack around this by dealing with
this case by adding a complete key to the function and having it call
the function again with some generic timestamp. I implemented this in
a way such that you miss one create for every delete which was pretty
shitty but the best I could come up with based on the use of
timestamps and the fact that there is no data in the error response.

Any thoughts on why there would be an error response just because a
delete occurred? Moreover, it is really weird because the error
doesn't happen on the delete, it happens on the next create after a
delete. No idea

I implemented the live update and deletes using only one channel and
everything works nicely. There are no longer any error responses being
returned to the Javascript function. Just a proof of concept. My
Javascript isn't the best so it might be a little messy. You can see
it here:

https://gist.github.com/2466176


Andrew

[Chachi-Inactive]

Sorry for resurrecting a dead thread,

I was going through the tutorial today when I ran into this issue where I was able to get the live message creation to work, but not the live message deletion. Would it make sense if this portion of the tutorial were changed?

init() ->
    {ok, WatchId} = boss_news:watch("greetings",
    fun(created, NewGreeting) ->
        boss_mq:push("new-greetings", NewGreeting);
    (deleted, OldGreeting) ->
        boss_mq:push("old-greetings", OldGreeting)
    end),
    {ok, [WatchId]}.

It seems to prescribe an anti-pattern. Perhaps something like Andrew's gist code would be more appropriate?
Would it be possible for me to edit the tutorial and submit it to someone?

-Chachi-Inactive