You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Jerry Tian (JIRA)" <se...@james.apache.org> on 2013/01/17 05:30:23 UTC
[jira] [Commented] (JAMES-1436) APPEND IMAP command can result in
JAMES IMAP waiting indefinitely for data
[ https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555838#comment-13555838 ]
Jerry Tian commented on JAMES-1436:
-----------------------------------
Hi Eric,
I have followed this issue since beta4 release, and since then using James in production.
Before the patch from Sarmant, since receiving complaints from our customers, by looking into our production James's server log, I can find client connection hangs frequently.The mail client is the one that Apple using on iOS devices.
So I try to reproduce this problem on our test server, using Java Mail API to access the IMAP folder and append new messages(It is typical IMAP operation code, if needed, I will paste them here).
And indeed, sometimes, after successful login into the server and try to append new messages, the client will hang forever(at least for 5-6 minutes on our system). If I kill the client process and repeat the test, chances are if it hangs before, it will hang this time. But if I wait for another several minutes, suddenly some messages can be appended successfully, then fail again.
I have applied Sarmant's patch in beta4 release and with the new patch, both our test and production server no longer hangs up mail clients(our test JAVA mail client and iOS client).
Days before, after try to update the James part to trunk version in our test env, which is now beta5-SNAPSHOT, this mysterious bug comes back again. At first I didn't realize this, but then I recall that the patch I used before. After rechecking this JIRA issue and the trunk code base, it is clear the patch is not merged into trunk.
And for STARTTTLS part, since our test server is using non-secured connection, and production server is using secured connection, I can confirm that they are both working after the patch is applied.
> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org