Re: Problems with the GUI?
On Sat, Dec 05, 2009 at 07:24:00PM +0100, Henrik Sarvell wrote: I wasn't doing that and my site was subsequently visited by bots (hence the random feeling time factor that was involved) which triggered output on stderr, which I hadn't directed to a log file, which in turn somehow tripped up the redirection in picolisp, hence the strange problems I experienced. This was one of the problems. We observed it mainly while writing debug logs. Here I had mistakenly written to Henrik to redirect stderr, but forgot about stdout. After starting with the above line I haven't been able to reproduce the pro= blem. Maybe Alex can elaborate? However, there seems to have been another reason, which I believe to see also in the logs. I had seen sporadic errors in production applications (quite seldom, only every few months), which I finally believe to have traced down to two problems: - Functions which handle I/O events (wait, key, sync and listen) were not completely reentry-safe. This could give problems in the GUI if, for example, 'sync' was called internally by DB functions. - The Post/Redirect/Get mechanism in the GUI could fail, if that sequence was disturbed by another out-of-band POST caused by a browser with multiple parallel HTTP connections to the client. This happened typically if the server was too sluggish to complete the Post/Redirect/Get sequence before the next event occurred. I fixed both issues about two weeks ago in the train over the Alps from Slovenia to Bavaria. That's why I called these the alpine bugs :-) The first one was fixed by an improved internal event handling (waitFd() in src/io.c), so that nested calls to waitFd() will not wait for file/socket descriptors already handled at a higher level. The second one was repaired by introducing a sequenctial event number into the GUI protocol (passed as *Evt= argument in the URL). After that, I could not reproduce these problems any more, and also Henrik's server runs without problems since he upgraded to the new release. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Problems with the GUI?
Maybe this information will help a little. I am logged in at the
moment (ie having a proper cookie), in Firefox and the app loads
properly.
I start Galeon (a mozilla based browser) and since I don't have a
cookie there I get the login form, however upon submitting it I'm not
redirected to /@desktop but to
:46953/402748303615582...@start?*menu=3d+0*Tab=3D+1*ID=3D
When I subsequently try to go to @desktop manually, I get the redirect
headers in the result which means (usrQuit) was called:
(de desktop (Uid)
(rss-html
(if (; (usrQuit) feeds)
(script loadPopularWords('getPopularWords', 0, 'replace');)
(prin Import some stuff and you will see something here.
(de usrQuit ()
(let Usr (getUsr)
(unless Usr (redir @logout)) Usr))
However this is what I get in the content area:
HTTP/1.0 303 See Other
Server: PicoLisp
Location: http://vizreader.com:80/@logout
Content-Type: text/html
Import some stuff and you will see something here.
This is the headers and the error message so I suppose the redirect
called by (usrQuit) isn't working properly.
Meanwhile I'm able to use the application properly in Firefox where I
do have a cookie, I think I'm going to try to investigate a little by
doing a redirect in (start), then I would know if the problem appears
with (redirect) even though I have a cookie.
The picolisp I'm using is a 32bit version compiled on a 64bit machine,
I hope this doesn't have anything to do with it.
/Henrik
On Sun, Nov 29, 2009 at 5:30 PM, Alexander Burger a...@software-lab.de wro=
te:
On Sun, Nov 29, 2009 at 10:40:05AM +0100, Henrik Sarvell wrote:
Yes the (patch _htHead '(format (car @H)) 0) line didn't help in the end=
:(
OK, so we know at least that it is not a HTTP/1.1 problem.
1.) Started it and tried to break it by logging out and in a few times
from different browsers.
2.) Went home a few hours later and tried from home and got it right awa=
y.
Could it be that it has to do with some cookie timeout, or cookie vs.
client-IP mismatch? If it is not a race condition or some other
heisenbug, you should try to trace it down, to find out exactly where
things go wrong. I would start with -traceAll with stderr redirected to
a file like
=A0 ./dbg login-test/main.l-- -traceAll -g 2errlog
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Problems with the GUI?
Hi Henrik, Still same problem when I tried from home today, despite the patch, You mean only the patch of '_htHead', or also fixing the described bug? Unfortunately, I cannot debug this here, as I can't reproduce the problem. what do we do? Did you take a look at my non-GUI example, could it be a way forward for me? I do not think that this makes a fundamental difference. It is just wild guessing as long as we don't find the reason of the problems. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Problems with the GUI?
Hi Henrik, 2.) Subsequent AJAX calls are using a relative path and I don't want to hardcode absolute paths in the JS, hence they won't work and the application fails since it relies on them. How paths are represented in URLs does not depend on the framework, but on the way you build your URLs in the app. I also usually never use any absolute paths. I was forgot to save the IRC buffer today so I didn't catch the patch but I remembered the zeroing out of Http1, anyway I tried simply doing this is in the entrypoint: (de start () (off *JS) (zero *Http1) (if (getUsr) (desktop) (signin))) Note the (zero *Http1). That approach seems to be working, I can In IRC I wrote (patch _htHead '(format (car @H)) 0) after loading lib/http.l Changing '*Http1' explicitly doesn't help, because it is set by '_htHead' on each HTTP transaction, depending on the client's HTTP header. One very strange thing though, the HTML output looks like this when the form first loads: *start* 408 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html xmlns=3Dhttp://www.w3.org/1999/xhtml; xml:lang=3Den lang=3Den .. /html 0 *end* Note the initial 408 and the final 0. This is because '_htHead' also sets chunked transfer mode. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Problems with the GUI?
This is odd, the problem seems to be happening when I switch machines, I logged out and in several times at work today to try and trigger the problem. When I came home I still had the cookie so everything worked ok, I logged out, looks like this now: (de logout () (setq *Cookies NIL) (cookie 'uid NIL) (signin)) No redirects anymore, and when I tried to log back in I got exactly the same problem, despite removing the redirect and having (start) look like this: (de start () (off *JS) (if (getUsr) (desktop) (signin))) So no JS either. If you're out of ideas I'll try to reproduce the problem with a simple app that you can easily run. /Henrik On Tue, Nov 24, 2009 at 10:57 AM, Henrik Sarvell hsarv...@gmail.com wrote= : Yes (redir) is just a shortcut to: (de redir (Func) =A0 (redirect (pack *Domain (or Func @desktop redirecting causes you to lose part of the session's context Good to know. I'm sorry, it seems like I missed to list (start) earlier: (de start () (if (getUsr) (desktop) (signin))) This is the entry point, it will try and get a user object with the help of the user id in the cookie, if it can't it will simply call signin which when submitted routes to the dead end (sometimes). In fact (usrQuit) and (logout) actually doesn't have anything to do with the problem at hand since they are not called at all. I'm sorry that I've been unnecessarily confusing. I suppose we're back to the beginning here if manipulating *SesId won't help me and since I'm not doing unnecessary redirects in this case? Obviously the form is rendered correctly and when I submit the following should be executed since I'm pretty sure I enter the right password: (prog =A0(cookie 'uid Uid) =A0(setq *Cookies (cons 'uid Uid)) =A0(redir)) And (redir) should render the desktop. However somehow something else cuts in between, but only sometimes when the server has been running for some time, never when I just restarted it. Could this thing that captures the button click before I have time to redirect be something in the new JavaScript stuff you've been doing lately? On Tue, Nov 24, 2009 at 10:01 AM, Alexander Burger a...@software-lab.de = wrote: On Tue, Nov 24, 2009 at 09:27:16AM +0100, Henrik Sarvell wrote: I think I understand, how would I properly log someone out of the normal GUI, ie when using (app) et al, setting *SesId to NIL maybe? I just browsed http.l and noticed that variable. I would not manipulate '*SesId'. This would just give errors due to illegal accesses to the session. I use lib/adm.l, which has functions for login and logout. I'm not sure in your case, but for terminating a session just (bye) might also suffice. (de usrQuit () =A0 (let Usr (getUsr) =A0 =A0 =A0(or Usr (redir @logout What does 'redir' do? Something like 'redirect' in lib/http.l? Then it would be better to call (logout) directly instead of redirecting to @logout, wouldn't it? Also, this would avoid an additional HTTP transaction. So the following redirects to logout if the user id is not in a cookie: (de logout () =A0 =A0(setq *Cookies NIL) =A0 =A0(cookie 'uid NIL) =A0 =A0(redir @start)) Same here. I would directly call 'start' or any other functions needed. (de signin () =A0 =A0(app) =A0 =A0(action =A0 =A0 =A0 (html 0 RSS Reader *Css NIL =A0 =A0 =A0 =A0 =A0(form NIL =A0 =A0 =A0 =A0 =A0 =A0 (table NIL NIL NIL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(row NIL Username =A0(gui 'uname '(+= TextField) 10)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(row NIL Password =A0(gui 'pwd =A0 '= (+PwField) =A0 10)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(row NIL =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (gui '(+Button) Login =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'(let Uid (chkLogin (val (:= home uname)) (val (: home pwd))) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(if Uid =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (prog =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(cookie = 'uid Uid) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(setq *C= ookies (cons 'uid Uid)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(redir)) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (err Could not= login.) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(row NIL (href Sign Up @register= ))) It was after pressing the Login button here I got the problem, redirecting to, and rendering the login form was not a problem. Thre redirecting causes you to lose part of the session's context. Perhaps it all works if you just do the processig directly, as I suggested? The code will probably also become much simpler. You could try to just use the 'login' function from lib/adm.l, as in app/gui.l. I think that it has all necessary mechanisms. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Problems with the GUI?
Hi Alex, you know I use the standard GUI for logging in and registration. After the server has been on for a while I suddenly get http://vizreader.com:39968/366072015751376...@start?*menu=+0*Tab=+1*ID= and Firefox can't establish a connection to the server at vizreader.com:39968 when I try to login, trying to load the registration form gives me the same. Do you know why I get this behavior? I have no idea where 366072015751376...@start?*menu=+0*Tab=+1*ID= is coming from. Killing all picolisp instances and restarting the server makes everything work again. /Henrik -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Re: Problems with the GUI?
Hi Henrik, registration. After the server has been on for a while I suddenly get http://vizreader.com:39968/366072015751376...@start?*menu=+0*Tab=+1*ID= and Firefox can't establish a connection to the server at This looks like a timeout. Sessions have by default a timeout of 5 minutes before a user logs in (and after a user logs out), and 1 hour while a user is logged in. However, as I said, this applies only to sessions, i.e. children of the main server process. The server itself does not time out. So I actually don't know what causes the problem. I have no idea where 366072015751376...@start?*menu=+0*Tab=+1*ID= is coming from. This is the standard link URL generated by the GUI. It assumes that a menu via menu and perhaps tabs via tab are present, but does not harm if they are not. It has probably nothing to do with the timeout. Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
