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 "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/03/04 09:49:00 UTC

[jira] [Created] (JAMES-3511) java.util.NoSuchElementException: heartbeatHandler

Benoit Tellier created JAMES-3511:
-------------------------------------

             Summary: java.util.NoSuchElementException: heartbeatHandler
                 Key: JAMES-3511
                 URL: https://issues.apache.org/jira/browse/JAMES-3511
             Project: James Server
          Issue Type: Improvement
          Components: IMAPServer
            Reporter: Benoit Tellier


We encountered the following IMAP failure:

{code:java}
t logger 	
	org.apache.james.imapserver.netty.ImapChannelUpstreamHandler
t message 	
	Error while processing imap request
t protocol 	
	IMAP
t sessionId 	
	SID-rxzyjwusjzrc
t severity 	
	WARN
t stacktrace 	
	java.util.NoSuchElementException: heartbeatHandler
	at org.jboss.netty.channel.DefaultChannelPipeline.getContextOrDie(DefaultChannelPipeline.java:684)
	at org.jboss.netty.channel.DefaultChannelPipeline.remove(DefaultChannelPipeline.java:153)
	at org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:215)
	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.Channels.fireMessageReceived(Channels.java:296)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443)
	at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303)
	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.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:43)
	at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:67)
	at org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:314)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Work
{code}

I believe a concurrency issue causes the handler to be removed twice.

We should be idempotent here: the end result is that the heartbeat handler is no longer here, hence we should not fail.

Similarly, if the heartbeat handler is concurrently set, we end up putting it anyway, resulting in an IllegalArgument exception.

The heartbeat handler sends a heartbeat  every 30s which is far less than the IMAP command execution timing. If in some corner case we miss it, this is not missin critical to me: it's management should not result in connection closure.

I tried to reproduce, as well as Gauthier Di Folco months ago, without success. I'd like to add defensive try/catchs to handle these failures.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org