[
https://issues.apache.org/jira/browse/S4-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165833#comment-13165833
]
Karthik Kambatla commented on S4-7:
-----------------------------------
To ensure we don't loose messages on the wire, we should maintain a queue for
each channel and when the ChannelFuture reports success, dequeue the first
message in the queue.
Given we already have another queue for incoming messages to tolerate network
glitches, would it make sense to have a single queue for both and have a
separate thread (pool) for going to send the events in these per-channel
message queues.
The NettyEmitter would change as follows:
1. We maintain one bounded messageQueue per partition
2. send() always queues the message to the messageQueue and returns
3. Another thread (pool) sifts through each messageQueue in round-robin fashion
and sends these messages - dequeues messages on ChannelFuture.success()
4. For extended functionality, send() can allow registering a callback to
confirm to the client (of NettyEmitter) that the message has been sent
Comments?
> Netty to tolerate network glitches and connection loss
> ------------------------------------------------------
>
> Key: S4-7
> URL: https://issues.apache.org/jira/browse/S4-7
> Project: Apache S4
> Issue Type: Bug
> Reporter: Leo Neumeyer
> Assignee: Karthik Kambatla
> Fix For: 0.5
>
>
> NettyEmitter connects to different partitions and creates channels over which
> it communicates to other listeners.
> It suffers from the following issues --
> 1. If the underlying topology changes, the channels and the associated
> connections are not updated.
> 2. If a connection gets disconnected, it stays disconnected.
> 3. If for any reason, a connection can't be made, send() drops the message to
> be sent.
> The solution is to -
> 1. Maintain a bounded messageQueue for each destination partition - if a
> connection does not exist, the message should be queued.
> 2. Maintain a map of the channel used for each destination partition - update
> this map on changes to topology, or on send() in case of disconnections.
> 3. Every time a (re-)connection is made, send the queued messages first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
