HttpSession problem when client on same server

[Rodger Donaphon]

In my application, a java client program is accessing a servlet. Debugging the servlet I discovered that HttpSession.isNew() always returns TRUE when the client is on the same host as the servlet. The servlet returns XML data. The client is treating the servlet as an InputStream.

It works OK when the client is on a different machine, like my desktop PC. I access the servlet using a fully qualified domain name, but it is locally resolved. The final domain name is TBD and not yet on a DNS server.

I started using Tomcat5. Upgraded to Tomcat 6. No improvement.

According to my research, my problem can occur if the client refuses to accept the session. Not sure what that means. I tried using the HttpClient library, but it did not help.

For debugging, this is a BIG problem since all develop and unit test are on the same server.

To isolate the problem I am using the following simple test. processRequest simply returns the value of 'count'. Normally, it should increment each time the servlet is accessed. But when the client is on the same machine as Tomcat, it is stuck at 1 because httpSession.isNew() is always returning TRUE.

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        HttpSession httpSession = request.getSession();
        if (httpSession.isNew()) {
            count = new Integer(1);
            httpSession.setAttribute("count", count);
            httpSession.setMaxInactiveInterval(-1);
        } else {
            count = (Integer) httpSession.getAttribute("count");
            count = new Integer(count.intValue()+1);
            httpSession.setAttribute("count", count);
        }
        
        processRequest(request, response);
    }

Any input would be appreciated.

[Bear Bibeault]

Why do you care whether the session is new or not? Sounds like you might be trying to use the session lifecycle in an inappropriate manner.

[Rodger Donaphon]

The real application needs the servlet to maintain session variables. The example code with the 'count' session variable is just for troubleshooting purposes.

[William Brogden]

Exactly how is this "client program" accessing the servlet? What does the client program do to preserve cookies?


Bill

[Bear Bibeault]

But you really haven't answered the question. Why do you care if the session is new or not?

[Tim Holloway]

Bear Bibeault wrote:But you really haven't answered the question. Why do you care if the session is new or not?

Huh? Because if the session is new, the session variables set in earlier requests aren't going to be there. It will be a blank session.

It sounds like one of 2 possibilities, neither of which actually depends on whether or not the client and server are on the same machine:

1. The failing client has cookies disabled and there's no URL rewriting in effect, so there's no place to pass the session ID back and forth between client and server. Since all HTTP requests are "one-off" with no enduring connection, there's no other way to keep the session identity in sync.

2. The client is doing low-level "brute force" HTTP. The HttpURLConnection can automatically handle cookies, but straight do-it-yourself network read/write logic would only handle the cookies with the session ID in them if the client implemented the low-level cookie logic explicitly.

[Rodger Donaphon]

Thanks for your input.

The problem is that I did not understand how cookies are used to maintain session.

Once I added code to save the JSESSION cookie and put it in subsequent requests, the problem went away.