Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of esjewett@gmail.com designates
 209.85.220.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=SrdUMIn0TSIL2TKVNvVv+KA88bsXqyklnz4kFAAqcv3+QwbMkKL8cbx2go0WFqdadA
         kBnQjy0SLsEMISkiKy9pQxwEr4yXcT6DZ+i9n2+XKh0nQVtN7Nu/+9/iO+Z4R4IQKGFa
         NxP5GkKAdNDnvoDQoJXa/CwjIzK2AycxDV16g=
MIME-Version: 1.0
In-Reply-To: <c7fc82820909010938k7f4c4d92q158108751cb40d95@mail.gmail.com>
References: <c7fc82820907190320t35c30adbqa46649522ceee210@mail.gmail.com>
	 <cdbebedf0908271038h131e2bffpec9658601ee239d8@mail.gmail.com>
	 <c7fc82820908302150p39a4b0dfs2f291184133b71d@mail.gmail.com>
	 <cdbebedf0908310850w64a89a08o68a88cc44b17ecd2@mail.gmail.com>
	 <c7fc82820908312151o3efdc7dav297bbb6492fa529d@mail.gmail.com>
	 <E35C4D67-F346-492A-8E8C-CF49284E782F@gmail.com>
	 <68f4a0e80909010531j5381a930m2b245dfd22cc651@mail.gmail.com>
	 <c7fc82820909010742w37ac9541q22aaeccdd449de85@mail.gmail.com>
	 <68f4a0e80909010825n2036fbf7u365f4a3f20fd0012@mail.gmail.com>
	 <c7fc82820909010938k7f4c4d92q158108751cb40d95@mail.gmail.com>
Date: Tue, 1 Sep 2009 13:31:13 -0400
Message-ID: <68f4a0e80909011031h47861b26g9d4fd624aff5d978@mail.gmail.com>
Subject: Re: [Lift] JSON handler doesn't respond
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001485f723a458404d047287848e

--001485f723a458404d047287848e
Content-Type: text/plain; charset=ISO-8859-1

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 <vdichev@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
>

--001485f723a458404d047287848e--