Live data from Hacker News

Poll: Unknown or expired link on YC

news.ycombinator.com

11–20 of 37 posts

Re: Poll: Unknown or expired link on YC

#12
post #7

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacceptable. Are there elegant solutions to fix this? Could someone link the explanation to how the continuation sessions work, please?

I believe the specific code has to do with "fnid harvesting". See the comments here: http://github.com/nex3/arc/tree/master/srv.arc line 330 or so.

The general idea is described here: http://dresese.thehyatts.net/archives/000253.html

pg's original patent on this scheme: http://www.freepatentsonline.com/6205469.html

Re: Poll: Unknown or expired link on YC

#13
post #11
post #3

I usually only get it if I have a comment reply open for a long time before clicking add. Feels like the continuation lasts for about 20 minutes.

There's no set timeout. They're kept in a queue.

With the load going up so much (causing the crashes) it also means the links expire faster. I would guess in under 10 minutes sometimes, maybe under 5.

Re: Poll: Unknown or expired link on YC

#14
post #7

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacceptable. Are there elegant solutions to fix this? Could someone link the explanation to how the continuation sessions work, please?

Explanation: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www...

A possible elegant solution is suggested in the paper: store the continuation on the client. I don't know what problems this presents in practice.

Re: Poll: Unknown or expired link on YC

#15
post #7

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacceptable. Are there elegant solutions to fix this? Could someone link the explanation to how the continuation sessions work, please?

Explanation: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www... A possible elegant solution is suggested in the paper: store the continuation on the client. I don't know what problems this presents in practice.

With GET requests, you frequently run into URL size issues. IE has a roughly 1800 character limit, which is pretty easy to hit with machine-generated data. I remember going through hell with JSF charting frameworks, trying to squeeze the serialized data down under 1800 characters. Eventually we gave up, pulled everything out of the serialized data (it still took up over 1K though, just through framework metadata, and so only left us around 500-800 bytes to play with), and threw it into query parameters that we could control ourselves.

This isn't an issue with POST, but then you run into the normal POST issues with refreshability, bookmarkability, and portable URLs.

Re: Poll: Unknown or expired link on YC

#20
post #8

Earlier quoted context omitted.

Pretty sure that's what pg's said it is. Personally, that's way too short, as I'll leave threads open for half a day without reading it, then can't comment. I don't see any fundamental reason why continuations have to expire so fast.

Because they take up ram on the server. 20 minutes is standard session timeout for most session based web frameworks.

I wonder - would it be technically feasible to page the continuations out to temporary files on the server? Kind of like cookies, but on the server instead of the client!
Post reply on HN