Hello,
I am using AJAX requests periodically on each page of my site to update a part of the display. These requests, however, prevent the session from becoming stale. Aside from fiddling with the last-click member of the session objects directly, what is the best way of keeping the periodic AJAX requests while letting unattended sessions become too-old-p?
Thanks,
Tim S
On Fri, 03 Aug 2007 00:45:01 -0400, timothy tschaef@sbcglobal.net wrote:
I am using AJAX requests periodically on each page of my site to update a part of the display. These requests, however, prevent the session from becoming stale. Aside from fiddling with the last-click member of the session objects directly, what is the best way of keeping the periodic AJAX requests while letting unattended sessions become too-old-p?
There currently is no exported facility to overcome this kind of problem.
Hello,
Can anyone give me a way to debug the following problem, or tell me likely places to investigate?
With Hunchentoot 0.11.1 I have a problem on this machine:
Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
but I don't have that problem on this machine:
Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 i686 i686 i386 GNU/Linux
I am running LWL Pro 4.3.7.
On the x86_64 machine, every page, even the Hunchentoot default page, has some seemingly-random binary data that comes after the headers but before the content. This appears in the browser as strange characters at the top of the page, often (but not always) followed by part or all of the desired web page. The random binary data is not in the content variable that is written to the stream. The headers are OK, the content is OK, it is only that there is extra binary data between the headers and the content.
I found a workaround. In headers.lisp, in function start-output, in the following code, write-sequence is the original code in hunchentoot while write-string is the workaround needed to get good output and avoid the extraneous binary data between the headers and the content.
... (setf (flexi-stream-external-format *hunchentoot-stream*) (reply-external-format)) ;; now optional content (unless (or (null content) head-request-p) (ignore-errors #+x86_64RHEL5-workaround (write-string (coerce (loop for c across content collect (code-char c)) 'string)
*hunchentoot-stream*) #-x86_64RHEL5-workaround (write-sequence content *hunchentoot-stream*))) (when chunkedp ;; turn chunking on after the headers have been sent (setf (chunked-stream-output-chunking-p (flexi-stream-stream *hunchentoot-stream*)) t)) *hunchentoot-stream*))
Again, can anyone give me tips on where to look or how to debug the problem?
Thanks,
Jeff Caldwell
____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=...
On Mon, 20 Aug 2007 12:47:06 -0700 (PDT), Jeff Caldwell jdcal@yahoo.com wrote:
Can anyone give me a way to debug the following problem, or tell me likely places to investigate?
With Hunchentoot 0.11.1 I have a problem on this machine:
Linux machine-1-name 2.6.18-8.1.8.el5 #1 SMP Mon Jun 25 15:19:07 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
but I don't have that problem on this machine:
Linux machine-2-name 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 i686 i686 i386 GNU/Linux
I am running LWL Pro 4.3.7.
On the x86_64 machine, every page, even the Hunchentoot default page, has some seemingly-random binary data that comes after the headers but before the content. This appears in the browser as strange characters at the top of the page, often (but not always) followed by part or all of the desired web page. The random binary data is not in the content variable that is written to the stream. The headers are OK, the content is OK, it is only that there is extra binary data between the headers and the content.
I found a workaround. In headers.lisp, in function start-output, in the following code, write-sequence is the original code in hunchentoot while write-string is the workaround needed to get good output and avoid the extraneous binary data between the headers and the content.
... (setf (flexi-stream-external-format *hunchentoot-stream*) (reply-external-format)) ;; now optional content (unless (or (null content) head-request-p) (ignore-errors #+x86_64RHEL5-workaround (write-string (coerce (loop for c across content collect (code-char c)) 'string)
*hunchentoot-stream*) #-x86_64RHEL5-workaround (write-sequence content *hunchentoot-stream*))) (when chunkedp ;; turn chunking on after the headers have been sent (setf (chunked-stream-output-chunking-p (flexi-stream-stream *hunchentoot-stream*)) t)) *hunchentoot-stream*))Again, can anyone give me tips on where to look or how to debug the problem?
Looks like a possible bug in flexi-streams (/or/ in LWL 4) to me and should probably be discussed on the corresponding mailing list - see Cc. Could you check if the test suite of flexi-streams runs through on your x86_64 machine? Are you using the newest version of flexi-streams? Could you check if you get the same problems with LWL 5.0.x, maybe using the Personal Edition? Unfortunately, I don't have a 64-bit machine yet to check this myself.
Thanks, Edi.
-
Edi Weitz -
Jeff Caldwell -
timothy