[jira] [Updated] (GEODE-3057) Keep Thread Local Comm Buffer in selector thread
[
https://issues.apache.org/jira/browse/GEODE-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-3057:
-
Labels: starter (was: newbie)
> Keep Thread Local Comm Buffer in selector thread
>
>
> Key: GEODE-3057
> URL: https://issues.apache.org/jira/browse/GEODE-3057
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
> Labels: starter
>
> In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool
> every time that {run} is called by a selector, and release it back after the
> particular message.
> This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to
> have the selector thread own a buffer that all commands running on that
> selector can use.
> As a side note, maybe it would make sense to split the run function in two,
> with {run} being called in the connection-per-thread case and
> {{doMessageOnSelector}} or so being called by the selector?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3057) Keep Thread Local Comm Buffer in selector thread
[
https://issues.apache.org/jira/browse/GEODE-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt updated GEODE-3057:
Labels: newbie (was: )
> Keep Thread Local Comm Buffer in selector thread
>
>
> Key: GEODE-3057
> URL: https://issues.apache.org/jira/browse/GEODE-3057
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Galen O'Sullivan
>Priority: Major
> Labels: newbie
>
> In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool
> every time that {run} is called by a selector, and release it back after the
> particular message.
> This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to
> have the selector thread own a buffer that all commands running on that
> selector can use.
> As a side note, maybe it would make sense to split the run function in two,
> with {run} being called in the connection-per-thread case and
> {{doMessageOnSelector}} or so being called by the selector?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3057) Keep Thread Local Comm Buffer in selector thread
[
https://issues.apache.org/jira/browse/GEODE-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3057:
Component/s: client/server
> Keep Thread Local Comm Buffer in selector thread
>
>
> Key: GEODE-3057
> URL: https://issues.apache.org/jira/browse/GEODE-3057
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Galen O'Sullivan
>
> In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool
> every time that {run} is called by a selector, and release it back after the
> particular message.
> This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to
> have the selector thread own a buffer that all commands running on that
> selector can use.
> As a side note, maybe it would make sense to split the run function in two,
> with {run} being called in the connection-per-thread case and
> {{doMessageOnSelector}} or so being called by the selector?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (GEODE-3057) Keep Thread Local Comm Buffer in selector thread
[
https://issues.apache.org/jira/browse/GEODE-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-3057:
Description:
In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool
every time that {run} is called by a selector, and release it back after the
particular message.
This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to
have the selector thread own a buffer that all commands running on that
selector can use.
As a side note, maybe it would make sense to split the run function in two,
with {run} being called in the connection-per-thread case and
{{doMessageOnSelector}} or so being called by the selector?
was:
In {ServerConnection.run()}, we currently pull a comm buffer from the pool
every time that {run} is called by a selector, and release it back after the
particular message.
This buffer is allocated in a {ThreadLocal}, so it would make more sense to
have the selector thread own a buffer that all commands running on that
selector can use.
As a side note, maybe it would make sense to split the run function in two,
with {run} being called in the connection-per-thread case and
{doMessageOnSelector} or so being called by the selector?
> Keep Thread Local Comm Buffer in selector thread
>
>
> Key: GEODE-3057
> URL: https://issues.apache.org/jira/browse/GEODE-3057
> Project: Geode
> Issue Type: Improvement
>Reporter: Galen O'Sullivan
>
> In {{ServerConnection.run()}}, we currently pull a comm buffer from the pool
> every time that {run} is called by a selector, and release it back after the
> particular message.
> This buffer is allocated in a {{ThreadLocal}}, so it would make more sense to
> have the selector thread own a buffer that all commands running on that
> selector can use.
> As a side note, maybe it would make sense to split the run function in two,
> with {run} being called in the connection-per-thread case and
> {{doMessageOnSelector}} or so being called by the selector?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
