[DISCUSS] Add Idempotent Key to External Plugin's PrepareConf Request

[Zexuan Luo <sp...@apache.org>]

Because APISIX is multiple worker architecture, the same route
configuration will be sent multiple times as different PrepareConf
Requests.

When developing a plugin in the runner, we need a way to store route
level data, which is useful for limit-req or other similar features. A
natural way to do it is to store the data in the route configuration.
However, as the PrepareConf Requests are redundant, we can't ensure
the route configurations in the runner to be unique per route.

Therefore, here I propose to add the idempotent key to the PrepareConf
request. We already use a conf_key as the key to identify routes at
the worker level. What we need to do is:
1. send this key via a new field "key" in the PrepareConf request to the runner.
2. before parsing the configuration, the runner needs to check if the
request with the same key has been processed. If so, the runner
returns the token of the previous request directly.

What about your opinions?

Re: [DISCUSS] Add Idempotent Key to External Plugin's PrepareConf Request

[ZhengSong Tu <tz...@gmail.com>]

I get,  +1.

Zexuan Luo <sp...@apache.org> 于2021年7月7日周三 上午8:55写道：

> If we have N route configuration data for the same route, the
> limit-req rank will be N * rate as each configuration has its own
> counter.
>
> ZhengSong Tu <tz...@gmail.com> 于2021年7月6日周二 下午9:19写道：
> >
> > I think I see what you mean. When apisix has some data stored in a lua
> > shared dict,
> > the data structure of the current communication between
> > apisix and runner cannot be expressed, is that what you mean？
> >
> > > we need a way to store route
> > > level data, which is useful for limit-req or other similar features.
> >
> > I still don't understand very well here. Can you use limit-req as an
> > example to describe exactly what is problem.
> >
> >
> > Zexuan Luo <sp...@apache.org> 于2021年7月6日周二 下午3:59写道：
> >
> > > Because APISIX is multiple worker architecture, the same route
> > > configuration will be sent multiple times as different PrepareConf
> > > Requests.
> > >
> > > When developing a plugin in the runner, we need a way to store route
> > > level data, which is useful for limit-req or other similar features. A
> > > natural way to do it is to store the data in the route configuration.
> > > However, as the PrepareConf Requests are redundant, we can't ensure
> > > the route configurations in the runner to be unique per route.
> > >
> > > Therefore, here I propose to add the idempotent key to the PrepareConf
> > > request. We already use a conf_key as the key to identify routes at
> > > the worker level. What we need to do is:
> > > 1. send this key via a new field "key" in the PrepareConf request to
> the
> > > runner.
> > > 2. before parsing the configuration, the runner needs to check if the
> > > request with the same key has been processed. If so, the runner
> > > returns the token of the previous request directly.
> > >
> > > What about your opinions?
> > >
>

Re: [DISCUSS] Add Idempotent Key to External Plugin's PrepareConf Request

[Zexuan Luo <sp...@apache.org>]

If we have N route configuration data for the same route, the
limit-req rank will be N * rate as each configuration has its own
counter.

ZhengSong Tu <tz...@gmail.com> 于2021年7月6日周二 下午9:19写道：
>
> I think I see what you mean. When apisix has some data stored in a lua
> shared dict,
> the data structure of the current communication between
> apisix and runner cannot be expressed, is that what you mean？
>
> > we need a way to store route
> > level data, which is useful for limit-req or other similar features.
>
> I still don't understand very well here. Can you use limit-req as an
> example to describe exactly what is problem.
>
>
> Zexuan Luo <sp...@apache.org> 于2021年7月6日周二 下午3:59写道：
>
> > Because APISIX is multiple worker architecture, the same route
> > configuration will be sent multiple times as different PrepareConf
> > Requests.
> >
> > When developing a plugin in the runner, we need a way to store route
> > level data, which is useful for limit-req or other similar features. A
> > natural way to do it is to store the data in the route configuration.
> > However, as the PrepareConf Requests are redundant, we can't ensure
> > the route configurations in the runner to be unique per route.
> >
> > Therefore, here I propose to add the idempotent key to the PrepareConf
> > request. We already use a conf_key as the key to identify routes at
> > the worker level. What we need to do is:
> > 1. send this key via a new field "key" in the PrepareConf request to the
> > runner.
> > 2. before parsing the configuration, the runner needs to check if the
> > request with the same key has been processed. If so, the runner
> > returns the token of the previous request directly.
> >
> > What about your opinions?
> >

Re: [DISCUSS] Add Idempotent Key to External Plugin's PrepareConf Request

[ZhengSong Tu <tz...@gmail.com>]

I think I see what you mean. When apisix has some data stored in a lua
shared dict,
the data structure of the current communication between
apisix and runner cannot be expressed, is that what you mean？

> we need a way to store route
> level data, which is useful for limit-req or other similar features.

I still don't understand very well here. Can you use limit-req as an
example to describe exactly what is problem.


Zexuan Luo <sp...@apache.org> 于2021年7月6日周二 下午3:59写道：

> Because APISIX is multiple worker architecture, the same route
> configuration will be sent multiple times as different PrepareConf
> Requests.
>
> When developing a plugin in the runner, we need a way to store route
> level data, which is useful for limit-req or other similar features. A
> natural way to do it is to store the data in the route configuration.
> However, as the PrepareConf Requests are redundant, we can't ensure
> the route configurations in the runner to be unique per route.
>
> Therefore, here I propose to add the idempotent key to the PrepareConf
> request. We already use a conf_key as the key to identify routes at
> the worker level. What we need to do is:
> 1. send this key via a new field "key" in the PrepareConf request to the
> runner.
> 2. before parsing the configuration, the runner needs to check if the
> request with the same key has been processed. If so, the runner
> returns the token of the previous request directly.
>
> What about your opinions?
>