There is also the Ns_Task API which is more flushed out, and is used by the new ns_http command.
But each Ns_Task implementation requires coding in C, which is probably okay for those needing high performance. It is still difficult to figure out exactly how it should be used. Anyway, for those who haven't looked at ns_http or Ns_Task, what happens is you create a queue, in a new thread. You can add 'tasks', A task as a series of states, like sending data, receiving data, and each task has an id. So one thread can add tasks, and a different thread can 'wait', you just have to us nsv_ to store the task id. I'm not sure that it could be useful from the driver thread... tom jackson On Wednesday 16 April 2008 11:19, Jim Davidson wrote: > 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. -- 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.
