gateleen-hook: Allow flexible RequestQueue configuration per hook

[mcweba]

The current implementation of the HookHandler allows the definition of exactly one QueueClient implementation. The QueueClient provides access to the queuing mechanism implemented by vertx-redisques.

Since the HookHandler allows a single QueueClient only, all the queueing related actions will be performed against the same vertx-redisques instance.

We have now the requirement to let hooks be performed on different vertx-redisques instances, therefore we should be able to

• configure the vertx-redisques instance to be used in the hook configuration
• provide multiple QueueClient implementations in the HookHandler

To configure the vertx-redisques instance to be used in the hook configuration, a property called queueClient could be added. When no queueClient property is defined (or not valid), the default QueueClient is used.

Example hook configuration:

PUT http://myserver7012/gateleen/everything/_hooks/listeners/http/myexample
{
    "methods": [
        "PUT"
    ],
    "queueClient"; "someOtherQueueClient",
    "destination": "/gateleen/example/thePosition",
    "filter": "/gateleen/everything/.*/position.*",
    "staticHeaders": {
        "X-Expire-After": "3600"
    }    
}

[lbovet]

Choosing a different queue implementation is not something specific to hooks. We should open this possibility to other contexts (normal requests, schedulers, ...). Routing to a different queue implementation should be actually done by the queueClient itself. We can have a dispatchingQueueClient that inspects a header (or a prefix of the x-queue name) and delegate to a wrapped queueClient. We have actually done this in our project to use a transient implementation of queues. This actually needs no additional configurable part in gateleen. Not that for hooks, this requires that we can override the queue used for the propagated request. This is something we have in the pipeline in our project but have not yet created a gateleen issue... Let's have a look together to coordinate this.

On Tue, Nov 14, 2017 at 5:13 PM Marc-André Weber notifications@github.com wrote:

The current implementation of the HookHandler allows the definition of exactly one QueueClient implementation. The QueueClient provides access to the queuing mechanism implemented by vertx-redisques https://github.com/swisspush/vertx-redisques.

Since the HookHandler allows a single QueueClient only, all the queueing related actions will be performed against the same vertx-redisques instance.

We have now the requirement to let hooks be performed on different vertx-redisques instances, therefore we should be able to

• configure the vertx-redisques instance to be used in the hook configuration
• provide multiple QueueClient implementations in the HookHandler

To configure the vertx-redisques instance to be used in the hook configuration, a property called queueClient could be added. When no queueClient property is defined (or not valid), the default QueueClient is used.

Example hook configuration:

PUT http://myserver7012/gateleen/everything/_hooks/listeners/http/myexample { "methods": [ "PUT" ], "queueClient"; "someOtherQueueClient", "destination": "/gateleen/example/thePosition", "filter": "/gateleen/everything/./position.", "staticHeaders": { "X-Expire-After": "3600" } }

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/swisspush/gateleen/issues/178, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqPnFf8ajezJVauoJvtENJXdJj4XdsEks5s2bw7gaJpZM4Qdl3i .

[mcweba]

As discussed with @lbovet we do not implement this functionality directly in gateleen. The requirements are very project specific and therefore it would not make much sense to implement this in gateleen.

Since the HookHandler only requires the RequestQueue interface, a project using gateleen is free to implement this interface how ever they want.