[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-1436.
---------------------------------
Fix Version/s: 3.6.1
3.7.0
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 3.7.0, 3.6.1
>
> Attachments: JAMES-1436.patch, JAMES-1436.patch.r1432540,
> ThunderbirdAndIMAPserver.log
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
