[Lift] Comet issue for Lift-2.0-scala280-SNAPSHOT
Hi,
I've been testing out the Lift-2.0-scala280-SNAPSHOT a little bit and
found a issue with Comet actor, setHtml and ajaxInvoke.
When trying to invoke the following partial update nothing seems to
happen:
partialUpdate(SetHtml("field", JsRaw("alert('hi')"))._2} value="Say hi" /
>))
This works as expected however:
partialUpdate(SetHtml("field", a(() => JsRaw("alert('hi')"),
Link)))
I've created a example app to illustrate the problem if someone is
interested:
git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git
Best regards
Trond
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
> As mentioned earlier, please try *lifespan* instead. > > def lifespan: Box[TimeSpan] is what you probably want. Ah :D I thought you were correcting the type parameter in David's email, didn't notice the function name. Thanks a lot! :) -- Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
On Wed, Feb 10, 2010 at 9:36 AM, Indrajit Raychaudhuri wrote: > Adam, > > As mentioned earlier, please try *lifespan* instead. > > def lifespan: Box[TimeSpan] is what you probably want. > Thanks for correcting me on this. I must have had a brain mis-fire when I typed the method name. > > - Indrajit > > > On 10/02/10 10:58 PM, Adam Warski wrote: > >> Hello, >> >> to be extra sure I pulled the latest sources from git and recompiled. >> And I still get an error: >> >> error: method timespan overrides nothing >> override def timespan: Box[TimeSpan] = Full(0 seconds) >> >> Yep, override def timespan: Int does if fact override nothing... please >>> look at my mail. The method to override is def timespan: >>> Box[Helpers.TimeSpan] >>> >> >> if I was trying to override a method with another method with an >> incompatible return type, I would get another error (like "error overriding >> method x in class A of type => Int; >> method x has incompatible type => String") >> >> Searching for "timespan" method in the current source: >> >> http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-webkit/src/main/scala/net/liftweb/http/CometActor.scala >> >> also doesn't return anything. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
Adam, As mentioned earlier, please try *lifespan* instead. def lifespan: Box[TimeSpan] is what you probably want. - Indrajit On 10/02/10 10:58 PM, Adam Warski wrote: Hello, to be extra sure I pulled the latest sources from git and recompiled. And I still get an error: error: method timespan overrides nothing override def timespan: Box[TimeSpan] = Full(0 seconds) Yep, override def timespan: Int does if fact override nothing... please look at my mail. The method to override is def timespan: Box[Helpers.TimeSpan] if I was trying to override a method with another method with an incompatible return type, I would get another error (like "error overriding method x in class A of type => Int; method x has incompatible type => String") Searching for "timespan" method in the current source: http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-webkit/src/main/scala/net/liftweb/http/CometActor.scala also doesn't return anything. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
Hello, to be extra sure I pulled the latest sources from git and recompiled. And I still get an error: error: method timespan overrides nothing override def timespan: Box[TimeSpan] = Full(0 seconds) > Yep, override def timespan: Int does if fact override nothing... please look > at my mail. The method to override is def timespan: Box[Helpers.TimeSpan] if I was trying to override a method with another method with an incompatible return type, I would get another error (like "error overriding method x in class A of type => Int; method x has incompatible type => String") Searching for "timespan" method in the current source: http://github.com/dpp/liftweb/blob/master/framework/lift-base/lift-webkit/src/main/scala/net/liftweb/http/CometActor.scala also doesn't return anything. -- Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
On 10/02/10 9:49 PM, David Pollak wrote:
On Wed, Feb 10, 2010 at 8:13 AM, Adam Warski mailto:a...@warski.org>> wrote:
Hello,
> Yes, in fact there is a timespan method in CometActor. You
should be using Lift 2.0-M1 or 2.0-SNAPSHOT.
I'm using 2.0-SNAPSHOT:
class Test extends CometActor {
def render = NodeSeq.Empty
override def timespan = 0
}
error: method timespan overrides nothing
override def timespan = 0
^
one error found
same for timeSpan.
Yep, override def timespan: Int does if fact override nothing... please
look at my mail. The method to override is def timespan:
Box[Helpers.TimeSpan]
You probably mean
def lifespan: Box[TimeSpan]
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
--
You received this message because you are subscribed to the Google
Groups "Lift" group.
To post to this group, send email to liftweb@googlegroups.com
.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google
Groups "Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
On Wed, Feb 10, 2010 at 8:13 AM, Adam Warski wrote:
> Hello,
>
> > Yes, in fact there is a timespan method in CometActor. You should be
> using Lift 2.0-M1 or 2.0-SNAPSHOT.
>
> I'm using 2.0-SNAPSHOT:
>
> class Test extends CometActor {
> def render = NodeSeq.Empty
> override def timespan = 0
> }
>
> error: method timespan overrides nothing
> override def timespan = 0
> ^
> one error found
>
> same for timeSpan.
>
Yep, override def timespan: Int does if fact override nothing... please
look at my mail. The method to override is def timespan:
Box[Helpers.TimeSpan]
>
> --
> Adam Warski
> http://www.warski.org
> http://www.softwaremill.eu
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
Hello,
> Yes, in fact there is a timespan method in CometActor. You should be using
> Lift 2.0-M1 or 2.0-SNAPSHOT.
I'm using 2.0-SNAPSHOT:
class Test extends CometActor {
def render = NodeSeq.Empty
override def timespan = 0
}
error: method timespan overrides nothing
override def timespan = 0
^
one error found
same for timeSpan.
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
On Tue, Feb 9, 2010 at 11:40 PM, Adam Warski wrote: > Hello, > > > A CometActor has a lifespan of the session, not a particular page. The > same component may be visible on many different pages. The same component > may receive messages from external source, even when the component is not > being displayed. The CometActor is a much more pure (in the Smalltalk > sense) implementation of MVC than anything else on the web. > > Ah, I see. Makes sense :) But still I would like to make the actor more > short-lived then the session (which lives now 30 minutes I think). > > > If you want a CometActor to shut down if it has not appeared on any page > for a certain period of time, you can override timespan = Full(2 minutes) in > the CometActor. > > unfortunately there's no "timespan" method in CometActor (nor any other > method with the word "time" in it - I looked before I posted :) ). So is > there a way to make the actor live shorter then the session? > Yes, in fact there is a timespan method in CometActor. You should be using Lift 2.0-M1 or 2.0-SNAPSHOT. > > -- > Thanks, > Adam Warski > http://www.warski.org > http://www.softwaremill.eu > > > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
Hello, > A CometActor has a lifespan of the session, not a particular page. The same > component may be visible on many different pages. The same component may > receive messages from external source, even when the component is not being > displayed. The CometActor is a much more pure (in the Smalltalk sense) > implementation of MVC than anything else on the web. Ah, I see. Makes sense :) But still I would like to make the actor more short-lived then the session (which lives now 30 minutes I think). > If you want a CometActor to shut down if it has not appeared on any page for > a certain period of time, you can override timespan = Full(2 minutes) in the > CometActor. unfortunately there's no "timespan" method in CometActor (nor any other method with the word "time" in it - I looked before I posted :) ). So is there a way to make the actor live shorter then the session? -- Thanks, Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Comet shutdown?
On Tue, Feb 9, 2010 at 3:28 AM, Adam Warski wrote: > Hello, > > I'm playing with comet support in lift, following the example from the > book, and it works fine except for shutting down. > I close the browser window where the page with the comet client was open > and I would expect that at some point shortly after that the localShutdown > method should be called. > > However this doesn't happen (at least didn't happen in the last 10 > minutes). Only when I shutdown the container, I see that the shutdown method > was called. > > A CometActor has a lifespan of the session, not a particular page. The same component may be visible on many different pages. The same component may receive messages from external source, even when the component is not being displayed. The CometActor is a much more pure (in the Smalltalk sense) implementation of MVC than anything else on the web. > Is there some config to make the clients shutdown after the page > referencing them is no longer open? > If you want a CometActor to shut down if it has not appeared on any page for a certain period of time, you can override timespan = Full(2 minutes) in the CometActor. Thanks, David > > -- > Adam Warski > http://www.warski.org > http://www.softwaremill.eu > > > > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Comet shutdown?
Hello, I'm playing with comet support in lift, following the example from the book, and it works fine except for shutting down. I close the browser window where the page with the comet client was open and I would expect that at some point shortly after that the localShutdown method should be called. However this doesn't happen (at least didn't happen in the last 10 minutes). Only when I shutdown the container, I see that the shutdown method was called. Is there some config to make the clients shutdown after the page referencing them is no longer open? -- Adam Warski http://www.warski.org http://www.softwaremill.eu -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [lift] Comet making jetty take a long time to shutdown
Just a bit more on this: I've noticed that if all users have logged out then jetty shuts down quickly... Channing Walton wrote: > > Hi, > I've added some comet-fu in my lift app but I've found that it now takes a > minute or so for jetty to shut down. > > Is there something I should have done to enable things to shutdown > quicker? > > Channing > -- View this message in context: http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27477445.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Re: Re: Re: [lift] Comet making jetty take a long time to shutdown
RunWebApp was produced in test/scala when I created the lift project using
the basic archetype.
http://github.com/mrxtravis/liftweb/blob/master/lift-archetype-basic/src/main/resources/archetype-resources/src/test/scala/RunWebApp.scala
bearfeeder wrote:
>
> On Thu, Feb 4, 2010 at 2:51 PM, Channing Walton
> wrote:
>
>>
>> Thanks for the advice, I'll definitely rethink the pattern.
>>
>> I'm actually seeing the problem when I use RunWebApp. When I press a key
>> RunWebApp should shut down but it just hangs for me.
>>
>>
> What is RunWebApp?
>
>
>>
>>
>> bearfeeder wrote:
>> >
>> > On Thu, Feb 4, 2010 at 2:31 PM, Channing Walton
>> > wrote:
>> >
>> >> Actually I'm seeing the same thing with RunWebApp. Methinks there is a
>> >> problem with my comet, I copied the pattern from somewhere else so it
>> may
>> >> well be wrong. Here it is:
>> >>
>> >> (apologies for the names - imagination is escaping me)
>> >>
>> >> class NewIssuesPump extends CometActor {
>> >>
>> >> def render =
>> >>
>> >>
>> >> { Deal.recentDeals.map(d => {d.name}
>> >> {d.created.asHtml}) }
>> >>
>> >
>> > I would recommend against this pattern. It's less than optimal to make
>> an
>> > external call during the render process.
>> >
>> > It's much better to send the recentDeals data to the CometActor via a
>> > message. That way, the CometActor isn't blocking on the RDBMS and you
>> > don't
>> > have 20 or 50 different CometActors all making the same RDBMS call at
>> > once.
>> >
>> > The Tick pattern is only good for a clock... it's very bad for other
>> > patterns.
>> >
>> > But this is not causing the problem (unless the query is taking a
>> minute).
>> >
>> > If you can tell me how the Jetty process is getting the message to
>> > shutdown,
>> > I'll try to reproduce the issue.
>> >
>> >
>> >>
>> >>
>> >>
>> >> override def lowPriority = {
>> >>case Tick => reRender(false)
>> >> }
>> >>
>> >> override def localSetup {
>> >>super.localSetup()
>> >>NewIssuesPumpMaster ! SubscribePump(this)
>> >> }
>> >>
>> >> override def localShutdown {
>> >>NewIssuesPumpMaster ! UnsubPump(this)
>> >>super.localShutdown()
>> >> }
>> >> }
>> >>
>> >> case object Tick
>> >> case class SubscribePump(pump : NewIssuesPump)
>> >> case class UnsubPump(pump: NewIssuesPump)
>> >>
>> >> object NewIssuesPumpMaster extends LiftActor {
>> >>
>> >> private var pumps : List[NewIssuesPump] = Nil
>> >>
>> >> override def messageHandler = {
>> >> case SubscribePump(pump) => pumps ::= pump
>> >> case UnsubPump(pump) => pumps -= pump
>> >> case Tick => pumps.foreach(_ ! Tick)
>> >>}
>> >> }
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27460808.html
>> >> Sent from the liftweb mailing list archive at Nabble.com.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "Lift" group.
>> >> To post to this group, send email to lift...@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >>
>> liftweb+unsubscr...@googlegroups.com
>>
>> >
>> >> .
>> >> For more options, visit this group at
>> >> http://groups.google.com/group/liftweb?hl=en.
>> >>
>> >>
>> >
>> >
>> > --
>> > Lift, the simply functional web framework http://liftweb.net
>> > Beginning Scala http://www.apress.com/book/view/1430219890
>> > Follow me: http://twitter.com/dpp
>> > Surf the harmonics
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Lift" group.
>> > To post to this group, send email to lift...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> >
>> liftweb+unsubscr...@googlegroups.com
>> .
>> > For more options, visit this group at
>> > http://groups.google.com/group/liftweb?hl=en.
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27461062.html
>> Sent from the liftweb mailing list archive at Nabble.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this grou
Re: [Lift] Re: Re: Re: [lift] Comet making jetty take a long time to shutdown
On Thu, Feb 4, 2010 at 2:51 PM, Channing Walton wrote:
>
> Thanks for the advice, I'll definitely rethink the pattern.
>
> I'm actually seeing the problem when I use RunWebApp. When I press a key
> RunWebApp should shut down but it just hangs for me.
>
>
What is RunWebApp?
>
>
> bearfeeder wrote:
> >
> > On Thu, Feb 4, 2010 at 2:31 PM, Channing Walton
> > wrote:
> >
> >> Actually I'm seeing the same thing with RunWebApp. Methinks there is a
> >> problem with my comet, I copied the pattern from somewhere else so it
> may
> >> well be wrong. Here it is:
> >>
> >> (apologies for the names - imagination is escaping me)
> >>
> >> class NewIssuesPump extends CometActor {
> >>
> >> def render =
> >>
> >>
> >> { Deal.recentDeals.map(d => {d.name}
> >> {d.created.asHtml}) }
> >>
> >
> > I would recommend against this pattern. It's less than optimal to make
> an
> > external call during the render process.
> >
> > It's much better to send the recentDeals data to the CometActor via a
> > message. That way, the CometActor isn't blocking on the RDBMS and you
> > don't
> > have 20 or 50 different CometActors all making the same RDBMS call at
> > once.
> >
> > The Tick pattern is only good for a clock... it's very bad for other
> > patterns.
> >
> > But this is not causing the problem (unless the query is taking a
> minute).
> >
> > If you can tell me how the Jetty process is getting the message to
> > shutdown,
> > I'll try to reproduce the issue.
> >
> >
> >>
> >>
> >>
> >> override def lowPriority = {
> >>case Tick => reRender(false)
> >> }
> >>
> >> override def localSetup {
> >>super.localSetup()
> >>NewIssuesPumpMaster ! SubscribePump(this)
> >> }
> >>
> >> override def localShutdown {
> >>NewIssuesPumpMaster ! UnsubPump(this)
> >>super.localShutdown()
> >> }
> >> }
> >>
> >> case object Tick
> >> case class SubscribePump(pump : NewIssuesPump)
> >> case class UnsubPump(pump: NewIssuesPump)
> >>
> >> object NewIssuesPumpMaster extends LiftActor {
> >>
> >> private var pumps : List[NewIssuesPump] = Nil
> >>
> >> override def messageHandler = {
> >> case SubscribePump(pump) => pumps ::= pump
> >> case UnsubPump(pump) => pumps -= pump
> >> case Tick => pumps.foreach(_ ! Tick)
> >>}
> >> }
> >>
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27460808.html
> >> Sent from the liftweb mailing list archive at Nabble.com.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Lift" group.
> >> To post to this group, send email to lift...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> liftweb+unsubscr...@googlegroups.com
>
> >
> >> .
> >> For more options, visit this group at
> >> http://groups.google.com/group/liftweb?hl=en.
> >>
> >>
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27461062.html
> Sent from the liftweb mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Re: Re: [lift] Comet making jetty take a long time to shutdown
Thanks for the advice, I'll definitely rethink the pattern.
I'm actually seeing the problem when I use RunWebApp. When I press a key
RunWebApp should shut down but it just hangs for me.
bearfeeder wrote:
>
> On Thu, Feb 4, 2010 at 2:31 PM, Channing Walton
> wrote:
>
>> Actually I'm seeing the same thing with RunWebApp. Methinks there is a
>> problem with my comet, I copied the pattern from somewhere else so it may
>> well be wrong. Here it is:
>>
>> (apologies for the names - imagination is escaping me)
>>
>> class NewIssuesPump extends CometActor {
>>
>> def render =
>>
>>
>> { Deal.recentDeals.map(d => {d.name}
>> {d.created.asHtml}) }
>>
>
> I would recommend against this pattern. It's less than optimal to make an
> external call during the render process.
>
> It's much better to send the recentDeals data to the CometActor via a
> message. That way, the CometActor isn't blocking on the RDBMS and you
> don't
> have 20 or 50 different CometActors all making the same RDBMS call at
> once.
>
> The Tick pattern is only good for a clock... it's very bad for other
> patterns.
>
> But this is not causing the problem (unless the query is taking a minute).
>
> If you can tell me how the Jetty process is getting the message to
> shutdown,
> I'll try to reproduce the issue.
>
>
>>
>>
>>
>> override def lowPriority = {
>>case Tick => reRender(false)
>> }
>>
>> override def localSetup {
>>super.localSetup()
>>NewIssuesPumpMaster ! SubscribePump(this)
>> }
>>
>> override def localShutdown {
>>NewIssuesPumpMaster ! UnsubPump(this)
>>super.localShutdown()
>> }
>> }
>>
>> case object Tick
>> case class SubscribePump(pump : NewIssuesPump)
>> case class UnsubPump(pump: NewIssuesPump)
>>
>> object NewIssuesPumpMaster extends LiftActor {
>>
>> private var pumps : List[NewIssuesPump] = Nil
>>
>> override def messageHandler = {
>> case SubscribePump(pump) => pumps ::= pump
>> case UnsubPump(pump) => pumps -= pump
>> case Tick => pumps.foreach(_ ! Tick)
>>}
>> }
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27460808.html
>> Sent from the liftweb mailing list archive at Nabble.com.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
--
View this message in context:
http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27461062.html
Sent from the liftweb mailing list archive at Nabble.com.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: Re: [lift] Comet making jetty take a long time to shutdown
On Thu, Feb 4, 2010 at 2:31 PM, Channing Walton wrote:
>
>
> bearfeeder wrote:
> >
> > On Thu, Feb 4, 2010 at 1:11 PM, Channing Walton
> > wrote:
> >
> >>
> >> ah, thats a good question. I am using sbt and its jetty-stop. I'll find
> >> out
> >> what its doing.
> >>
> >
> > I'm pretty sure Lift cancels the Comet connections during the Servlet
> > unload
> > process.
> >
>
> Actually I'm seeing the same thing with RunWebApp. Methinks there is a
> problem with my comet, I copied the pattern from somewhere else so it may
> well be wrong. Here it is:
>
> (apologies for the names - imagination is escaping me)
>
> class NewIssuesPump extends CometActor {
>
> def render =
>
>
> { Deal.recentDeals.map(d => {d.name}
> {d.created.asHtml}) }
>
I would recommend against this pattern. It's less than optimal to make an
external call during the render process.
It's much better to send the recentDeals data to the CometActor via a
message. That way, the CometActor isn't blocking on the RDBMS and you don't
have 20 or 50 different CometActors all making the same RDBMS call at once.
The Tick pattern is only good for a clock... it's very bad for other
patterns.
But this is not causing the problem (unless the query is taking a minute).
If you can tell me how the Jetty process is getting the message to shutdown,
I'll try to reproduce the issue.
>
>
>
> override def lowPriority = {
>case Tick => reRender(false)
> }
>
> override def localSetup {
>super.localSetup()
>NewIssuesPumpMaster ! SubscribePump(this)
> }
>
> override def localShutdown {
>NewIssuesPumpMaster ! UnsubPump(this)
>super.localShutdown()
> }
> }
>
> case object Tick
> case class SubscribePump(pump : NewIssuesPump)
> case class UnsubPump(pump: NewIssuesPump)
>
> object NewIssuesPumpMaster extends LiftActor {
>
> private var pumps : List[NewIssuesPump] = Nil
>
> override def messageHandler = {
> case SubscribePump(pump) => pumps ::= pump
> case UnsubPump(pump) => pumps -= pump
> case Tick => pumps.foreach(_ ! Tick)
>}
> }
>
> --
> View this message in context:
> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27460808.html
> Sent from the liftweb mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: Re: [lift] Comet making jetty take a long time to shutdown
bearfeeder wrote:
>
> On Thu, Feb 4, 2010 at 1:11 PM, Channing Walton
> wrote:
>
>>
>> ah, thats a good question. I am using sbt and its jetty-stop. I'll find
>> out
>> what its doing.
>>
>
> I'm pretty sure Lift cancels the Comet connections during the Servlet
> unload
> process.
>
Actually I'm seeing the same thing with RunWebApp. Methinks there is a
problem with my comet, I copied the pattern from somewhere else so it may
well be wrong. Here it is:
(apologies for the names - imagination is escaping me)
class NewIssuesPump extends CometActor {
def render =
{ Deal.recentDeals.map(d => {d.name}
{d.created.asHtml}) }
override def lowPriority = {
case Tick => reRender(false)
}
override def localSetup {
super.localSetup()
NewIssuesPumpMaster ! SubscribePump(this)
}
override def localShutdown {
NewIssuesPumpMaster ! UnsubPump(this)
super.localShutdown()
}
}
case object Tick
case class SubscribePump(pump : NewIssuesPump)
case class UnsubPump(pump: NewIssuesPump)
object NewIssuesPumpMaster extends LiftActor {
private var pumps : List[NewIssuesPump] = Nil
override def messageHandler = {
case SubscribePump(pump) => pumps ::= pump
case UnsubPump(pump) => pumps -= pump
case Tick => pumps.foreach(_ ! Tick)
}
}
--
View this message in context:
http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27460808.html
Sent from the liftweb mailing list archive at Nabble.com.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [lift] Comet making jetty take a long time to shutdown
On Thu, Feb 4, 2010 at 1:11 PM, Channing Walton wrote: > > ah, thats a good question. I am using sbt and its jetty-stop. I'll find out > what its doing. > I'm pretty sure Lift cancels the Comet connections during the Servlet unload process. > > > > bearfeeder wrote: > > > > On Thu, Feb 4, 2010 at 2:15 AM, Channing Walton > > wrote: > > > >> > >> Hi, > >> I've added some comet-fu in my lift app but I've found that it now takes > >> a > >> minute or so for jetty to shut down. > >> > >> > > How are you shutting down your Jetty server? > > > > -- > View this message in context: > http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27459820.html > Sent from the liftweb mailing list archive at Nabble.com. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [lift] Comet making jetty take a long time to shutdown
ah, thats a good question. I am using sbt and its jetty-stop. I'll find out what its doing. bearfeeder wrote: > > On Thu, Feb 4, 2010 at 2:15 AM, Channing Walton > wrote: > >> >> Hi, >> I've added some comet-fu in my lift app but I've found that it now takes >> a >> minute or so for jetty to shut down. >> >> > How are you shutting down your Jetty server? > -- View this message in context: http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27459820.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [lift] Comet making jetty take a long time to shutdown
On Thu, Feb 4, 2010 at 2:15 AM, Channing Walton wrote: > > Hi, > I've added some comet-fu in my lift app but I've found that it now takes a > minute or so for jetty to shut down. > > How are you shutting down your Jetty server? > Is there something I should have done to enable things to shutdown quicker? > > Channing > -- > View this message in context: > http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27450451.html > Sent from the liftweb mailing list archive at Nabble.com. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [lift] Comet making jetty take a long time to shutdown
No, it eventually quits peacefully. Timothy Perrett wrote: > > > Are you seeing a stack trace? > > Cheers, Tim > > > On 4 Feb 2010, at 10:15, Channing Walton wrote: > >> >> Hi, >> I've added some comet-fu in my lift app but I've found that it now takes >> a >> minute or so for jetty to shut down. >> >> Is there something I should have done to enable things to shutdown >> quicker? >> >> Channing >> -- >> View this message in context: >> http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27450451.html >> Sent from the liftweb mailing list archive at Nabble.com. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- View this message in context: http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27450729.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [lift] Comet making jetty take a long time to shutdown
Are you seeing a stack trace? Cheers, Tim On 4 Feb 2010, at 10:15, Channing Walton wrote: > > Hi, > I've added some comet-fu in my lift app but I've found that it now takes a > minute or so for jetty to shut down. > > Is there something I should have done to enable things to shutdown quicker? > > Channing > -- > View this message in context: > http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27450451.html > Sent from the liftweb mailing list archive at Nabble.com. > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] [lift] Comet making jetty take a long time to shutdown
Hi, I've added some comet-fu in my lift app but I've found that it now takes a minute or so for jetty to shut down. Is there something I should have done to enable things to shutdown quicker? Channing -- View this message in context: http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27450451.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Comet long polls turning to fast short polls
Hi, I'm trying to build a small Twitter application using scala, using Twitter4j java library. In my application I'm using 2 comet actors, one needed for managing general updates(non-Twitter) and one for making twitter updates. Problem is as soon as I log into twitter using my app, I see that the Comet long polls are changing to very quick short polls, which seem to be very cpu intensive. The fast short polls seem to persist even when I'm navigating away from the page. Any idea why this behaviour is seen?? Here's the html body of the page at runtime: --- // // // // // // --- -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Comet Actor
I have a some code in a CometActor that I want to run right after render is called for the first time. What is the best way to do this? I could set a boolean variable in the render method and then send a message back to the CometActor to tell it to run the code. I suspect there is a better way? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Concurrency control of database access in Lift/Comet
Howdy, I think you misunderstand how Actors work. An Actor only consumes resources while it is processing an item in its mailbox. So if an Actor is hanging out, doing nothing, it will only consume memory (like any other object.) When the Actor receives a message, it allocates some additional resources to process the message. Those resources always include a thread. In Lift, those resources also include an "S" scope. When "S" (session state) comes into scope, a connection to the RDBMS may be allocated (depending on you application's transaction policy) so that all RDBMS interactions that take place during that message processing will be part of a single RDBMS transaction. There are no resources allocated while a browser is waiting for a Comet event (except an NIO connection and a few objects allocated in memory). It's only when something happens that will cause HTML to go to the browser that events get put into mailboxes and RDBMS connections get pulled out of a pool. I hope this helps clear up the questions you had. Thanks, David On Sun, Oct 4, 2009 at 10:41 AM, donfranciscodequevedo < donfranciscodequev...@gmail.com> wrote: > > I have read that the Lift framework supports the CometActor model. > As far as I understand this is achieved by creating many threads out > of some thread pool, each of which handles one or more client socket > connection to a client. > > My question is, what kind of approach Lift takes to handle access from > such threads to a shared object, e.g. a database? > > Many thread based applications use locks to access shared data, which > however won't scale well. I read that better models would be timestamp > ordering or multiversion concurrency control like e.g. used by > CouchDB. > > Perhaps this is also handled automatically by the database and I don't > have to bother about it at all from my application? Is it save to use > a database connection from different threads? > > A simple example that came to my mind would be a Comet chat > application, where one wants to save the communication to a database. > How would the concurrent write requests from two threads to the > database be handled in such case? > > > Best regards > > > Gregor > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Concurrency control of database access in Lift/Comet
Its really more of a Java problem, or JDBC to be specific. The normal way to configure this would be to establish a pool of connections, when a thread, or actor, needs to interact with the database it takes a connection from the pool, uses it, then returns it to the pool. This is the same regardless of how you approach concurrency (actors/locks/dataflow/etc.). When every connection in the pool is in use, subsequent requests will block until one becomes available, thus limiting the number of simultaneous requests to the DB. Tuning is then handled by adjusting the pool size to a value that delivers greatest throughput from the database. Depending on your exact requirements, it's then possible to build a layer on to of this that can take advantage of asynchronous messages to actors On Mon, Oct 5, 2009 at 12:50 PM, donfranciscodequevedo wrote: > > Thanks Kevin, > I know, that this is more of a theoretical problem, but now that I > have read so much about Actors and concurrent programming, I am > actually curious about the underlying concurrency strategies taken by > Scala. Infact I realize, that this is actually more a Scala question, > than a Lift one. But it is interesting for lift too, as it it builds > upon Scalas actor model. > > So as far as I understand you suggest, that I take the concurrency > problem over to the database and leave it up to the database to handle > concurrency like in the following flow schema: > > Many open Comet connections -> one thread per one or more client > socket connections -> one database connection per thread -> > concurrency handling in DB > > This approach however means that my application will generate many > open connections to the database and therefore much connection (IPC-) > overhead. Also by doing so it doesn't actually use the advantages of > Scalas concurrency model. > > My approach was instead something like this: > Many open Comet connections -> one thread per one or more client > socket connections -> one thread receiving messages from all other > threads putting them in a message queue -> one database connection -> > DB access > > Concurrency in such model is handled by the message system of Scala, > which AFAIK is thread safe and doesn't use locks?! The advantage would > be, that I just would need one database connection, which to me sounds > more efficient. > > I think my question can be drilled down to the following. How > efficient is Scala's concurrency model? Do Scala Actors use locks in > the underpinning or are concurrency operations atomic? (I read here > http://www.ibm.com/developerworks/java/library/j-scala04109.html that > Scala uses locks under the hood too so after all I could finish up > with the same problems like with shared memory and mutexes?) > > Best regards > > > Gregor > > > > > > On 4 Okt., 21:06, Kevin Wright wrote: >> In my experience, the database engine itself does a pretty good job of >> managing concurrent connections like this out of the box, which is >> much of the reason why connection pooling is so effective. >> >> Of course, thinks can be a bit interesting on the database side if you >> want to get really obsessive about performance, with possibilities >> such as tinkering with page sizes, locking strategies, and such like, >> but it's extremely rare for this to be a bottleneck in an application. >> >> However... For the example you've given, I'd just run a dedicated >> actor to persist chat messages. There's no need to wait for a message >> to be persisted before displaying it to the user, so asynchronous >> messages can really help out here. >> >> On Sun, Oct 4, 2009 at 6:41 PM, donfranciscodequevedo >> >> wrote: >> >> > I have read that the Lift framework supports the CometActor model. >> > As far as I understand this is achieved by creating many threads out >> > of some thread pool, each of which handles one or more client socket >> > connection to a client. >> >> > My question is, what kind of approach Lift takes to handle access from >> > such threads to a shared object, e.g. a database? >> >> > Many thread based applications use locks to access shared data, which >> > however won't scale well. I read that better models would be timestamp >> > ordering or multiversion concurrency control like e.g. used by >> > CouchDB. >> >> > Perhaps this is also handled automatically by the database and I don't >> > have to bother about it at all from my application? Is it save to use >> > a database connection from different threads? >> >> > A simple example that came to my mind would be a Comet chat >> > application, where one wants to save the communication to a database. >> > How would the concurrent write requests from two threads to the >> > database be handled in such case? >> >> > Best regards >> >> > Gregor > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups
[Lift] Re: Concurrency control of database access in Lift/Comet
Thanks Kevin, I know, that this is more of a theoretical problem, but now that I have read so much about Actors and concurrent programming, I am actually curious about the underlying concurrency strategies taken by Scala. Infact I realize, that this is actually more a Scala question, than a Lift one. But it is interesting for lift too, as it it builds upon Scalas actor model. So as far as I understand you suggest, that I take the concurrency problem over to the database and leave it up to the database to handle concurrency like in the following flow schema: Many open Comet connections -> one thread per one or more client socket connections -> one database connection per thread -> concurrency handling in DB This approach however means that my application will generate many open connections to the database and therefore much connection (IPC-) overhead. Also by doing so it doesn't actually use the advantages of Scalas concurrency model. My approach was instead something like this: Many open Comet connections -> one thread per one or more client socket connections -> one thread receiving messages from all other threads putting them in a message queue -> one database connection -> DB access Concurrency in such model is handled by the message system of Scala, which AFAIK is thread safe and doesn't use locks?! The advantage would be, that I just would need one database connection, which to me sounds more efficient. I think my question can be drilled down to the following. How efficient is Scala's concurrency model? Do Scala Actors use locks in the underpinning or are concurrency operations atomic? (I read here http://www.ibm.com/developerworks/java/library/j-scala04109.html that Scala uses locks under the hood too so after all I could finish up with the same problems like with shared memory and mutexes?) Best regards Gregor On 4 Okt., 21:06, Kevin Wright wrote: > In my experience, the database engine itself does a pretty good job of > managing concurrent connections like this out of the box, which is > much of the reason why connection pooling is so effective. > > Of course, thinks can be a bit interesting on the database side if you > want to get really obsessive about performance, with possibilities > such as tinkering with page sizes, locking strategies, and such like, > but it's extremely rare for this to be a bottleneck in an application. > > However... For the example you've given, I'd just run a dedicated > actor to persist chat messages. There's no need to wait for a message > to be persisted before displaying it to the user, so asynchronous > messages can really help out here. > > On Sun, Oct 4, 2009 at 6:41 PM, donfranciscodequevedo > > wrote: > > > I have read that the Lift framework supports the CometActor model. > > As far as I understand this is achieved by creating many threads out > > of some thread pool, each of which handles one or more client socket > > connection to a client. > > > My question is, what kind of approach Lift takes to handle access from > > such threads to a shared object, e.g. a database? > > > Many thread based applications use locks to access shared data, which > > however won't scale well. I read that better models would be timestamp > > ordering or multiversion concurrency control like e.g. used by > > CouchDB. > > > Perhaps this is also handled automatically by the database and I don't > > have to bother about it at all from my application? Is it save to use > > a database connection from different threads? > > > A simple example that came to my mind would be a Comet chat > > application, where one wants to save the communication to a database. > > How would the concurrent write requests from two threads to the > > database be handled in such case? > > > Best regards > > > Gregor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Concurrency control of database access in Lift/Comet
In my experience, the database engine itself does a pretty good job of managing concurrent connections like this out of the box, which is much of the reason why connection pooling is so effective. Of course, thinks can be a bit interesting on the database side if you want to get really obsessive about performance, with possibilities such as tinkering with page sizes, locking strategies, and such like, but it's extremely rare for this to be a bottleneck in an application. However... For the example you've given, I'd just run a dedicated actor to persist chat messages. There's no need to wait for a message to be persisted before displaying it to the user, so asynchronous messages can really help out here. On Sun, Oct 4, 2009 at 6:41 PM, donfranciscodequevedo wrote: > > I have read that the Lift framework supports the CometActor model. > As far as I understand this is achieved by creating many threads out > of some thread pool, each of which handles one or more client socket > connection to a client. > > My question is, what kind of approach Lift takes to handle access from > such threads to a shared object, e.g. a database? > > Many thread based applications use locks to access shared data, which > however won't scale well. I read that better models would be timestamp > ordering or multiversion concurrency control like e.g. used by > CouchDB. > > Perhaps this is also handled automatically by the database and I don't > have to bother about it at all from my application? Is it save to use > a database connection from different threads? > > A simple example that came to my mind would be a Comet chat > application, where one wants to save the communication to a database. > How would the concurrent write requests from two threads to the > database be handled in such case? > > > Best regards > > > Gregor > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Concurrency control of database access in Lift/Comet
I have read that the Lift framework supports the CometActor model. As far as I understand this is achieved by creating many threads out of some thread pool, each of which handles one or more client socket connection to a client. My question is, what kind of approach Lift takes to handle access from such threads to a shared object, e.g. a database? Many thread based applications use locks to access shared data, which however won't scale well. I read that better models would be timestamp ordering or multiversion concurrency control like e.g. used by CouchDB. Perhaps this is also handled automatically by the database and I don't have to bother about it at all from my application? Is it save to use a database connection from different threads? A simple example that came to my mind would be a Comet chat application, where one wants to save the communication to a database. How would the concurrent write requests from two threads to the database be handled in such case? Best regards Gregor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] comet
How can assure that every time a comet page is loaded, it starts again fresh? I.e. as if the page were being loaded for the first time? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet Actors - single browser, multiple tabs, same URL - out of control GET problem
We have a lift app (innovationgames.com) which has a page (actually several) with comet actors. When we go to the same URL in two tabs in the same browser, we see that the long polls (GET requests) return immediately in rapid fire succession and this behavior continues until we exit one of the tabs. We thought maybe we did something wrong in our code, so we tried the same thing using demo.liftweb.net. We saw the same behavior in the demo site that we see in our site. If you try this with something else like Gmail, it does not show this behavior. I thought I would post to this group and get some feedback before submitting a bug. Thanks in advance. Dano --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet Chat
Hello lifted, I am playing around with the 50ish line based comet example that dpp has talked about in several talks and that is written more about here: http://m.3wa.com/?p=304 Today I showed this to a friend and it looks like the focus of the input box is lost when an update is received. Does anybody have a clue on how this can be fixed? Is it not possible to just update part of the DOM without having to steal the focus from the input field? -- Bjarte Stien Karlsen Ronatoppen 6a, 4638 Kristiansand 95219547 MSN: m...@ibjarte.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet logger initialized too early?
Hi,
In trying to move to slf4j/logback I encountered an error when I removed
log4j from the cp:
09:53:50.297 [main] ERROR org.mortbay.log - failed LiftFilter
java.lang.NoClassDefFoundError: org/apache/log4j/LogManager
at net.liftweb.util.LogBoot$.log4jIsConfigured$1(Log.scala:113)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:129)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:95)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:95)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$.checkConfig(Log.scala:93)
[lift-util-1.1-SNAPSHOT.jar:na]
at
net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger(Log.scala:139)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$$anonfun$3.apply(Log.scala:141)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.util.LogBoot$$anonfun$3.apply(Log.scala:141)
[lift-util-1.1-SNAPSHOT.jar:na]
at net.liftweb.http.LiftRules$.(LiftRules.scala:654)
[lift-webkit-1.1-SNAPSHOT.jar:na]
I would seem that the Comet logger is initialised before lift is booted
(and thus using the default log config):
from LiftRules:
var cometLogger: LiftLogger = {
val ret = LogBoot.loggerByName("comet_trace")
ret.level = LiftLogLevels.Off
ret
}
Shouldn't this initialization be moved to after lift is booted?
/Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Comet render and jQuery
I am might be going about this in the wrong way but I wanted to get
confirmation.
I have a comet lift snippet that waits for a comet actor to send down
search results triggered by a button click after entering keywords.
Loading...
In the actor I rendor the search results and merge an onclick function
into the header document.ready. Things seem to work fine but after
the snippet renders the onclick function does not activate until I
click on 2 hyperlinks, which takes me to the linked website (click
url) then hitting the back button back to the liftwebsite, basically
reloading the page twice. After this the alert box shows up for each
hyperlink.
I can refactor this to work in a different way but I wanted to
understand what is wrong here if anyone knows.
Thanks in advance
def render = {
def searchResultFormatter(itemToFormat: SearchResultSet): NodeSeq
= {
{itemToFormat.resultSetItem.title}
{itemToFormat.resultSetItem.summary}
}
bind("SearchResults" -> {searchLinks.flatMap
(resultFormatter _)}
{Unparsed
("""
jQuery(document).ready(function() {
$('.searchlink').click(function() {
alert('call made it here');
return (false);
});
})
""")}
)
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Comet DispatchPF - RestfulCometActor?
Hey folks, As you may or may not know, i'm currently working on integrating lift with objective-j... One of the things i'm keen to integrate is lifts comet support. The current implementation of CometActor is pretty much based around javascript and manipulating the DOM. This is great for the vast majority of use cases however its not so great when you want a a more REST orientated approach. Id like to have a comet option that could mean i could push data back down the wire, but with dispatchPF, not with . What are peoples thoughts? I took a look at this but its so deep inside the lift internals its a bit deep for me to delve without more information on how i could go about implementing this. Thoughts? Cheers, Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet request exception
I just copied comet sample named "Clock" from the p. 142 of the liftbook into my app. It doesn't work. First time it renders timestamp normally, but since 10 seconds: WARN - Request for /comet_request/58946720417/1ha35q9iqp4el failed Bail java.lang.Exception: Bail at net.liftweb.http.LiftRules$.doContinuation(LiftRules.scala:436) at net.liftweb.http.LiftServlet.setupContinuation(LiftServlet.scala: 352) at net.liftweb.http.LiftServlet.handleComet(LiftServlet.scala:363) at net.liftweb.http.LiftServlet.net$liftweb$http$LiftServlet$ $dispatchStatefulRequest(LiftServlet.scala:232) at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: 155) at net.liftweb.http.LiftServlet$$anonfun$2.apply(LiftServlet.scala: 155) at net.liftweb.http.S$.net$liftweb$http$S$$wrapQuery(S.scala:908) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit$1$ $anonfun$apply$18.apply(S.scala:1026) at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:845) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$doAround$1.apply (S.scala:846) at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith (DB.scala:117) at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ $doWith$1.apply(DB.scala:118) at net.liftweb.mapper.DB$$anon$1$$anonfun$net$liftweb$mapper$DB$$anon$ $doWith$1.apply(DB.scala:118) at net.liftweb.mapper.DB$.use(DB.scala:305) at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$$doWith (DB.scala:118) at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:124) at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:846) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_nest2InnerInit $1.apply(S.scala:1024) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit(S.scala: 1023) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24$$anonfun$apply$25$$anonfun$apply$26.apply(S.scala:1044) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24$$anonfun$apply$25.apply(S.scala:1043) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23$$anonfun$apply $24.apply(S.scala:1042) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22$$anonfun$apply$23.apply(S.scala: 1041) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21$$anonfun$apply$22.apply(S.scala:1040) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1$ $anonfun$apply$21.apply(S.scala:1039) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit$1.apply (S.scala:1038) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:1037) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30$$anonfun$apply$31$$anonfun$apply$32.apply(S.scala:1068) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30$$anonfun$apply$31.apply(S.scala:1067) at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:191) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29$$anonfun $apply$30.apply(S.scala:1066) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$29.apply (S.scala:1065) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:1064) at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65) at net.liftweb.http.S$._init(S.scala:1063) at net.liftweb.http.S$.init(S.scala:779) at net.liftweb.http.LiftServlet.doService(LiftServlet.scala:154) at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply (LiftServlet.scala:83) at net.liftweb.http.LiftServlet$$anonfun$doIt$1$1.apply (LiftServlet.scala:83) at net.liftweb.util.TimeHelpers$class.calcTime(TimeHelpers.scala:241) at net.liftweb.util.Helpers$.calcTime(Helpers.scala:29) at net.liftweb.util.TimeHelpers$class.logTime(TimeHel
[Lift] comet sample app rendering problem
Lifted,
i'm trying a minor variation on DPP's comet screencast and am running into a
weird rendering problem. The component associated with the "comet-managed
state" never renders. The relevant methods are listed below. Any help would
be greatly appreciated.
Best wishes,
--greg
// View
R-E-P-L
// CometListenee
case class Messages( ms : List[DataSamplePattern] )
class REPLForm extends CometActor with CometListenee {
...
override def highPriority = {
case Messages( what ) => {
_theDataSampleToRender =
Some( what ).asInstanceOf[Option[DataSample]]
reRender( true )
}
}
def registerWith = TemperatureTSCometRenderer
def render = {
{
ajaxText(
"Now",
s => { TemperatureTSCometRenderer ! InitialTime( s ); Noop}
)
}
{
ajaxText(
"Now",
s => { TemperatureTSCometRenderer ! FinalTime( s ); Noop}
)
}
}
// Wire this up to Lift's support for Comet updates.
object TemperatureTSCometRenderer
extends Actor
with ListenerManager
with TempDataServiceCnxn[TemperatureDataService.type]
with TemperatureDataSource
{
var _theUpdate : Option[DataSample] = None
override def highPriority = {
case Connect( tds ) => {
println( "received connect" );
setTemperatureDataService(
Some( tds ).asInstanceOf[Option[TemperatureDataService.type]]
)
}
case DataSample( initTime, finalTime, tics, values ) => {
println( "received data" );
println( "update cache, render data" );
updateCache( DataSample( initTime, finalTime, tics, values )
)
_theUpdate =
Some( DataSample( initTime, finalTime, tics, values ) )
updateListeners()
}
case InitialTime( s ) => {
println( "initial time request" );
}
case dsp : DataSamplePattern => {
println( "check cache for data" );
println( "if empty render null points and request data from service"
);
println( "else if meets rules render" );
println( "else recalc, render and request any additional data" );
getMatchingSamples( dsp ) match {
case Nil => {
println( "cache miss" )
getTemperatureDataService match {
case Some( tds ) =>
tds ! RequestTemperatureData( dsp, this )
case None =>
throw new Exception( "disconnected from data service" )
}
dsp match {
case DataSamplePattern(
Some( initTime ),
Some( finalTime ),
Some( tics ),
_
) => {
println(
DataSample(
initTime, finalTime, tics, None
).toString
)
}
case _ => throw new Exception( "not implemented" )
}
}
case sample :: samples => {
println( "cache hit" )
sample
}
}
}
}
def createUpdate = _theUpdate
// start the actor
start()
// connect to the TemperatureDataService
this ! Connect( TemperatureDataService )
}
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Comet - Unique to each page
I noticed in the chat demo that if you enter your name or chat into one tab, the same results will propagate to the other tab. I need a short lived comet session that's unique to each tab -- I want to prevent one tab from mixing its data with another tab. I understand that most user browser only allow for 2 HTTP connections at a time, but as I said, I have about 10 consecutive pushes to the server that I'll be making and then I want the comet connection to immediately terminate. Is this possible to do with the existing lift CometActor? If so, any suggestions on where to begin? Thanks, Bradford --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet question
Hi: How can I pass initialization parameter to a Comet Actor? Using the chat demo as a use case, consider if I want; - let the user choose a chat room, - the list of chat room is only known at runtime (I can't pass the room's id in the xhtml template) Is it as simple as calling "S.param()" inside the "render()" method ? Thanks Francois --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet
Hi, I was testing comet and chat demo and after opening 4 or 5 windows AJAX requests started to end after 500-700ms, rather than 10 seconds. I know that in most cases this is not an issue (who wants to open 4 chat windows?), but I'm curious what is the problem here. I think that's it's not jQuery related problem. I'm not a scala programmer (yet :) - is there anything with comet implementation that may cause such a behaviour? Cheers --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Comet and Flot
I am interested in adding some (almost) real-time charts to a project of mine. I have a couple of questions, though. 1) Is there documentation on lift's server and client implementation of comet available online? 2) Are there any reasons why dojo's comet client wasn't considered? 3) I see that there is a flot widget that will be integrated into lift soon. What benefits do these widgets offer over a normal JavaScript implementation? 4) I have an immutable Map of data that I need to "push" to the JQuery chart. Where should I begin? Do I send this in JSON format? A lot of questions, I know! p.s. I am loving lift so far. Great work. The CometActor tutorial was very useful as well. Thanks, Bryan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
