[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555945#comment-13555945
]
Jerry Tian commented on JAMES-1436:
-----------------------------------
Sarmant's patch on beta4 is not working now.Seems the code base has been
refactored.
I compiled a new patch based on trunk with the following SVN meta.
apache-james-trunk jerry$ svn info server/protocols/protocols-imap4
Path: server/protocols/protocols-imap4
URL:
https://svn.apache.org/repos/asf/james/server/trunk/protocols/protocols-imap4
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1432540
Node Kind: directory
Schedule: normal
Last Changed Author: ieugen
Last Changed Rev: 1429276
Last Changed Date: 2013-01-05 21:09:12 +0800 (Sat, 05 Jan 2013)
After patching this file on trunk code, writing several hundred testing mail
messages into our test server doesn't hang up now.
Hope this helps.
> 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-beta5
> Environment: Ubuntu 12.04 x86_64
> Reporter: Samant Maharaj
> Attachments: JAMES-1436.patch, 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 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: [email protected]
For additional commands, e-mail: [email protected]
