[
https://issues.apache.org/jira/browse/CASSGO-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bohdan Siryk updated CASSGO-133:
--------------------------------
Description:
>From PR description:
>
{{Conn.executeQuery}} and {{Conn.executeBatch}} both respond to a
{{*RequestErrUnprepared}} by evicting the prepared-statement cache entry and
recursing on themselves with no upper bound.
When the server persistently re-reports the same statement as unprepared after
re-prepare — for example a coordinator thrashing its prepared-statement cache
under high statement cardinality, or a misbehaving proxy/fork — the recursion
never terminates. The goroutine stack eventually exceeds
{{runtime.SetMaxStack}} (1 GiB by default), at which point Go's runtime crashes
the *entire process* with an unrecoverable stack-overflow throw. No
{{recover()}} can intercept it.
>
The driver should not fall in an endless recursion, better is to return an
error and allow RetryPolicy to decide whether it is worth retry on the same
host or another one.
was:
>From PR description:
>
{{Conn.executeQuery}} and {{Conn.executeBatch}} both respond to a
{{*RequestErrUnprepared}} by evicting the prepared-statement cache entry and
recursing on themselves with no upper bound.
When the server persistently re-reports the same statement as unprepared after
re-prepare — for example a coordinator thrashing its prepared-statement cache
under high statement cardinality, or a misbehaving proxy/fork — the recursion
never terminates. The goroutine stack eventually exceeds
{{runtime.SetMaxStack}} (1 GiB by default), at which point Go's runtime crashes
the *entire process* with an unrecoverable stack-overflow throw. No
{{recover()}} can intercept it.
>
The drvier should not fall in an endless recursion, better is to return an
error and allow RetryPolicy to decide wheter it is worth retry on the same host
or another one
> Cap RequestErrUnprepared retry recursion on query and batch paths
> -----------------------------------------------------------------
>
> Key: CASSGO-133
> URL: https://issues.apache.org/jira/browse/CASSGO-133
> Project: Apache Cassandra Go driver
> Issue Type: Improvement
> Reporter: Bohdan Siryk
> Priority: Normal
>
> From PR description:
> >
> {{Conn.executeQuery}} and {{Conn.executeBatch}} both respond to a
> {{*RequestErrUnprepared}} by evicting the prepared-statement cache entry and
> recursing on themselves with no upper bound.
> When the server persistently re-reports the same statement as unprepared
> after re-prepare — for example a coordinator thrashing its prepared-statement
> cache under high statement cardinality, or a misbehaving proxy/fork — the
> recursion never terminates. The goroutine stack eventually exceeds
> {{runtime.SetMaxStack}} (1 GiB by default), at which point Go's runtime
> crashes the *entire process* with an unrecoverable stack-overflow throw. No
> {{recover()}} can intercept it.
> >
> The driver should not fall in an endless recursion, better is to return an
> error and allow RetryPolicy to decide whether it is worth retry on the same
> host or another one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
