The new CDAWeb server has a cache of info responses calculated already, so it is unproductive to cache them in the server-java info cache. Further, an initial attempt at disabling this caching showed there are errors in how this is implemented, where two simultaneous threads can step on one another's work.
I've kludged in a control where infos can indicate that they should not be cached, using the json tag "x_info_caching" which should be set to false when files in /tmp/hapi-server/info should not be created. This will probably change!
The Linux command "ab" shows where there are issues:
ab -v 3 -n 50 -c 50 "http://localhost:8280/HapiServer/hapi/info?dataset=AC_OR_SSC¶meters=XYZ_GSE" > ~/tmp/20250508/ab.log
The problem with multiple threads is fixed by writing to a temporary file and then moving the file into position in /tmp/hapi-server/info. There may be additional issues which show with stress testing, and this should be done. However in the CDAWeb case, there is no need to cache, and when caching is disabled, files should not be created here.
The new CDAWeb server has a cache of info responses calculated already, so it is unproductive to cache them in the server-java info cache. Further, an initial attempt at disabling this caching showed there are errors in how this is implemented, where two simultaneous threads can step on one another's work.
I've kludged in a control where infos can indicate that they should not be cached, using the json tag "x_info_caching" which should be set to false when files in /tmp/hapi-server/info should not be created. This will probably change!
The Linux command "ab" shows where there are issues:
The problem with multiple threads is fixed by writing to a temporary file and then moving the file into position in /tmp/hapi-server/info. There may be additional issues which show with stress testing, and this should be done. However in the CDAWeb case, there is no need to cache, and when caching is disabled, files should not be created here.