One thing that would help all of the engineering groups here at LCO, especially reliability, and would be likely be a useful feature for external customers would be to add the ability to cache the data for outstanding commands (much like you cache the handlers in a queue with the corresponding sequence number), and add a threadedClient/asyncClient method called retry that dumps the existing socket, opens a new one, and resends all the commands in the queue, with each one still attached to the (possibly same) sequence number and callback handlers. This allows us to keep moving forward in a relatively painless way if one command in a sequence times out, or we have a major fault somewhere in the stream of commands. I would expect the ability to save data for retries to be optional and must be specified explicitly, as it increases the memory demands linearly with queue size, and could push many systems that aren't chock full of RAM over the edge. of the client Does this make sense?
One thing that would help all of the engineering groups here at LCO, especially reliability, and would be likely be a useful feature for external customers would be to add the ability to cache the data for outstanding commands (much like you cache the handlers in a queue with the corresponding sequence number), and add a threadedClient/asyncClient method called retry that dumps the existing socket, opens a new one, and resends all the commands in the queue, with each one still attached to the (possibly same) sequence number and callback handlers. This allows us to keep moving forward in a relatively painless way if one command in a sequence times out, or we have a major fault somewhere in the stream of commands. I would expect the ability to save data for retries to be optional and must be specified explicitly, as it increases the memory demands linearly with queue size, and could push many systems that aren't chock full of RAM over the edge. of the client Does this make sense?