Hello,
It sounds like Mantid is passing queries to ICAT without a 'LIMIT' paging argument in the query.
These pull back >100,000 results from the database and cause OutOfMemory issues.
We plan to limit these very large queries on the server side, but it would give a better user experience if Mantid restricted the queries via paging.
Thanks,
Tom
-----Original Message-- - - -
Subject: FW: ** PROBLEM alert - icatisis/check-glassfish is CRITICAL **
Hi Tom,
This seems to have been caused by somebody asking for all datafiles in datasets where the investigation name is zero again:
2014-07-16 09:19:18,571 [http-listener-2(4)] INFO BeanManager - uows/9743 searching for Datafile `<->` Dataset `<->` Investigation[name = '0']
which is Dr Maximilian Skoda in ISIS according to the ICAT user table.
I presume this is Mantid related activity?
Cheers,
Kevin
I think the issue here is with the CatalogGetDataFiles algorithm. It currently doesn't set the LIMIT parameter in the ICAT query so it tries to access everything. We need to look at how paging was implemented in the main ICat interface and do something similar (or create some kind of reusable widget).
In any case I think it would be a good idea for all of the ICAT algorithms to have a default limit set (something like 100) to avoid this problem.
From Tom:
I think the issue here is with the CatalogGetDataFiles algorithm. It currently doesn't set the LIMIT parameter in the ICAT query so it tries to access everything. We need to look at how paging was implemented in the main ICat interface and do something similar (or create some kind of reusable widget).
In any case I think it would be a good idea for all of the ICAT algorithms to have a default limit set (something like 100) to avoid this problem.