Skip to content
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

QUERY_TIMEOUT: Your query request was running for too long #45

Open
etrabelsi opened this issue Jan 17, 2017 · 4 comments
Open

QUERY_TIMEOUT: Your query request was running for too long #45

etrabelsi opened this issue Jan 17, 2017 · 4 comments

Comments

@etrabelsi
Copy link

etrabelsi commented Jan 17, 2017

Can you add support for setting timeout in beatbox as parameter to the constructor ?

@hynekcer
Copy link
Contributor

hynekcer commented Jan 17, 2017

I agree. Which one source do you use? Does this work for also you? (still without timeout setting?):

pip install git+https://github.com/hynekcer/beatbox-davisagli.git@7f628a789cba#egg=beatbox

If so then I can add the timeout setting and ask for commit to PyPI beatbox , otherwise "hibernation" of this project would continue because there are different clones by more authors and the clone on PyPI is not active more.

@etrabelsi
Copy link
Author

etrabelsi commented Jan 17, 2017

@hynekcer
It seems to be weird fork of this repository ,it doesn't support this kind of login.

self.sf = beatbox._tPartnerNS
self.svc = beatbox.Client()
self.svc.login(user_name, password + security_token)

any toughts?

@superfell
Copy link
Owner

Do you want to set the timeout in the hopes of extending it so as to not get a QUERY_TIMEOUT result? if so that won't help, the QUERY_TIMEOUT response is generated from a server side timeout, and is not adjustable from the client.

@hynekcer
Copy link
Contributor

I think that a frequent requirement is to set a shorter value for the case that a simple query is unusually slow or the connection is sometimes broken but not known to be closed. Especially on a web server is a shorter timeout important because the user will more probably retry than wait. It usually works good surprisingly because the cache on SFDC is filled by necessary data by the first terminated request and the second request frequently succeeds fast.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants