I recognised that ByteBuffer from the PooledByteBufferAllocator are
not always initialized with 0. If a buffer gets reused the old value
is still present. In my understanding it would be necessary to clear
previous data if a buffer is reused.
The following program shows the issue:
import
On Thu, Sep 18, 2008 at 11:34 AM, Loureiro, Gil [EMAIL PROTECTED] wrote:
Note: You should change manually to uppercase all the letter on the resulting
hash.
That should not be needed. If it is, please report a bug in JIRA.
/niklas
Stefan Gmeiner wrote:
I recognised that ByteBuffer from the PooledByteBufferAllocator are
not always initialized with 0. If a buffer gets reused the old value
is still present. In my understanding it would be necessary to clear
previous data if a buffer is reused.
I don't think this is
I don't think this is necessary. A 0 is also a valid data, so I see no
difference between a buffer not being zero'ed and a buffer containing only
0.
I would agree with you if we are not talking about C instead of java.
Most of the initialised data in java is set to specified
(well-defined)
I have the exact problem; the FtpServer (with listener) starts fine, but a
FTP client (such as FileZilla Ftp client used as a test case) can only make
connections to it, and then fails (while waiting for 'welcome message'). At
the same time, my main application throws exception attached below.
I have the exact problem; the FtpServer (with listener) starts fine, but a
FTP client (such as FileZilla Ftp client used as a test case) can only make
connections to it, and then fails (while waiting for 'welcome message'). At
the same time, my main application throws exception attached below.
