TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

["Owens, Steve" <St...@disney.com>]

Hello,

I am not sure if this question should be directed to the users or the dev
discussion group so please advise on proper categorization of this inquiry.

I am trying to debug a transformation plugin that I have developed that
simply prepends and appends a small string to whatever content is being
returned to the client.

About 70% of the time this plugin works as expected and writes the prefix
and suffix and the entire content is delivered to the client.

However about 30% of the time the content is truncated at the client even
though the trace logging indicates that all of the content was written to
the output VIO.

It seems to be a race condition wherein sometimes the transaction is shut
down before ATS delivers all of the content to the client.

The only API call I am making from within my plugin that could indicate to
ATS that we are done with processing is

 	TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

I am making this call in response to a TS_EVENT_VCONN_WRITE_COMPLETE
subject to the following conditions:
1. I have already written all content that I am ever going to write to the
Output VIO e.g 33993 bytes in total.
2. I have confirmed that the output_vio.nbytes = 33993; output_vio.ndone=
33993.

I do not make the call to
TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1) unless both
conditions are met.

YET, for some reason in about 1/3 of the times the code executes, the
content is truncated and I am observing things in my logs that indicate
that something has shut down the transaction.


My question is what more can I do to ensure that ATS behaves reliably and
delivers the content that I have written to the output vio to the client?

Best Regards,

Steve Owens

Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

[James Peach <jp...@apache.org>]

On Aug 27, 2013, at 7:29 PM, "Bardwell, William" <wb...@akamai.com> wrote:

> I also think that the current behavior is wrong.  I think that TSVConnShutdown(0,1) should be equivalent to shutdown(SHUT_WR) which means that it causes an eof to be read by the other end of the connection.  Indeed I am having issues using the VConn from TSHttpConnect() where there is no way to tell it that I am done sending a request such that I get a clear indication when the response is done.  Most of the code treats a shutdown properly, but PluginVC::do_io_shutdown() does not seem to do quite the right thing, HttpSM::tunnel_handler_ua()  and  HttpTunnel::consumer_handler() also treat EOS slightly wrong (they close things up totally), HttpTransact.cc how_to_open_connection() insists on no pending_work which seems wrong...I am working on a fix, but I am not sure if I am there yet.

Are there any small fixes or refactorings that would make the behaviour more consistent? Maybe not a complete fix, but an incremental improvement ...

> 
> -William bardwell
> ________________________________________
> From: Alan M. Carroll [amc@network-geographics.com]
> Sent: Saturday, August 17, 2013 10:48 PM
> To: Owens, Steve
> Subject: Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
> 
> Monday, August 12, 2013, 5:55:44 PM, you wrote:
> 
>> The only API call I am making from within my plugin that could indicate to
>> ATS that we are done with processing is
> 
>>        TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);
> 
> That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.
> 
> The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.

RE: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

["Bardwell, William" <wb...@akamai.com>]

I also think that the current behavior is wrong.  I think that TSVConnShutdown(0,1) should be equivalent to shutdown(SHUT_WR) which means that it causes an eof to be read by the other end of the connection.  Indeed I am having issues using the VConn from TSHttpConnect() where there is no way to tell it that I am done sending a request such that I get a clear indication when the response is done.  Most of the code treats a shutdown properly, but PluginVC::do_io_shutdown() does not seem to do quite the right thing, HttpSM::tunnel_handler_ua()  and  HttpTunnel::consumer_handler() also treat EOS slightly wrong (they close things up totally), HttpTransact.cc how_to_open_connection() insists on no pending_work which seems wrong...I am working on a fix, but I am not sure if I am there yet.

-William bardwell
________________________________________
From: Alan M. Carroll [amc@network-geographics.com]
Sent: Saturday, August 17, 2013 10:48 PM
To: Owens, Steve
Subject: Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

Monday, August 12, 2013, 5:55:44 PM, you wrote:

> The only API call I am making from within my plugin that could indicate to
> ATS that we are done with processing is

>         TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.

The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.

Re: TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

["Alan M. Carroll" <am...@network-geographics.com>]

Monday, August 12, 2013, 5:55:44 PM, you wrote:

> The only API call I am making from within my plugin that could indicate to
> ATS that we are done with processing is

>         TSVConnShutdown(TSTransformOutputVConnGet(contp), 0, 1);

That call means "shut down the connection right now", which seems to be precisely the effect you are seeing.

The better thing to do is chain the TS_EVENT_VCONN_WRITE_COMPLETE to the input VIO from which you are getting data. See example/null-transform/null-transform.c:190.