[
https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17421121#comment-17421121
]
Benoit Tellier commented on JAMES-1436:
---------------------------------------
As reported by https://github.com/jtconsolq,
ImapServerTest::largeAppendsShouldWork is unstable and fails one time out of
100 (average).
Here is the related James stack trace:
{code:java}
java.lang.AssertionError: null
at
org.jboss.netty.handler.codec.frame.FrameDecoder.appendToCumulation(FrameDecoder.java:319)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:308)
at
org.apache.james.imapserver.netty.SwitchableLineBasedFrameDecoder.messageReceived(SwitchableLineBasedFrameDecoder.java:47)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.messageReceived(SimpleChannelUpstreamHandler.java:124)
{code}
It is linked to this fix: If data remains in the cumulation buffer after say a
APPEND, we flush it, as it avoids
APPEND to wait indefinitly for data. However this did let the cumulation buffer
in a
non usable state causing following commands to fail.
We should this set the cumulation buffer to null to no longer use it (and
allocate a new one)
in order to prevent failures in follow up message processing. This simple fix
is enough to get away with it!
PR (3.7.0 - SNAPSHOT master) https://github.com/apache/james-project/pull/673
PR (3.6.x backport) https://github.com/apache/james-project/pull/674
I also came up with another hacky fix, I document it for posterity, but please
do not pay attention to it (uggly!) - the idea was to bypass the framing if
framing would have thrown an exception, however it would have had effectively
disabled framing on the first flush (bypass it as we have a non usable
cumulation buffer).
{code:java}
@Override
public synchronized void messageReceived(ChannelHandlerContext ctx,
MessageEvent e) throws Exception {
if (this.framingEnabled) {
if (this.cumulation != null && !this.cumulation.readable()) {
ctx.sendUpstream(e);
} else {
super.messageReceived(ctx, e);
}
} else {
ctx.sendUpstream(e);
}
}
{code}
> 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
> Attachments: JAMES-1436.patch, JAMES-1436.patch.r1432540,
> ThunderbirdAndIMAPserver.log
>
> Time Spent: 20m
> 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]
