getThreadLocalRequest.getSession null

[iweb Appe]

I have a gwt app that is running when deployed on tomcat on server A

For some reason the same app when is deployed on tomcat on a server B has a session issue

We have Method 1 and Method 2 inside a servlet that extends RemoteServiceServlet

We have a method1 in which we do:

this.getThreadLocalRequest.getSession(true).setAttribute("myuserid", myuserid)

Then in a second method we do

this.getThreadLocalRequest.getSession(false).getAttribute("myuserid")

which throws a null pointer exception as getSession retuns null

It is strange as this only happens on the server B

I have verified the tomcat config files like context.xml files and they are identical

I have printed currentThread.gtId() inside both methods and they are different but as said no issue on server A.

[Jens]

Use your browser dev tools to inspect the network request. You should check if server B sends back a session id cookie and that this session id cookie is transmitted back to the server for the second method that does getSession(false). If it doesn't or the session is already invalidated (either through code or through session timeout configuration on server B) then getSession(false) will return null.

-- J.

[Craig Mitchell]

Your question lacks some details.  You talk about two servers, but don't tell us if they are active-active, or just running one server at a time.

If they are active-active, we'd need to know how you are doing your session replication between then servers.

If you are only running one server at a time, then Jens reply is a good idea.

I personally prefer to handle sessions myself, with a cookie and a memcache (yes, not really sessions at all), so I can easily scale.  But that's just a little side note.  :)

Either way, this outside of GWT's responsibilities, but still happy to help.

[iweb Appe]

Thanks for your responses.

I still didn't find a solution. We have reinstalled tomcat but nothing's changed.

@Jens I debbuged in DevTools and found that for the server A, there is a Post request containing a sessionId sent to it and intercepted by the service containing both methods. The same request is sent to the server B but doesn't contain a sessionId. I still didn't understand why. The same app is deployed and by the way we can only are using IE to access web pages.

So The sessionId is sent from both servers to the front. But only sent back to server A.

@Craig both servers are working and active.I have no idea about session replication, how do I check that?

This is for sure related to the server, it must be some config or maybe a security config? 

[Craig Mitchell]

1. Don't use IE.  It's a deprecated browser, and GWT no longer supports it.  However, that's unlikely to be your problem.

2. It's still not clear what you're doing.  I suspect you are running the servers independently with different URLs, and not active-active behind a router.

3. Depending on your Web Server, you usually should see your session id in a cookie, not in a post message.  I'm actually not sure how Chrome shows you the cookie transmission in the dev tools, I don't think it does.

[Jens]

@Jens I debbuged in DevTools and found that for the server A, there is a Post request containing a sessionId sent to it and intercepted by the service containing both methods. The same request is sent to the server B but doesn't contain a sessionId. I still didn't understand why. The same app is deployed and by the way we can only are using IE to access web pages.

So The sessionId is sent from both servers to the front. But only sent back to server A.

Ok then you should check the cookie information. Is the cookie domain and path correct and matches both servers (I guess both servers have different subdomains)?

If server A response sets a cookie using "Set-Cookie: sessionId=123; Domain=serverA.company.com; Path=/" then this cookie will not be transmitted to a server on domain "serverB.company.com" because the domain does not match. The same is true if the server response only sends "Set-Cookie: sessionId=123;" because then the domain and path value will contain default values which are taken from the corresponding request.

You would need to set the cookie to "Domain=company.com" in order to share it between different subdomains.

Also, if you do not use session replication on server side, then keep in mind that a session created by server A is unknown to server B. In that case "getSession(false)" on server B would return null because it does not know the sessionId and "false" tells it to not create a new session automatically. 

-- J.