FS/Web stateful service interaction

[jamoore]

In 4.4, web methods were all converted to use a

   svc = openStatefulService()
   try:
      svc.doWork();
   finally:
      svc.close()

idiom. In other words, no stateful service lives longer than a single http requestl. With Bio-Formats now backing many of the services (renderingengine, rawpixelsservice, etc), this means that each method call (getPlane(), renderJpeg()) is performing a full setIdinvocation. For some formats, this can take several seconds.

Melissa is working on reducing setId times, and eventually the Bio-Formats state can be cached server-side in order to further speed up the individual lookups, but there may still be the need for properly handling state from the web client.

A first step is likely to evaluate the user impact of the slow down (especially when several users are accessing the web simultaneously). #10183

If the Blitz Gateway is to re-use existing stateful services (E.g. rendering engine already initialised on a particular imageId) then we have to support several steps

• Once we have joined a session...
• Identify stateful services that exist on the server
• Determine whether any of these are initialised with the correct ImageId?
• Recreate the client-side proxy
• Update the state (E.g. turn channels on/off etc) and get output (Render plane)
• Leave the service open.
• The server would need to purge or limit the number of these open stateful services.

NB: If multiple web workers are simultaneously following the above steps, I imagine it's possible that they could both try to work with the same stateful service, causing all sorts of problems!

[wmoore]

Josh: would it help to have a performance testing web page, which tries to render multiple planes from the same (or different) images and logs the time taken? This could be part of webtest and included in dev_4_4 and develop, then we can compare times etc.

E.g. sequentially render all the planes in a specified image / images.

[jmoore]

Will: a test like that we could have on both branches might be ideal. Something like ​ApacheBench

[agilo]

Updated status, related task in progress

[wmoore]

Josh / Chris / Carlos - any idea how tricky are the steps I've outlined above? How bad is the risk of 2 workers accessing the same stateful service etc?