[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samant Maharaj updated JAMES-1436:
----------------------------------
Description:
When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get
into a state where the ImapRequestFrameDecoder will wait for a number message
bytes that will never arrive.
This has the effect of causing the IMAP client to also block indefinitely
waiting for a response from the server.
h4. Root Cause:
This is due to the DelimiterBasedFrameDecoder being removed from the Netty
pipeline by the ImapRequestFrameDecoder.
If the DelimiterBasedFrameDecoder still contains less than one line of data in
its buffer, that data will never be flushed and forwarded down the pipeline.
The effect of this is that a small number of bytes, typically from the early
part of the message are omitted and the final byte count does not match the
value calculated from the APPEND command. This results in the APPEND command
never being completely decoded and hence no append actually takes place nor
does a response get sent to the client.
In order to trigger this bug,
was:
When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get
into a state where the ImapRequestFrameDecoder will wait for a number message
bytes that will never arrive.
This has the effect of causing the IMAP client to also block indefinitely
waiting for a response from the server.
Root Cause:
This is due to the DelimiterBasedFrameDecoder being removed from the Netty
pipeline by the ImapRequestFrameDecoder.
If the DelimiterBasedFrameDecoder still contains less than one line of data in
its buffer, that data will never be flushed and forwarded down the pipeline.
The effect of this is that a small number of bytes, typically from the early
part of the message are omitted and the final byte count does not match the
value calculated from the APPEND command. This results in the APPEND command
never being completely decoded and hence no append actually takes place nor
does a response get sent to the client.
> APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data
> --------------------------------------------------------------------------
>
> Key: JAMES-1436
> URL: https://issues.apache.org/jira/browse/JAMES-1436
> Project: JAMES Server
> Issue Type: Bug
> Components: IMAPServer
> Affects Versions: 3.0-beta4
> Environment: Ubuntu 12.04 x86_64
> Reporter: Samant Maharaj
>
> When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get
> into a state where the ImapRequestFrameDecoder will wait for a number message
> bytes that will never arrive.
> This has the effect of causing the IMAP client to also block indefinitely
> waiting for a response from the server.
> h4. Root Cause:
> This is due to the DelimiterBasedFrameDecoder being removed from the Netty
> pipeline by the ImapRequestFrameDecoder.
> If the DelimiterBasedFrameDecoder still contains less than one line of data
> in its buffer, that data will never be flushed and forwarded down the
> pipeline. The effect of this is that a small number of bytes, typically from
> the early part of the message are omitted and the final byte count does not
> match the value calculated from the APPEND command. This results in the
> APPEND command never being completely decoded and hence no append actually
> takes place nor does a response get sent to the client.
> In order to trigger this bug,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
