[
https://issues.apache.org/jira/browse/SSHD-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14394138#comment-14394138
]
Guillaume Nodet edited comment on SSHD-445 at 4/3/15 6:42 AM:
--------------------------------------------------------------
I like the idea.
The BufferManager could easily be configured on the FactoryManager.
For the asynchronous part, we could do reference counting to avoid having to
catch the exception so that the buffer can be released. The client code would
thus be the same in both sync and async cases.
{code}
try (Buffer buffer=manager.newBuffer(...)) {
buffer.putXXX();
buffer.putXXX();
buffer.putXXX();
asyncSend(buffer);
}
void asyncSend(Buffer buffer) throws Exception {
buffer.reference();
...
// somewhere in another thread
buffer.release();
}
{code}
But yes, that's a lot of refactoring. I suppose we'd need to measure if it
helps at all at the end.
was (Author: gnt):
I like the idea.
The BufferManager could easily be configured on the FactoryManager.
For the asynchronous part, we could do reference counting to avoid having to
catch the exception so that the buffer can be released. The client code would
thus be the same in both sync and async cases.
{code}
try (Buffer buffer=manager.newBuffer(...)) {
buffer.putXXX();
buffer.putXXX();
buffer.putXXX();
asyncSend(buffer);
}
void asyncSend(Buffer buffer) throws Exception {
buffer.reference();
...
// somewhere in another thread
buffer.release();
}
{code}
> Allow a pluggable BufferManager for Buffer(s) used to send SSH messages
> -----------------------------------------------------------------------
>
> Key: SSHD-445
> URL: https://issues.apache.org/jira/browse/SSHD-445
> Project: MINA SSHD
> Issue Type: Improvement
> Reporter: Goldstein Lyor
>
> The current code creates new _Buffer_ instances whenever it needs to create
> an encoded SSH message for sending. This causes GC "pressure" if the protocol
> is "chatty" - a lot of short-lived (often small) buffers are created and
> almost immediately disposed. Instead, if would be nice to have some kind of
> _BufferManager_ that is configured for the server/client, and it is used to
> allocate buffers for sending. Once the buffer is no longer needed (i.e., its
> data has been transmitted) it can be _release()_-d - e.g.:
> {panel}
> {code:java}
> Buffer buffer=manager.newBuffer(...);
> try {
> buffer.putXXX();
> buffer.putXXX();
> buffer.putXXX();
> syncSend(buffer);
> } finally {
> buffer.release();
> }
> {code}
> {panel}
> *Note(s)*
> - If an *asynchronous* send is used, then the _IOCompletionHandler_ will
> release the buffer. In such a case, then code will look slightly different:
> {panel}
> {code:java}
> Buffer buffer=manager.newBuffer(...);
> try {
> buffer.putXXX();
> buffer.putXXX();
> buffer.putXXX();
> asyncSend(buffer);
> } catch(IOException | RuntimeException e) {
> buffer.release();
> throw e;
> }
> {code}
> {panel}
> - We could consider making the _Buffer_ also _AutoCloseable_ so that the
> _close()_ method calls _release()_. This would enable us to use
> _try-with-resource_ blocks which are easier to read than _try-catch-finally_
> ones.
> - The default implementation could be "detached" buffers - i.e., a manager
> that creates a new buffer every time - same as current. In time we could
> consider adding pools, etc...
> - I do not have a patch available - I started to look at what it entails and
> it is complex enough to warrant further thinking and discussion
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
