Re: getThreadLocalRequest.getSession null

@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.

 

@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? 

Le vendredi 30 septembre 2022 à 03:50:53 UTC+2, ma...@craig-mitchell.com a écrit :

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.

On Thursday, 29 September 2022 at 6:24:33 pm UTC+10 Jens wrote:

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.

dhia.xd...@gmail.com schrieb am Mittwoch, 28. September 2022 um 12:21:36 UTC+2:

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.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/50dfce72-bc17-4dc0-94ad-6eca08bf0b43n%40googlegroups.com.