You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by David Pollak <fe...@gmail.com> on 2009/07/20 20:05:24 UTC
Re: [Lift] JSON handler doesn't respond
On Sun, Jul 19, 2009 at 3:20 AM, Vassil Dichev <vd...@gmail.com> wrote:
>
> Hello folks,
>
> I've gathered some information on the recent problems where ESME was
> hanging.
> The problem seems to be that the json handler, generated with
> S.buildJsonFunc, sometimes stops working after the browser has been
> open for awhile. Not all user sessions stop working though (I'm
> currently trying with 3 open sessions).
>
> I've also tried calling the generated JavaScript function manually
> from each of the browsers and it confirms the fact that for some
> sessions the handler is not invoked. I execute the function e.g. in
> the url bar like this:
>
> javascript:F6669067195625JG({'command': 'post', 'params':{'msg':
> document.getElementById('textdude').value, 'tags':
> document.getElementById('tagdude').value, 'access_pool':
> document.getElementById('access_pool').value, 'reply-to':
> currentConvNumber}});
>
> As a result, in the sessions where things don't work the pattern
> matching on JsonCmd is not reached at all, whereas "case JsonCmd"
> matches fine where it works.
>
> Any ideas on how to debug this? Has anyone experienced the same problem?
Vassil,
I have not seen problems like this.
The debugging tools I user are Firebug on the client and the catch-all
pattern match on the server.
If you can create a reproducible case for me, I'll look into it (although
I'm slammed this week.)
Thanks,
David
>
>
> Greetings,
> Vassil
>
> P.S. We are running Lift version 1.1-SNAPSHOT. I experienced the
> problem under OpenJDK 6, but it occurs with Sun's JDK 6 too.
>
> --~--~---------~--~----~------------~-------~--~----~
> 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+unsubscribe@googlegroups.com<li...@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
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Ethan Jewett <es...@gmail.com>.
I'm trying to reproduce it now (waiting). I was able to verify that if
you're running Firebug in FF3.5, it keeps a record of all the headers of all
requests since you loaded the page, so it's pretty easy to check what the
cookie and session ID looked like at the beginning and compare it to what it
looks like at the end.
Ethan
On Tue, Sep 1, 2009 at 12:38 PM, Vassil Dichev <vd...@apache.org> wrote:
> I cannot reproduce the problem locally, so probably we don't need to
> do any more debugging. Anyway, you can read on if you want my detailed
> explanations of the problem.
>
> > I don't see that this had been mentioned before. Definitely makes it
> sound
>
> Well, you can't have multiple users logged in a single browser
> session. When you try to open another browser on the same machine, it
> sees the open port of the existing firefox instance, so it just sends
> a command to this existing instance to open a new window. Like you
> said- one browser, one cookie.
>
> >
> > Do you get the same issue intermittently when you are logged in as only
> one
> > user in a single browser?
>
> Yes. As I mentioned, Dick and Anne have also reproduced the problem,
> and they definitely haven't played with multiple Firefox instances.
>
> > Just trying to understand the problem...
>
> Me too. I'm not saying that this *is* the cause of the problem. David
> asked what I do to reproduce the problem. Since I've already mentioned
> that I'm using Firefox before, I decided to provide more details on
> the last scenario when I experienced this problem. This was the case
> when I was testing "resends", where you need to have 3 users, where B
> follows A, and C follows B but not A. I doubt this is relevant, but
> decided to share it, since, again, David is trying to reproduce the
> problem.
>
> >>
> >> I was thinking along the lines of Chrome doing something so that the
> >> session doesn't expire as easily.
> >>
> >
> > I'm not sure what Chrome could be doing differently. As far as I know
> from
> > my API hacking, the lift session is just stored as a cookie, which is
> then
> > sent in the header of every subsequent request to the site. Either the
> > cookie is being sent or it's not. If it is being sent but not recognized
> on
> > the Lift side, then that would be an ESME issue. If it is not being sent
> > correctly, then that is a browser issue.
>
> I'm not sure, but I think long polling has some specifics for
> different browsers. If for some reason the session expires more easily
> on one browser, but not on the other, this could be relevant. Since
> long polling relies on renewing the request after a timeout, that
> could make the browser keep the session without expiring it. Of
> course, that's just hypothetical.
>
> At least, I'm trying to reproduce the problem with Chrome on the old
> Stax instance and so far I cannot, and I can with Firefox.
>
> Vassil
>
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
I cannot reproduce the problem locally, so probably we don't need to
do any more debugging. Anyway, you can read on if you want my detailed
explanations of the problem.
> I don't see that this had been mentioned before. Definitely makes it sound
Well, you can't have multiple users logged in a single browser
session. When you try to open another browser on the same machine, it
sees the open port of the existing firefox instance, so it just sends
a command to this existing instance to open a new window. Like you
said- one browser, one cookie.
>
> Do you get the same issue intermittently when you are logged in as only one
> user in a single browser?
Yes. As I mentioned, Dick and Anne have also reproduced the problem,
and they definitely haven't played with multiple Firefox instances.
> Just trying to understand the problem...
Me too. I'm not saying that this *is* the cause of the problem. David
asked what I do to reproduce the problem. Since I've already mentioned
that I'm using Firefox before, I decided to provide more details on
the last scenario when I experienced this problem. This was the case
when I was testing "resends", where you need to have 3 users, where B
follows A, and C follows B but not A. I doubt this is relevant, but
decided to share it, since, again, David is trying to reproduce the
problem.
>>
>> I was thinking along the lines of Chrome doing something so that the
>> session doesn't expire as easily.
>>
>
> I'm not sure what Chrome could be doing differently. As far as I know from
> my API hacking, the lift session is just stored as a cookie, which is then
> sent in the header of every subsequent request to the site. Either the
> cookie is being sent or it's not. If it is being sent but not recognized on
> the Lift side, then that would be an ESME issue. If it is not being sent
> correctly, then that is a browser issue.
I'm not sure, but I think long polling has some specifics for
different browsers. If for some reason the session expires more easily
on one browser, but not on the other, this could be relevant. Since
long polling relies on renewing the request after a timeout, that
could make the browser keep the session without expiring it. Of
course, that's just hypothetical.
At least, I'm trying to reproduce the problem with Chrome on the old
Stax instance and so far I cannot, and I can with Firefox.
Vassil
Re: [Lift] JSON handler doesn't respond
Posted by Ethan Jewett <es...@gmail.com>.
On Tue, Sep 1, 2009 at 10:42 AM, Vassil Dichev <vd...@apache.org> wrote:
>
>
> Err, no. Of course I open the three browser sessions with three
> different profiles:
>
> firefox -no-remote -P test1
> firefox -no-remote -P test2
> etc.
>
I don't see that this had been mentioned before. Definitely makes it sound
like less of a browser issue, though I don't understand why a user session
would expire more quickly when multiple browsers are open than if not.
Do you get the same issue intermittently when you are logged in as only one
user in a single browser?
Just trying to understand the problem...
>
> I was thinking along the lines of Chrome doing something so that the
> session doesn't expire as easily.
>
I'm not sure what Chrome could be doing differently. As far as I know from
my API hacking, the lift session is just stored as a cookie, which is then
sent in the header of every subsequent request to the site. Either the
cookie is being sent or it's not. If it is being sent but not recognized on
the Lift side, then that would be an ESME issue. If it is not being sent
correctly, then that is a browser issue.
Can you verify if Firefox is sending a "Cookie:" value in the header during
your initial setup, and then whether it is sending the same "Cookie:" value
once the sessions start failing?
Ethan
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
> Sounds like this might be a browser bug (or perhaps "working as designed" in
> SAP parlance). Unless I'm mistaken, the user is identified by a session
> cookie. Cookies are stored in some manner by the browser, usually with the
> domain as the key. It sounds like at least in Firefox, the cookie for 2 of
> the 3 user sessions is being replaced at some point by the cookie of the 3rd
> user session, resulting in an inability to post or read messages with the
> users who are now using the wrong session cookie.
> Chrome has a more sandboxed model than Firefox, so it probably keeps the
> cookies for a given window or tab local to that window until the window is
> closed. Interesting question for Chrome: Open three windows with three
> different users. Close each window. Open ESME again in Chrome. Which user is
> logged in? I'd bet it's the user that was logged into the last of the three
> windows that was closed.
> If this is what is happening, then I doubt that there is much that can be
> done on the Lift side of the house.
Err, no. Of course I open the three browser sessions with three
different profiles:
firefox -no-remote -P test1
firefox -no-remote -P test2
etc.
Note the "-no-remote" parameter, it means that a new window does not
connect to the existing Firefox instance.
I was thinking along the lines of Chrome doing something so that the
session doesn't expire as easily.
Re: [Lift] JSON handler doesn't respond
Posted by Ethan Jewett <es...@gmail.com>.
Sounds like this might be a browser bug (or perhaps "working as designed" in
SAP parlance). Unless I'm mistaken, the user is identified by a session
cookie. Cookies are stored in some manner by the browser, usually with the
domain as the key. It sounds like at least in Firefox, the cookie for 2 of
the 3 user sessions is being replaced at some point by the cookie of the 3rd
user session, resulting in an inability to post or read messages with the
users who are now using the wrong session cookie.
Chrome has a more sandboxed model than Firefox, so it probably keeps the
cookies for a given window or tab local to that window until the window is
closed. Interesting question for Chrome: Open three windows with three
different users. Close each window. Open ESME again in Chrome. Which user is
logged in? I'd bet it's the user that was logged into the last of the three
windows that was closed.
If this is what is happening, then I doubt that there is much that can be
done on the Lift side of the house.
Ethan
On Tue, Sep 1, 2009 at 1:42 AM, Anne Kathrine Petterøe <yo...@gmail.com>wrote:
> I only use Firefox as a browser, and have had this error several times.
> So maybe it is the browser making a difference?
>
> /Anne
>
>
> On 01 Sep, 2009, at 06:51 , Vassil Dichev wrote:
>
> I built Lift locally and put dumps in LiftSession's cleanupUnseenFuncs
>> and updateFuncByOwner. So far I cannot reproduce the problem.
>>
>> <snapshot>
>>>> <buildNumber>1724</buildNumber>
>>>> </snapshot>
>>>> <lastUpdated>20090828152733</lastUpdated>
>>>>
>>>> Do I have the correct updated jar?
>>>>
>>>>
>>> I have no idea.
>>>
>>
>> Since you've mentioned in the past that you're using hudson for
>> building the lift jars before they're uploaded to the public maven
>> repo, I was hoping that one can associate the build number or date
>> with the specific commit.
>>
>> Can you specify the exact steps to reproduce the problem? I have really,
>>> really tried to make it happen and can't. :-(
>>>
>>
>> I'm using Firefox, on different versions of Linux. I have three users
>> (e.g. a follows b, b follows c) and I open up the ESME main page in a
>> separate browser for each user. I post a message for each to make sure
>> it works. I leave the browsers open and after a while I check again
>> whether I can send a message with all users. Usually half an hour is
>> enough for 2-3 of the users to block. The problem can always be
>> reproduced on the Stax instance, too, by just leaving a session open-
>> Dick can confirm that it regularly happens to him, too. Maybe he can
>> add some details on how he reproduces it.
>>
>> Let's see if the fix works this time. If not, the only difference I
>> can think of is the browser- you could be using Chrome or Safari. I've
>> tried reproducing with Chrome in the past once or twice and couldn't.
>>
>> Vassil
>>
>
>
Re: [Lift] JSON handler doesn't respond
Posted by Anne Kathrine Petterøe <yo...@gmail.com>.
I only use Firefox as a browser, and have had this error several times.
So maybe it is the browser making a difference?
/Anne
On 01 Sep, 2009, at 06:51 , Vassil Dichev wrote:
> I built Lift locally and put dumps in LiftSession's cleanupUnseenFuncs
> and updateFuncByOwner. So far I cannot reproduce the problem.
>
>>> <snapshot>
>>> <buildNumber>1724</buildNumber>
>>> </snapshot>
>>> <lastUpdated>20090828152733</lastUpdated>
>>>
>>> Do I have the correct updated jar?
>>>
>>
>> I have no idea.
>
> Since you've mentioned in the past that you're using hudson for
> building the lift jars before they're uploaded to the public maven
> repo, I was hoping that one can associate the build number or date
> with the specific commit.
>
>> Can you specify the exact steps to reproduce the problem? I have
>> really,
>> really tried to make it happen and can't. :-(
>
> I'm using Firefox, on different versions of Linux. I have three users
> (e.g. a follows b, b follows c) and I open up the ESME main page in a
> separate browser for each user. I post a message for each to make sure
> it works. I leave the browsers open and after a while I check again
> whether I can send a message with all users. Usually half an hour is
> enough for 2-3 of the users to block. The problem can always be
> reproduced on the Stax instance, too, by just leaving a session open-
> Dick can confirm that it regularly happens to him, too. Maybe he can
> add some details on how he reproduces it.
>
> Let's see if the fix works this time. If not, the only difference I
> can think of is the browser- you could be using Chrome or Safari. I've
> tried reproducing with Chrome in the past once or twice and couldn't.
>
> Vassil
JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
On Mon, Aug 31, 2009 at 9:51 PM, Vassil Dichev <vd...@apache.org> wrote:
> I built Lift locally and put dumps in LiftSession's cleanupUnseenFuncs
> and updateFuncByOwner. So far I cannot reproduce the problem.
>
> >> <snapshot>
> >> <buildNumber>1724</buildNumber>
> >> </snapshot>
> >> <lastUpdated>20090828152733</lastUpdated>
> >>
> >> Do I have the correct updated jar?
> >>
> >
> > I have no idea.
>
> Since you've mentioned in the past that you're using hudson for
> building the lift jars before they're uploaded to the public maven
> repo, I was hoping that one can associate the build number or date
> with the specific commit.
>
There's an open request to associate the Git hash with the build, but
apparently Maven cannot yet do that.
In terms of build date, it's available via LiftRules.liftBuildDate
>
> > Can you specify the exact steps to reproduce the problem? I have really,
> > really tried to make it happen and can't. :-(
>
> I'm using Firefox, on different versions of Linux. I have three users
> (e.g. a follows b, b follows c) and I open up the ESME main page in a
> separate browser for each user. I post a message for each to make sure
> it works. I leave the browsers open and after a while I check again
> whether I can send a message with all users. Usually half an hour is
> enough for 2-3 of the users to block. The problem can always be
> reproduced on the Stax instance, too, by just leaving a session open-
> Dick can confirm that it regularly happens to him, too. Maybe he can
> add some details on how he reproduces it.
>
> Let's see if the fix works this time. If not, the only difference I
> can think of is the browser- you could be using Chrome or Safari. I've
> tried reproducing with Chrome in the past once or twice and couldn't.
>
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
I built Lift locally and put dumps in LiftSession's cleanupUnseenFuncs
and updateFuncByOwner. So far I cannot reproduce the problem.
>> <snapshot>
>> <buildNumber>1724</buildNumber>
>> </snapshot>
>> <lastUpdated>20090828152733</lastUpdated>
>>
>> Do I have the correct updated jar?
>>
>
> I have no idea.
Since you've mentioned in the past that you're using hudson for
building the lift jars before they're uploaded to the public maven
repo, I was hoping that one can associate the build number or date
with the specific commit.
> Can you specify the exact steps to reproduce the problem? I have really,
> really tried to make it happen and can't. :-(
I'm using Firefox, on different versions of Linux. I have three users
(e.g. a follows b, b follows c) and I open up the ESME main page in a
separate browser for each user. I post a message for each to make sure
it works. I leave the browsers open and after a while I check again
whether I can send a message with all users. Usually half an hour is
enough for 2-3 of the users to block. The problem can always be
reproduced on the Stax instance, too, by just leaving a session open-
Dick can confirm that it regularly happens to him, too. Maybe he can
add some details on how he reproduces it.
Let's see if the fix works this time. If not, the only difference I
can think of is the browser- you could be using Chrome or Safari. I've
tried reproducing with Chrome in the past once or twice and couldn't.
Vassil
Re: [Lift] JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
On Sun, Aug 30, 2009 at 9:50 PM, Vassil Dichev <vd...@apache.org> wrote:
> > Okay... I think I found the problem and am fixing it in Lift.
>
> Unfortunately, I can still reproduce the problem... Is the fix in this
> commit?
>
Yes.
>
>
> http://github.com/dpp/liftweb/commit/5582e28be1b3e627a921575e8682dfe01587b8c7
>
> My local repo version reports this:
>
> <snapshot>
> <buildNumber>1724</buildNumber>
> </snapshot>
> <lastUpdated>20090828152733</lastUpdated>
>
> Do I have the correct updated jar?
>
I have no idea.
Can you specify the exact steps to reproduce the problem? I have really,
really tried to make it happen and can't. :-(
>
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
> Okay... I think I found the problem and am fixing it in Lift.
Unfortunately, I can still reproduce the problem... Is the fix in this commit?
http://github.com/dpp/liftweb/commit/5582e28be1b3e627a921575e8682dfe01587b8c7
My local repo version reports this:
<snapshot>
<buildNumber>1724</buildNumber>
</snapshot>
<lastUpdated>20090828152733</lastUpdated>
Do I have the correct updated jar?
Vassil
Re: [Lift] JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
Okay... I think I found the problem and am fixing it in Lift.
On Sun, Aug 16, 2009 at 4:16 PM, Vassil Dichev <vd...@apache.org> wrote:
> > I'm not sure this will help. I really need the steps to reproduce it
> > because I'll need to reproduce it again and again to insert debug info to
> > see why it's happening. Reproduction steps (including perhaps browser
> > versions, OS versions, etc.) would be a lot more valuable.
>
> My intention was to create an environment, where one can start
> debugging right away. The browser and OS versions are part of the
> virtual image.
>
> I realized VirtualBox images are not at all convenient, so I tried to
> debug myself. If it's what I think it is, it's embarrassing I didn't
> see it before. I had a hunch that it's related to an expiring session.
> Sure enough:
>
> object JsonPoster extends SessionVar(S.buildJsonFunc{
> ...
>
> I rewrote to extend JsonHandler, where the JsonFunc seems to be
> rebuilt when the session expires. Even if it doesn't solve the bug, it
> at least improves readability.
>
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
> I'm not sure this will help. I really need the steps to reproduce it
> because I'll need to reproduce it again and again to insert debug info to
> see why it's happening. Reproduction steps (including perhaps browser
> versions, OS versions, etc.) would be a lot more valuable.
My intention was to create an environment, where one can start
debugging right away. The browser and OS versions are part of the
virtual image.
I realized VirtualBox images are not at all convenient, so I tried to
debug myself. If it's what I think it is, it's embarrassing I didn't
see it before. I had a hunch that it's related to an expiring session.
Sure enough:
object JsonPoster extends SessionVar(S.buildJsonFunc{
...
I rewrote to extend JsonHandler, where the JsonFunc seems to be
rebuilt when the session expires. Even if it doesn't solve the bug, it
at least improves readability.
Vassil
Re: [Lift] JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
On Fri, Jul 31, 2009 at 12:17 AM, Vassil Dichev <vd...@apache.org> wrote:
> > I've been running a browser open to an esme instance for most of the
> > afternoon and it still "just works".
>
> I managed to create a VirtualBox image where reproduced the case and
> did a snapshot when ESME is already stuck.
I'm not sure this will help. I really need the steps to reproduce it
because I'll need to reproduce it again and again to insert debug info to
see why it's happening. Reproduction steps (including perhaps browser
versions, OS versions, etc.) would be a lot more valuable.
>
>
> I'm not sure what it takes to copy the disk AND snapshot to another
> machine but it seems it involves at least two files- .vdi for the disk
> and .sav for the runtime execution state. If it's too complicated it
> would be easier if I just recreate the state in a VMWare image.
>
> What is the recommended way to transfer huge temporary files like this
> in Apache? Is there a file service we can use or the way to go is to
> use one of the free file services out there?
>
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
> I've been running a browser open to an esme instance for most of the
> afternoon and it still "just works".
I managed to create a VirtualBox image where reproduced the case and
did a snapshot when ESME is already stuck.
I'm not sure what it takes to copy the disk AND snapshot to another
machine but it seems it involves at least two files- .vdi for the disk
and .sav for the runtime execution state. If it's too complicated it
would be easier if I just recreate the state in a VMWare image.
What is the recommended way to transfer huge temporary files like this
in Apache? Is there a file service we can use or the way to go is to
use one of the free file services out there?
Vassil
Re: [Lift] JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
I've been running a browser open to an esme instance for most of the
afternoon and it still "just works".
On Mon, Jul 27, 2009 at 1:29 PM, Vassil Dichev <vd...@apache.org> wrote:
> > I'll run an ESME instance for 40 minutes with the basic browser
> connection
> > and see what I can find. Scheduled for Thursday.
>
> I'm usually seeing this when I run a couple of browsers
> simultaneously. If it's still so easy to reproduce, I might try to
> create a VM image suspended at the moment I experience the problem.
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
> I'll run an ESME instance for 40 minutes with the basic browser connection
> and see what I can find. Scheduled for Thursday.
I'm usually seeing this when I run a couple of browsers
simultaneously. If it's still so easy to reproduce, I might try to
create a VM image suspended at the moment I experience the problem.
Re: [Lift] JSON handler doesn't respond
Posted by David Pollak <fe...@gmail.com>.
I'll run an ESME instance for 40 minutes with the basic browser connection
and see what I can find. Scheduled for Thursday.
On Mon, Jul 27, 2009 at 4:50 AM, Vassil Dichev <vd...@apache.org> wrote:
> >> I've gathered some information on the recent problems where ESME was
> >> hanging.
> >> The problem seems to be that the json handler, generated with
> >> S.buildJsonFunc, sometimes stops working after the browser has been
> >> open for awhile. Not all user sessions stop working though (I'm
> >> currently trying with 3 open sessions).
> >>
> >> I've also tried calling the generated JavaScript function manually
> >> from each of the browsers and it confirms the fact that for some
> >> sessions the handler is not invoked. I execute the function e.g. in
> >> the url bar like this:
> >>
> >> javascript:F6669067195625JG({'command': 'post', 'params':{'msg':
> >> document.getElementById('textdude').value, 'tags':
> >> document.getElementById('tagdude').value, 'access_pool':
> >> document.getElementById('access_pool').value, 'reply-to':
> >> currentConvNumber}});
> >>
> >> As a result, in the sessions where things don't work the pattern
> >> matching on JsonCmd is not reached at all, whereas "case JsonCmd"
> >> matches fine where it works.
> >>
> >> Any ideas on how to debug this? Has anyone experienced the same problem?
> >
> >
> > Vassil,
> >
> > I have not seen problems like this.
> >
> > The debugging tools I user are Firebug on the client and the catch-all
> > pattern match on the server.
> >
> > If you can create a reproducible case for me, I'll look into it (although
> > I'm slammed this week.)
>
> I noticed that whenever I get stuck, I managed to get post working by
> logging in and out. What was curious is that even when posting doesn't
> work, everything else works fine (but then only posting uses the json
> handler, I think).
>
> I'm using Firefox 3.0.10 and I manage to consistently reproduce the
> bug after about half an hour. I'll try other browsers to see if it's
> browser-specific.
>
> Vassil
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Re: [Lift] JSON handler doesn't respond
Posted by Vassil Dichev <vd...@apache.org>.
>> I've gathered some information on the recent problems where ESME was
>> hanging.
>> The problem seems to be that the json handler, generated with
>> S.buildJsonFunc, sometimes stops working after the browser has been
>> open for awhile. Not all user sessions stop working though (I'm
>> currently trying with 3 open sessions).
>>
>> I've also tried calling the generated JavaScript function manually
>> from each of the browsers and it confirms the fact that for some
>> sessions the handler is not invoked. I execute the function e.g. in
>> the url bar like this:
>>
>> javascript:F6669067195625JG({'command': 'post', 'params':{'msg':
>> document.getElementById('textdude').value, 'tags':
>> document.getElementById('tagdude').value, 'access_pool':
>> document.getElementById('access_pool').value, 'reply-to':
>> currentConvNumber}});
>>
>> As a result, in the sessions where things don't work the pattern
>> matching on JsonCmd is not reached at all, whereas "case JsonCmd"
>> matches fine where it works.
>>
>> Any ideas on how to debug this? Has anyone experienced the same problem?
>
>
> Vassil,
>
> I have not seen problems like this.
>
> The debugging tools I user are Firebug on the client and the catch-all
> pattern match on the server.
>
> If you can create a reproducible case for me, I'll look into it (although
> I'm slammed this week.)
I noticed that whenever I get stuck, I managed to get post working by
logging in and out. What was curious is that even when posting doesn't
work, everything else works fine (but then only posting uses the json
handler, I think).
I'm using Firefox 3.0.10 and I manage to consistently reproduce the
bug after about half an hour. I'll try other browsers to see if it's
browser-specific.
Vassil