Kapil Bansal wrote: > Hi Pid, > Thanks for the reply,the PDF is already being generated before it is passed > to the servlet, in the Servlet they are just attaching a end user specif > Watermark to the PDF .So when the end user tries to view the PDF ,he has to > wait for the full file to download and then only they can see it.
Which, to all intents & purposes is the same as generating it from scratch. > I have > checked that PDF is linearized already ....so is there a way that we can > force the Jboss to byte serve the PDF or as Mark said "Get the latest > default servlet from svn and use it to replace the one shipped with JBOSS" > ... > I have tried to replace the web.xml from the tomcat 6.0.x and placed it in > the tomcat 5.5 directory ,as the web.xml was having mime type changes in it > ..but it did not give any positive results... That's not the problem and won't help. > I was sugeested two options... > 1) Implement byte serve protocol in the Java Servlet Which is (effectively) the same as my second suggestion. > 2) Implement a Web Server like IIS etc..and let it take care of streaming Which is (effectively) the same as my first suggestion. An updated Tomcat will serve the file perfectly well, but only if it's saved to the file system first. p > is there any other way by which youcan help me out.. > Regards > Kapil > > > On Sun, May 17, 2009 at 5:59 PM, Pid <p...@pidster.com> wrote: > >> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
