[
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: [email protected]
For additional commands, e-mail: [email protected]
