sergey.vishnevetskiy Posted February 8, 2018 Share Posted February 8, 2018 Report can be generated with /rest_v2/reportExecutions. After that it can be downloaded with /rest_v2/reportExecutions/<requestId>/exports/<id>/outputResource, and after that it becames unavailable. My question is - where it is stored between creating and downloading? And follow ups - how lond it'll be stored, do I have to worry about cleaning procedures if API will be revealed to enduser, and downloading not guaranted?UPD: Experimentally proved that this reports stored roughly for an hour. So no cleaning procedures required. But question persists - where they stored and how storage time regulated? Link to comment Share on other sites More sharing options...
Solution ghudson_1 Posted February 14, 2018 Solution Share Posted February 14, 2018 When using reportExecutions the report stays in memory on the server, similar to the filled JRPrint object that gets filled before being flushed out during an export in JRS UI use-cases, for example from the UI ReportViewer to PDF. The JRPrints stay in memory entirely unless they are so huge page-wise that virtualization kicks in (and you can search wiki/community for details on virtualization if needed). It stays for the duration of the user-session which made the reportExecutions call. (see web.xml for session timeout) Link to comment Share on other sites More sharing options...
sergey.vishnevetskiy Posted February 15, 2018 Author Share Posted February 15, 2018 Thank you. I think by "memory" you mean RAM to be exact. And about session timeout - it's bit wierd when we talk about asynchronus call. But anyway it resolves my needs.P.S. And what if session timeout set to 0 (not expiring)? Link to comment Share on other sites More sharing options...
ghudson_1 Posted February 15, 2018 Share Posted February 15, 2018 yes - the JVM's ram/memory/heapIt is asynchronous and are parts are session-bound. For example the specific IDs in /<requestId>/exports/<id> are only accessible via the user-session which originated the request.Session expiration set to zero would be bad, don't do that or you'll eventually encounter an out of memory exception (and wonky stuff will occur prior). Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now