You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Acácio Centeno <ac...@azion.com> on 2014/04/01 15:36:05 UTC
Question about developing plugins using the C++ API
Hello,
We're creating a plugin that blocks/redirects some requests based on its
properties. We're using the C++ API, and created a RemapPlugin because we
need different configurations for different mappings.
On the DoRemap method, if we figure we need to block the request, we create
a TransactionPlugin instance, in order to intercept the
SEND_RESPONSE_HEADERS hook and do some modifications to the response, such
as changing the status code and adding headers.
When we did this, ATS would segfault when we tried to set a header. Then we
decided to create a global plugin to do some testing and found out that
just by adding the GlobalPlugin the TransactionPlugin was able to perform
the modification with no errors.
We found out that the reason for this behavior is that the GlobalPlugin
initialization calls a series of methods that end up calling
initTransactionClientResponse before the plugin developers' hooks are
activated.
Notice that a GlobalPlugin + Transaction alone wouldn't do because we need
these different configuration files. Of course we could have just one file
and have a different sections in it for each remap, but we don't like this
approach as the plugin's configuration file would have to be kept in sync
with the remap file, that is, whenever a new mapping was added, we would
have to add another section to the plugin configuration, and given the
dynamic nature of our configurations, we find it to be too error prone.
Given this, are we doing the right thing, that is, creating a Remap +
Transaction + Global plugin or there would be an easier way?
Best regards,
--
Acácio Centeno
Porto Alegre, Brasil + 55 51 3012 3005
Miami, USA + 1 305 704 8816
Quaisquer informações contidas neste e-mail e anexos podem ser
confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
de utilização deste documento depende de autorização do emissor, sujeito as
penalidades cabíveis.
Any information in this e-mail and attachments may be confidential and
privileged, protected by legal confidentiality. The use of this document
require authorization by the issuer, subject to penalties.
Re: Question about developing plugins using the C++ API
Posted by Acácio Centeno <ac...@azion.com>.
Hello,
As it turns out, the transaction.error() call was not the cause of the
problem. We made a minimalist plugin (attached), to simulate the problem,
and it's still happening.
Could someone tell us if we're using the API the wrong way?
We're using v4.2.0 on CentOS 6, and we've recompiled ATS with -O0 -g to
help clear out the problem (the file segfault.log has a backtrace).
Thanks.
On Wed, Apr 2, 2014 at 4:39 PM, Acácio Centeno <ac...@azion.com>wrote:
> We found out we were using the API in a wrong way, we were calling
> transaction.error() and this was causing the problem. Sorry for the
> inconvenience.
>
>
> On Tue, Apr 1, 2014 at 2:25 PM, Brian Geffon <br...@apache.org> wrote:
>
>> Hi,
>> This sounds like a bug in the C++ API, would you mind creating a Jira
>> ticket and assigning it to me?
>>
>> Thanks.
>> Brian
>>
>>
>> On Tue, Apr 1, 2014 at 6:36 AM, Acácio Centeno <acacio.centeno@azion.com
>> >wrote:
>>
>> > Hello,
>> >
>> > We're creating a plugin that blocks/redirects some requests based on its
>> > properties. We're using the C++ API, and created a RemapPlugin because
>> we
>> > need different configurations for different mappings.
>> >
>> On the DoRemap method, if we figure we need to block the request, we
>> create
>> > a TransactionPlugin instance, in order to intercept the
>> > SEND_RESPONSE_HEADERS hook and do some modifications to the response,
>> such
>> > as changing the status code and adding headers.
>>
>>
>> > When we did this, ATS would segfault when we tried to set a header.
>> Then we
>> > decided to create a global plugin to do some testing and found out that
>> > just by adding the GlobalPlugin the TransactionPlugin was able to
>> perform
>> > the modification with no errors.
>>
>>
>> > We found out that the reason for this behavior is that the GlobalPlugin
>> > initialization calls a series of methods that end up calling
>> > initTransactionClientResponse before the plugin developers' hooks are
>> > activated.
>> >
>> > Notice that a GlobalPlugin + Transaction alone wouldn't do because we
>> need
>> > these different configuration files. Of course we could have just one
>> file
>> > and have a different sections in it for each remap, but we don't like
>> this
>> > approach as the plugin's configuration file would have to be kept in
>> sync
>> > with the remap file, that is, whenever a new mapping was added, we would
>> > have to add another section to the plugin configuration, and given the
>> > dynamic nature of our configurations, we find it to be too error prone.
>> >
>> > Given this, are we doing the right thing, that is, creating a Remap +
>> > Transaction + Global plugin or there would be an easier way?
>> >
>> > Best regards,
>> > --
>> > Acácio Centeno
>> >
>> > Porto Alegre, Brasil + 55 51 3012 3005
>> > Miami, USA + 1 305 704 8816
>> >
>> > Quaisquer informações contidas neste e-mail e anexos podem ser
>> > confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer
>> forma
>> > de utilização deste documento depende de autorização do emissor,
>> sujeito as
>> > penalidades cabíveis.
>> >
>> > Any information in this e-mail and attachments may be confidential and
>> > privileged, protected by legal confidentiality. The use of this document
>> > require authorization by the issuer, subject to penalties.
>> >
>>
>
>
>
> --
> Acácio Centeno
>
> Porto Alegre, Brasil + 55 51 3012 3005
> Miami, USA + 1 305 704 8816
>
> Quaisquer informações contidas neste e-mail e anexos podem ser
> confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
> de utilização deste documento depende de autorização do emissor, sujeito as
> penalidades cabíveis.
>
> Any information in this e-mail and attachments may be confidential and
> privileged, protected by legal confidentiality. The use of this document
> require authorization by the issuer, subject to penalties.
>
--
Acácio Centeno
Porto Alegre, Brasil + 55 51 3012 3005
Miami, USA + 1 305 704 8816
Quaisquer informações contidas neste e-mail e anexos podem ser
confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
de utilização deste documento depende de autorização do emissor, sujeito as
penalidades cabíveis.
Any information in this e-mail and attachments may be confidential and
privileged, protected by legal confidentiality. The use of this document
require authorization by the issuer, subject to penalties.
Re: Question about developing plugins using the C++ API
Posted by Acácio Centeno <ac...@azion.com>.
We found out we were using the API in a wrong way, we were calling
transaction.error() and this was causing the problem. Sorry for the
inconvenience.
On Tue, Apr 1, 2014 at 2:25 PM, Brian Geffon <br...@apache.org> wrote:
> Hi,
> This sounds like a bug in the C++ API, would you mind creating a Jira
> ticket and assigning it to me?
>
> Thanks.
> Brian
>
>
> On Tue, Apr 1, 2014 at 6:36 AM, Acácio Centeno <acacio.centeno@azion.com
> >wrote:
>
> > Hello,
> >
> > We're creating a plugin that blocks/redirects some requests based on its
> > properties. We're using the C++ API, and created a RemapPlugin because we
> > need different configurations for different mappings.
> >
> On the DoRemap method, if we figure we need to block the request, we create
> > a TransactionPlugin instance, in order to intercept the
> > SEND_RESPONSE_HEADERS hook and do some modifications to the response,
> such
> > as changing the status code and adding headers.
>
>
> > When we did this, ATS would segfault when we tried to set a header. Then
> we
> > decided to create a global plugin to do some testing and found out that
> > just by adding the GlobalPlugin the TransactionPlugin was able to perform
> > the modification with no errors.
>
>
> > We found out that the reason for this behavior is that the GlobalPlugin
> > initialization calls a series of methods that end up calling
> > initTransactionClientResponse before the plugin developers' hooks are
> > activated.
> >
> > Notice that a GlobalPlugin + Transaction alone wouldn't do because we
> need
> > these different configuration files. Of course we could have just one
> file
> > and have a different sections in it for each remap, but we don't like
> this
> > approach as the plugin's configuration file would have to be kept in sync
> > with the remap file, that is, whenever a new mapping was added, we would
> > have to add another section to the plugin configuration, and given the
> > dynamic nature of our configurations, we find it to be too error prone.
> >
> > Given this, are we doing the right thing, that is, creating a Remap +
> > Transaction + Global plugin or there would be an easier way?
> >
> > Best regards,
> > --
> > Acácio Centeno
> >
> > Porto Alegre, Brasil + 55 51 3012 3005
> > Miami, USA + 1 305 704 8816
> >
> > Quaisquer informações contidas neste e-mail e anexos podem ser
> > confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer
> forma
> > de utilização deste documento depende de autorização do emissor, sujeito
> as
> > penalidades cabíveis.
> >
> > Any information in this e-mail and attachments may be confidential and
> > privileged, protected by legal confidentiality. The use of this document
> > require authorization by the issuer, subject to penalties.
> >
>
--
Acácio Centeno
Porto Alegre, Brasil + 55 51 3012 3005
Miami, USA + 1 305 704 8816
Quaisquer informações contidas neste e-mail e anexos podem ser
confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
de utilização deste documento depende de autorização do emissor, sujeito as
penalidades cabíveis.
Any information in this e-mail and attachments may be confidential and
privileged, protected by legal confidentiality. The use of this document
require authorization by the issuer, subject to penalties.
Re: Question about developing plugins using the C++ API
Posted by Brian Geffon <br...@apache.org>.
Hi,
This sounds like a bug in the C++ API, would you mind creating a Jira
ticket and assigning it to me?
Thanks.
Brian
On Tue, Apr 1, 2014 at 6:36 AM, Acácio Centeno <ac...@azion.com>wrote:
> Hello,
>
> We're creating a plugin that blocks/redirects some requests based on its
> properties. We're using the C++ API, and created a RemapPlugin because we
> need different configurations for different mappings.
>
On the DoRemap method, if we figure we need to block the request, we create
> a TransactionPlugin instance, in order to intercept the
> SEND_RESPONSE_HEADERS hook and do some modifications to the response, such
> as changing the status code and adding headers.
> When we did this, ATS would segfault when we tried to set a header. Then we
> decided to create a global plugin to do some testing and found out that
> just by adding the GlobalPlugin the TransactionPlugin was able to perform
> the modification with no errors.
> We found out that the reason for this behavior is that the GlobalPlugin
> initialization calls a series of methods that end up calling
> initTransactionClientResponse before the plugin developers' hooks are
> activated.
>
> Notice that a GlobalPlugin + Transaction alone wouldn't do because we need
> these different configuration files. Of course we could have just one file
> and have a different sections in it for each remap, but we don't like this
> approach as the plugin's configuration file would have to be kept in sync
> with the remap file, that is, whenever a new mapping was added, we would
> have to add another section to the plugin configuration, and given the
> dynamic nature of our configurations, we find it to be too error prone.
>
> Given this, are we doing the right thing, that is, creating a Remap +
> Transaction + Global plugin or there would be an easier way?
>
> Best regards,
> --
> Acácio Centeno
>
> Porto Alegre, Brasil + 55 51 3012 3005
> Miami, USA + 1 305 704 8816
>
> Quaisquer informações contidas neste e-mail e anexos podem ser
> confidenciais e privilegiadas, protegidas por sigilo legal. Qualquer forma
> de utilização deste documento depende de autorização do emissor, sujeito as
> penalidades cabíveis.
>
> Any information in this e-mail and attachments may be confidential and
> privileged, protected by legal confidentiality. The use of this document
> require authorization by the issuer, subject to penalties.
>