[
https://issues.apache.org/jira/browse/GEODE-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246888#comment-17246888
]
ASF subversion and git services commented on GEODE-8773:
--------------------------------------------------------
Commit 12065b0c9decd6283f051c9fff649eaf32196990 in geode-native's branch
refs/heads/support/1.14 from Matthew Reddington
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=12065b0 ]
GEODE-8773: Ensure that PING and CLOSE_CONNECTION are not transactional. (#706)
* Test that PING and CLOSE_CONNECTION are not implicitly transactional.
* Always send TxId -1 (NOTX in Java) for PING and CLOSE_CONNECTION
- These should never be part of a transaction
Co-authored-by: Blake Bender <bbl...@vmware.com>
> Unnecessary transaction overhead being created on server
> --------------------------------------------------------
>
> Key: GEODE-8773
> URL: https://issues.apache.org/jira/browse/GEODE-8773
> Project: Geode
> Issue Type: Bug
> Components: native client
> Reporter: Blake Bender
> Assignee: Blake Bender
> Priority: Major
> Labels: pull-request-available
>
> This is a _very_ old bug, that was just discovered. In the Geode protocol,
> no matter which message is being handled, a Geode server will examine the
> “transaction Id” value in the message header, and if it is not the symbolic
> constant “NOTX” (aka -1), will assume the message is part of a transaction
> with that Id, and _set up resources for a transaction if one with that Id
> doesn’t already exist_. Said resource can include a high priority thread. In
> conjunction with this, we have the fact that the native client goes out of
> its way to always set the transaction id to 0 for PING and CLOSE_CONNECTION
> messages. The last ingredient for reproducing this problem is to have a whole
> bunch (like on the order of several hundred or several thousand) client
> applications start up and exit in a short period of time. Each will send at
> least one CLOSE_CONNECTION message, all with transaction Id 0, thus each
> client instance will leave one dangling transaction on the server. Eventually
> these will cause the server to spin up a fatal number of high-priority
> threads.
> The fix in the native client is trivial, just stop writing 0 instead of the
> transaction ID in the PING and CLOSE_CONNECTION messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
