esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: [Lift] JSON handler doesn't respond
Date Tue, 01 Sep 2009 16:38:11 GMT
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

Mime
View raw message