Kapil Bansal wrote: > One of my customer is facing the issue that he is not able to byte server > the > PDF as PDF is getting completely downloaded in the memory first and then > displayed..They are using JBOSS 4.0.3 SP1 ...I was going through the link > https://issues.apache.org/bugzilla/show_bug.cgi?id=45419 and it says that > this > has been fixed in 6.0.x and will be included in 6.0.19 onwards....So what > can i > suggest to my customer ..because even with Jboss 4.2.0 ,tomcat 6.0.13 is > shipped ...so if they upgrade to JBOSS 4.2.0 will it solve their issue??
If the bug is fixed in 6.0.19 and JBOSS includes 6.0.13, it's obviously not fixed. > .They > are using Java Code to serve the PDF and i got one suggestion to implement > byte serving functionality in the servlet but it is causing some performance > issues.It is quite urgent and any help will be highly appreciated. The issue you quote refers to the DefaultServlet which serves static files. If your customer is generating a PDF on request, within a servlet, then this bug fix will not solve their problem. They would need to a) advertise and b) manage delivery of the Accept-Ranges. Random access to a file requires that all of the bytes of the file are available. If the PDF is generated on demand, then you'd need to generate it each time before you can select a byte range from within it. I presume that this is the issue you refer to when you say that it is "completely downloaded in the memory first" and that it's causing performance problems - the client is making multiple requests for the same resource and the generator servlet is causing multiple heavy hits on the server. If my assessment of your problem is correct, then you would need to create the PDF once only but then make the same data available to subsequent requests. You could do this a couple of ways: 1. create a hard file once, during the initial request (perhaps by intercepting the request with a Filter that checks the file doesn't exist & generating it), then allow Tomcat to serve it as a static file for subsequent requests. Downside: not fixed until +6.0.19 is released 2. create the PDF as a byte array, cache it for a short period, roll your own Accept ranges implementation. Chances are that the requests will come in short bursts for the same file; after a short period of no requests for a resource, dispose of the cached byte array. Downside: keeping large objects in memory might be problematic p > Regards > Kapil > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
