[jira] [Created] (SSHD-445) Allow a pluggable BufferManager for Buffer(s) used to send SSH messages

["Goldstein Lyor (JIRA)" <ji...@apache.org>]

Goldstein Lyor created SSHD-445:
-----------------------------------

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