Webhook trigger multiple times when using sg-replicate

[arihant rk]

We have been trying out the sg-replicate which replicates clients requests between syncgateway's for active-active scenarios. but we could see that replication happens as like clients posting same request to another syncgateway.

we are using webhooks for triggering pending documents which changes state as it triggers to webservices. 

we are seeing webhook is triggering twice, one for actual and other for replicated syncgateway which should not be the case for active -active scenarios. applications will receive webhook trigger multiplesfor the same document.

any solution to stop webhook triggering in replicated syncgateway?

[Jens Alfke]

On Jul 4, 2016, at 11:45 PM, arihant rk <ark...@gmail.com> wrote:

We have been trying out the sg-replicate which replicates clients requests between syncgateway's for active-active scenarios. but we could see that replication happens as like clients posting same request to another sync gateway.

Yes. sg_replicate and Couchbase Lite use the same replication protocol.

we are seeing webhook is triggering twice, one for actual and other for replicated syncgateway which should not be the case for active -active scenarios. applications will receive webhook trigger multiplesfor the same document.

If you have web-hooks defined on both servers, and one server is replicating documents to the other, then yes, you would see the web-hooks fire on both servers. That’s expected behavior. The web-hook fires when a revision is added to that server.

any solution to stop webhook triggering in replicated sync gateway?

Don’t configure web-hooks on that server?

You’ll probably need to describe in more detail what you’re using the web-hooks for, why you need them on both servers, and why it’s wrong for them to fire on both.

—Jens

[arihant rk]

Thanks Alfke for quick reply,

we want use sg-replicate for active-active scenarioes. two syncgateway replication, and each one will be connected respective couchbase cluster. i am using a same config file in both syncgateway.

And clients will be connected to both syncgateways and serving requests.

we are using the webhooks for activating clients, we can not have different configurations in both syncgateways as request will be of similar kind in both syncgateways. 

if the request sent SYNC1 and webhook triggered to activate. The same request will be replicated to SYNC 2 by sg-replicate, again webhook triggers for activating client which is already activated.

webhooks used for sending events, why do we need same events multiple times.

please let me know is it correct usage of webhook.

[Jens Alfke]

On Jul 5, 2016, at 2:07 AM, arihant rk <ark...@gmail.com> wrote:

if the request sent SYNC1 and webhook triggered to activate. The same request will be replicated to SYNC 2 by sg-replicate, again webhook triggers for activating client which is already activated.

Can you just ignore the redundant activation if you see the client is already activated?

webhooks used for sending events, why do we need same events multiple times.

Because it’s a distributed system; especially when you use active-active replication, which means you’ve created a peer-to-peer network (where some of the peers happen to be servers.) A document revision arriving at a peer isn’t a unique event; it’s information propagating across the mesh.

—Jens

[arihant rk]

Thanks jens,

if we are using for active-active and for we are using webhooks for other usecases. it will be overhead on application. 

is it possible to distinguish requests from sg-replicate and acuaul client to syncgateway in the webhook. and we can ignore in the webook part of syncgateway.

[Jens Alfke]

On Jul 7, 2016, at 5:55 AM, arihant rk <ark...@gmail.com> wrote:

is it possible to distinguish requests from sg-replicate and acuaul client to syncgateway in the webhook. and we can ignore in the webook part of syncgateway.

I don’t think so. The requests come in using the REST API like any others. At the REST handler level SG could tell the difference from the User-Agent header, but that info isn’t passed down to the storage level that the web-hook is called from.

—Jens