Sample start time is incorrect when there is a connection failure

[Minna]

Hi,

Whenever there is a connection failure, the sample start time of that particular request is defaulted to 1970-01-01 and if we are running the test in CLI mode, the sample start time in .jtl log is displayed as 0 and in dashboard report also start time is shown as 1/1/70 . This in turn generate wrong graphs.

We have given 0 delay between requests and hence when large tests are run, we get the Connection failure message Close frame with status code 1001 and close reason 'Server cannot accept new client connection in state Closing', and subsequent requests gives error Sampler configured for using existing connection, but there is no connection and the wrong graph is displayed for this particular error.

Could you please check this and give a solution. Sorry for being demanding, but it will be really helpful if you could help me out as soon as possible since we have planned a project release this week and have encountered this issue at last minute and we cannot deliver without a proper explanation for incorrect dates and graphs.

Please find attached the error screenshots

Regards,

Minna

[Minna]

Hi,

Any update on this issue. Is this a bug or a settings change required..?

Thanks

Minna

[Peter Doornbosch]

Well, the start time is not set and the reason for that is that the sampler did not start. And the sampler did not start, because it is configured to use a connection which is not there. You could prevent this situation by configuring a different “Action to be taken after a Sampler error” in the enclosing Thread Group.

I do not consider this to be bug, because start time is used to compute the duration of the request; setting start and end times when there is no request will lead to incorrect computations w.r.t. duration times. There was no request made, so the start time of the request cannot be determined.

The fact that JMeter displays absence of start time as a date in 1970 should be considered as a bug in JMeter. This is caused by a common programming mistake: taking a (valid) value to have a special meaning (“not set” in this case).