incubator-s4-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (JIRA)" <>
Subject [jira] [Assigned] (S4-41) Guaranteed Event-Delivery
Date Mon, 13 Aug 2012 20:34:38 GMT


Karthik Kambatla reassigned S4-41:

    Assignee:     (was: Karthik Kambatla)
> Guaranteed Event-Delivery
> -------------------------
>                 Key: S4-41
>                 URL:
>             Project: Apache S4
>          Issue Type: New Feature
>    Affects Versions: 0.5.0
>            Reporter: Karthik Kambatla
>             Fix For: 0.6
> From Skype call on 1/24:
> Guaranteed Event Delivery needs to be supported, but should be optional as it is bound
to have significant performance trade-offs. Essentially, the Sender needs to be ACKed on successful/failed
send of an event. In case of a failure or unknown status (timeout), the Sender re-sends the
> Note: This JIRA is related to S4-37, the extent to which it is related needs to be decided.
> Should this be implemented at the application level (s4-core) or communication level
> -To implement it in the comm-layer, guaranteed message delivery (comm-layer) should translate
to guaranteed event delivery (app-level). Receiver uses a blocking queue - thus, every message
received is queued as an event (no messages are dropped) unless in case of interruptions.
Also, we can modify Receiver to use a SynchronousQueue and have Listeners use ArrayBlockingQueue
to make sure that no messages are dropped even in case of interruptions.
> -To implement it in the application-level, the Receiver should send an ACK to the Sender.
This entails the following (1) Receiver should know the Sender details, (2) a special ACKEvent,
(3)  direct hand-shake between the Sender and Receiver (like implementing our own TCP).
> Given these circumstances, I feel the best way to achieve this is to (1) guarantee message-delivery,
and (2) ensure that translates to guaranteed event-delivery.
> Please comment.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message