Hi Josh,
Yes, the primary cause for concern is ERROR in the log. I'm not 100% sure whether the error also has a behavior for users. But one of the strong hunches I have is that it can be triggered by downloading large sets (250+) of original files.
Right now, I've managed to trigger the ERROR by:
- Downloading the original files of a dataset of 470 images (JPG files, several GB) using the INSIGHT 64 bit windows client.
- The download is quick (several files per few seconds) for the first 200 images. In then slows down, to eventually a crawl of 1 or 2 images every 10 seconds. At that point also in the log the following can be seen:
- Code: Select all
2015-02-23 09:53:20,778 INFO [ ome.services.util.ServiceHandler] (Server-203) Cleanup: ome.services.RawFileBean@339d41dc
2015-02-23 09:53:20,778 INFO [omero.cmd.SessionI] (Server-203) Unregistered servant:99af1836-e928-46cd-abe5-75bf3c2361d0/f0a5d7c3-230f-4b73-96bf-7402a21b50d2-RepoRawFileStoreI(omero.api._RawFileStoreTie@23ddff02)
2015-02-23 09:53:20,778 WARN [ omero.cmd.SessionI] (Server-260) Holder is null for 99af1836-e928-46cd-abe5-75bf3c2361d0/1627895d-5d6f-42b8-8859-3dfcf838d4ebomero.api.RawFileStore(omero.api._RawFileStoreTie@3e0ee0ec)
2015-02-23 09:53:20,778 INFO [ omero.cmd.SessionI] (Server-260) Unregistered servant:99af1836-e928-46cd-abe5-75bf3c2361d0/1627895d-5d6f-42b8-8859-3dfcf838d4ebomero.api.RawFileStore(omero.api._RawFileStoreTie@3e0ee0ec)
2015-02-23 09:53:26,236 INFO [ ome.services.util.ServiceHandler] (Server-270) Meth: interface ome.api.IContainer.getImages
What can be seen is that there is a pause between the second "Unregistered servant" line and the "interface ome.api.IContainer.getImages" call of 6 seconds. This seems to correspond at which moment the new image appears.
What may be a related but, very annoying UI behavior to say the least, is that the file dialog for the Download will stay visible during the entire download, and will keep getting refocused repeatedly. Also the Activity window will flicker behind this, but never come into view.
- Now, a way I've found to trigger the final ERROR quite quickly is to kill the client process (task manager) while the Download is in progress. Then restarting the client and starting a second download. Several minutes later the ERROR will show.
- What's important to observe is that the servant UUIDs in the final ERROR are the same as those shown in the WARN log above.
I'm BTW less sure that this is related to the fact that we run some parts of the binary repository over NFS.
With kind regards,
Paul