Binary services need a throttling mechanism

[jmoore]

Now that import and multi-window viewing are in full-swing, we need to start thinking about how to curb them somewhat. In OME, the transfer of binary files is only limited by the number of Apache threads, but the actual import is asynchronous and jobbed out as possible. (Right?)

With our current remote infrastructure, basically there's no way (currently) to throttle calls. With a more advanced infrastructure (two-way invocation, etc.) it'd be possible to cleanly solve this problem (the server takes turns requesting files from the clients), but a short-term solution is also in order to prevent OutOfMemoryExceptions

Short-term possibilities:

• Throw an exception. At either service creation or service invocation an exception could be thrown. All consumers of the binary service would need to check for that exception and retry.
• Blocking. Again, at either creation or invocation, the service could simply block until a slot becomes available.
• boolean return. Another option is to have all setter methods return a boolean. This leads to an idiom of the form: while( setPlane(...) ) { // don't do this too often }, meaning that operations will be retried until they succeed.
• Status return. Rather than a boolean, a Status object could be returned.

Longer-term possibilities:

• Asynchronous. This really doesn't help us. The initial transfer of binary data is still uncontrolled.
• Two-way invocation. ...