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
On Sunday, April 22, 2012 2:08:21 PM UTC-5, Andrew Ledvina wrote:
>
> 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
>
> On Apr 22, 6:37 am, Evan Miller <[email protected]> wrote:
> > 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
> >
> >
> >
> >
> >
> > On Sat, Apr 21, 2012 at 11:15 AM, Andrew Ledvina <[email protected]>
> wrote:
> > > 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 Millerhttp://www.evanmiller.org/
--
You received this message because you are subscribed to the Google Groups
"ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit
https://groups.google.com/d/msgid/chicagoboss/09bbb33b-3059-4b68-8915-8fa16922bfca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
