You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Nishant Gaurav <ng...@linkedin.com.INVALID> on 2017/05/17 22:54:47 UTC
Reloading remap.config without restarting trafficserver
Hi everyone,
I work as a part of Traffic team at LinkedIn. Our team has a use case where
we want to reload ‘remap.config’ without restarting trafficserver. I
understand that I can use ‘traffic_ctl config reload’ command for the same,
but we don’t want dependence on an external process to run traffic_ctl.
In order to achieve this I submitted this pull request
<https://github.com/apache/trafficserver/pull/1815/files> last week, in
which I introduced a new API function 'TSRemapConfigReload()' which can
reload remap.config. The way we are using it is that we have a thread
(running as a part of plugin) which keeps on polling a git mirror at
regular interval. Once it identifies that there is a change in remap.config
file in that git mirror, it pulls the new file and replaces the the old
config file with the new one on disk (with creating a backup of the
previous one). After doing that it calls TSRemapConfigReload() to reload
the new remap.config.
The corresponding pull request for this was not accepted as James pointed
out that plugin is not the correct place to do it. As an alternative he
suggested that we can use ‘TSReconfigure()’ which is part of ‘mgmtapi.h’.
The problem with that is, the functions as a part of management API are not
available inside plugins.
I am starting this thread to discuss the correct way to solve this problem.
Regards,
Nishant
Re: Reloading remap.config without restarting trafficserver
Posted by James Peach <jp...@apache.org>.
On 17 May 2017, at 15:54, Nishant Gaurav wrote:
> Hi everyone,
>
> I work as a part of Traffic team at LinkedIn. Our team has a use case
> where
> we want to reload ‘remap.config’ without restarting trafficserver.
> I
> understand that I can use ‘traffic_ctl config reload’ command for
> the same,
> but we don’t want dependence on an external process to run
> traffic_ctl.
In the medium term, can you reconsider this? I don’t know of any
drawbacks to running traffic_manager.
> In order to achieve this I submitted this pull request
> <https://github.com/apache/trafficserver/pull/1815/files> last week,
> in
> which I introduced a new API function 'TSRemapConfigReload()' which
> can
> reload remap.config. The way we are using it is that we have a thread
> (running as a part of plugin) which keeps on polling a git mirror at
> regular interval. Once it identifies that there is a change in
> remap.config
> file in that git mirror, it pulls the new file and replaces the the
> old
> config file with the new one on disk (with creating a backup of the
> previous one). After doing that it calls TSRemapConfigReload() to
> reload
> the new remap.config.
To elaborate a bit … I think that just having TSRemapConfigReload() is
not sufficient. There are potentially lots of reload cases and I think
that having a single API that covers just one of those makes for
unwieldy and unsatisfying usage. What I would like to see is a really
good reason that the existing management API could not be used, in
conjunction with a proposal that covers approximately the same set of
use cases.
Without knowing anything about your deployment, it seems so easy to
write something like a small Go program to do the poll and call
TSReconfigure that I don’t really understand why you’d want to do
this in a plugin :)
> The corresponding pull request for this was not accepted as James
> pointed
> out that plugin is not the correct place to do it. As an alternative
> he
> suggested that we can use ‘TSReconfigure()’ which is part of
> ‘mgmtapi.h’.
> The problem with that is, the functions as a part of management API
> are not
> available inside plugins.
AFAIK it’s fine for plugins to use the management API, but of course
you would need to be running traffic_manager for it to work. The main
drawbacks to using the management API that I can think of are that it is
blocking, and that it uses a single global socket internally, so you
would need to guarantee that only one plugin at a time is using it.
cheers,
James
Re: Reloading remap.config without restarting trafficserver
Posted by Nishant Gaurav <ng...@linkedin.com.INVALID>.
Thank you, James and Leif for your reply. There are couple of problems
that I had while using TSReconfigure (from mgmtapi.h).
There are some functions which have been defined in both ‘ts.h’ and
‘mgmtapi.h’ with different argument types which leads to conflict as both
of them are C APIs, and function overloading is now allowed there.
For Example : In ‘ts.h’ _TSstrdup() has been defined as
tsapi char *_TSstrdup(const char *str, *int64_t length*, const char *path);
the same function has been defined in mgmtapi.h as
tsapi char *_TSstrdup(const char *str, *int length*, const char *path);
There are similar other functions like _TSmalloc() and _TSrealloc(), which
are defined in both the APIs, and have different argument types like
‘size_t’ and ‘unsigned int’. Since I need both ‘ts.h’ and ‘mgmtapi.h’
inside my plugin I get compile time failure mentioning conflicts while
building my plugin.
The other reason why I am not inclined towards using TSReconfigure(), is
because it reloads remap.config asynchronously by signaling event to
LocalManager. Because of this, if a faulty remap.config is getting
reloaded, our plugin code will have no way to know that an error has
happened. In case of failure we want to inform other systems like send an
event to monitoring system.
Also ‘TSReconfigure()’ reloads all the configs where as our use case is to
just reload remap.config (as it gets changed frequently) where as other
configs config changes are not frequent and have other mechanism of getting
deployed.
One other alternative that I have is to define reloadUrlRewrite() function
inside my plugin with an ‘extern’ identifier. That way I will be able to
use this to reload the reamp.config file without having a compile time
error, and at runtime the corresponding implementation inside
ReverseProxy.cc will be called. Since this code is being run as a part of
async thread, I don't mind it being blocking. Just wanted to get your
thought on this one.
Regards,
Nishant
On Fri, May 19, 2017 at 1:50 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> > On May 17, 2017, at 4:54 PM, Nishant Gaurav <ng...@linkedin.com.INVALID>
> wrote:
> >
> > Hi everyone,
> >
> > I work as a part of Traffic team at LinkedIn. Our team has a use case
> where
> > we want to reload ‘remap.config’ without restarting trafficserver. I
> > understand that I can use ‘traffic_ctl config reload’ command for the
> same,
> > but we don’t want dependence on an external process to run traffic_ctl.
> >
> > In order to achieve this I submitted this pull request
> > <https://github.com/apache/trafficserver/pull/1815/files> last week, in
> > which I introduced a new API function 'TSRemapConfigReload()' which can
>
>
> Hmmm, not sure I fully understand this, but why wouldn’t you use the Mgmt
> C-API for this in your plugin? You don’t need a new TS API for that, no?
> I’m sure you can look at the code for traffic_ctl, and see how it uses the
> mgmt C-APIs to do the config reload.
>
> Or what am I missing? :-)
>
> Cheers,
>
> — leif
>
>
Re: Reloading remap.config without restarting trafficserver
Posted by Leif Hedstrom <zw...@apache.org>.
> On May 17, 2017, at 4:54 PM, Nishant Gaurav <ng...@linkedin.com.INVALID> wrote:
>
> Hi everyone,
>
> I work as a part of Traffic team at LinkedIn. Our team has a use case where
> we want to reload ‘remap.config’ without restarting trafficserver. I
> understand that I can use ‘traffic_ctl config reload’ command for the same,
> but we don’t want dependence on an external process to run traffic_ctl.
>
> In order to achieve this I submitted this pull request
> <https://github.com/apache/trafficserver/pull/1815/files> last week, in
> which I introduced a new API function 'TSRemapConfigReload()' which can
Hmmm, not sure I fully understand this, but why wouldn’t you use the Mgmt C-API for this in your plugin? You don’t need a new TS API for that, no? I’m sure you can look at the code for traffic_ctl, and see how it uses the mgmt C-APIs to do the config reload.
Or what am I missing? :-)
Cheers,
— leif
Re: Reloading remap.config without restarting trafficserver
Posted by Alan Carroll <so...@yahoo-inc.com.INVALID>.
One option would be to schedule an event on a ET_TASK thread and call system("traffic_ctl config reload") there. Or, if you already have a thread polling a mirror, why not call system("...") there?
On Wednesday, May 17, 2017, 6:55:38 PM EDT, Nishant Gaurav <ng...@linkedin.com.INVALID> wrote: Hi everyone,
I work as a part of Traffic team at LinkedIn. Our team has a use case where
we want to reload ‘remap.config’ without restarting trafficserver. I
understand that I can use ‘traffic_ctl config reload’ command for the same,
but we don’t want dependence on an external process to run traffic_ctl.
In order to achieve this I submitted this pull request
<https://github.com/apache/trafficserver/pull/1815/files> last week, in
which I introduced a new API function 'TSRemapConfigReload()' which can
reload remap.config. The way we are using it is that we have a thread
(running as a part of plugin) which keeps on polling a git mirror at
regular interval. Once it identifies that there is a change in remap.config
file in that git mirror, it pulls the new file and replaces the the old
config file with the new one on disk (with creating a backup of the
previous one). After doing that it calls TSRemapConfigReload() to reload
the new remap.config.
The corresponding pull request for this was not accepted as James pointed
out that plugin is not the correct place to do it. As an alternative he
suggested that we can use ‘TSReconfigure()’ which is part of ‘mgmtapi.h’.
The problem with that is, the functions as a part of management API are not
available inside plugins.
I am starting this thread to discuss the correct way to solve this problem.
Regards,
Nishant