Bad sample timestamp
omixen
I just installed the latest java melody (javamelody-1.29.0.zip) for
one of my webapps (not on tomcat) on Tomcat 5.5
The dashboard is working great, and I have configured the MySQL
settings, and it is working fine as well.
However, I'm still getting the bad sample timestamp (see below). I
tried recompiling the jar from SVN, and make sure the synchronized is
there, but still getting the error now.
Any help would be appreciated.
Thanks,
Tom
Here's what my log says:
WARN - exception while collecting data
java.io.IOException: Bad sample timestamp 1307635450. Last update time
was 1307635450, at least one second step is required
at net.bull.javamelody.JRobin.createIOException(JRobin.java:373)
at net.bull.javamelody.JRobin.addValue(JRobin.java:321)
--
at net.bull.javamelody.Collector.collect(Collector.java:257)
at net.bull.javamelody.Collector.collectWithoutErrors(Collector.java:
243)
at
net.bull.javamelody.Collector.collectLocalContextWithoutErrors(Collector.java:
233)
at net.bull.javamelody.FilterContext
$CollectTimerTask.run(FilterContext.java:52)
--
at java.util.TimerThread.run(Timer.java:462)
Caused by: org.jrobin.core.RrdException: Bad sample timestamp
1307635450. Last update time was 1307635450, at least one second step
is required
at org.jrobin.core.RrdDb.store(Unknown Source)
Emeric Vernat
It is not a very common error and I do not have much to suggest, sorry.
I suppose that you have added the javamelody jar file in WEB-INF/lib.
(not in tomcat lib directory).
I suppose that the webapp was deployed correctly without a hot
redeployment going bad (leading to several javamelody threads perhaps)
and that the server resources (cpu, memory) are ok.
If there is no obvious solution, I suggest testing on another server or
another webapp in order to find the difference with a working case.
bye,
Emeric
Le 09/06/2011 18:33, omixen a �crit :
omixen
for more information on JRobin.
1. a hint from another website via Google: PERHAPS it could be because
it is trying to write on the same Rrd file in case there are two
separate instances of the Java Melody in the same server.
2. Perhaps related to this topic as well:
http://groups.google.com/group/javamelody/browse_thread/thread/a5f73a85961ee7f5/8904742b1bc35112?lnk=gst&q=port#8904742b1bc35112
The following is my take on this issue which is not yet confirmed. You
can tell me if I'm wrong, I will post my fix here as well.
As I figured out, didn't realize this before, we have two webapps
pointing to the same lib folder (one of the webapp (test environment)
has a shortcut to the the other's (staging) lib folder)
anyway, basically having two different webapp on the same server,
running with no context, just different port number creates the
exception.
e.g.
[1] http://localhost:8001/
and
[2] http://localhost:8002/
[2] has its lib pointing to [1]'s WEB-INF/lib folder (which has
javamelody and jrobin jars)
web.xml has only been modified on [1]
both webapps are writing to the same Rrd folder: $CATALINA_BASE/temp/
javamelody/<app_localhost>
Considered fix: try to incorporate port number or app specific
identifier.
I'm gonna try to do this fix and see, but would be great if javamelody
official release takes this into consideration.
thanks,
Tommy
omixen
I'm still getting the error after the followings:
Tried configuring javamelody on the second webapp.
Explicitly set a different rrd directory using the storage-directory
param:
<filter>
<filter-name>monitoring</filter-name>
<filter-class>net.bull.javamelody.MonitoringFilter</filter-class>
<init-param>
<param-name>storage-directory</param-name>
<param-value>javamelody_app_host_port</param-value>
</init-param>
</filter>
Confirmed that both directories got created when the server was
restarted.
And the data on /monitoring was reset and different from one another.
Since there are two instances of javamelody in this server currently.
I'm seeing on the dashboard right now under threads: (number shows how
many instances shown)
2 javamelody
2 jrobin
5 javamelody app_name
5 jrobin app_name
1 javamelody dummytobringup
1 jrobin dummytobringup
Do these numbers sound correct?
Thanks in advance.
Tommy
On Jun 14, 10:26 am, omixen <omi...@gmail.com> wrote:
> Thanks for your reply. I looked into those hints you gave and searched
> for more information on JRobin.
>
> 1. a hint from another website via Google: PERHAPS it could be because
> it is trying to write on the same Rrd file in case there are two
> separate instances of the Java Melody in the same server.
> Thanks for your reply. I looked into those hints you gave and searched
> for more information on JRobin.
>
> 1. a hint from another website via Google: PERHAPS it could be because
> it is trying to write on the same Rrd file in case there are two
> separate instances of the Java Melody in the same server.
Emeric Vernat
In your previous email, you were saying "it is trying to write on the
same Rrd file in case there are twoseparate instances of the Java Melody
in the same server". I would say Yes, it could be something like that,
if we add "and in the same webapp" at the end.
And if we read the names of the threads in your last email it could be
the case.
But first, it was a good idea to use the storage-directory parameter, in
order to use different directories in this case (same computer, same
webapps names in two server instances).
Then, it does not work yet, so it is something else...
You said:
"2 javamelody
2 jrobin
5 javamelody app_name
5 jrobin app_name
1 javamelody dummytobringup
1 jrobin dummytobringup".
These numbers do not sound correct at all.
If you have configured javamelody in only one webapp, there should be only 1 thread with name starting with javamelody and 1 thread with name starting with jrobin.
And not 8 of each thread ! And if "app_name" is the name of your webapp, what is "dummytobringup" and why is there javamelody threads in this webapp?
Why are there so many javamelody filters initialized with each one
starting 1 javamelody and 1 jrobin threads ?
I suppose that the configuration between the 2 server instances is
related to the issue.
(and do you confirm that you use Tomcat 5.5 and not Tomcat 7 ? I ask
because of web-fragment.xml)
bye,
Emeric
Le 14/06/2011 21:50, omixen a �crit :
omixen
Thanks for the reply. I'm still investigating the issues when I get
the chance. We are using Tomcat 5.5.
Could you tell me the correct number of threads I should expect to see
from the /monitoring ?
-Tommy
Darren Hartford
Would it be feasible, and reasonable idea, to provide functionality such as in the web.xml params/commandline startup params of javamelody to provide 'markers' for app versions?
Usecase I have is that each update/deployment of the code will have various fixes that, from the javamelody review point of view, should have an impact on specific methods (http, ejb, sql, etc). It would be nice to have a marker on each collection/aggregate based on the app version.
From a detail-point-of-view showing over a long period of time show the same method with different statistic characteristics for each app version would really help represent if the app is improving over time. (or, just show one specific app version of statistic information)
thoughts? feasibility?
-D
Emeric Vernat
If you are still investigating this issue, the answer is:
If you have configured javamelody in only one webapp, there should be only 1 thread with name starting with javamelody and 1 thread with name starting with jrobin.
And if you have 2 monitored webapps in one server, you will have 4 threads, etc.
bye,
Emeric
Le 16/06/2011 20:36, omixen a �crit :