On Mon, Sep 15, 2014 at 3:38 PM, Peter Kirby <lpki...@harding.edu> wrote:
> On Mon, Sep 15, 2014 at 2:01 PM, Peter Kirby <lpki...@harding.edu> wrote: > > > On Mon, Sep 15, 2014 at 10:26 AM, Daniel Mikusa <dmik...@pivotal.io> > > wrote: > > > >> Have you tried deploying a simple test application to confirm that > >> clustering is working properly? > >> > > > > I just setup a small session counter and it appears to not be shared > > across the different servers correctly. Thanks for the suggestion. I'll > > keep working on that and reply again if, after fixing session info, I > still > > have the same problem. > > > Well, if I had known it would be that fast of a fix, I would not have > replied to the email. I had accidentally left one server on Tomcat 8.0.12 > and the other on Tomcat 7.0.55. After they were both on the same version, > the session information is shared perfectly, which is what I expected. > > However, the original problem remains. I discovered I don't even have to > submit the page to fix the "broken" session. I can go to the web page and > after it loads hit refresh. That takes care of the first page that just > resets. After the refresh button I can log in as normal. > > If I do actually submit the first time, the jessionid variable shows up in > the URL when the page comes up the second time in case that's helpful. > > Thanks for your time. > It might be helpful to look at the access logs on your Tomcat instances and also whatever is in front of them. This might start to give an account of what happens after the request leaves your browser. Also might be helpful to increase the log level for clustering. I think the following should be helpful. org.apache.catalina.ha.level = FINEST org.apache.catalina.tribes.level = CONFIG Note, you'll probably also have to set the log level of your handler to FINEST, otherwise that'll filter out these messages. 1catalina.org.apache.juli.FileHandler.level = FINEST or set ".level" for whatever handler the messages are being sent to. Dan
