JSF and Primefaces File upload and download speed optimization - a case for multithreading?

[Jay Tai]

I'm using Primefaces in a JSF application to upload and download files. This is fine for small files but becomes slow for larger files, even to the point that donwloaded files end up corrupted. My guess is that this is caused by network interruptions due to excessively long download times.
The network being used is broadband and the download speeds are similarly slow accross different types of networks.

My most immediate need is to speed up document downloads if that's possible so i"ll use the download methods as my example.


The jsf:

  <p:commandLink id="downLoadLink" value="Download" ajax="false">
                                <p:fileDownload value="#{proDocFolBean.downloadFromFolders}" 
                                                contentDisposition="attachment"/>
                            </p:commandLink>

The backing bean method:

    public StreamedContent getDownloadFromFolders() throws FileNotFoundException {

        docToDownLoad = selectedProDocs.getRowData();
        
        int id = docToDownLoad.getProjectDocId();
        docToDownLoad.setProjectDocId(id);
        docToDownLoad = docsFacade.find(id);
        pathName = docToDownLoad.getPathName();
        docToDownLoad.setPathName(pathName);
        docName = docToDownLoad.getDocName();
        docToDownLoad.setDocName(docName);

        contentType = FacesContext.getCurrentInstance().getExternalContext().getMimeType(pathName);

        return new DefaultStreamedContent(new FileInputStream(pathName), contentType, docName);

    }

    public void setDownloadFromFolders (StreamedContent downloadedFile) {
        this.downloadedFile = downloadedFile;
    }

My questions are:

1) Can modifying my methods better optimize download speed? For instance, should I be thinking about using multithreading (even though I've read about the hazards of manually creating multiple threads)?
2) Is JSF and PF a sensible combination to use for these types of function?
3) Any other suggestions for how to optimize the speed in terms of what I'm trying to achieve?

Many thanks in advance!

[Tim Holloway]

I had a little discussion the other day on this forum about JSF2.2 and how JSF seems to be turning from a "do 1 thing and do it well" framework to a "do HTTP no matter what sort of violence it involves".

This is sort of a case in point.

I've always maintained that it's cleaner to put JSF aside and do one's downloads via straight servlets or JSPs instead of warping JSF to do that sort of work. On the other hand, you have a ready-made taglib to obscure most of the warts, so... OK.

Multi-threading isn't going to help you here, unless you can figure out how to make a torrent out of it anyway. So relax, you don't have to consider violating the J2EE constraint on spawning threads.

And I don't think that there's anything you can actually do in the webapp that's going to make it better, whether it's something I'd put my blessing on or not. The mechanisms here are ultimately fairly simple, even if getting at them without a boost from something like your PrimeFaces tag isn't very pretty.

What I'm afraid of is that you have an infrastructure issue. First off, just to say you did it, I'd check the disk drive itself using whatever disk utilities are appropriate. For example, "badblocks" for Linux, or the Windows filesystem checker with block check (requires reboot). And, if it's a fragmentable filesystem you're dealing with, defrag it just for good measure. In the case of uploads, make sure there's a comfortable free-space cushion, as that will reduce potential fragmentation.

Then comes the hard part. If you're seeing corrupted data in the upload/download process, then it's likely that at some point along the network path there's at least one unit that's mis-configured or defective. In the old days that was often a bad MTU setting, although I've gotten the impression that MTUs are more self-adjusting these days. So make friends with a network tech!

Something that might help is to break the transmission into chunks, but chunking does require some software support. Check the PrimeFaces tag to see it has chunking options built in. If not, you're not likely to be able to explore that route unless you dirtch the Primefaces tag and go to raw code.

[Jay Tai]

Thanks for a typically insightful answer. Bear with my long response. The infrastructure is going to be my first port of call. In light of what you said, I also want to DO SOME JSF 'soul searching' and figure out if there's non infrastructure which flaws which can be non-violently fixed by JSF or outside JSF. First let me understand something about the limitations of JSF.

I've heard no end of horror stories about this. I've ended up with a virtually end to end enterprise application which I wrote almost purely in JSF with the usual compliments of POJOs, JPA and PF. The application covers security, document management, project management, stats management functionality and then some. Much of the insights for doing it gained from this forum, sleepless nights but minimal JSF violence. The application appears to work quite well for 30+ users SO FAR. Alongside the horrifying tales, including Gosling himself professing his passionate hate for JSF, I've been surprised at the framework's flexibility and reach. Maybe I've done something fundamentally wrong by relying so heavily on it? Or, maybe JSF isn't so bad after all. As I understand it, JSF simply promises the ability to interact fairly efficiently with POJOs and/or servlets. So, doesn't that mean flexibility is the core of JSF's design logic? I'm also aware of the JSF / Spring compatibility but in all honesty I've given in to development deadlines using what I know and simply haven't put in the time to learn enough about Spring YET!

So, I'm agreeing with your recommendation to look in the architecture first, but simply asking at this point if you agree that JSF has become quite a robust framework for good range of needs. Finally, coming back to your discussion about:

I had a little discussion the other day on this forum about JSF2.2 and how JSF seems to be turning from a "do 1 thing and do it well" framework to a "do HTTP no matter what sort of violence it involves".

Could you give an example of the 1 thing JSF does well and how everything else fits around that? Thank you!

[Tim Holloway]

The "1 thing" that JSF does well is MVC. JSF is, in fact a virtually pure implementation of the Model/View/Controller paradigm with no excess baggage or kludges needed to make it work. You design the Views using templates, design the Models as POJOs, and the Controllers are already done for you. JSF renders the forms and data, validates the inputs, reports errors, updates the Models and invokes the associated business logic (action methods). All automatically, with minimum fuss.

Perhaps just as importantly, JSF is a non-greedy framework. In older times one problem that most frameworks (and many IDEs) had was that they expected to own the entire app and constrain their will on the shape of the app. JSF allows you to do JSF things, but stuff that isn't a good fit for JSF can still be done with raw servlets and JSPs, and even other non-greedy frameworks (such as Struts).

And, last, but hardly least JSF does all this using stock components and generic functions wherever possible. CSS, JavaScript, J2EE scoped objects. And it does integrate well with Spring.

Having said that, JSF is not for everyone or everything. There's a lot of overhead in all that magic and I've never gotten a good feel for how well it works at scale. There's such a large class of applications that have no more than a handful of users that it hasn't mattered to me. Especially since JSF's non-greedy nature makes it easy to swap out JSF forms on a case-by-case basis for something lighter if I do run into bottlenecks. And, of course if an app is primarily a web service provider or some other application that's not a heavy user of forms, it's not appropriate.

Still, there's plenty of places where JSF excels, so until something better comes along, it's going to be one of my preferred tools.