On 12/14/11 3:52 PM, Volker Braun wrote:
On Wednesday, December 14, 2011 8:58:23 PM UTC, jason wrote:
> So maybe this is where my confusion lies.. If I make two
sucessive posts
> to the /eval url, should they
> a) both have the same session_id and two different msg_ids, or
> b) always random session and msg ids (4 random UUIDs for 2 requests)?
(b). They should certainly have two different session ids. The message
ids should be unique across all messages, so those should be unique
too,
though I suppose maybe you could make the argument that the message ids
need to be unique just inside a session (but that's not what we
assumed,
so I'm not sure if it will work).
Think of it as a routing protocol. The session id routes to the correct
Sage session, while the message id is just a unique identifier for the
message itself.
Thats precisely how I thought about it, but you keep telling me that its
not. Since I want to use the same sessions (that is, have a history and
variables) I though I should be setting the same session UUID for
subsequent eval calls. But you keep telling me to use different sessions
for each call, so I'm not routing anywhere but, rather, get a new
instance every time.
Ah, okay. I thought you wanted to initiate a new session each time.
Yes, it should work if you use the same session id for each request.
However, there is a timeout on sessions, which is the time a session
waits for a new command (and is reset after each command is executed),
and that may be what is causing the problem here. Generally, a session
is ended immediately after the first command string is finished.
However, if the user does this:
interact_singlecell.__single_cell_timeout__=45
that will set the timeout to 45 seconds. There is a hard-coded maximum
of 60 seconds for the timeout.
You can guess that we get interacts to work by setting that timeout to
60 seconds. That means the user has up to 60 seconds to change a
control on the interact (sending a new request to the server).
We put the timeout in there because, as a single-cell server, we
imagined that most people would just run a command and be done, and we
wanted to free up as many worker processes as we could.
Thanks,
Jason
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
