[ 
https://issues.apache.org/jira/browse/GEODE-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246182#comment-17246182
 ] 

ASF GitHub Bot commented on GEODE-8773:
---------------------------------------

mreddington opened a new pull request #706:
URL: https://github.com/apache/geode-native/pull/706


   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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
>
> 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)

Reply via email to