Interesting. I am familiar with thread issues, and the backend code does not have any static variables either. However, this exchange may have uncovered the problem.
Something I am unclear about is the code that connects the frontend to the backend. It seems like GWT duplicates some of the intermediary code that connects the two ends. One in Java that runs on the backend, and another copy that runs on the frontend in JavaScript. For example, the code that defines the data structure that is transmitted between the ends must be available on both ends. This may be where my problem is. I do have instance variables there. Off the cuff, I'm not sure how to protect that. Thanks for the help! Blake On Fri, May 10, 2013 at 7:45 AM, Jens <jens.nehlme...@gmail.com> wrote: > If I run it from a single browser (as I do during development) it runs >> fine. It becomes flaky when I try to use it from different browsers and/or >> different machines at the same time. I know about tomcat reusing the same >> backend instances so I am sensitive about that. (I don't know if GlassFish >> does that too.) The backend code for the flaky part has no instance >> variables so reuse should not be a problem. >> >> Due to the responses on this mailing list and my tests, I now think the >> problem is on the backend. One instance runs fine. If I introduce a >> second instance, the second instance runs fine but then the first instance >> messes up randomly. I'll keep looking. >> > > Sounds like a typical thread safety issue. As you said you dont have > instance variables, do you have non final static class variables? If so, > your code probably does not do what you think it should do. Lets assume you > have static int intVariable = 0; somewhere and Thread A sets value to 5 and > later on expects to read a value of 5. Between write and read a second > Thread B could modify the value. This can even happen between two lines of > code. > > Depending on the concrete code you want to use synchronized blocks, > ThreadLocal variables, classes from > http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html > > In case of ThreadLocal variables, make sure to clean them up once the > request is done. Otherwise you probably run into a ThreadLocal memory leaks > and PermGen space issues on redeployment. > > -- J. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@googlegroups.com. > Visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
