t; Hi,
> I am trying to understand the ATS behavior when it receives a close from
> the client. I would appreciate it if someone can point me in the code where
> to start looking at to understand the behavior. Thanks.
>
> Dk.
>
Hi,
I am trying to understand the ATS behavior when it receives a close from
the client. I would appreciate it if someone can point me in the code where
to start looking at to understand the behavior. Thanks.
Dk.
Hi all,
please take a moment to go through all the Issues you have filed on Github, and
close the ones that are either resolved (i.e. committed via a PR), or those
which no longer applies. Things are running out of control a bit, and we’re not
doing a good job closing open Issues as they are
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/447
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/447#issuecomment-178057937
+1, lets get this back ported to 6.1.1 as well (please mark the Jira
accordingly). Although this might also need that other patch for the new
timeout, right? If so,
GitHub user bryancall opened a pull request:
https://github.com/apache/trafficserver/pull/447
TS-4168: Only close inactive and active connections that have a non-zâ¦
â¦ero timeout
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/434
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user zwoop commented on the pull request:
https://github.com/apache/trafficserver/pull/434#issuecomment-173747195
Looks good, I'd like to get this in for a 6.1.0 respin.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as we
GitHub user bryancall opened a pull request:
https://github.com/apache/trafficserver/pull/434
TS-4131: InactivityCop doesn't close active connections that have timâ¦
â¦edout
You can merge this pull request into a Git repository by running:
$ git pull https://githu
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/389
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user maskit commented on the pull request:
https://github.com/apache/trafficserver/pull/389#issuecomment-170236549
rebased to follow the changes in master
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your pro
Github user masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/389#discussion_r48120660
--- Diff: proxy/http2/HTTP2.cc ---
@@ -665,11 +666,19 @@ http2_decode_header_blocks(HTTPHdr *hdr, const
uint8_t *buf_start, const uint8_t
Github user maskit commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/389#discussion_r48120169
--- Diff: proxy/http2/HTTP2.cc ---
@@ -665,11 +666,19 @@ http2_decode_header_blocks(HTTPHdr *hdr, const
uint8_t *buf_start, const uint8_t
}
Github user masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/389#discussion_r48112070
--- Diff: proxy/http2/HTTP2.cc ---
@@ -665,11 +666,19 @@ http2_decode_header_blocks(HTTPHdr *hdr, const
uint8_t *buf_start, const uint8_t
Github user masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/389#discussion_r48111940
--- Diff: proxy/http2/HTTP2.cc ---
@@ -665,11 +666,19 @@ http2_decode_header_blocks(HTTPHdr *hdr, const
uint8_t *buf_start, const uint8_t
Github user masaori335 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/389#discussion_r48111868
--- Diff: proxy/http2/RegressionHPACK.cc ---
@@ -441,6 +441,7 @@ REGRESSION_TEST(HPACK_Decode)(RegressionTest *t, int,
int *pstatus)
box = RE
GitHub user maskit opened a pull request:
https://github.com/apache/trafficserver/pull/389
TS-3967: Set stream state to close after a RST_STEAM has been sent
https://issues.apache.org/jira/browse/TS-3967
The original patches are on the JIRA ticket. I updated the patches to
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/291
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
GitHub user masaori335 opened a pull request:
https://github.com/apache/trafficserver/pull/291
[TS-3834] Close connection after sending GOAWAY Frame
Fix [TS-3834](https://issues.apache.org/jira/browse/TS-3834)
```
$ ./h2spec -h `hostname` -p 4443 -t -k -s 5.4.1
5.4
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/249
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user shinrich commented on the pull request:
https://github.com/apache/trafficserver/pull/249#issuecomment-121225068
Pushed new changes based on @sudheerv 's comments. Makes sense to keep the
keep-alive case with the session close case, so I also moved that
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
Not what I see for non-VC errors (in fact, there really is no reason to
close the connection on non-VC errors
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
The existing code is pretty eager to do_io_close() on the VC in error cases
anyway.
---
If your project is
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
What if the SM is killed before a tunnel is started (e.g. error responses
before remap, origin connection
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
Ah, in the KA case, ua_session->release() will be called in
tunnel_handler_ua() and ua_session will be set
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
Good point. Thought I tested that case, but evidently not.
---
If your project is set up for it, you can
== 0);
+ // Delay the close of the user agent session, so the close session
+ // occurs after the close transaction
+ if (ua_session != NULL)
--- End diff --
Unless I'm missing something, this seems like it might break (close) keep
alive sessions?
---
If
GitHub user shinrich opened a pull request:
https://github.com/apache/trafficserver/pull/249
TS-1007: SSLN Close called before TXN Close
I'd appreciate a review on this. I feel pretty comfortable with the change
in HttpSM.cc to delay the session close until after the transa
0;
+if (this->lerrno < 0) {
Why do you look at VConnection::lerrno instead of the lerrno argument?
Hmm. Good catch. I started with someone else's patch. They had the
code in a UnixNetVConnection free close function. Seemed more
appropriate to move it back to a virtual over
> + Debug("ssl-shutdown", "previous shutdown state 0x%x", shutdown_mode);
> + new_shutdown_mode = shutdown_mode | SSL_RECEIVED_SHUTDOWN;
> +}
> +if (new_shutdown_mode != shutdown_mode) {
> + // We do not need to sit around and wait for
> On Jan 15, 2015, at 5:29 PM, zw...@apache.org wrote:
>
>
[snip]
> diff --git a/plugins/tcpinfo/tcpinfo.cc b/plugins/tcpinfo/tcpinfo.cc
> index 481f553..1937eed 100644
> --- a/plugins/tcpinfo/tcpinfo.cc
> +++ b/plugins/tcpinfo/tcpinfo.cc
> @@ -171,12 +171,9 @@ log_tcp_info(Config * config, cons
Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/42
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
GitHub user jablko opened a pull request:
https://github.com/apache/trafficserver/pull/42
TS-2578 Close the client connection when you close TransformTerminus
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jablko/trafficserver
fixed
-Bryan
On Jul 10, 2013, at 2:50 AM, Igor Galić wrote:
>> diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
>> index 8035b38..aebdd89 100644
>> --- a/proxy/http/HttpSM.cc
>> +++ b/proxy/http/HttpSM.cc
>> @@ -3285,6 +3285,11 @@ HttpSM::tunnel_handler_post_ua(int event,
>> HttpTunnelP
> diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
> index 8035b38..aebdd89 100644
> --- a/proxy/http/HttpSM.cc
> +++ b/proxy/http/HttpSM.cc
> @@ -3285,6 +3285,11 @@ HttpSM::tunnel_handler_post_ua(int event,
> HttpTunnelProducer * p)
>case VC_EVENT_READ_COMPLETE:
>case HTTP_TUNNEL_E
Hi Alan,
Thanks for the reply.
I guess by chunk you mean a request to origin server.
I dont get it why I will get two VConn close events due to chunks not
consistent in size. I think they will only impact performace of read/write.
Code Logic:-
I have created a thread function for read/write
g> wrote:
Updated Branches:
refs/heads/master 4a614a967 -> 27c0f2248
TS-1601: HttpServerSession::release don't close ServerSession if
ServerSessionPool locking contention
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo
Commit: http://git-wip-us.apache.org/repo
On 04/01/2013, at 6:27 PM, chen...@apache.org wrote:
> Updated Branches:
> refs/heads/master 4a614a967 -> 27c0f2248
>
>
> TS-1601: HttpServerSession::release don't close ServerSession if
> ServerSessionPool locking contention
>
>
> Project: htt
Hi All,
Currently , it seems not possible to generate chunked responses whenever a
transform plugin is executed on the origin response.
Instead, ts will disable keepalive.
I created a jira ticket and a proposed patch
https://issues.apache.org/jira/browse/TS-1004
Regards,
Otto van der Schaaf
difference between these methods is,
> other than close() printing an error message if the caller tries to
> close STDIN (file descriptor 0). Surely that check isn't enough to
> make one "fast" and the other not.
>
I can't see what the functional difference between these methods is,
other than close() printing an error message if the caller tries to
close STDIN (file descriptor 0). Surely that check isn't enough to
make one "fast" and the other not.
41 matches
Mail list logo
