Would be great to emit from ``init``? about sailor-nodejs HOT 10 CLOSED

What is the use case behind it?

from sailor-nodejs.

Actually the story is a bit tricky - check this out:

https://github.com/elasticio/amqp-component/blob/master/lib/triggers/consume.js#L55

AMQP trigger is like some others (salesforce streaming, twitter streaming, google pubsub etc) are passive listening triggers, they need to be started once and then they produce data when data is there. When using such trigger in long-running task it works very well.

However as you you know our admiral has a special timeout feature so when incoming message accepted wherever the trigger wants it or not, in this case the init method:

https://github.com/elasticio/amqp-component/blob/master/lib/triggers/consume.js#L17

will be called only once, but process method will be called multiple times. Simple solution would be to move all code into the init method and leave process method empty, like that:

elasticio/amqp-component@75c1665

this however does not work because this at the time init is executed is not the same this at the time process is executed ;)

from sailor-nodejs.

I see. The use case is very nice.

So, what we have is a trigger that is neither polling nor webhook. Wouldn't make sense to introduce a new trigger type, say listener? This would be accomplished in component.json by setting "type":"listener", in the same way we define polling triggers right now. For such listener triggers the process function would be invoked only once to start listening on queues.

from sailor-nodejs.

Very interesting idea. Actually the solution described above does only work with the 'realtime' flow. If we would declare a new trigger type we could make sure Admiral won't kill it even in case of non-realtime flow hence save resources.
I also see this as a first step to 'unload' webhooks functionality and potentially in future to load-balance TCP connections from outside to containers hence enable new protocol support (e.g. MTOM) in user-space.

from sailor-nodejs.

Actually the solution described above does only work with the 'realtime' flow.

Does a listener trigger type make any sense in a non-realtime flow?

from sailor-nodejs.

from sailor-nodejs.

But the trigger container must be realtime and running all the time for that purpose anyway, right? Otherwise it won't get any messages.

from sailor-nodejs.

from sailor-nodejs.

Sorry, but i don't get it. The trigger creates a consumer and subscribes it. If the container is killed, the consumer is unregistered. Admiral does not know anything the queue the trigger is consuming message from. Am I missing something?

from sailor-nodejs.

My point was that, just like you said:

the trigger container must be realtime and running all the time for that purpose anyway

so if we introduce new trigger type then we need to make sure that admiral won't kill it, even if the overal flow type won't be real-time. Which is very good because if non-realtime flow with first 'listener' trigger then all other containers will be started on-demand, and shut-down if no messages were produced by the listening trigger, which is cool.

from sailor-nodejs.