a few HTTP hits are lost for the first hit(s) on new requests

[GoogleCodeExporter]

As said by manolis in the users group 
(http://groups.google.com/group/javamelody/browse_thread/thread/c2562230440c85fa
):

Hi,
first of all thanks, for this great software.
I am using it the last 2 weeks and I face a strange issue. I was using our
own application but I replicated the behavior with the test-webapp bundled
with javamelody software.
I believe some http requests hits are lost and do not appear in the monitor 
page. I observed that with the http requests I am not sure about the other 
counters
The environments I am using is
os: windows xp
jdk: java version "1.6.0_22"
container: tomcat-6.0.20

How you can replicate it:

a)Install test-webapp on tomcat
b)Clean any statistics in the melody storage-directory about the
“test-webapp”
c)Access http://localhost:8080/test-webapp/index.jsp and reload it 2,3 times

d)Access http://localhost:8080/test-webapp/index.jsp. You will see no http
statistics there

Same applies for any other url

From my little investigation, I believe the above has to do the following:
1) Every time you make a http request, this is added to the Counter with
name=“http”, storageName = “http”. However, in order to be visible to 
the
/monitoring page it has also to be added to the Counter with name=“http”,
storageName = “http_<yyyyMMdd>”
This is done in the method Collector.collectCounterRequestData inside the if 
block
I believe that this method is a called either when the
FilterContext$CollectTimerTask runs, or the /monitoring url is accessed

2) 1st time the method Collector.collectCounterRequestData is called for a
given newRequest, the call to:
final CounterRequest request = requestsById.get(requestStorageId);
returns null thus the flow does not enter the if block below and the
newRequest is added to the requestsById at the end of the method

3) On the next invocation of the Collector.collectCounterRequestData now the 
call:
final CounterRequest request = requestsById.get(requestStorageId);
does return a request object. However if the hits of the newRequest remain
the same; i.e. the URL in question was not accessed again in the meantime,
then the call to:
lastPeriodRequest.removeHits(request);
return 0, thus again the flow does not enter the if block below. If however the 
hits were increased then the request is added to the Counter with storageName = 
“http_<yyyyMMdd>” and everything is ok.

Since I believe that the FilterContext$CollectTimerTask runs every minute, I 
guess that for every new request, we only miss the clicks/hits for the first 
couple of minutes, so it not big harm. However, I am not sure of this occurs 
also under different scenarios, that is why I reported.

Original issue reported on code.google.com by evernat@free.fr on 30 Apr 2011 at 1:42

[GoogleCodeExporter]

Manolis is right. hits are not lost when looking at the statistics of the "all" 
period, but a few hits may not be added correctly when looking at the 
statistics of the "day" period.
This is because of how the delta of hits is computed every minute in the method 
Collector.collectCounterRequestData.
This happens only for the first hits on new requests which were unknown before 
and so which are not yet in the statistics for the "all" period. And this 
happens only for the hits on these new requests in the first minute when these 
requests are unknown (or less depending on CollectTimerTask).
So very few hits are currently lost, and it has mostly zero impact on the 
statistics overall: no harm.

But still after a complete study, a change will be made to fix this.

Original comment by evernat@free.fr on 30 Apr 2011 at 1:55

[GoogleCodeExporter]

The fix is committed in trunk (revision 1846) and it is ready for the next 
release (1.29).

I have made a new build with the fix and it is available at:
http://javamelody.googlecode.com/files/javamelody-20110430.jar

Original comment by evernat@free.fr on 30 Apr 2011 at 5:18

• Changed state: Fixed