A note about the operation of the plugin.
The decision to abort the connection typically happens after all input has
been read, but before writing all the output.
The plugin withholds (in a buffer) a certain amount of tail output, until
it can be sure that the connection will not have to be aborted - that
decision is dependent on the entire input.
If everything is OK, the remaining withheld data is written out, otherwise
the transaction should be aborted.
On Tue, Oct 29, 2013 at 11:46 AM, Carlos Guerreiro <
carlos.h.guerre...@gmail.com> wrote:
> Same result:
>
> FATAL: HttpTunnel.cc:1243: failed assert `c->alive == true`
>
>
>
> On Mon, Oct 28, 2013 at 9:13 PM, Carlos Guerreiro <
> carlos.h.guerre...@gmail.com> wrote:
>
>> Hi Shaun,
>>
>> I haven't tried sending TS_EVENT_VCONN_EOS yet. I'll tried it out
>> tomorrow for sure.
>> Thanks for the hint.
>>
>> Br,
>> Carlos
>>
>>
>> On Mon, Oct 28, 2013 at 8:18 PM, Shaun mcginnity <
>> shaun.mcginn...@gmail.com> wrote:
>>
>>> Hi Carlos,
>>>
>>> Have you tried sending TS_EVENT_VCONN_EOS to the VConn write VIO? (This
>>> was
>>> Alan's recommendation and it works for us.)
>>>
>>> Regards,
>>>
>>> Shaun
>>>
>>>
>>> On Oct 28, 2013, at 3:51 AM, Carlos Guerreiro
>>> <carlos.h.guerre...@gmail.com> wrote:
>>>
>>> > Thanks for the hint.
>>> >
>>> > I've tried that before (and again now). Unfortunately I get an assert
>>> and a
>>> > crash right on TSContCall.
>>> >
>>> > [Oct 28 12:37:48.170] Server {0x2aaaadbea700} DEBUG:
>>> <HttpTunnel.cc:1241
>>> > (consumer_handler)> (http_tunnel) [0] consumer_handler [transform write
>>> > VC_EVENT_ERROR]
>>> > FATAL: HttpTunnel.cc:1243: failed assert `c->alive == true`
>>> >
>>> > This happens at a point where data has been written to the output
>>> > connection but the write operation has not yet completed.
>>> > Any suggestions are welcome.
>>>
>>> I think that Brian and Alan are the most experience with
>>> transformations. Maybe they can help
>>> ...
>>>
>>> >
>>> > Br,
>>> > Carlos
>>> >
>>> >
>>> >
>>> > On Fri, Oct 25, 2013 at 6:56 PM, James Peach <jpe...@apache.org>
>>> wrote:
>>> >
>>> >> On Oct 24, 2013, at 10:59 PM, Carlos Guerreiro <
>>> >> carlos.h.guerre...@gmail.com> wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> What is the correct way to abort an HTTP transaction in a
>>> transformation
>>> >>> plugin, while transforming the message body?
>>> >>> So that origin server and client sockets are closed ASAP and
>>> everything
>>> >> is
>>> >>> cleaned up properly in the entire transformation chain.
>>> >>
>>> >> I'm guessing that you would inject the error into the transformation
>>> chain
>>> >> using TSContCall(..., TS_EVENT_ERROR, ...). I see this being done in
>>> >> plugins/gzip/gzip.cc, plugins/experimental/esi/esi.cc and
>>> >> lib/atscppapi/src/TransformationPlugin.cc.
>>> >>
>>> >> Interestingly, most of these examples use that pattern to propagate
>>> >> errors, but few (none?) use it to generate errors.
>>> >>
>>> >> J
>>> >>
>>>
>>
>>
>
