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

Ethernal cycle of requests with errors #24

Open
nizovtsevnv opened this issue Feb 6, 2020 · 3 comments
Open

Ethernal cycle of requests with errors #24

nizovtsevnv opened this issue Feb 6, 2020 · 3 comments

Comments

@nizovtsevnv
Copy link

For example, if I send INSERT request with wrong date format "2020-02-06 07:15:23.364727" (ruby Time format), then this request will never been executed and makes computation power leak.

Could you make a solution for this?

For example: if exception is not about clickhouse server connection then remove this bad request from a sending cycle to a separate dump file with list of bad requests.

@Des1re7
Copy link

Des1re7 commented Aug 13, 2020

Hello!
I faced similar issue and wrote a workaroud for 400 error. What error codes do you have that it makes sense to put in a separate folder?

@nikepan
Copy link
Owner

nikepan commented Aug 13, 2020

good idea! i remember it and try to implement in future. thanks!

@splichy
Copy link
Contributor

splichy commented Nov 16, 2020

If it only one row from many you can workaround with https://clickhouse.tech/docs/en/operations/settings/settings/#settings-input_format_allow_errors_num
But it will hide basically all the insert errors.
Anyway, in our case, we had multiline inserts where one or two out of ~200 rows had e.g. negative integer(interger overflow) while CH schema was UInt32 - so while we were waiting for fix in app we have temporarily enabled input_format_allow_errors to avoid dumping inserts to disk and trying to insert them over and over.

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

4 participants