[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
Thanks Marius and David for your suggestions.
I'll try that out.
As to the problem itself, don't you think there should some kind of
exception generation to avoid the issue happening?
On Feb 16, 10:35 pm, Marius wrote:
> On Feb 16, 11:17 am, soumik wrote:
>
>
>
>
>
> > Hi Marius,
> > Thanks for the quick update.
> > The xhtml returned from the listFilesInDir() is actually sent as a
> > message to a display CometActor which renders the xhtml it receives
> > within a specific tag.
> > So in essence we have these multiple feature threads running(the one
> > in question is intended to be a local file manager feature) which
> > generates xhtml for different functions which are then sent to this
> > one display CometActor which displays it.
> > So we intend to handle multi-feature tasking by running just the one
> > CometActor and not multiples of them which obviously is a problem for
> > lift(since the max no. of CometActors in a page is 2).
>
> > But back to your explanation of the S context getting lost, I think I
> > understand what you mean regarding the session context. But does it
> > also apply for SHtml generator methods?? I mean, does SHtml generator
> > methods depend on the state of the session??
>
> Yes if you bind functions. Functions are kept per session.
>
> > Another question I have is - even if SHtml generator methods fail to
> > co-relate the session, shouldn't SHtml generator methods return?? or
> > throw an exception?
>
> No as SHtml should be used in the proper S context. That's why it is
> called [S]html.
>
> > I don't know if you happened to use the exact same function in a
> > LiftActor object or not, but if you do that you'll see that the
> > function just doesn't return.
>
> > Also, I don't intend to maintain state preservation.
>
> You do not explicitly but as you are trying to bind functions (attach
> a scla function to a link, button etc) you need the proper context.
>
> > I just want to
> > create a list of tags for all files which when clicked should
> > make an Ajax call to a specific function in the LiftActor thread which
> > processes the selection. Could you suggest some alternative way I
> > could go about this with the current architecture(1 comet actor for
> > display and individual feature-specific LiftActors sending xhtml to
> > CometActor for rendering)??
>
> Take Dave's advice. It is very good and leads to cleaner separation of
> concern.
>
>
>
>
>
> > Thanks,
> > Soumik
>
> > On Feb 16, 1:16 pm, Marius wrote:
>
> > > Well so you're using it from your own actor. I would not recommend
> > > this due to state preservation. I mean S context is very likely lost
> > > because your LiftActor is running on a different thread. What you need
> > > is to pass the LiftSession instance to your LiftActor say using some
> > > distinct message like:
>
> > > case class Init(session: LiftSession)
>
> > > then in your messageHandler
>
> > > protected def messageHandler = {
> > > case FileManagerMsg(someMsg) =>
> > > {
> > > S.initIfNotInitted(session) {
> > > var fileList = listFilesInDir("/Users/soumik/Movies/")
> > > Log.info("OUTPUT: " + fileList)
> > > }
> > > }
>
> > > }
>
> > > But I'm not sure from your code wht you do with the output of your
> > > listFilesInDir since that never gets to be rendered.
>
> > > I strongly recommend using CometActor whenever you want to render
> > > something asynchronously. It does a lots of good things for you.
>
> > > Br's,
> > > Marius
>
> > > On Feb 16, 9:33 am, soumik wrote:
>
> > > > Hi Marius,
>
> > > > Thanks for your response. I'm sorry for mis-communicating my problem
> > > > earlier. As you pointed out the problem doesn't occur when the call to
> > > > the function is made from a CometActor.
> > > > In my case too, it was not a CometActor. Rather, it was the LiftActor.
> > > > (Sometime back we had different CometActors for different feature
> > > > threads, now we have 1 single CometActor which takes care of the
> > > > display and different LiftActor threads which do the feature related
> > > > stuff. Hence the confusion on my part).
>
> > > > Anyways, here's the relevant code:
> > > > --
[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
Hi Marius,
Thanks for the quick update.
The xhtml returned from the listFilesInDir() is actually sent as a
message to a display CometActor which renders the xhtml it receives
within a specific tag.
So in essence we have these multiple feature threads running(the one
in question is intended to be a local file manager feature) which
generates xhtml for different functions which are then sent to this
one display CometActor which displays it.
So we intend to handle multi-feature tasking by running just the one
CometActor and not multiples of them which obviously is a problem for
lift(since the max no. of CometActors in a page is 2).
But back to your explanation of the S context getting lost, I think I
understand what you mean regarding the session context. But does it
also apply for SHtml generator methods?? I mean, does SHtml generator
methods depend on the state of the session??
Another question I have is - even if SHtml generator methods fail to
co-relate the session, shouldn't SHtml generator methods return?? or
throw an exception?
I don't know if you happened to use the exact same function in a
LiftActor object or not, but if you do that you'll see that the
function just doesn't return.
Also, I don't intend to maintain state preservation. I just want to
create a list of tags for all files which when clicked should
make an Ajax call to a specific function in the LiftActor thread which
processes the selection. Could you suggest some alternative way I
could go about this with the current architecture(1 comet actor for
display and individual feature-specific LiftActors sending xhtml to
CometActor for rendering)??
Thanks,
Soumik
On Feb 16, 1:16 pm, Marius wrote:
> Well so you're using it from your own actor. I would not recommend
> this due to state preservation. I mean S context is very likely lost
> because your LiftActor is running on a different thread. What you need
> is to pass the LiftSession instance to your LiftActor say using some
> distinct message like:
>
> case class Init(session: LiftSession)
>
> then in your messageHandler
>
> protected def messageHandler = {
> case FileManagerMsg(someMsg) =>
> {
> S.initIfNotInitted(session) {
> var fileList = listFilesInDir("/Users/soumik/Movies/")
> Log.info("OUTPUT: " + fileList)
> }
> }
>
> }
>
> But I'm not sure from your code wht you do with the output of your
> listFilesInDir since that never gets to be rendered.
>
> I strongly recommend using CometActor whenever you want to render
> something asynchronously. It does a lots of good things for you.
>
> Br's,
> Marius
>
> On Feb 16, 9:33 am, soumik wrote:
>
> > Hi Marius,
>
> > Thanks for your response. I'm sorry for mis-communicating my problem
> > earlier. As you pointed out the problem doesn't occur when the call to
> > the function is made from a CometActor.
> > In my case too, it was not a CometActor. Rather, it was the LiftActor.
> > (Sometime back we had different CometActors for different feature
> > threads, now we have 1 single CometActor which takes care of the
> > display and different LiftActor threads which do the feature related
> > stuff. Hence the confusion on my part).
>
> > Anyways, here's the relevant code:
> > -
> > object TheVideoPlayerThread extends LiftActor
> > {
> > val threadName = "FileManager"
>
> > def listFilesInDir(dirName:String): NodeSeq =
> > {
> > Log.info("Recursing for: " + dirName)
> > val files = (new java.io.File(dirName)).listFiles
>
> > def showFile1() = "AAA"
>
> > {dirName}
> >
> > {files.flatMap(f => {
> > if (f.isDirectory())
> > {
> > Log.info("Directory: " + f.toString)
> > listFilesInDir(f.toString)
> > }
> > else
> > {
> > Log.info("Regular file: " + f.getName)
> >
> > {SHtml.link("", () => showFile1,
> > Text(f.getName)) } //This is the line causing the
> > issue
> >
> > }
> > }
> > )}
> >
> > }
>
> > protected def messageHandler = {
> > case FileManagerMsg(someMsg) =>
> > {
> > var fileList = listFilesInDir("/Users/soumik/Movies/")
> > Log.info("OUTPUT: " + fileList)
> >
[Lift] Re: Error processing SHtml functions withing nested NodeSeq/Scala code
Hi Marius,
Thanks for your response. I'm sorry for mis-communicating my problem
earlier. As you pointed out the problem doesn't occur when the call to
the function is made from a CometActor.
In my case too, it was not a CometActor. Rather, it was the LiftActor.
(Sometime back we had different CometActors for different feature
threads, now we have 1 single CometActor which takes care of the
display and different LiftActor threads which do the feature related
stuff. Hence the confusion on my part).
Anyways, here's the relevant code:
-
object TheVideoPlayerThread extends LiftActor
{
val threadName = "FileManager"
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info("Recursing for: " + dirName)
val files = (new java.io.File(dirName)).listFiles
def showFile1() = "AAA"
{dirName}
{files.flatMap(f => {
if (f.isDirectory())
{
Log.info("Directory: " + f.toString)
listFilesInDir(f.toString)
}
else
{
Log.info("Regular file: " + f.getName)
{SHtml.link("", () => showFile1,
Text(f.getName)) } //This is the line causing the
issue
}
}
)}
}
protected def messageHandler = {
case FileManagerMsg(someMsg) =>
{
var fileList = listFilesInDir("/Users/soumik/Movies/")
Log.info("OUTPUT: " + fileList)
}
}
-
(I've omitted some of code in this thread which are not related to the
file listing functionality.)
The problem I see is as soon as I encounter the first file in the
directory specified, it prints - "Regular file: ", but after
that I don't see the log - "OUTPUT - ...". The function never returns.
Same function works perfectly in a CometActor and I see the nodeseq of
files in tags to be rendered.
Also in the same method in my LiftActor object, if I replace the line:
{SHtml.link("", () => showFile1, Text(f.getName)) }
with just
{f.getName}
I see the function return and print the log "OUTPUT - .." with the
list of all the files as entries.
I'm sorry I couldn't give a more concrete example which you could run
and reproduce the issue. I'll appreciate if you could just give this
function a try from any LiftActor object and check the output on
console.
Also, I'm still on 1.1-SNAPSHOT. I've a fairly big codebase, so not
sure if migrating to 2.0-SNAPSHOT will cause any other issues,
particularly with jquery(i'm using lot of jquery plugins dependent on
1.3.2, not sure if all of them works nicely with 1.4).
Thanks,
Soumik
On Feb 15, 11:22 pm, Marius wrote:
> I don't think the cause is in SHtml. I tried your code from a snippet
> and from a Comet actor and there was no lock whatsoever. But I did use
> lift 2.0-SNAPSHOT. can you try with 2.0-SNAPSHOT ?
>
> Br's,
> Marius
>
> On 15 feb., 15:20, soumik wrote:
>
> > Hi,
> > I'm using 1.1-SNAPSHOT lift release and am experiencing strange
> > behaviour when trying to output a NodeSeq formed from nested NodeSeq &
> > Scala code.
>
> > To highlight the problem let me show you the code I'm trying to
> > execute:
> > ---
> > def listFilesInDir(dirName:String): NodeSeq =
> > {
> > Log.info("Recursing for: " + dirName)
> > val files = (new java.io.File(dirName)).listFiles
>
> > def playFile1() = "AAA"
>
> > {dirName}
> >
> > {files.flatMap(f => {
> > if (f.isDirectory())
> > {
> > Log.info("Directory: " + f.toString)
> > listFilesInDir(f.toString)
> >
> > }
> > else
> > {
> > Log.info("Regular file: " + f.getName)
> >
> > {SHtml.link("", () => playFile1,
> > Text("Something")) } /* Problem in this line */
> >
> > }
> > }
> > )}
> >
> > ---
> > I'm trying to render the output of the above function in a comet
> > actor. The problem i see is with the highlighted line of code. When
> > the execution reaches this line of code, it gets stuck; the function
> > doesn't return and i don't ge
[Lift] Error processing SHtml functions withing nested NodeSeq/Scala code
Hi,
I'm using 1.1-SNAPSHOT lift release and am experiencing strange
behaviour when trying to output a NodeSeq formed from nested NodeSeq &
Scala code.
To highlight the problem let me show you the code I'm trying to
execute:
---
def listFilesInDir(dirName:String): NodeSeq =
{
Log.info("Recursing for: " + dirName)
val files = (new java.io.File(dirName)).listFiles
def playFile1() = "AAA"
{dirName}
{files.flatMap(f => {
if (f.isDirectory())
{
Log.info("Directory: " + f.toString)
listFilesInDir(f.toString)
}
else
{
Log.info("Regular file: " + f.getName)
{SHtml.link("", () => playFile1,
Text("Something")) } /* Problem in this line */
}
}
)}
---
I'm trying to render the output of the above function in a comet
actor. The problem i see is with the highlighted line of code. When
the execution reaches this line of code, it gets stuck; the function
doesn't return and i don't get a NodeSeq to render.
However, for some reason if I change the highlighted line of code to
say:
{f.getName}
I get the proper NodeSeq which lists all the files in the directory.
Seems to me that the SHtml class functions are encountering an error
scenario(frm which its unable to recover). I've tried a couple of
SHtml functions(a, text, link, submit etc.) all of them show the same
problem, but if I use some other scala code it executes properly.
Could anyone look into this and verify whether this is indeed a bug
with the SHtml functions?
Thanks,
Soumik
--
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: Comet long polls turning to fast short polls
I was able to figure out what the problem was.
The main page comet actor had a jquery plugin (gritter - displays
growl-like alerts), which makes ajax calls.
This plugin was the one which was causing the problem. When I removed
call to the jquery function for the plugin, the problem was not seen.
Thanks guys for your quick responses.
Soumik
On Nov 24, 2:05 pm, Timothy Perrett wrote:
> Are you using ActorPing or something? Can you post your actor code?
>
> Cheers, Tim
>
> On 24 Nov 2009, at 08:50, soumik wrote:
>
> > Thanks for the quick response, Marius.
>
> > I am not running the browser with multiple tabs/windows. Its just 1
> > firefox window with 1 tab pane.
> > And I see this happening.
>
> > About the part where I said, navigating away from the page doesn't
> > affect the ajax polls, let me clarify a little.
> > I have a page where I have 1 comet Actor for just general updates
> > (related to my application) and another page with 2 comet actors - the
> > general comet actor and a twitter-update comet actor. When I see this
> > issue with the twitter page, if I go back to the main page with 1
> > comet actor, the short ajax polls don't seem to cease. Also the comet
> > actor id on both the pages(seen on the console performing ajax polls)
> > seem to be the same.
>
> > In the page source i've attached in my previous post, the comet actor,
> > 1oz5aj38jk1he, as seen here:
> >
>
> > seems to be the one making those short ajax polls.
>
> > Also, is there any way by which we can check the destination of the
> > ajax requests??
>
> > On Nov 24, 12:51 pm, Marius wrote:
> >> Are you using multiple tabs with the same page? or even having
> >> multiple instances of the same browser having the same page opened in
> >> the same time? If so don't, because the Ajax connections are shared
> >> between tabs and even different instances of the same browsers. Try
> >> using different browsers opening the same page if you want to test it.
>
> >> After we get the session from SessionMaster we send a BreakOut message
> >> which makes the ContinuationActors for this session to Unlisten from
> >> CometActor. Consequently the the Comet connection is interrupted by
> >> sending a response to the client. This mechanism is intended to avoid
> >> Ajax connections starvation from browsers as browsers are quite
> >> limited there.
>
> >> Having multiple Comets in the same page supposed to use a single Ajax
> >> connection not more.
>
> >> What do you mean by : "The fast short polls seem to persist even when
> >> I'm navigating away from the page. ". Who would send the comet request
> >> once you're not anymore on that page?
>
> >> Br's,
> >> Marius
>
> >> On Nov 24, 8:42 am, soumik wrote:
>
> >>> 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:
> >>> ---
> >>>
>
> >>> >>> id="F1063843174138UI2" style="display: inline">
> >>>
> >>>
> >>>
> >>> // <![CDATA[
> >>> /* JSON Func TwitterExp $$ F1063843174141L51 */function
> >>> F1063843174141L51(obj) {liftAjax.lift_ajaxHandler
> >>> ('F1063843174141L51='+ encodeURIComponent(JSON.stringify(obj)),
> >>> null,null);}
> >>> // ]]>
>
> >>>
> >>> // <![CDATA[
> >>> var destroy_F1063843174138UI2 = function() {}
> >>> // ]]>
> >>>
>
> >>>
> >>>
>
> >>> >>> id="F10638431741235UP" style="display: inline">
>
> >>>
> >>> // <![CDATA[
> >>> /* JSON Func defaultActor $$ F1063843174126YCZ */function
> >>> F1063843174126YCZ(ob
[Lift] Re: Comet long polls turning to fast short polls
Thanks for the quick response, Marius.
I am not running the browser with multiple tabs/windows. Its just 1
firefox window with 1 tab pane.
And I see this happening.
About the part where I said, navigating away from the page doesn't
affect the ajax polls, let me clarify a little.
I have a page where I have 1 comet Actor for just general updates
(related to my application) and another page with 2 comet actors - the
general comet actor and a twitter-update comet actor. When I see this
issue with the twitter page, if I go back to the main page with 1
comet actor, the short ajax polls don't seem to cease. Also the comet
actor id on both the pages(seen on the console performing ajax polls)
seem to be the same.
In the page source i've attached in my previous post, the comet actor,
1oz5aj38jk1he, as seen here:
seems to be the one making those short ajax polls.
Also, is there any way by which we can check the destination of the
ajax requests??
On Nov 24, 12:51 pm, Marius wrote:
> Are you using multiple tabs with the same page? or even having
> multiple instances of the same browser having the same page opened in
> the same time? If so don't, because the Ajax connections are shared
> between tabs and even different instances of the same browsers. Try
> using different browsers opening the same page if you want to test it.
>
> After we get the session from SessionMaster we send a BreakOut message
> which makes the ContinuationActors for this session to Unlisten from
> CometActor. Consequently the the Comet connection is interrupted by
> sending a response to the client. This mechanism is intended to avoid
> Ajax connections starvation from browsers as browsers are quite
> limited there.
>
> Having multiple Comets in the same page supposed to use a single Ajax
> connection not more.
>
> What do you mean by : "The fast short polls seem to persist even when
> I'm navigating away from the page. ". Who would send the comet request
> once you're not anymore on that page?
>
> Br's,
> Marius
>
> On Nov 24, 8:42 am, soumik wrote:
>
> > 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:
> > ---
> >
>
> > > id="F1063843174138UI2" style="display: inline">
> >
> >
> >
> > // <![CDATA[
> > /* JSON Func TwitterExp $$ F1063843174141L51 */function
> > F1063843174141L51(obj) {liftAjax.lift_ajaxHandler
> > ('F1063843174141L51='+ encodeURIComponent(JSON.stringify(obj)),
> > null,null);}
> > // ]]>
>
> >
> > // <![CDATA[
> > var destroy_F1063843174138UI2 = function() {}
> > // ]]>
> >
>
> >
> >
>
> > > id="F10638431741235UP" style="display: inline">
>
> >
> > // <![CDATA[
> > /* JSON Func defaultActor $$ F1063843174126YCZ */function
> > F1063843174126YCZ(obj) {liftAjax.lift_ajaxHandler
> > ('F1063843174126YCZ='+ encodeURIComponent(JSON.stringify(obj)),
> > null,null);}
> > // ]]>
>
> >
> > // <![CDATA[
> > var destroy_F10638431741235UP = function() {}
> > // ]]>
> >
>
> > </
> > script>
> > <script type="text/javascript" src="/comet_request/1oz5aj38jk1he/
> > cometAjax.js">
>
> >
> > // <![CDATA[
> > var lift_toWatch = {"F1063843174138UI2": 1063843174140 ,
> > "F10638431741235UP": 1063843174142};
> > // ]]>
> >
> >
> > // <![CDATA[
>
> > var lift_page = "F1063843174137HVV";
> > // ]]>
>
> >
> > ---
--
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: Comet long polls turning to fast short polls
Thanks for the quick response, Marius.
I am not running the browser with multiple tabs/windows. Its just 1
firefox window with 1 tab pane.
And I see this happening.
About the part where I said, navigating away from the page doesn't
affect the ajax polls, let me clarify a little.
I have a page where I have 1 comet Actor for just general updates
(related to my application) and another page with 2 comet actors - the
general comet actor and a twitter-update comet actor. When I see this
issue with the twitter page, if I go back to the main page with 1
comet actor, the short ajax polls don't seem to cease. Also the comet
actor id on both the pages(seen on the console performing ajax polls)
seem to be the same.
In the page source i've attached in my previous post, the comet actor,
1oz5aj38jk1he, as seen here:
seems to be the one making those short ajax polls.
Also, is there any way by which we can check the destination of the
ajax requests??
On Nov 24, 12:51 pm, Marius wrote:
> Are you using multiple tabs with the same page? or even having
> multiple instances of the same browser having the same page opened in
> the same time? If so don't, because the Ajax connections are shared
> between tabs and even different instances of the same browsers. Try
> using different browsers opening the same page if you want to test it.
>
> After we get the session from SessionMaster we send a BreakOut message
> which makes the ContinuationActors for this session to Unlisten from
> CometActor. Consequently the the Comet connection is interrupted by
> sending a response to the client. This mechanism is intended to avoid
> Ajax connections starvation from browsers as browsers are quite
> limited there.
>
> Having multiple Comets in the same page supposed to use a single Ajax
> connection not more.
>
> What do you mean by : "The fast short polls seem to persist even when
> I'm navigating away from the page. ". Who would send the comet request
> once you're not anymore on that page?
>
> Br's,
> Marius
>
> On Nov 24, 8:42 am, soumik wrote:
>
> > 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:
> > ---
> >
>
> > > id="F1063843174138UI2" style="display: inline">
> >
> >
> >
> > // <![CDATA[
> > /* JSON Func TwitterExp $$ F1063843174141L51 */function
> > F1063843174141L51(obj) {liftAjax.lift_ajaxHandler
> > ('F1063843174141L51='+ encodeURIComponent(JSON.stringify(obj)),
> > null,null);}
> > // ]]>
>
> >
> > // <![CDATA[
> > var destroy_F1063843174138UI2 = function() {}
> > // ]]>
> >
>
> >
> >
>
> > > id="F10638431741235UP" style="display: inline">
>
> >
> > // <![CDATA[
> > /* JSON Func defaultActor $$ F1063843174126YCZ */function
> > F1063843174126YCZ(obj) {liftAjax.lift_ajaxHandler
> > ('F1063843174126YCZ='+ encodeURIComponent(JSON.stringify(obj)),
> > null,null);}
> > // ]]>
>
> >
> > // <![CDATA[
> > var destroy_F10638431741235UP = function() {}
> > // ]]>
> >
>
> > </
> > script>
> > <script type="text/javascript" src="/comet_request/1oz5aj38jk1he/
> > cometAjax.js">
>
> >
> > // <![CDATA[
> > var lift_toWatch = {"F1063843174138UI2": 1063843174140 ,
> > "F10638431741235UP": 1063843174142};
> > // ]]>
> >
> >
> > // <![CDATA[
>
> > var lift_page = "F1063843174137HVV";
> > // ]]>
>
> >
> > ---
--
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] Re: **Breaking Changes** **README** **Important**
Hi, I've a few question regarding the changes made. - Firstly, with the changes made, how do I have a method which can now accept both scala Actor as well as a CometActor?? Prior to the changes, I had a function "def registerActor(act: Actor) which could handle both scala Actor as well as CometActor,; now if I change this to "def registerActor(act: GenericActor)" it throws compilation error asking to a type to be specified for the GenericActor. What change would you suggest to have my code compile? - Secondly, I also get compilation error for calling scheduleAtFixedRate method on ActorPing. Says no such method. Has this method been deprecated and if so, what is the method I should be calling instead? Thanks, Soumik On Oct 22, 10:35 am, Indrajit Raychaudhuri wrote: > Code change should suffice. > > pom.xml updates won't be necessary since lift-util has lift-common as > dependency and your application (which must be having lift-util as > dependency) would resolve the lift-common dependency transitively. > > Cheers, Indrajit > > On 22/10/09 10:57 AM, Jonathan Ferguson wrote: > > > Do we need to update our pom's or should it be code changes only ? > > > Cheers > > > Jono > > > 2009/10/22 David Pollak > <mailto:feeder.of.the.be...@gmail.com>> > > > Folks, > > > As the title of this email indicates, there are breaking changes in > > Lift that just got pushed to master. > > > We've migrated from Scala Actors to Lift Actors and included a > > series of traits that allow Lift to use its own Actors or Akka > > Actors (or anything else that implements that interface.) > > > The two big changes that you'll have to work with are: > > > * Box/Full/Empty/Failure was moved from the > > lift-util/net.liftweb.util package to the > > lift-common/net.liftweb.common package. The reason for this > > change is that we're going to make the lift-common package a > > more generic, non-web related package. It currently contains > > Box and Actor, but in the future may contain other interfaces > > that will have concrete implementations outside of Lift. We > > moved Box there because Box is richer than Scala's Option > > class and being able to carry Exceptions around in a Box while > > still being able to map/flatMap/foreach over a Box (these are > > unavailable for Scala's Either). Some we're going to actively > > promote using Box as a replacement for Option in all Scala > > apps. What this means for you is you have to import > > net.liftweb.common._ in any file that you also import > > net.liftweb.util.? > > * Lift no longer support Scala Actors for Comet Actors. The > > GenericActor API offers pretty much the same client interface > > to Lift's Actors, so ! and !? work the same way. However, > > there's no link, self, start or exit methods. > > > Please do an "mvn -U clean install" on your code and run it against > > the new code. If you have any Comet-related weirdness, please > > report it immediately. We're planning M7 in 2 weeks, so we've got > > lots of time to iron any kinks out of this code. > > > Thanks, > > > David > > > -- > > Lift, the simply functional web frameworkhttp://liftweb.net > > Beginning Scalahttp://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 -~--~~~~--~~--~--~---
