[
https://issues.apache.org/jira/browse/PROTOCOLS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934121#action_12934121
]
Stefano Bagnara commented on PROTOCOLS-11:
------------------------------------------
Well, the issue is that Retr and Top command handlers are wrong :-)
They are blocking:
AbstractRetrCmdHandler.writeMessageContentTo does a loop and blocks while it
writes each line of the message to the output channel.
This way if the remote client is blocking you either fill a buffer or block an
executor thread of the SEDA pool.
So it has to be changed.
In the API we solved this issue for incoming streams (DataCmdHandler for SMTP)
and we push a new linehandler in the chain to handle asynchronous streaming.
Maybe this needs a similar solution but reversed for writing a stream.
I'm opening a new JIRA for this purpose.
> Make CommandHandler/LineHandler/ConnectHandler more consistent
> --------------------------------------------------------------
>
> Key: PROTOCOLS-11
> URL: https://issues.apache.org/jira/browse/PROTOCOLS-11
> Project: JAMES Protocols
> Issue Type: Task
> Affects Versions: 1.0, 1.1
> Reporter: Norman Maurer
> Assignee: Norman Maurer
> Fix For: 1.2-M2
>
>
> At the moment we have three different Handler types. These are
> ConnectHandler, CommandHandler and LineHandler. The ConnectHandler and
> LineHandler use void as return type and so if you want to write something
> back to the client you use Session.write(...). On the other hand if you use
> CommandHandler you can use the return type of Response to trigger a write
> back to the client and Session.write(..). We should only use
> Session.write(...) in all cases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
