User Story #10178 (closed)
FS/Web stateful service interaction
|Reported by:||jamoore||Owned by:||wmoore|
|Cc:||web-team@…, fs@…||Story Points:||n.a.|
|Total Remaining Time:||n.a.||Estimated Remaining Time:||n.a.|
Description (last modified by wmoore)
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!
Change History (10)
comment:8 Changed 8 years ago by jburel
- Keywords FS added
- Milestone changed from OMERO-4.5 to OMERO-5