Had an offline chat with Suho and found out that following are the reasons
for having a receiver queue;
* In HA mode there's a "state" sync happening at the startup of a DAS node.
We need to buffer the events that we may receive during this time.
* Currently, the "event" sync is a synchronous
On Wed, Jan 31, 2018 at 4:56 PM Nirmal Fernando wrote:
> Suho,
>
> Thanks for the reply. What I am thinking is why we need a receiver queue,
> if we made DAS1->DAS2 async?
>
How will this fix the issue?
>
>
> On Wednesday, January 31, 2018, Sriskandarajah Suhothayan
Suho,
Thanks for the reply. What I am thinking is why we need a receiver queue,
if we made DAS1->DAS2 async?
On Wednesday, January 31, 2018, Sriskandarajah Suhothayan
wrote:
> AFAIR the event queue is used for buffering the events when states are
> being synced, else there will
AFAIR the event queue is used for buffering the events when states are
being synced, else there will be back pressure on the clients.
I think the rationale for using the same thread with synchronous call and
performing operations in both DAS1 and DAS2 ( in the order DAS1 -> DAS2 ->
DAS2-Siddhi ->
InputEventDispatcher will send the event to the callback immediately while
QueueInputEventDispatcher will queue events first and there will be an
internal worker (QueueInputEventDispatcherWorker) which send the events to
the callback. The reason to accumulate events in a queue in HA is to be
used
Thanks, Grainier. Please see my comments inline.
On Wed, Jan 31, 2018 at 1:07 PM, Grainier Perera wrote:
> InputEventDispatcher will send the event to the callback immediately while
> QueueInputEventDispatcher will queue events first and there will be an
> internal worker
Hi All,
Can any of you remember the reason for using a receiver queue in HA mode?
if (mode == Mode.HA) {
HAConfiguration haConfiguration =
EventReceiverServiceValueHolder.getEventManagementService()
.getManagementModeInfo().getHaConfiguration();
Lock readLock =