2010/5/19 Guido Trotter <[email protected]>: > - The REQ_WAIT_FOR_JOB_CHANGE luxi request is changed to be > subscription-based, so that the executing thread doesn't have to be > - hogged while changes arrive. > + waiting for the changes to arrive. Threads producing messages (job > + queue executors) will signal the client work queue threads when there > + is a change, and those will notify the subscribed clients. This should > + be implemented without requiring the work queue threads to reacquire > + the job queue lock, to decrease its contention.
So you would submit two kinds of tasks (messages and job updates) to the client request queue? I wonder whether having just one thread dedicated (which could be a single long-running task in the client request pool) to sending updates instead of always submitting a new task. During the lifetime of a job there can be many, many updates. Either way you need something actively checking the subscriptions for timeouts (not on the connections, but for waiting, so that you return if there was no change for e.g. 30 sec). I think this would be easier with a long-running thread. While currently not implemented, I'd like to see WaitForJobChange be able to wait a short time (e.g. 1 second) after an update to wait for further updates, so that there's less back-and-forth between server and clients. This is very important for RAPI, where requests aren't as cheap as for LUXI[1]. How would you implement something like this in the new model? I'm currently thinking of a good way of doing it with the current model. Michael [1] With the current RAPI client based on urllib2, calling any resource involves establishing two SSL connections, the first for a 401 Unauthorized reply, and the second with authentication information; each connection causes a fork on the server
