This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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.
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.
An IDE is no substitute for an Intelligent Developer.
Joined: Jan 23, 2009
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.