Unsolved
This post is more than 5 years old
9 Posts
0
3682
Requests Timeout with the increase in the Concurrent Reads
We are trying to do performance testing of our Java application to read from Atmos and to write into Atmos using Rest API (atmos-client 2.2.2). Everything works fine with a few users. As we increase the number of concurrent users in the order of 2000, we see a lot of errors related to Request Timeout mentioned below.
AtmosException{errorCode=1031, httpCode=403} com.emc.atmos.AtmosException: The request timestamp was outside the valid time window.
at com.emc.atmos.api.jersey.ErrorFilter.handle(ErrorFilter.java:61)
at com.emc.atmos.api.jersey.RetryFilter.handle(RetryFilter.java:51)
at com.emc.atmos.api.jersey.AuthFilter.handle(AuthFilter.java:41)
Please let me know if there is a setting that we have to change to avoid such errors.
Thanks,
Vandan
chris_arnett
110 Posts
0
August 26th, 2016 08:00
This error means that the clock on the client and the clock on the server are more than 5 minutes apart. All ECS nodes should already sync their clocks to a central NTP server. You should make sure that all clients are synchronized to the same time.
If this is not possible, you can also use the calculateServerClockSkew() method within AtmosApi to estimate and adjust for the skew between the two machines. Make this call during client creation (perhaps right after the constructor). It is only necessary to call this method once for each client instance.
VandanKumar
9 Posts
0
August 26th, 2016 09:00
Chris,
Thanks for the response. Could you please explain a bit more about the two approaches?
Approach 1:
How do we actually sync the clocks between the Client (in this case this is a windows 2012 server running a Java process) and the Atmos Nodes?
Approach 2:
The API says that the calculateServerClockSkew() method will do the following:
"Calculates rough clock skew. Implementations will likely use the date response header from an inert HTTP request".
And it returns a "long". Could you please explain what I need to do with this "long" to actually adjust the skew between the two machines.
Thanks,
Vandan
chris_arnett
110 Posts
0
August 26th, 2016 11:00
Vandan,
Most modern operating systems are capable of syncing their clocks via NTP. This is true in Windows as well. For more information, look here. If all of the clients do this, you should be fine. ECS is also configured to sync via NTP during installation. It's generally better if both server and client are synced to the same NTP server, but that's not necessary unless one of the NTP servers itself is significantly skewed.
If it's not possible or feasible to configure all of the clients for NTP, or you are still seeing this error, simply calling calculateServerClockSkew() will make the necessary clock skew adjustment. You do not need to capture or assign the return value, but it might be useful in a log statement so you know how far off a particular client's clock is.
- Stu
VandanKumar
9 Posts
0
August 26th, 2016 14:00
Stu,
Thanks for the response. Will try the solution and let you know once I test and confirm the changes.
Thanks,
Vandan