[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509560#comment-13509560
]
Peter Kvokacka commented on JAMES-1436:
---------------------------------------
Hello
I just want to confirm that I had similar issue after upgrading to 3.0 beta4
and the patch worked for me nicely as well. Thanks Samant.
I can reproduce problem just by saving DRAFT email on IMAP account from
Thunderbird/Outlook/iPad. I've got no problem at all when connection is not
secure. When I switch to STARTTLS it always hangs and ends with error after
while (or client tries to reconnect a do same operation again).
I attached file ThunderbirdAndIMAPserver.log witch contains logs from time when
error occured. We are using our own implementation of mailbox API (which is not
yet 100% complete/final) but I don't think it has anything to do with the
issue. Hope this helps.
Peter
> 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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
