Central server not updating graphs when monitoring multiple applications.

[GoogleCodeExporter]

I have a suite of webapplications all monitored with javamelody. All use 1.44.0 
for monitoring so I deployed the same version of the optional central server to 
a separate server, and added the urls to the different applications. All the 
applications are added, and corresponding folders is added to tomcats temp 
directory.

Switching between the applications works pretty much as expected. All 
statistics is fetched from the correct application, but not the graphs. All 
graphs are displayed correctly for the first application, but when switching 
between applications, the graphs stay the same. Refreshing the browser window 
does not show correct graphs.

I use Tomcat 7.0.42 with Java 1.7.0_40 server jre on a Windows 2012 server for 
running the collect server. The javamelody version is 1.44 for all 
applications. I have tested using IE10.

Original issue reported on code.google.com by gunnar.v...@gmail.com on 20 Sep 2013 at 8:55

[GoogleCodeExporter]

Is it reproduced with Firefox or Chrome?

Original comment by evernat@free.fr on 23 Sep 2013 at 11:38

[GoogleCodeExporter]

I have tried with IE9, IE10, FF22 and FF24. 

FF is working as expected. IE is not.

Original comment by gunnar.v...@gmail.com on 24 Sep 2013 at 9:19

[GoogleCodeExporter]

At the moment, I do not reproduce the issue with IE8 (sorry), Java 1.7.0_40 and 
the embedded Winstone server inside the centralized server (that is the one 
started by "java -jar javamelody.war").

Are you able to stop Tomcat, then start Winstone with something like "java -jar 
javamelody.war" to do a test?
And / or do you have IE8 somewhere to do a test?

Thanks

Original comment by evernat@free.fr on 30 Sep 2013 at 8:40

[GoogleCodeExporter]

I am experiencing this issue as well. When clicking through the applications, 
the graphs are static, but the statistics are completely different. I'm using 
1.41.0 in the applications and for central collect server.

Original comment by brent.at...@gmail.com on 1 Oct 2013 at 1:43

[GoogleCodeExporter]

I found that my problem was actually being caused by the fact that the collect 
app uses a cookie to pass the current application to the servlet for rendering 
the right graphs (check those URLs, there's no path or parameter that denotes 
which app to render). The problem was that the cookie's path didn't match with 
the path that the browser was using - because it is behind a reverse proxy and 
the URLs are being rewritten.

After using mod_proxy's top ProxyPassReverseCookiePath directive to correct the 
paths being sent back to the browser, everything seems to be working fine.

Original comment by brent.at...@gmail.com on 1 Oct 2013 at 4:10

[GoogleCodeExporter]

I get this error even when connecting directly to tomcat, bypassing the proxy. 
But I guess the cookie probably is the cause for this problem. I'll check.

Original comment by gunnar.v...@gmail.com on 2 Oct 2013 at 8:16

[GoogleCodeExporter]

I am using the same name for the proxy and the application. Both use the name 
javamelody. But in IE the cookie is not passed when fetching the graphs, only 
when fetching the html.
I checked the application in Chrome, and there the cookie is passed along with 
the requests also when fetching the graphs.

Original comment by gunnar.v...@gmail.com on 4 Oct 2013 at 7:41

[GoogleCodeExporter]

@brent
I have added a note in the user guide to better help users with similar case:
https://code.google.com/p/javamelody/wiki/UserGuideAdvanced#6._If_reverse_proxy
Thanks

Original comment by evernat@free.fr on 6 Oct 2013 at 3:45

[GoogleCodeExporter]

@gunnar
Do you know what was going on with the cookie in MS Internet Explorer?

A thing to check would be the date and time of the server and of the client. 
Because the cookie is persistant for 1 month, if the server's date is far in 
the past the cookie may be too old for MSIE as soon as being created.

Original comment by evernat@free.fr on 10 Nov 2013 at 11:37

[GoogleCodeExporter]

All the servers are synchronized with an external ntp server, so the date is 
not the issue.

I haven't spent time investigating this further, but what I noticed was that 
the request did not contain cookies when fetching the graphs. Regardless if I 
used the apache-proxy or adressed tomcat directly.

Original comment by g...@knowit.no on 10 Nov 2013 at 2:40

[GoogleCodeExporter]

I tried to find some way to force IE to use cookies when fetching graphs, but 
alas. Neither changing document mode, or changing user agent string works. Nor 
emptying the browser cache.

I even tried to enable third-party cookies in IE, but that did not make a 
difference.

Original comment by gunnar.v...@gmail.com on 14 Nov 2013 at 9:16

[GoogleCodeExporter]

@gunnar
Are there non-alphanumeric characters in the hostname of the server, such as 
underscore (_)?
I think that MS Internet Explorer doesn't like cookies for a hostname which 
contains an underscore, unlike all the other browsers.

Original comment by evernat@free.fr on 16 Nov 2013 at 9:58

[GoogleCodeExporter]

That is in fact exactly the case. The servers name does indeed have an 
underscore in it. I will try to adress the application with the ip-adress and 
see if that does the trick. 

Original comment by gunnar.v...@gmail.com on 17 Nov 2013 at 3:21

[GoogleCodeExporter]

So, the solution is to not name the server running your collect server with a 
name containing an alphanumeric character. I tried accessing the server by it's 
ip-adress, and all the graphs showed up correctly.

From: 
http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-interna
ls-faq.aspx

Q5: IE won’t set a cookie when the hostname/domain contains an underscore?

A: Correct. Technically, underscore is not a DNS character, and while Windows 
will let you use an underscore when naming your machine, it warns you that 
doing so may cause problems. One such problem is that WinINET blocks attempts 
to set cookies on such domains.

Original comment by gunnar.v...@gmail.com on 17 Nov 2013 at 3:30

[GoogleCodeExporter]

At the end, this is an issue in Internet Explorer and not in javamelody.
Resolving as invalid for javamelody.

Original comment by evernat@free.fr on 17 Nov 2013 at 8:04

• Changed state: Invalid