You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Vassil Dichev <vd...@apache.org> on 2009/09/01 06:51:38 UTC
Re: [Lift] JSON handler doesn't respond
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 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