-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connections time out rather often #158
Comments
hi @markusheiden thanks for reporting this. I'm trying to repro it. Can you continuously reproduce this issue? and did you find and steps to repro? |
We are using many (12) threads in parallel to access the API on each instance (> 10 independent instances). This most often happens when we download KeywordPerformanceReportRequests reports via the ReportingServiceManager. I reduced the parallelism to 6 threads and the problem was reduced significantly and currently just happens occasionally. My problem is that I don't know what the limit for parallel access to the API is. What is the exact limit? How is the limit counted: Per developer token, per application (client ID), or per customer? The current behavior (simply not answering) makes it hard to reliably use the API with parallelism. Without parallelism, the API access would take too long. The Google Ads API does this a bit better: They answer with an error that contains the delay that is needed before we may access the API again. Is there something similar in the Bing Ads API too? |
hi there, this error does not seem like related to service side throttling, otherwise client will receive a RATE_EXCEEDED user error. |
@qitia Thanks for clarifying that. We already retry 3 times. Because reducing the load reduces the problem, it has to be some kind of load problem. Maybe the connection timeout is too low under load conditions. How can I increase that? |
https://stackoverflow.com/questions/2148915/how-do-i-set-the-timeout-for-a-jax-ws-webservice-client does above solution helps? |
@qitia Thanks, we will try that. But that solution will not suffice, because when the Bing Ads SDK uses the Apache HTTP Client for the final report download, there is the same problem:
|
According to the CXF docs, the connection timeout can be configured via the See https://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport(includingSSLsupport)-Theconduitelement for the config. This configures the connection timeout to 15 minutes because 5 minutes were to be not enough for us: <beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:http="http://cxf.apache.org/transports/http/configuration"
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/transports/http/configuration http://cxf.apache.org/schemas/configuration/http-conf.xsd">
<http:conduit name="{https://bingads.microsoft.com/Reporting/v13}IReportingServicePort.http-conduit">
<http:client ConnectionTimeout="900000" />
</http:conduit>
</beans> Instead of |
Another one that happened multiple times:
|
Another one:
|
Another one:
|
hi @markusheiden does it help to config the timeout per your previous post? |
No, the connection timeout had already been set to 15 minutes for the above requests in the <beans ...>
<http:conduit name="*.http-conduit">
<http:client ConnectionTimeout="900000" />
</http:conduit>
</beans> This config is just for the SOAP requests. I have not changed the connection timeout for the Apache HTTP client used for all other Bing Ads API requests yet. E.g. for the connection to These connection timeouts happen just for a few of our requests. But they are annoying because they happen several times a week. I wasn't able to determine a request that fails reproducibly yet. |
For some time we already noticed that the connections to the Bing Ads API time out rather often.
Is that a load-limiting behavior or a bug?
Why isn't that handled by the ReportingServiceManager via a meaningful exception?
Are there any limits on how many connections can be opened in parallel? What are the exact restrictions?
Stacktrace:
The text was updated successfully, but these errors were encountered: