ViewExpiredException triggered by Servlet-generated sessions

Question

I have spent some time reading BalusC's answer on this question but I can't seem to apply that knowledge to my situation. I am also getting the ViewExpiredException but only under certain circumstances.

My page is backed by a @ViewScoped bean and uses two p:layoutUnits to display a p:tree (west) with the contents of the folder in the center pane. Selecting a folder in the tree triggers an AJAX event to update the center pane with the contents of the selected folder. The skeleton of the JSF is as follows:

            <p:layout id="workLayout">

                <p:layoutUnit id="paneTree"
                              position="west"
                              size="200">

                    <h:form id="treeForm">
                        <p:tree value="#{workspace.listTree}"
                                var="node"
                                dynamic="true"
                                selectionMode="single"
                                >
                            <p:ajax event="select"
                                    listener="#{workspace.onNodeSelect}"
                                    update="panelData"
                                    />
                            <p:treeNode>
                                <h:outputText value="#{node.name}" />
                            </p:treeNode>
                        </p:tree>
                    </h:form>

                </p:layoutUnit>

                <p:layoutUnit id="paneData"
                              position="center"
                              resizable="true">

                    <h:panelGroup id="panelData" >
                        <h:form id="formData" rendered="#{workspace.selected ne null}">
                            <h2>#{workspace.selected.name}: #{workspace.selected.title}</h2>
                            <p>

                                <div id="divImages"
                                     style="width: 49%; height: 99%; float: right">

                                    <p:panel rendered="#{empty workspace.listImages}">
                                        <p>No Images In This List.</p>
                                    </p:panel>

                                    <ui:repeat value="#{workspace.listImages}"
                                               var="img"
                                               >
                                        <p>
                                            #{img.name}: #{img.title}
                                        </p>
                                        <img src="#{workspace.getUrl(img)}"
                                            style="max-width: 250px"
                                             />
                                        <hr/>
                                    </ui:repeat>

                                </div>
                                <div id="divDocs"
                                     style="width: 49%; height: 99%; float: left">


                                    <p:dataTable id="tableFiles"
                                                 value="#{workspace.listDocuments}"
                                        >
                                        <p:column  ...
                                        <p:column  ...
                                        <p:column  ...

                                    </p:dataTable>

                                </div>

                            </p>
                        </h:form>
                    </h:panelGroup>

                </p:layoutUnit>

The trouble starts when you select a folder that has a few images in it. As little as 10 or fewer images is enough to create the problem. This causes the ui:repeat element to render the number of img tags, each with a URL that loads an image.

The URL triggers a Servlet in the application that the same CDI domain so it can inject the same resources as the managed beans do. The Servlet responds with just a response header with the MIME type and the data. However each img access creates a new @SessionScoped bean -- the same one this JSF page uses. It does not get the same instance as the JSF page and the various img accesses do not share a session bean between them either. Each access generates a new one.

The Servlet looks like this:

@WebServlet(name = "Obj", urlPatterns = {"/obj/*"})
public class Obj extends HttpServlet {

    @Inject ProtoObjectControl poc;
    @Inject UserSession us;

The UserSession is the @SessionScoped object that contains login information (which is not logged in since it always generates a new one) and various utilities like the log functions. The ProtoObjectControl is a DAO object to fetch the image to display.

The end result is that the page that did the display ends up crashing with a ViewExpiredException. I think this is because the explosion of sessions is consuming resources that are getting exhuasted. If I take out the img tag and run the page with that the ViewExpiredException never comes up and the page works as reliably as Mac Finder or Windows File Explorer.

So is there any way to explain why this happens and to engineer around it? I want to not have a limit on the number of images that can come up in the display. Ideally I would like to have the Servlet access the same UserSession bean as the JSF page -- it is after all being accessed from the same client -- but perhaps that is not possible. Is there any other approach?

Answer 1

Based on BalusC's input above I think this problem has been solved. The error was in my code as follows:

public String getBaseUrl() {
    if (baseURL != null) return baseURL;
    FacesContext fc = FacesContext.getCurrentInstance();
    if (fc == null) return "";
    ExternalContext ec = fc.getExternalContext();
    baseURL = String.format("http://%s:%d/%s/",
            ec.getRequestServerName(),
            ec.getRequestServerPort(),
            ec.getRequestContextPath());
    return baseURL;
}

Using this method generates URLs of the form:

http://localhost:8080//MyApp/obj?id=nnn

The problem of course is the double slash before the application context path. Correcting this results in no new sessions being created because the container correctly correlates the GET requests to the servlet as part of the same session.

Although the program works now there are two unresolved questions:

1. In all the extraneous sessions, each got a JSESSIONID cookie with a different value. But with Firebug I could not find any corresponding set-cookie coming from the server. So where were those values coming from?

2. It would seem that JSF applications of this nature -- where you use a Servlet to serve objects that fill in a page -- require that the Servlet execute in the same session context as the main application. The unexplained (to me at least) question is why did the Faclets page crash just because the URL in the src tag was malformed and extraneous sessions were being generated? I wouldn't expect it to if the URL was addressing a different server (a image storing service for example). I would also expect Glassfish to handle thousands of sessions with no problem.

Hopefully this article will save somebody from this particular pitfall someday.