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
On Tue, Sep 1, 2009 at 10:42 AM, Vassil Dichev vdic...@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
On Mon, Aug 31, 2009 at 9:51 PM, Vassil Dichev vdic...@apache.org wrote:
I built Lift locally and put dumps in LiftSession's cleanupUnseenFuncs
and updateFuncByOwner. So far I cannot reproduce the problem.
snapshot
buildNumber1724/buildNumber
/snapshot
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
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
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
Okay... I think I found the problem and am fixing it in Lift.
On Sun, Aug 16, 2009 at 4:16 PM, Vassil Dichev vdic...@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
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
On Fri, Jul 31, 2009 at 12:17 AM, Vassil Dichev vdic...@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'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 vdic...@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
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 vdic...@apache.org wrote:
I've gathered some information on the recent problems where ESME was
hanging.
The problem
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
On Sun, Jul 19, 2009 at 3:20 AM, Vassil Dichev vdic...@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
Hello folks,
I have 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
14 matches
Mail list logo