> > @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, [email protected] > 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. >>> >>> [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/50dfce72-bc17-4dc0-94ad-6eca08bf0b43n%40googlegroups.com.
