[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982139#comment-13982139
]
Mark edited comment on JAMES-1436 at 4/26/14 11:51 PM:
-------------------------------------------------------
The problem is quite easy to reproduce. You just need to run a plain (ssl)
socket against your imaps port and divide your APPEND command into two parts
such that the message itself is not sent in parts aligned with linefeeds. Maybe
use flush() on the stream to force sending a trailing line not ending on CR/LF.
The basic poblem is that we'd need a LineBasedFrameDecoder followed by a
FixedLengthFrameDecoder in case of the APPEND command, both available in Netty
3.8.1 (which I am currently trying to port James to). It should not be too hard
to accomplish that. :-)
BTW: is anyone already working on a Netty 4 port?
was (Author: gwdfl59u):
The problem is quite easy to reproduce. You just need to run a plain (ssl)
socket against your imaps port and divide your APPEND command into two parts
such that the message itself is not sent in parts aligned with linefeeds. Maybe
use flush() on the stream to force sending a trailing line not ending on CR/LF.
The basic poblem is that we'd need a LineBasedFrameDecoder followed by a
FixedLengthFrameDecoder in case of the APPEND command, both available in Netty
3.8.1 (which I am currently trying to port James to). It should not be too hard
to accomplish that. :-)
> 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: Trunk, 3.0-beta4, 3.0.0-beta5
> Environment: Ubuntu 12.04 x86_64
> Reporter: Samant Maharaj
> Attachments: JAMES-1436.patch, JAMES-1436.patch.r1432540,
> ThunderbirdAndIMAPserver.log
>
>
> 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 a race condition when the DelimiterBasedFrameDecoder is
> 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 reliably trigger this bug, JAMES was configured to accept a
> remote debugging connection and a conditional breakpoint set at
> org.jboss.netty.handler.codec.frame.FrameDecoder:439. The condition was set
> to 'Thread.sleep(200l); false'. This results in introducing a 200ms delay on
> each frame decoding loop without actually hitting the breakpoint. The effect
> of this is to allow the threadpool running ImapRequestFrameDecoder time to
> consume the individual frames and remove the DelimiterBasedFrameDecoder from
> the pipeline.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
