Hi,
I'm glad you noticed Ns_QueueWait. It was designed to address one of
the most common scalability problems we had noticed at AOL where
threads get backed up waiting for a response from a remote resource
(e.g., REST or SOAP result). The idea (as mentioned in the change
note below) is that you wait for I/O events to complete, accumulate
all the potentially slow remote stuff before queuing the request for
processing, using "connection local storage" as needed to hold the
remote data.
Sadly, only the low level API was written. Adding a more convenient
HTTP interface that you could then add REST or SOAP things on top
would make sense but wasn't done. It's possible you could write a
simple Tcl wrapper -- the callbacks would look like Tk callbacks.
However, you'd need to be careful using it and understand that the Tcl
interp used for the queue wait callbacks would not be the same as the
Tcl interface used later plus there's the trouble mapping Tcl I/O
objects to something you can wait on with a call to select() or
poll(). Thinking about it now as I'm typing, perhaps a smarter
solution would have been to use the Tcl event loop in a 2nd dedicated
thread: Requests would be read with the current AOLserver I/O event
loop and then passed to a Tcl event loop if needed before being queued
for execution by a dedicated thread. Hmm....
-Jim
On Apr 14, 2008, at 8:15 PM, Tom Jackson wrote:
Since Jim Davidson is somewhat monitoring the newsgroup at the
moment, I want
to take advantage...
One new feature of AOLserver 4.5 is the Ns_QueueWait API:
Ns_QueueWait:
New interface to enable event-driven callbacks in the driver
thread before dispatching to pools for processing. This
allows drivers to augment data received from the client
(headers, request, content) with additional data fetched
over the network (likely stored in connection-local storage
via Ns_Cls). An example would be to add certain personalization
data received via a Web service. The benefit of this approach
is to accumulate additional data efficiently with driver-thread
based event callbacks instead of through potentially blocking
calls within connection threads.
My first question is if there are any examples of using this
interface?
Second is just a note to Jeff Rogers: this looks like a plugin
interface that
could work for your application.
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]
> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
