6 Replies Latest reply: Oct 6, 2013 9:38 AM by user5866800 RSS

    Long running threads (Jasper Reports) and AM-Pooling




      we are developing quite large application with ADF an BC. We have quite a lot of reports generated through Jasper that take quite long time to complete. The result is a PDF document that user gets on the UI so he can download it over download link. Reports that take over an hour to finish are never completed and returned to the user on UI. I think the problem is in AM-Polling because we are using default AM-Polling settings:

      <AM-Pooling jbo.ampool.maxinactiveage="600000" jbo.ampool.monitorsleepinterval="600000" jbo.ampool.timetolive="3600000"/>


      The AM is destroyed or returned to pool before reports finishes. How to properly configure those settings that even long running threads will do there jobs to the end.


      We also modified web.xml as follows:





      Any help appreciated.


      Regards, Tadej

        • 1. Re: Long running threads (Jasper Reports) and AM-Pooling
          Dimitar Dimitrov

          Your problem is not related to ADF ApplicationModules. AMs are returned to the pool no earlier than the end of request, so for sure they are not destroyed by the framework while the report is running. The AM timeout settings you are referring to are applicable only to idle AMs in the pool but not to AMs that have been checked out and used by some active request.


          If you are using MS Internet Explorer, then most probably your problem is related to the IE's ReceiveTimeout setting, which defines a timeout for receiving a response from the server. I have had such problems with long running requests (involving DB processing running for more than 1 hour) and solved my problem by increasing this timeout. By default this timeout is as follows:

          • IE4 - 5 minutes
          • IE5, 6, 7, 8 - 60 minutes

          I cannot find what the default value is for IE9 and IE10, but some people claim it is only 10 seconds, although this information does not sound reasonable and reliable! Anyway, the real value is hardly greater than 60 minutes.


          You should increase the ReceiveTimeout registry value to an appropriate value (greater than the time necessary for your report to complete). Follow the instructions of MS Support here:

          Internet Explorer error &quot;connection timed out&quot; when server does not respond


          I have searched Internet for similar timeout settings for Google Chrome and Mozilla Firefox, but I have not found anything, so I instructed my customers (who execute long-running DB processing) to configure and use IE for these requests.



          • 2. Re: Long running threads (Jasper Reports) and AM-Pooling

            Its not clear how you exactly generate report.

            From your description it seems that you invoke some method in AM which uses existing db connection to generate report?

            Also its not clear is user blocked until report is fully generated(I suppose that this is true because you mentioned session-timeout parameter ) or he can use application?


            Maybe you can offload report generation to report server(for example JasperServer) or at least to some servlet and get connection directly from data source?

            For long running reports, best approach is to use some report server, or some custom asynchronous service(for example, for each user you can create folder on filesystem and keep generated reports there, then write page which will display links for generated reports in specific(user) folder)



            • 3. Re: Long running threads (Jasper Reports) and AM-Pooling
              Dimitar Dimitrov

              In my opinion it is not a good idea to increase the HTTP Session timeout in web.xml to 300 minutes for all the users, because this value is too large and you may overload the server's memory with a lot of expired sessions (that are kept for too much time). If I were you, I would leave the timeout to the default value and modify session's timeout programatically to a large value only at the beginning of requests that were expected to be extra long-running and restore the session's timeout at the end of request. You can use the Java API method HttpSession.setMaxInactiveInterval(int) for this purpose.



              • 4. Re: Long running threads (Jasper Reports) and AM-Pooling

                I think this might be the case. I'am calling Jasper report through AM exposed method and it might the problem with browser then. I'm using glasspane so user can't click anything else in that tab. I will try setting HttpSession.setMaxInactiveInterval(int) and see how it goes. Ty for replies.



                • 5. Re: Long running threads (Jasper Reports) and AM-Pooling
                  Dimitar Dimitrov

                  I would like to add something related to my 1st post, where I said "AMs are returned to the pool no earlier than the end of request, so for sure they are not destroyed by the framework while the report is running". This is true if the report generation is synchronous (e.g. the server waits while the report is being generated and responds to the client browser after the report generation is done). However, If your initial request (which starts the report generation) responds back immediately (leaving the report to be generated asynchronously in background), then the AM is released and checked back in the AM pool immediately. In this way the AM instance may be (re)used by another session/request or destroyed when shrinking the AM pool, while the report in background is continuing using it. If this is your case, then you should re-design your concept because the report must not use the AM if it has already been released back into the AM pool.


                  • 6. Re: Long running threads (Jasper Reports) and AM-Pooling

                    Well i'm calling exposed method from viewobject which is defined programmatically so i think report generation is synchronus. I also read above post telling that could be browser timeout. I don't really know how to check what could be the problem.