Open marsmith opened 6 years ago
This is the wording we've been using:
We are using a load balancer on production with sticky sessions enabled, so when using the production services there is an injected server-identifying cookie in the response header. If you are using the separate watershed/parameters endpoints, you need to ensure your requests are passing back the session cookies. This should be supported by all http clients, but in some cases needs to be activated. In our case all we needed to do was include the "withCredentials" header. Our service documentation page is outdated so this option has not been enabled, this could also be the cause of some of the issues. One way to verify is to look at the response headers of the watershed services to ensure they are coming from the same machine. You can also look at the "usgswim-hostname" property of the watershed request response, and use that name for subsequent requests. The host name will be either "PRODWEBB" or "PRODWEBA". You can make direct requests using https://prodwebb.streamstats.usgs.gov/streamstatsservices or https://prodweba.streamstats.usgs.gov/streamstatsservices, etc., these should only be used after you've acquired your watershed the way you've been querying it.
Updated response:
StreamStats is hosted on two servers, and we use a load balancer to balance traffic between these two servers. When using StreamStatsServices, you will want to ensure that you use the same server for multiple service requests. There are several ways to do this:
For jquery/ajax: