[ome-devel] Problem with float point image channel min/max range

[José Salavert Torres]

Dear Josh,

We were not able to identify this failure until now. We used the pre-release version because we needed support for floating point images.

Regarding your question, the server is installed at EBI in an environment in which it took us more than a week to be able to set up an omero compilation / installation environment. So performing updates is not an easy / reasonable task and we continued using that version when we saw it worked properly.

Please be comprehensive about our infrastructure: all the tools / libraries / ***ice dependencies*** and python files must be manually installed without root privileges in our machines, setting the path variables and python environment, finding the binaries and libXXX.so files etc, and the same stands for the build chain. Making a git pull can put us in a situation in which we would need to spend more days manually updating our environment.

Right now a service is running with all PDBe entries in the OMERO database, so in order to upgrade the server we need to upgrade the database also. If not we will need to drop the entire database and import all the entries again. This takes around a week because it is a very i/o demanding task. Also, this is aggravated by continued failures in the import process related to session tokens (that force us to clean the OMERO.data directory hidden lock files manually and restart the server). This may also stop our release cycle of the service.

Is it possible to upgrade an existing omero database to a new version schema without dropping the database?

Now that I answered your question, again, please be comprehensive. Before we try to update the server which may (or may not) make us spend about a week, please can you have a quick  look and see if the problems we are experiencing are still reproduced in the current version?

Please, can you simply import entry EMD-2796:

ftp://ftp.ebi.ac.uk/pub/databases/emdb/structures/EMD-2796/map/emd_2796.map.gz <ftp://ftp.ebi.ac.uk/pub/databases/emdb/structures/EMD-2796/map/emd_2796.map.gz>

Into a running instance of OMERO and ask for:

	… /webgateway/render_image_region_quality/43450/99/0/100?c=1|0:0&region=26,29,169,169  (service down)
	… /webgateway/render_image_region_quality/43450/99/0/100?c=1|-0.000475:-0.000476&region=26,29,169,169 (too much compute time)

to the web gateway and check both issues.

Sincerely, I expected a different response, I can also check the amount of commits between our version and the current one with a simple git command, but that does not solve the issue for us. If you can not confirm that the problem is already solved we can not risk updating at this moment.

We put a lot of effort into making the OMERO service run and takes us days to do it.

> On 23 Jun 2015, at 12:48, Josh Moore <josh at glencoesoftware.com> wrote:
> 
> On Tue, Jun 23, 2015 at 1:13 PM, José Salavert Torres <josator at ebi.ac.uk <mailto:josator at ebi.ac.uk>> wrote:
>> Dear OMERO developers,
> 
> Hi José,
> 
> 
>> I am on commit “c6f9a94b0a16ac352e1d7287954d08c0d881eb06”.
>> When asking for images through the Webserver gateway, I have experienced a
>> problem that hangs the server.
>> 
>> 
>> If I send an URL like:
>> 
>> ... /webgateway/render_image_region/35203/99/0?c=1|0:0&region=29,0,169,169”
>> 
>> with the channel min and max values equal to zero:
>> 
>> ?c=1|0:0
>> 
>> the server starts an intensive computation and stops returning any other
>> image requests (the service is down due the overloading until you reset it).
>> 
>> Also, if the minimum / maximum range is smaller than the precision this has
>> an impact in the performance that is greater the narrower this range is. i.e
>> given :
>> 
>> min = -10
>> max = 30
>> 
>> A call with:
>> 
>> ?c=1|20.00:22.01
>> 
>> Will trigger an image calculation that will take a lot of time and
>> resources, slowing down the server and making it unresponsive for several
>> minutes.
>> 
>> Can you reproduce these issues?
> 
> Before we start trying to reproduce, is there a reason you're using a
> pre-release version (5.1.0-m4)? There are some 2000+ commits between
> what you're working on and the current release tag ("v5.1.2").
> 
> Cheers,
> ~Josh.
> 
>> José
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk <mailto:ome-devel at lists.openmicroscopy.org.uk>
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel <http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20150623/bed69300/attachment-0001.html>