[jira] [Work logged] (TS-4735) Possible deadlock on traffic_server startup

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4735?focusedWorklogId=26564=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26564
 ]

ASF GitHub Bot logged work on TS-4735:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 04:17
Start Date: 18/Aug/16 04:17
Worklog Time Spent: 10m 
  Work Description: GitHub user kshri23 opened a pull request:

https://github.com/apache/trafficserver/pull/872

TS-4735: Fix race condition in traffic_server startup

Set max_msgs_in_row to 1 temporarily during traffic_server startup to avoid 
a hitting race condition when we receive configurations continuously from 
traffic_manager while coming up. We will reset this limit back to 10,000 in 
reconfigure() once the initial synchronization is done.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kshri23/trafficserver fix_4735

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/872.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #872


commit 0fd360bd3154a02a8c532de87f6b001adf14ed7f
Author: Shrihari Kalkar 
Date:   2016-08-18T02:32:49Z

Fix race condition in traffic_server startup

Set max_msgs_in_row to 1 during traffic_server startup to avoid hitting
race condition as seen in issue TS-4735




Issue Time Tracking
---

Worklog Id: (was: 26564)
Time Spent: 10m
Remaining Estimate: 0h

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating 

[GitHub] trafficserver pull request #872: TS-4735: Fix race condition in traffic_serv...

[kshri23]

GitHub user kshri23 opened a pull request:

https://github.com/apache/trafficserver/pull/872

TS-4735: Fix race condition in traffic_server startup

Set max_msgs_in_row to 1 temporarily during traffic_server startup to avoid 
a hitting race condition when we receive configurations continuously from 
traffic_manager while coming up. We will reset this limit back to 10,000 in 
reconfigure() once the initial synchronization is done.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kshri23/trafficserver fix_4735

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/872.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #872


commit 0fd360bd3154a02a8c532de87f6b001adf14ed7f
Author: Shrihari Kalkar 
Date:   2016-08-18T02:32:49Z

Fix race condition in traffic_server startup

Set max_msgs_in_row to 1 during traffic_server startup to avoid hitting
race condition as seen in issue TS-4735




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26563=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26563
 ]

ASF GitHub Bot logged work on TS-4733:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 02:51
Start Date: 18/Aug/16 02:51
Worklog Time Spent: 10m 
  Work Description: Github user kshri23 commented on the issue:

https://github.com/apache/trafficserver/pull/871
  
Yes, it does. I verified that by running the test submitted as part of that 
fix.


Issue Time Tracking
---

Worklog Id: (was: 26563)
Time Spent: 0.5h  (was: 20m)

> Cache writes fail when client requests IMS and server replies 200
> -
>
> Key: TS-4733
> URL: https://issues.apache.org/jira/browse/TS-4733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #871: TS-4733: Skip modifying response length for HEAD r...

[kshri23]

Github user kshri23 commented on the issue:

https://github.com/apache/trafficserver/pull/871
  
Yes, it does. I verified that by running the test submitted as part of that 
fix.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26562=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26562
 ]

ASF GitHub Bot logged work on TS-4733:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 02:49
Start Date: 18/Aug/16 02:49
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/871
  
Does this replace the previous commits from TS-3828? The last comment is a 
little confusing, in that it sounds this would replace the previous commits?


Issue Time Tracking
---

Worklog Id: (was: 26562)
Time Spent: 20m  (was: 10m)

> Cache writes fail when client requests IMS and server replies 200
> -
>
> Key: TS-4733
> URL: https://issues.apache.org/jira/browse/TS-4733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #871: TS-4733: Skip modifying response length for HEAD r...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/871
  
Does this replace the previous commits from TS-3828? The last comment is a 
little confusing, in that it sounds this would replace the previous commits?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work started] (TS-4735) Possible deadlock on traffic_server startup

[Shrihari (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TS-4735 started by Shrihari.

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4735) Possible deadlock on traffic_server startup

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4735:
--
Assignee: Shrihari

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26561=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26561
 ]

ASF GitHub Bot logged work on TS-4733:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 02:18
Start Date: 18/Aug/16 02:18
Worklog Time Spent: 10m 
  Work Description: GitHub user kshri23 opened a pull request:

https://github.com/apache/trafficserver/pull/871

TS-4733: Skip modifying response length for HEAD response

When we get a response to a HEAD request and if the response header
has a 'CHUNKED' header we set the response length to undefined. We
shouldn't be doing that because that length is used later to send the
response to client.
This fixes TS-3828 in a different way.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kshri23/trafficserver fix_4733

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/871.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #871


commit 8811c02da0d8b36305ebd11102cd95ce9209e5c4
Author: Shrihari Kalkar 
Date:   2016-08-18T02:07:54Z

Skip modifying response length for HEAD response

When we get a response to a HEAD request and if the response header
has a 'CHUNKED' header we set the response length to undefined. We
shouldn't be doing that because that length is used later to send the
response to client.




Issue Time Tracking
---

Worklog Id: (was: 26561)
Time Spent: 10m
Remaining Estimate: 0h

> Cache writes fail when client requests IMS and server replies 200
> -
>
> Key: TS-4733
> URL: https://issues.apache.org/jira/browse/TS-4733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #871: TS-4733: Skip modifying response length for...

[kshri23]

GitHub user kshri23 opened a pull request:

https://github.com/apache/trafficserver/pull/871

TS-4733: Skip modifying response length for HEAD response

When we get a response to a HEAD request and if the response header
has a 'CHUNKED' header we set the response length to undefined. We
shouldn't be doing that because that length is used later to send the
response to client.
This fixes TS-3828 in a different way.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kshri23/trafficserver fix_4733

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/871.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #871


commit 8811c02da0d8b36305ebd11102cd95ce9209e5c4
Author: Shrihari Kalkar 
Date:   2016-08-18T02:07:54Z

Skip modifying response length for HEAD response

When we get a response to a HEAD request and if the response header
has a 'CHUNKED' header we set the response length to undefined. We
shouldn't be doing that because that length is used later to send the
response to client.




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4735) Possible deadlock on traffic_server startup

[Shrihari (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425785#comment-15425785
 ] 

Shrihari commented on TS-4735:
--

Leif, yes. I am working on a fix for this right now. I am just going over the 
workflow right now.

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4217) END_STREAM flag is sent twice

[Masakazu Kitajo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masakazu Kitajo reassigned TS-4217:
---

Assignee: Masakazu Kitajo

> END_STREAM flag is sent twice
> -
>
> Key: TS-4217
> URL: https://issues.apache.org/jira/browse/TS-4217
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.2, 6.1.1
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> END_STREAM flag is sent twice if a response has Content-Length header and its 
> value is zero.
> The first one is on a HEADERS frame and the second one is on a DATA frame. 
> The DATA frame should not be sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4217) END_STREAM flag is sent twice

[Masakazu Kitajo (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425760#comment-15425760
 ] 

Masakazu Kitajo commented on TS-4217:
-

It still happens on master. This is obviously a bug but shouldn't cause a big 
problem.

> END_STREAM flag is sent twice
> -
>
> Key: TS-4217
> URL: https://issues.apache.org/jira/browse/TS-4217
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 5.3.2, 6.1.1
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> END_STREAM flag is sent twice if a response has Content-Length header and its 
> value is zero.
> The first one is on a HEADERS frame and the second one is on a DATA frame. 
> The DATA frame should not be sent.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-2237) URL encoding wrong in squid.blog

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2237?focusedWorklogId=26560=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26560
 ]

ASF GitHub Bot logged work on TS-2237:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:58
Start Date: 18/Aug/16 00:58
Worklog Time Spent: 10m 
  Work Description: Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
I'd say it is not sufficient.

As a workaround for most cases, it works, and personally I'm OK with it as 
is. However, I think the behavior of `TSStringPercentEncode` shouldn't be 
changed because it's just a workaround for logging issue.

So, if the API keeps current behavior, then I'm fine with landing this 
change.


Issue Time Tracking
---

Worklog Id: (was: 26560)
Time Spent: 2h 50m  (was: 2h 40m)

> URL encoding wrong in squid.blog
> 
>
> Key: TS-2237
> URL: https://issues.apache.org/jira/browse/TS-2237
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: David Carlin
>Assignee: Sudheer Vinukonda
>Priority: Minor
>  Labels: yahoo
> Fix For: 7.0.0
>
> Attachments: TS-2237.diff
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> I was replaying URLs captured from squid.blog and I noticed I was getting 
> 404's for some of them when squid.blog showed a 200 for that request.  Turns 
> out there is an issue with URL encoding.  For example:
> Requesting file 'duck%20sports%20authority.gif' via curl will put this in the 
> logs:
> duck%2520sports%2520authority.gif
> The % from %20 (space) in the request is being converted to %25 resulting in 
> %2520
> I tested both the % and % log fields - same thing happens.  I 
> tested on ATS 3.2.0 and 3.3.5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #866: TS-2237: Fix double encoding of URLs in squid logs...

[maskit]

Github user maskit commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
I'd say it is not sufficient.

As a workaround for most cases, it works, and personally I'm OK with it as 
is. However, I think the behavior of `TSStringPercentEncode` shouldn't be 
changed because it's just a workaround for logging issue.

So, if the API keeps current behavior, then I'm fine with landing this 
change.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4750:
--
Fix Version/s: 7.0.0

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4762) Improve the Lua package import paths.

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425681#comment-15425681
 ] 

Leif Hedstrom commented on TS-4762:
---

I have no idea, maybe also drag in [~humbedooh] ?

> Improve the Lua package import paths.
> -
>
> Key: TS-4762
> URL: https://issues.apache.org/jira/browse/TS-4762
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: sometime
>
>
> I noticed that when you build ATS with a non-default prefix, you end up with 
> unexpected Lua package paths.
> For example, this is what I had for {{package.path}}:
> {noformat}
> ./?.lua;/n/trafficserver/share/luajit-2.0.4/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/n/trafficserver/share/lua/5.1/?.lua;/n/trafficserver/share/lua/5.1/?/init.lua
> {noformat}
> Maybe we can think of a way to automatically get the right paths for the 
> platform.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4762) Improve the Lua package import paths.

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4762:
--
Fix Version/s: sometime

> Improve the Lua package import paths.
> -
>
> Key: TS-4762
> URL: https://issues.apache.org/jira/browse/TS-4762
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: sometime
>
>
> I noticed that when you build ATS with a non-default prefix, you end up with 
> unexpected Lua package paths.
> For example, this is what I had for {{package.path}}:
> {noformat}
> ./?.lua;/n/trafficserver/share/luajit-2.0.4/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/n/trafficserver/share/lua/5.1/?.lua;/n/trafficserver/share/lua/5.1/?/init.lua
> {noformat}
> Maybe we can think of a way to automatically get the right paths for the 
> platform.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4761) Let the Lua format() function accept a single string

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4761:
--
Fix Version/s: (was: 7.1.0)
   7.0.0

> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4761) Let the Lua format() function accept a single string

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4761:
--
Fix Version/s: 7.1.0

> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4762) Improve the Lua package import paths.

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4762:
--
Assignee: James Peach

> Improve the Lua package import paths.
> -
>
> Key: TS-4762
> URL: https://issues.apache.org/jira/browse/TS-4762
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua
>Reporter: James Peach
>Assignee: James Peach
>
> I noticed that when you build ATS with a non-default prefix, you end up with 
> unexpected Lua package paths.
> For example, this is what I had for {{package.path}}:
> {noformat}
> ./?.lua;/n/trafficserver/share/luajit-2.0.4/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/n/trafficserver/share/lua/5.1/?.lua;/n/trafficserver/share/lua/5.1/?/init.lua
> {noformat}
> Maybe we can think of a way to automatically get the right paths for the 
> platform.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4761) Let the Lua format() function accept a single string

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4761:
--
Assignee: James Peach

> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4761) Let the Lua format() function accept a single string

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425677#comment-15425677
 ] 

Leif Hedstrom commented on TS-4761:
---

Sounds good to me, make it so #1.

> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4758) back up the state machine after parent proxy failures

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4758:
--
Fix Version/s: sometime

> back up the state machine after parent proxy failures
> -
>
> Key: TS-4758
> URL: https://issues.apache.org/jira/browse/TS-4758
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy
>Reporter: James Peach
> Fix For: sometime
>
>
> I don't have a good idea how to handle this, but it would be helpful if 
> plugins could get a second chance of a parent proxy fails. The situation now 
> is that you have to call {{TSHttpTxnParentProxySet}} and cross your fingers. 
> It would be a lot better if the state machine backed up to a hook when the 
> parent proxy failed. OS-DNS would be a convenient hook, but it will be hard 
> to restart sanely from there since there is a log if state around the DNS 
> result. Maybe a new hook would make sense since that could also be used with 
> {{TSHttpTxnServerAddrSet}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4757) parent proxy API to go direct

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4757:
--
Fix Version/s: sometime

> parent proxy API to go direct
> -
>
> Key: TS-4757
> URL: https://issues.apache.org/jira/browse/TS-4757
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Parent Proxy, TS API
>Reporter: James Peach
> Fix For: sometime
>
>
> Once you call {{TSHttpTxnParentProxySet}} there is no way to undo that and no 
> way to ask for the transaction to go direct if the parent is unavailable.
> There's 2 possible cases:
> 1. Force a transaction to go direct after {{TSHttpTxnParentProxySet}} was set 
> (ie. undo its effects).
> 2. Allow a parent transaction to go direct if the parent fails (equivalent to 
> the {{go_direct}} configuration setting).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4756) traffic_manager now always dies when traffic_server dies

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4756:
--
Fix Version/s: 7.0.0

> traffic_manager now always dies when traffic_server dies
> 
>
> Key: TS-4756
> URL: https://issues.apache.org/jira/browse/TS-4756
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
> Fix For: 7.0.0
>
>
> As of ~6.0.0'ish, every time traffic_server crashes (restarts), traffic_cop 
> will consistently kill traffic_manager as well. I've tried hard to track this 
> down, but what has happened is that things have gotten progressively worse. 
> Whereas in 6.0.0, this happens fairly infrequently, in 6.1 it happens 
> moderately often, and in 7.0.0 (master) it happens always.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4733) Cache writes fail when client requests IMS and server replies 200

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4733:
--
Fix Version/s: 7.0.0

> Cache writes fail when client requests IMS and server replies 200
> -
>
> Key: TS-4733
> URL: https://issues.apache.org/jira/browse/TS-4733
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4754) Segmentation Fault with tproxy, tr-pass and garbage.

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4754:
--
Assignee: Alan M. Carroll

> Segmentation Fault with tproxy, tr-pass and garbage.
> 
>
> Key: TS-4754
> URL: https://issues.apache.org/jira/browse/TS-4754
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: Tommy Lee
>Assignee: Alan M. Carroll
> Fix For: sometime
>
>
> We have been suffering with a big problem here when client generates garbage 
> and TR-PASS flag is set.
> Trafficserver version is: 6.1.1 with these compile options: 
> --prefix=/usr/local/cache-6.0 --disable-luajit --enable-tproxy --enable-hwloc 
> --enable-debug --enable-static-libts
> If it's necessary I can share my config files.
> We get this segmentation fault:
> traffic_server: Segmentation fault (Address not mapped to object [0x229])
> traffic_server - STACK TRACE: 
> /usr/local/cache-6.0/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x4fbd3d]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ad6ef4a8cb0]
> /usr/local/cache-6.0/bin/traffic_server(_ZN17HttpClientSession19set_half_close_flagEv+0xc)[0x5972b0]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM22set_ua_half_close_flagEv+0x1f)[0x57756d]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0xaa3)[0x578ccb]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x272)[0x57fb8a]
> /usr/local/cache-6.0/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4fed76]
> /usr/local/cache-6.0/bin/traffic_server[0x720ea3]
> /usr/local/cache-6.0/bin/traffic_server[0x721243]
> /usr/local/cache-6.0/bin/traffic_server[0x721a92]
> /usr/local/cache-6.0/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x723d67]
> /usr/local/cache-6.0/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6e0)[0x71905e]
> /usr/local/cache-6.0/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4fed76]
> /usr/local/cache-6.0/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x131)[0x743f51]
> /usr/local/cache-6.0/bin/traffic_server(_ZN7EThread7executeEv+0x49b)[0x744569]
> /usr/local/cache-6.0/bin/traffic_server(main+0x13cb)[0x5317b2]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ad6f02f776d]
> /usr/local/cache-6.0/bin/traffic_server[0x4e4359]
> And GDB output:
> root@web:~# gdb /usr/local/cache-6.0/bin/traffic_server core.28120 
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/local/cache-6.0/bin/traffic_server...done.
> BFD: Warning: /root/core.28120 is truncated: expected core file size >= 
> 44404129792, found: 22498504704.
> warning: core file may not match specified executable file.
> [New LWP 28135]
> [New LWP 28146]
> [New LWP 28259]
> [New LWP 28647]
> [New LWP 28151]
> [New LWP 28289]
> [New LWP 28659]
> [New LWP 28157]
> [New LWP 28680]
> [New LWP 28669]
> [New LWP 28260]
> [New LWP 28174]
> [New LWP 28644]
> [New LWP 28180]
> [New LWP 28167]
> [New LWP 28147]
> [New LWP 28620]
> [New LWP 28204]
> [New LWP 28158]
> [New LWP 28225]
> [New LWP 28655]
> [New LWP 28666]
> [New LWP 28149]
> [New LWP 28515]
> [New LWP 28263]
> [New LWP 28715]
> [New LWP 28804]
> [New LWP 28621]
> [New LWP 28633]
> [New LWP 28205]
> [New LWP 28716]
> [New LWP 28168]
> [New LWP 28121]
> [New LWP 28697]
> [New LWP 28568]
> [New LWP 28692]
> [New LWP 28701]
> [New LWP 28725]
> [New LWP 28641]
> [New LWP 28665]
> [New LWP 28656]
> [New LWP 28341]
> [New LWP 28703]
> [New LWP 28679]
> [New LWP 28677]
> [New LWP 28714]
> [New LWP 28253]
> [New LWP 28614]
> [New LWP 28674]
> [New LWP 28676]
> [New LWP 28181]
> [New LWP 28630]
> [New LWP 28563]
> [New LWP 28696]
> [New LWP 28689]
> [New LWP 28695]
> [New LWP 28634]
> [New LWP 28632]
> [New LWP 28724]
> [New LWP 28640]
> [New LWP 28261]
> [New LWP 28693]
> [New LWP 28541]
> [New LWP 28617]
> [New LWP 28652]
> [New LWP 28608]
> [New LWP 28664]
> [New LWP 28255]
> [New LWP 28672]
> [New LWP 28783]
> [New LWP 28599]
> [New LWP 28325]
> [New LWP 28386]
> [New LWP 28687]
> [New LWP 28756]
> [New LWP 28785]
> [New LWP 28663]
> [New LWP 28682]
> [New LWP 28627]
> [New LWP 28601]
> [New LWP 28628]
> [New LWP 28164]
> [New LWP 28723]
> [New LWP 28684]
> [New LWP 28483]
> [New LWP 28611]
> [New LWP 

[jira] [Updated] (TS-966) cache.config dest_domain= dest_hostname= dest_ip= do not match anything

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-966:
-
Fix Version/s: Docs

> cache.config dest_domain= dest_hostname= dest_ip= do not match anything
> ---
>
> Key: TS-966
> URL: https://issues.apache.org/jira/browse/TS-966
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 3.1.0, 3.0.1
>Reporter: Igor Galić
>Assignee: Jon Sime
>  Labels: A
> Fix For: Docs
>
>
> Caching policies are not applied when using these options to match targets.
> It is also not very clear *what* dest_domain= vs dest_hostname= can match.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4754) Segmentation Fault with tproxy, tr-pass and garbage.

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4754:
--
Fix Version/s: sometime

> Segmentation Fault with tproxy, tr-pass and garbage.
> 
>
> Key: TS-4754
> URL: https://issues.apache.org/jira/browse/TS-4754
> Project: Traffic Server
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: Tommy Lee
> Fix For: sometime
>
>
> We have been suffering with a big problem here when client generates garbage 
> and TR-PASS flag is set.
> Trafficserver version is: 6.1.1 with these compile options: 
> --prefix=/usr/local/cache-6.0 --disable-luajit --enable-tproxy --enable-hwloc 
> --enable-debug --enable-static-libts
> If it's necessary I can share my config files.
> We get this segmentation fault:
> traffic_server: Segmentation fault (Address not mapped to object [0x229])
> traffic_server - STACK TRACE: 
> /usr/local/cache-6.0/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x4fbd3d]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x2ad6ef4a8cb0]
> /usr/local/cache-6.0/bin/traffic_server(_ZN17HttpClientSession19set_half_close_flagEv+0xc)[0x5972b0]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM22set_ua_half_close_flagEv+0x1f)[0x57756d]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0xaa3)[0x578ccb]
> /usr/local/cache-6.0/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x272)[0x57fb8a]
> /usr/local/cache-6.0/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4fed76]
> /usr/local/cache-6.0/bin/traffic_server[0x720ea3]
> /usr/local/cache-6.0/bin/traffic_server[0x721243]
> /usr/local/cache-6.0/bin/traffic_server[0x721a92]
> /usr/local/cache-6.0/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x723d67]
> /usr/local/cache-6.0/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6e0)[0x71905e]
> /usr/local/cache-6.0/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x68)[0x4fed76]
> /usr/local/cache-6.0/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x131)[0x743f51]
> /usr/local/cache-6.0/bin/traffic_server(_ZN7EThread7executeEv+0x49b)[0x744569]
> /usr/local/cache-6.0/bin/traffic_server(main+0x13cb)[0x5317b2]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2ad6f02f776d]
> /usr/local/cache-6.0/bin/traffic_server[0x4e4359]
> And GDB output:
> root@web:~# gdb /usr/local/cache-6.0/bin/traffic_server core.28120 
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /usr/local/cache-6.0/bin/traffic_server...done.
> BFD: Warning: /root/core.28120 is truncated: expected core file size >= 
> 44404129792, found: 22498504704.
> warning: core file may not match specified executable file.
> [New LWP 28135]
> [New LWP 28146]
> [New LWP 28259]
> [New LWP 28647]
> [New LWP 28151]
> [New LWP 28289]
> [New LWP 28659]
> [New LWP 28157]
> [New LWP 28680]
> [New LWP 28669]
> [New LWP 28260]
> [New LWP 28174]
> [New LWP 28644]
> [New LWP 28180]
> [New LWP 28167]
> [New LWP 28147]
> [New LWP 28620]
> [New LWP 28204]
> [New LWP 28158]
> [New LWP 28225]
> [New LWP 28655]
> [New LWP 28666]
> [New LWP 28149]
> [New LWP 28515]
> [New LWP 28263]
> [New LWP 28715]
> [New LWP 28804]
> [New LWP 28621]
> [New LWP 28633]
> [New LWP 28205]
> [New LWP 28716]
> [New LWP 28168]
> [New LWP 28121]
> [New LWP 28697]
> [New LWP 28568]
> [New LWP 28692]
> [New LWP 28701]
> [New LWP 28725]
> [New LWP 28641]
> [New LWP 28665]
> [New LWP 28656]
> [New LWP 28341]
> [New LWP 28703]
> [New LWP 28679]
> [New LWP 28677]
> [New LWP 28714]
> [New LWP 28253]
> [New LWP 28614]
> [New LWP 28674]
> [New LWP 28676]
> [New LWP 28181]
> [New LWP 28630]
> [New LWP 28563]
> [New LWP 28696]
> [New LWP 28689]
> [New LWP 28695]
> [New LWP 28634]
> [New LWP 28632]
> [New LWP 28724]
> [New LWP 28640]
> [New LWP 28261]
> [New LWP 28693]
> [New LWP 28541]
> [New LWP 28617]
> [New LWP 28652]
> [New LWP 28608]
> [New LWP 28664]
> [New LWP 28255]
> [New LWP 28672]
> [New LWP 28783]
> [New LWP 28599]
> [New LWP 28325]
> [New LWP 28386]
> [New LWP 28687]
> [New LWP 28756]
> [New LWP 28785]
> [New LWP 28663]
> [New LWP 28682]
> [New LWP 28627]
> [New LWP 28601]
> [New LWP 28628]
> [New LWP 28164]
> [New LWP 28723]
> [New LWP 28684]
> [New LWP 28483]
> [New LWP 28611]
> [New LWP 28631]
> [New LWP 28560]
> [New LWP 28283]

[jira] [Commented] (TS-4748) Congestion Control (congestion.config*(max_connection))

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425674#comment-15425674
 ] 

Leif Hedstrom commented on TS-4748:
---

[~shinrich] Any comments on this?

> Congestion Control (congestion.config*(max_connection))
> ---
>
> Key: TS-4748
> URL: https://issues.apache.org/jira/browse/TS-4748
> Project: Traffic Server
>  Issue Type: Test
>  Components: Configuration
>Reporter: Chai
> Fix For: sometime
>
>
> Hi,
> I have few questions with the congestion control features inside the apache 
> traffic server.
> Q1: How to calculate the max_connection? If 2 people request a web page at 
> the same time and the max_connection equal to 1, its that means congested for 
> origin server and who will get the error page?
> CASE 2: Maximum Number of Connections
> -
> TS will temporarily mark a server as congested if a "max_connection" number
> to the server is reached. If a new client request comes in and needs a new 
> connection to the server, the client will get 503 Retry-After back. 
> There is no PRAT on the "max_connection" reached servers.
> Q2: According to case 2 inside the congestion control as above, what is the 
> time of "temporarily mark a server as congested"?
> Q3: If a HTML page there are more than one 503 "too many users" return back 
> from traffic server, is the server marks as congested and will show the error 
> page?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4748) Congestion Control (congestion.config*(max_connection))

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4748:
--
Fix Version/s: sometime

> Congestion Control (congestion.config*(max_connection))
> ---
>
> Key: TS-4748
> URL: https://issues.apache.org/jira/browse/TS-4748
> Project: Traffic Server
>  Issue Type: Test
>  Components: Configuration
>Reporter: Chai
> Fix For: sometime
>
>
> Hi,
> I have few questions with the congestion control features inside the apache 
> traffic server.
> Q1: How to calculate the max_connection? If 2 people request a web page at 
> the same time and the max_connection equal to 1, its that means congested for 
> origin server and who will get the error page?
> CASE 2: Maximum Number of Connections
> -
> TS will temporarily mark a server as congested if a "max_connection" number
> to the server is reached. If a new client request comes in and needs a new 
> connection to the server, the client will get 503 Retry-After back. 
> There is no PRAT on the "max_connection" reached servers.
> Q2: According to case 2 inside the congestion control as above, what is the 
> time of "temporarily mark a server as congested"?
> Q3: If a HTML page there are more than one 503 "too many users" return back 
> from traffic server, is the server marks as congested and will show the error 
> page?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4753) collation hosts leak failover groups

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4753:
--
Fix Version/s: sometime

> collation hosts leak failover groups
> 
>
> Key: TS-4753
> URL: https://issues.apache.org/jira/browse/TS-4753
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Logging
>Reporter: James Peach
> Fix For: sometime
>
>
> By code inspection, when you create a failover group of collation hosts in 
> the logging configuration, the failover LogHost objects don't get freed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4745) pRecord.failCount not init in ParentRecord::ProcessParents

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4745:
--
Fix Version/s: 7.0.0

> pRecord.failCount not init in ParentRecord::ProcessParents
> --
>
> Key: TS-4745
> URL: https://issues.apache.org/jira/browse/TS-4745
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> the failCount is not init,is may be an big number ( it already happend in my 
> sisution),after the ats is startup.
> it will cause the parent immediately marked down,once connect the parent 
> failed.  
> fix the code:
> this->parents[i].failCount = 0;//added by xdchen,line:447



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425672#comment-15425672
 ] 

Leif Hedstrom commented on TS-4747:
---

If you have a fix for this, can you please make a Github PR with the changes?

> if the connection of parent is not alive, not make the parent host down,which 
> will select the the unavailable host again
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4749) Generate Warning message when origin_max_connections limit is passed

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4749:
--
Fix Version/s: 7.0.0

> Generate Warning message when origin_max_connections limit is passed
> 
>
> Key: TS-4749
> URL: https://issues.apache.org/jira/browse/TS-4749
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Help ops debug when ATS gets into an overwhelmed state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4745) pRecord.failCount not init in ParentRecord::ProcessParents

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425673#comment-15425673
 ] 

Leif Hedstrom commented on TS-4745:
---

If you have a fix for this, can you please make a Github PR with the changes?

> pRecord.failCount not init in ParentRecord::ProcessParents
> --
>
> Key: TS-4745
> URL: https://issues.apache.org/jira/browse/TS-4745
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> the failCount is not init,is may be an big number ( it already happend in my 
> sisution),after the ats is startup.
> it will cause the parent immediately marked down,once connect the parent 
> failed.  
> fix the code:
> this->parents[i].failCount = 0;//added by xdchen,line:447



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4744:
--
Component/s: Parent Proxy

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425671#comment-15425671
 ] 

Leif Hedstrom commented on TS-4744:
---

If you have a fix for this, can you please make a Github PR with the changes?

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4747:
--
Assignee: John Rushford

> if the connection of parent is not alive, not make the parent host down,which 
> will select the the unavailable host again
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4747) if the connection of parent is not alive, not make the parent host down,which will select the the unavailable host again

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4747:
--
Fix Version/s: 7.0.0

> if the connection of parent is not alive, not make the parent host down,which 
> will select the the unavailable host again
> 
>
> Key: TS-4747
> URL: https://issues.apache.org/jira/browse/TS-4747
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> the parent.config is like this:
> dest_domain=www.cxdtest.com parent=“dnstest1.com:80”;round_bin=strict
> and the dnstest1.com contains two ip:
> 192.168.1.1 （but it was down）
> 192.168.1.2
> if the request go to the parent, and the parent is domain,which contains 
> multi ip. if one ip is down,but we not make the host down ,if the next 
> request is comming, it will choice this ip again. we should make the host 
> down.
> fix code on HttpTransact::handle_response_from_parent(State *s) 
> default: {
> LookingUp_t next_lookup = UNDEFINED_LOOKUP;
> DebugTxn("http_trans", "[hrfp] connection not alive");
> s->state_machine->do_hostdb_update_if_necessary();//added by xdchen, make 
> the host down,line:3606



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4744) ParentConsistentHash::selectParent may select the unavailable parent

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4744:
--
Fix Version/s: 7.0.0

> ParentConsistentHash::selectParent may select the unavailable parent
> 
>
> Key: TS-4744
> URL: https://issues.apache.org/jira/browse/TS-4744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> code :ParentConsistentHash.cc,begin at line 141  
> do { // search until we've selected a different parent.
> prtmp = (pRecord *)fhash->lookup(NULL, 
> >chashIter[last_lookup], _around[last_lookup], );
> if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
> }
>   } while (prtmp && strcmp(prtmp->hostname, result->hostname) == 0);
> fix it like this:
> if (prtmp)
>   pRec = (parents[last_lookup] + prtmp->idx);
> else  //begin of added xdchen, line:143
>   pRec = NULL; //endof of added by xdchen  
>  if (prtmp) {
>   pRec = (parents[last_lookup] + prtmp->idx);
>   Debug("parent_select", "Selected a new parent: %s.", 
> pRec->hostname);
> }
> else  //begin of added xdchen, line:188
>   pRec = NULL; end of added xdchen
>  
>   }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4746) ParentRecord *secondary_parents malloc,but no place free,which will cause memery leak

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4746:
--
Assignee: John Rushford

> ParentRecord *secondary_parents malloc,but no place free,which will cause 
> memery leak
> -
>
> Key: TS-4746
> URL: https://issues.apache.org/jira/browse/TS-4746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
>Assignee: John Rushford
> Fix For: 7.0.0
>
>
> secondary_parents is malloc in  
> ParentRecord::ProcessParents(char *val, bool isPrimary) 
>   this->secondary_parents = (pRecord *)ats_malloc(sizeof(pRecord) * numTok); 
> //line:372 
> but no place to free it,which will cause memery leak.
> fix in 
> ParentRecord::~ParentRecord()
> { 
>   if(parents != NULL) {
> ats_free(parents);
>   }
>   if(primary_parents != NULL){
> ats_free(primary_parents);
>   }
>   if(second_parents != NULL){
> ats_free(second_parents);
>   }
>  ..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4746) ParentRecord *secondary_parents malloc,but no place free,which will cause memery leak

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4746:
--
Fix Version/s: 7.0.0

> ParentRecord *secondary_parents malloc,but no place free,which will cause 
> memery leak
> -
>
> Key: TS-4746
> URL: https://issues.apache.org/jira/browse/TS-4746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
> Fix For: 7.0.0
>
>
> secondary_parents is malloc in  
> ParentRecord::ProcessParents(char *val, bool isPrimary) 
>   this->secondary_parents = (pRecord *)ats_malloc(sizeof(pRecord) * numTok); 
> //line:372 
> but no place to free it,which will cause memery leak.
> fix in 
> ParentRecord::~ParentRecord()
> { 
>   if(parents != NULL) {
> ats_free(parents);
>   }
>   if(primary_parents != NULL){
> ats_free(primary_parents);
>   }
>   if(second_parents != NULL){
> ats_free(second_parents);
>   }
>  ..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4746) ParentRecord *secondary_parents malloc,but no place free,which will cause memery leak

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4746:
--
Component/s: Parent Proxy

> ParentRecord *secondary_parents malloc,but no place free,which will cause 
> memery leak
> -
>
> Key: TS-4746
> URL: https://issues.apache.org/jira/browse/TS-4746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: xiangdong chen
> Fix For: 7.0.0
>
>
> secondary_parents is malloc in  
> ParentRecord::ProcessParents(char *val, bool isPrimary) 
>   this->secondary_parents = (pRecord *)ats_malloc(sizeof(pRecord) * numTok); 
> //line:372 
> but no place to free it,which will cause memery leak.
> fix in 
> ParentRecord::~ParentRecord()
> { 
>   if(parents != NULL) {
> ats_free(parents);
>   }
>   if(primary_parents != NULL){
> ats_free(primary_parents);
>   }
>   if(second_parents != NULL){
> ats_free(second_parents);
>   }
>  ..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4742) FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4742:
--
Fix Version/s: sometime

> FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`
> --
>
> Key: TS-4742
> URL: https://issues.apache.org/jira/browse/TS-4742
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Clustering
>Reporter: Paul Stengel
> Fix For: sometime
>
>
> We're running TS in a two-server cluster right now. The clustering works well 
> and is functioning as you'd expect. However, every so often, TS crashes with 
> the following backtrace:
> {noformat}
> FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`
> traffic_server: using root directory '/usr'
> traffic_server: Aborted (Signal sent by tkill() 13260 114)
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa0)[0x55bbaed08f00]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x2b45c2ff13d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x2b45c3cd7418]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x2b45c3cd901a]
> /usr/lib/trafficserver/libtsutil.so.6(+0x2430f)[0x2b45c1c8f30f]
> /usr/lib/trafficserver/libtsutil.so.6(+0x243a9)[0x2b45c1c8f3a9]
> /usr/lib/trafficserver/libtsutil.so.6(+0x22595)[0x2b45c1c8d595]
> /usr/bin/traffic_server(+0x2ee7e8)[0x55bbaef207e8]
> /usr/bin/traffic_server(_ZN12OneWayTunnel10startEventEiPv+0x16f)[0x55bbaeecd9df]
> /usr/bin/traffic_server(_ZN14ClusterHandler32cluster_signal_and_update_lockedEiP18ClusterVConnectionP17ClusterVConnState+0x2f)[0x55bbaef05abf]
> /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x8fa)[0x55bbaeefff1a]
> /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0x171)[0x55bbaef00091]
> /usr/bin/traffic_server(_ZN14ClusterHandler13process_writeElb+0x578)[0x55bbaef00868]
> /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x195)[0x55bbaef00ae5]
> /usr/bin/traffic_server(_ZN12ClusterState10IOCompleteEv+0xc7)[0x55bbaef04be7]
> /usr/bin/traffic_server(_ZN12ClusterState16doIO_write_eventEiPv+0x119)[0x55bbaef04fd9]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x1191)[0x55bbaefabfd1]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x328)[0x55bbaef98ad8]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x92)[0x55bbaefdd362]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x679)[0x55bbaefde079]
> /usr/bin/traffic_server(+0x3aae49)[0x55bbaefdce49]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x2b45c2fe76fa]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b45c3da8b5d]
> {noformat}
> We've not found a way to reproduce the crash. Here are the diags.log entries 
> that show when the server starts back up (indicating a crash and recovery):
> {noformat}
> [Aug 11 07:23:46.245] Server {0x2afc9cf458c0} NOTE:  
> traffic server running
> [Aug 11 11:14:10.272] Server {0x2ba545a318c0} NOTE:  
> traffic server running
> [Aug 11 12:08:51.188] Server {0x2b887a0228c0} NOTE:  
> traffic server running
> [Aug 11 14:57:23.900] Server {0x2aad8422b8c0} NOTE:  
> traffic server running
> [Aug 11 14:58:17.844] Server {0x2b66aad508c0} NOTE:  
> traffic server running
> [Aug 11 15:08:38.752] Server {0x2b09a50cb8c0} NOTE:  
> traffic server running
> [Aug 11 15:08:51.001] Server {0x2aee8a7c88c0} NOTE:  
> traffic server running
> [Aug 11 15:10:46.796] Server {0x2ace4544e8c0} NOTE:  
> traffic server running
> [Aug 11 15:25:27.599] Server {0x2b90b94788c0} NOTE:  
> traffic server running
> [Aug 11 15:26:13.642] Server {0x2b814d2088c0} NOTE:  
> traffic server running
> [Aug 11 16:03:31.729] Server {0x2b259ff968c0} NOTE:  
> traffic server running
> [Aug 11 16:03:44.057] Server {0x2b1cf99198c0} NOTE:  
> traffic server running
> [Aug 11 16:15:27.307] Server {0x2b2333b1d8c0} NOTE:  
> traffic server running
> [Aug 11 16:39:56.205] Server {0x2b92f018f8c0} NOTE:  
> traffic server running
> [Aug 11 16:40:07.535] Server {0x2aad138ab8c0} NOTE:  
> traffic server running
> [Aug 11 16:40:17.971] Server {0x2b94640748c0} NOTE:  
> traffic server running
> [Aug 11 16:41:07.280] Server {0x2b45c1a798c0} NOTE:  
> traffic server running
> [Aug 11 17:01:28.328] Server {0x2adec40e68c0} NOTE:  
> traffic server running
> [Aug 11 17:06:17.853] Server {0x2aef987758c0} NOTE:  
> traffic server running
> {noformat}
> {noformat}
> root@gateway-us-east-1:/var/log/trafficserver$ traffic_server -V
> traffic_server: using root directory '/usr'
> Apache Traffic Server - traffic_server - 6.2.0 - (build # 080418 on Aug  4 
> 2016 at 18:36:55)
> {noformat}
> {noformat}
> root@gateway-us-east-1:~$ cat /usr/lib/os-release 
> NAME="Ubuntu"
> VERSION="16.04.1 LTS (Xenial Xerus)"
> ID=ubuntu

[jira] [Updated] (TS-4742) FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4742:
--
Component/s: Clustering

> FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`
> --
>
> Key: TS-4742
> URL: https://issues.apache.org/jira/browse/TS-4742
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Clustering
>Reporter: Paul Stengel
> Fix For: sometime
>
>
> We're running TS in a two-server cluster right now. The clustering works well 
> and is functioning as you'd expect. However, every so often, TS crashes with 
> the following backtrace:
> {noformat}
> FATAL: ClusterCache.cc:1759: failed assert `tc->tunnel_cont == tc`
> traffic_server: using root directory '/usr'
> traffic_server: Aborted (Signal sent by tkill() 13260 114)
> traffic_server - STACK TRACE: 
> /usr/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0xa0)[0x55bbaed08f00]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x113d0)[0x2b45c2ff13d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x2b45c3cd7418]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x2b45c3cd901a]
> /usr/lib/trafficserver/libtsutil.so.6(+0x2430f)[0x2b45c1c8f30f]
> /usr/lib/trafficserver/libtsutil.so.6(+0x243a9)[0x2b45c1c8f3a9]
> /usr/lib/trafficserver/libtsutil.so.6(+0x22595)[0x2b45c1c8d595]
> /usr/bin/traffic_server(+0x2ee7e8)[0x55bbaef207e8]
> /usr/bin/traffic_server(_ZN12OneWayTunnel10startEventEiPv+0x16f)[0x55bbaeecd9df]
> /usr/bin/traffic_server(_ZN14ClusterHandler32cluster_signal_and_update_lockedEiP18ClusterVConnectionP17ClusterVConnState+0x2f)[0x55bbaef05abf]
> /usr/bin/traffic_server(_ZN14ClusterHandler20valid_for_data_writeEP18ClusterVConnection+0x8fa)[0x55bbaeefff1a]
> /usr/bin/traffic_server(_ZN14ClusterHandler23build_write_descriptorsEv+0x171)[0x55bbaef00091]
> /usr/bin/traffic_server(_ZN14ClusterHandler13process_writeElb+0x578)[0x55bbaef00868]
> /usr/bin/traffic_server(_ZN14ClusterHandler16mainClusterEventEiP5Event+0x195)[0x55bbaef00ae5]
> /usr/bin/traffic_server(_ZN12ClusterState10IOCompleteEv+0xc7)[0x55bbaef04be7]
> /usr/bin/traffic_server(_ZN12ClusterState16doIO_write_eventEiPv+0x119)[0x55bbaef04fd9]
> /usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x1191)[0x55bbaefabfd1]
> /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x328)[0x55bbaef98ad8]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x92)[0x55bbaefdd362]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x679)[0x55bbaefde079]
> /usr/bin/traffic_server(+0x3aae49)[0x55bbaefdce49]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x76fa)[0x2b45c2fe76fa]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b45c3da8b5d]
> {noformat}
> We've not found a way to reproduce the crash. Here are the diags.log entries 
> that show when the server starts back up (indicating a crash and recovery):
> {noformat}
> [Aug 11 07:23:46.245] Server {0x2afc9cf458c0} NOTE:  
> traffic server running
> [Aug 11 11:14:10.272] Server {0x2ba545a318c0} NOTE:  
> traffic server running
> [Aug 11 12:08:51.188] Server {0x2b887a0228c0} NOTE:  
> traffic server running
> [Aug 11 14:57:23.900] Server {0x2aad8422b8c0} NOTE:  
> traffic server running
> [Aug 11 14:58:17.844] Server {0x2b66aad508c0} NOTE:  
> traffic server running
> [Aug 11 15:08:38.752] Server {0x2b09a50cb8c0} NOTE:  
> traffic server running
> [Aug 11 15:08:51.001] Server {0x2aee8a7c88c0} NOTE:  
> traffic server running
> [Aug 11 15:10:46.796] Server {0x2ace4544e8c0} NOTE:  
> traffic server running
> [Aug 11 15:25:27.599] Server {0x2b90b94788c0} NOTE:  
> traffic server running
> [Aug 11 15:26:13.642] Server {0x2b814d2088c0} NOTE:  
> traffic server running
> [Aug 11 16:03:31.729] Server {0x2b259ff968c0} NOTE:  
> traffic server running
> [Aug 11 16:03:44.057] Server {0x2b1cf99198c0} NOTE:  
> traffic server running
> [Aug 11 16:15:27.307] Server {0x2b2333b1d8c0} NOTE:  
> traffic server running
> [Aug 11 16:39:56.205] Server {0x2b92f018f8c0} NOTE:  
> traffic server running
> [Aug 11 16:40:07.535] Server {0x2aad138ab8c0} NOTE:  
> traffic server running
> [Aug 11 16:40:17.971] Server {0x2b94640748c0} NOTE:  
> traffic server running
> [Aug 11 16:41:07.280] Server {0x2b45c1a798c0} NOTE:  
> traffic server running
> [Aug 11 17:01:28.328] Server {0x2adec40e68c0} NOTE:  
> traffic server running
> [Aug 11 17:06:17.853] Server {0x2aef987758c0} NOTE:  
> traffic server running
> {noformat}
> {noformat}
> root@gateway-us-east-1:/var/log/trafficserver$ traffic_server -V
> traffic_server: using root directory '/usr'
> Apache Traffic Server - traffic_server - 6.2.0 - (build # 080418 on Aug  4 
> 2016 at 18:36:55)
> {noformat}
> {noformat}
> root@gateway-us-east-1:~$ cat /usr/lib/os-release 
> NAME="Ubuntu"
> VERSION="16.04.1 LTS (Xenial Xerus)"
> ID=ubuntu

[jira] [Commented] (TS-4735) Possible deadlock on traffic_server startup

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425667#comment-15425667
 ] 

Leif Hedstrom commented on TS-4735:
---

Are you by chance going to work on a fix for this? If so, let me know and I can 
add you as a contributor so we can assign it to you.

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4735) Possible deadlock on traffic_server startup

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom updated TS-4735:
--
Fix Version/s: 7.0.0

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
> Fix For: 7.0.0
>
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-3726) Expose build_error_response in order to making a formated error response in plugin

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-3726?focusedWorklogId=26559=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26559
 ]

ASF GitHub Bot logged work on TS-3726:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:40
Start Date: 18/Aug/16 00:40
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/772
  
@oknet  For now, I think we should close this PR, wait for @alhonen to 
clean up the underlying plumbing, and then revisit this? If you agree, please 
close this PR for, but obviously keep your changes for future.


Issue Time Tracking
---

Worklog Id: (was: 26559)
Time Spent: 10m
Remaining Estimate: 0h

> Expose build_error_response in order to making a formated error response in 
> plugin
> --
>
> Key: TS-3726
> URL: https://issues.apache.org/jira/browse/TS-3726
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: TS API
>Reporter: Oknet Xu
>Assignee: Oknet Xu
>  Labels: API, review
> Fix For: 7.1.0
>
> Attachments: TSHttpTxnErrorpageSet.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> expose build_error_response in order to making a formated error response in 
> plugin.
> ATS support multi-language error response page by body_factory.
> In the ATS internal, build_error_response used to generating it.
> I wrote a patch to expose build_error_response function for plugin.
> and modified example/basic_auth for a sample usage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #772: TS-3726: Expose build_error_response

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/772
  
@oknet  For now, I think we should close this PR, wait for @alhonen to 
clean up the underlying plumbing, and then revisit this? If you agree, please 
close this PR for, but obviously keep your changes for future.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #644: [TS 4437] Add new limit rate example plugin

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/644
  
I'm not sure if anyone has had the cycles to help debug this :-/ It might 
be worth emailing dev@ with a concrete question / request for help.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4522) did not check EPIPE on write_to_net_io

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4522?focusedWorklogId=26558=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26558
 ]

ASF GitHub Bot logged work on TS-4522:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:32
Start Date: 18/Aug/16 00:32
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/701
  
@oknet  ping ?


Issue Time Tracking
---

Worklog Id: (was: 26558)
Time Spent: 20m  (was: 10m)

> did not check EPIPE on write_to_net_io
> --
>
> Key: TS-4522
> URL: https://issues.apache.org/jira/browse/TS-4522
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
>Assignee: Oknet Xu
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On a closed socket fd:
> read(socketfd) return 0
> write(socketfd) return EPIPE
> In the write_to_net_io, we check the return value of write() with the same 
> way to read().
> {code}
> if (!r || r == -ECONNRESET) {
> {code}
> The bug makes no VC_EVENT_EOS callbacked while write_to_net_io, but 
> VC_EVENT_ERROR instead. 
> full code here:
> {code}
>   int64_t r = vc->load_buffer_and_write(towrite, buf, total_written, needs);
>   if (total_written > 0) {
> NET_SUM_DYN_STAT(net_write_bytes_stat, total_written);
> s->vio.ndone += total_written;
>   }
>   // check for errors
>   if (r <= 0) { // if the socket was not ready,add to WaitList
> if (r == -EAGAIN || r == -ENOTCONN) {
>   NET_INCREMENT_DYN_STAT(net_calls_to_write_nodata_stat);
>   if ((needs & EVENTIO_WRITE) == EVENTIO_WRITE) {
> vc->write.triggered = 0;
> nh->write_ready_list.remove(vc);
> write_reschedule(nh, vc);
>   }
>   if ((needs & EVENTIO_READ) == EVENTIO_READ) {
> vc->read.triggered = 0;
> nh->read_ready_list.remove(vc);
> read_reschedule(nh, vc);
>   }
>   return;
> }
> if (!r || r == -ECONNRESET) {
>   vc->write.triggered = 0;
>   write_signal_done(VC_EVENT_EOS, nh, vc);
>   return;
> }
> vc->write.triggered = 0;
> write_signal_error(nh, vc, (int)-total_written);
> return;
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4072) Diagnostic log rolling races

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4072?focusedWorklogId=26557=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26557
 ]

ASF GitHub Bot logged work on TS-4072:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:31
Start Date: 18/Aug/16 00:31
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/568
  
Time to land this?


Issue Time Tracking
---

Worklog Id: (was: 26557)
Time Spent: 1h  (was: 50m)

> Diagnostic log rolling races
> 
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: James Peach
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced 
> with a new log object. Since the global {{diags}} points to a a single 
> {{Diags}} object there is nothing to prevent a different thread logging 
> through this object at the time it is deleted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #701: TS-4522: check EPIPE instead r==0

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/701
  
@oknet  ping ?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #568: TS-4072 Diagnostic log rolling races

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/568
  
Time to land this?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #769: TS 4593: Extend ip_allow.config to filter destinat...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/769
  
@SolidWallOfCode Are we ready to land this?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4612) Proposal: InactivityCop Optimize

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4612?focusedWorklogId=26556=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26556
 ]

ASF GitHub Bot logged work on TS-4612:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:28
Start Date: 18/Aug/16 00:28
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
Where are we with this? Ready to land?


Issue Time Tracking
---

Worklog Id: (was: 26556)
Time Spent: 3.5h  (was: 3h 20m)

> Proposal: InactivityCop Optimize
> 
>
> Key: TS-4612
> URL: https://issues.apache.org/jira/browse/TS-4612
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Oknet Xu
> Fix For: sometime
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> By review the processing of InactivityCop::check_inactivity():
> 1. get all local vc from open_list
> 2. put them into cop_list
> 3. check every vc in cop_list if it is already timeouted
> 4. callback vc->handleEvent to close vc if it is timeout
> InactivityCop and NetHandler share one mutex.
> InactivityCop runs every second, NetHandler runs every 10ms, that means 
> Nethandler runs 100 times until next InactivityCop runs.
> if one vc has read/write in a Nethandler call, it is won't be timeout in the 
> next InactivityCop run.
> Thus, if the vc has read/write in Nethandler, we move it out of cop-list then 
> the InactivityCop runs would get better performace.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #771: TS-4612: Proposal: InactivityCop Optimize

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/771
  
Where are we with this? Ready to land?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4750) Erroneous WARNING: Connection leak from http keep-alive system

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4750?focusedWorklogId=26555=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26555
 ]

ASF GitHub Bot logged work on TS-4750:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:25
Start Date: 18/Aug/16 00:25
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@shinrich Lets do it! :)


Issue Time Tracking
---

Worklog Id: (was: 26555)
Time Spent: 1.5h  (was: 1h 20m)

> Erroneous WARNING: Connection leak from http keep-alive system
> --
>
> Key: TS-4750
> URL: https://issues.apache.org/jira/browse/TS-4750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> We saw this a while back, but didn't get the fix pushed to open source.  It 
> looks like the issue is still present in the current master.
> HttpSessionManager caches the server address, but that cached address drifts 
> from the get_remote_addr() in the vc associated with the cached server 
> session.  The problem is that one value is used to put the session into the 
> hash table, but the other value is used to remove the session from the hash 
> table later.  So the session gets lost in the hash table.  The session is not 
> found and the connection leak warning message is generated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #869: TS-4716: Install manpages in $PREFIX/share/man.

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
I'm +1 on this, would be curious if the original Jira poster can / have 
verify ?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #863: TS-4750: Fix Connection Leak warnings.

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/863
  
@shinrich Lets do it! :)


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4716) 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of /usr/share/man/man3

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4716?focusedWorklogId=26554=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26554
 ]

ASF GitHub Bot logged work on TS-4716:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:24
Start Date: 18/Aug/16 00:24
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/869
  
I'm +1 on this, would be curious if the original Jira poster can / have 
verify ?


Issue Time Tracking
---

Worklog Id: (was: 26554)
Time Spent: 1h 50m  (was: 1h 40m)

> 6.2.0: build is putting files into wrong directory? /usr/man/man3 instead of 
> /usr/share/man/man3
> 
>
> Key: TS-4716
> URL: https://issues.apache.org/jira/browse/TS-4716
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Build
>Reporter: Kyle O'Malley
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> PROBLEM:
> Unable to build rpm with 6.2.0 release due to files being dropped in wrong 
> location? 
> RPM build errors:
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/man/man3/*
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm.in
> File not found: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS.pm
> File not found by glob: 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/share/perl5/Apache/TS/*
> Bad exit status from /var/tmp/rpm-tmp.tPLFGl (%doc)
> These files are not ending up in /usr/share/man/man3, but rather 
> /usr/man/man3/
> Doesn't matter what I manually configure prefix or change build config to
> 
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --enable-layout=Debian 
> --libdir=/usr/lib64/trafficserver 
> --libexecdir=/usr/lib64/trafficserver/plugins --sysconfdir=/etc/trafficserver 
> --with-tcl=/usr/lib64 --disable-luajit --with-user=ats --with-group=ats 
> --enable-linux-native-aio --enable-experimental-plugins --disable-silent-rules
> h.rei...@thelounge.net mentioned this on 2016-27-07 on the user group, so 
> this could be a duplicate bug report
> == build system
> oel6.5 / linux 
> make-3.81-23.el6.x86_64
> ==
> something strange here (maybe) with INSTALL_DIRS missing?
> make -f Makefile-pl INSTALLDIRS= PREFIX=/usr 
> DESTDIR=/vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64 install
> make[4]: Entering directory 
> `/vagrant/rpmbuild/BUILD/trafficserver-6.2.0/lib/perl'
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS.pm.in
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/AdminClient.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/lib/perl5/Apache/TS/Config/Records.pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::AdminClient.3pm
> Installing 
> /vagrant/rpmbuild/BUILDROOT/trafficserver-6.2.0-1.x86_64/usr/man/man3/Apache::TS::Config::Records.3pm
> INSTALLDIRS not defined, defaulting to INSTALLDIRS=site



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-2237) URL encoding wrong in squid.blog

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2237?focusedWorklogId=26553=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26553
 ]

ASF GitHub Bot logged work on TS-2237:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:24
Start Date: 18/Aug/16 00:24
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
@maskit Are you saying the patch as is is not good / sufficient?


Issue Time Tracking
---

Worklog Id: (was: 26553)
Time Spent: 2h 40m  (was: 2.5h)

> URL encoding wrong in squid.blog
> 
>
> Key: TS-2237
> URL: https://issues.apache.org/jira/browse/TS-2237
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Reporter: David Carlin
>Assignee: Sudheer Vinukonda
>Priority: Minor
>  Labels: yahoo
> Fix For: 7.0.0
>
> Attachments: TS-2237.diff
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> I was replaying URLs captured from squid.blog and I noticed I was getting 
> 404's for some of them when squid.blog showed a 200 for that request.  Turns 
> out there is an issue with URL encoding.  For example:
> Requesting file 'duck%20sports%20authority.gif' via curl will put this in the 
> logs:
> duck%2520sports%2520authority.gif
> The % from %20 (space) in the request is being converted to %25 resulting in 
> %2520
> I tested both the % and % log fields - same thing happens.  I 
> tested on ATS 3.2.0 and 3.3.5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #866: TS-2237: Fix double encoding of URLs in squid logs...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/866
  
@maskit Are you saying the patch as is is not good / sufficient?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-2987) TS API to identify if the client connection is via HTTP/2

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2987?focusedWorklogId=26552=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26552
 ]

ASF GitHub Bot logged work on TS-2987:
--

Author: ASF GitHub Bot
Created on: 18/Aug/16 00:21
Start Date: 18/Aug/16 00:21
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/865
  
clang-format. Also, was this proposed on dev@ as well? I might have missed 
it though.


Issue Time Tracking
---

Worklog Id: (was: 26552)
Time Spent: 40m  (was: 0.5h)

> TS API to identify if the client connection is via HTTP/2
> -
>
> Key: TS-2987
> URL: https://issues.apache.org/jira/browse/TS-2987
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2, TS API
>Reporter: Sudheer Vinukonda
>Assignee: Alan M. Carroll
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Need a TS API for the plugins to be able to identify whether the incoming 
> client connection is via SPDY. The plugins would like to relay this 
> information over to the origins which may return a different kind of response 
> for a spdy client vs a non-spdy client. For example, the origins may skip the 
> optimizations such as domain-sharding which work well with non-spdy clients, 
> but, would cancel the benefits of spdy to multiplex requests. 
> The proposed API (the sole credit goes to [~amc]) checks the plugin_tag to 
> identify if the connection is spdy. In the future, the HttpSM data structure 
> may be enhanced to store a spdy indicator.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #865: TS-2987: Add new TS API TSHttpTxnPluginTagGet

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/865
  
clang-format. Also, was this proposed on dev@ as well? I might have missed 
it though.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4695) Remove the --enable-cppapi option

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4695?focusedWorklogId=26551=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26551
 ]

ASF GitHub Bot logged work on TS-4695:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 22:53
Start Date: 17/Aug/16 22:53
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/444/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26551)
Time Spent: 2h 10m  (was: 2h)

> Remove the --enable-cppapi option
> -
>
> Key: TS-4695
> URL: https://issues.apache.org/jira/browse/TS-4695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> With 7.0.0 and forward, we require C++11 support, so we should just remove 
> this option and always compile it.
> Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #860: TS-4695 Removes the --enable-cppapi build option

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/444/ for details.
 



---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately

[Masakazu Kitajo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Masakazu Kitajo reassigned TS-4350:
---

Assignee: Masakazu Kitajo

> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup
>Reporter: Masakazu Kitajo
>Assignee: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some 
> member function doesn't have {{const}} unreasonably. It leads 
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4350) Member functions in HTTPHdr should have const modifiers appropriately

[Masakazu Kitajo (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425544#comment-15425544
 ] 

Masakazu Kitajo commented on TS-4350:
-

I don't have the fix yet but I'll try.

> Member functions in HTTPHdr should have const modifiers appropriately
> -
>
> Key: TS-4350
> URL: https://issues.apache.org/jira/browse/TS-4350
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cleanup
>Reporter: Masakazu Kitajo
> Fix For: 7.0.0
>
>
> Practically, we can't use HTTPHdr and MIMEHdr with {{const}}, because some 
> member function doesn't have {{const}} unreasonably. It leads 
> misunderstanding of API and inappropriate modification.
> We should add {{const}} to the functions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4695) Remove the --enable-cppapi option

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4695?focusedWorklogId=26550=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26550
 ]

ASF GitHub Bot logged work on TS-4695:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 22:48
Start Date: 17/Aug/16 22:48
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/548/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 26550)
Time Spent: 2h  (was: 1h 50m)

> Remove the --enable-cppapi option
> -
>
> Key: TS-4695
> URL: https://issues.apache.org/jira/browse/TS-4695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> With 7.0.0 and forward, we require C++11 support, so we should just remove 
> this option and always compile it.
> Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #860: TS-4695 Removes the --enable-cppapi build option

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/548/ for details.
 



---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4695) Remove the --enable-cppapi option

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4695?focusedWorklogId=26549=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26549
 ]

ASF GitHub Bot logged work on TS-4695:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 22:38
Start Date: 17/Aug/16 22:38
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
Rebooted the FreeBSD VM's again, [approve ci].


Issue Time Tracking
---

Worklog Id: (was: 26549)
Time Spent: 1h 50m  (was: 1h 40m)

> Remove the --enable-cppapi option
> -
>
> Key: TS-4695
> URL: https://issues.apache.org/jira/browse/TS-4695
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Build
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> With 7.0.0 and forward, we require C++11 support, so we should just remove 
> this option and always compile it.
> Unless anyone objects?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #855: fix the memory leaks

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/855
  
Ah, so you have to create a Jira ticket (for now at least) in conjunction 
with the Github PR. Go to 
https://issues.apache.org/jira/browse/TS/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
  and create an account (unless you already did), create a new Issue for the 
Traffic Server project, and it will give you a TS- number. That's the 
Jira issue number, and you should refer to it in all commits etc. for this 
particular issue.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #860: TS-4695 Removes the --enable-cppapi build option

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/860
  
Rebooted the FreeBSD VM's again, [approve ci].


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4762) Improve the Lua package import paths.

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425524#comment-15425524
 ] 

James Peach commented on TS-4762:
-

[~zwoop] [~kichan] [~jesus] any ideas?

> Improve the Lua package import paths.
> -
>
> Key: TS-4762
> URL: https://issues.apache.org/jira/browse/TS-4762
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua
>Reporter: James Peach
>
> I noticed that when you build ATS with a non-default prefix, you end up with 
> unexpected Lua package paths.
> For example, this is what I had for {{package.path}}:
> {noformat}
> ./?.lua;/n/trafficserver/share/luajit-2.0.4/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/n/trafficserver/share/lua/5.1/?.lua;/n/trafficserver/share/lua/5.1/?/init.lua
> {noformat}
> Maybe we can think of a way to automatically get the right paths for the 
> platform.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4762) Improve the Lua package import paths.

[James Peach (JIRA)]

James Peach created TS-4762:
---

 Summary: Improve the Lua package import paths.
 Key: TS-4762
 URL: https://issues.apache.org/jira/browse/TS-4762
 Project: Traffic Server
  Issue Type: Improvement
  Components: Lua
Reporter: James Peach


I noticed that when you build ATS with a non-default prefix, you end up with 
unexpected Lua package paths.

For example, this is what I had for {{package.path}}:
{noformat}
./?.lua;/n/trafficserver/share/luajit-2.0.4/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/n/trafficserver/share/lua/5.1/?.lua;/n/trafficserver/share/lua/5.1/?/init.lua
{noformat}

Maybe we can think of a way to automatically get the right paths for the 
platform.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4761) Let the Lua format() function accept a single string

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425519#comment-15425519
 ] 

James Peach commented on TS-4761:
-

/cc [~zwoop] [~kichan]

> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4761) Let the Lua format() function accept a single string

[James Peach (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-4761:

Description: 
In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
can be a string or a LogFormat object returned from the {{format()}} function. 
It would be convenient to let {{format()}} take a string rather than a table to 
simplify the common case of non-interval formats.

This:
{noformat}
foo = format("my string")
{noformat}

rather than this:
{noformat}
foo = format{ Format = "my string" }
{noformat}

  was:
In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
can be a string or a LogFormat object returned from the {{format()}} function. 
It would be convenient to let {{format()}} take a string rather than a table to 
simplify the common case of non-interval formats.

Rather than thi


> Let the Lua format() function accept a single string
> 
>
> Key: TS-4761
> URL: https://issues.apache.org/jira/browse/TS-4761
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging, Lua
>Reporter: James Peach
>
> In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
> can be a string or a LogFormat object returned from the {{format()}} 
> function. It would be convenient to let {{format()}} take a string rather 
> than a table to simplify the common case of non-interval formats.
> This:
> {noformat}
> foo = format("my string")
> {noformat}
> rather than this:
> {noformat}
> foo = format{ Format = "my string" }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-4761) Let the Lua format() function accept a single string

[James Peach (JIRA)]

James Peach created TS-4761:
---

 Summary: Let the Lua format() function accept a single string
 Key: TS-4761
 URL: https://issues.apache.org/jira/browse/TS-4761
 Project: Traffic Server
  Issue Type: Improvement
  Components: Logging, Lua
Reporter: James Peach


In {{logging.config}}, the {{format}} option to the {{log.binary}} functions 
can be a string or a LogFormat object returned from the {{format()}} function. 
It would be convenient to let {{format()}} take a string rather than a table to 
simplify the common case of non-interval formats.

Rather than thi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work logged] (TS-4729) clang-analyzer: Dead assignment in Http2Stream

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4729?focusedWorklogId=26548=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26548
 ]

ASF GitHub Bot logged work on TS-4729:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 22:17
Start Date: 17/Aug/16 22:17
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/849
  
The return value for {{response_initialize_data_handling}} should be 
changed.  It is a bad design to return a bool (normally that would be mean 
success or failure) from this method and have it mean that the chunking has 
been completed.

It would better to call mark_body_done() in the method or pass in an 
argument in the method call.


Issue Time Tracking
---

Worklog Id: (was: 26548)
Time Spent: 2h 40m  (was: 2.5h)

> clang-analyzer: Dead assignment in Http2Stream
> --
>
> Key: TS-4729
> URL: https://issues.apache.org/jira/browse/TS-4729
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> {noformat}
> Bug Summary
> File: Http2Stream.cc
> Location: line 508, column 9
> Description:  Value stored to 'is_done' is never read
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #849: TS-4729: Fix dead assignment.

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/849
  
The return value for {{response_initialize_data_handling}} should be 
changed.  It is a bad design to return a bool (normally that would be mean 
success or failure) from this method and have it mean that the chunking has 
been completed.

It would better to call mark_body_done() in the method or pass in an 
argument in the method call.


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: clang-analyzer #2544

[jenkins]

See 

Changes:

[James Peach] TS-4751: Prune cached headers before merging the updated response.

[James Peach] doc: Remove stale Traffic Line references.

--
[...truncated 4970 lines...]
reading sources... [ 55%] 
developer-guide/api/functions/TSMimeHdrFieldValueStringSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintInsert.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValueUintSet.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesClear.en
reading sources... [ 56%] 
developer-guide/api/functions/TSMimeHdrFieldValuesCount.en
reading sources... [ 56%] developer-guide/api/functions/TSMimeHdrFieldsClear.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrFieldsCount.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrLengthGet.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrParse.en
reading sources... [ 57%] developer-guide/api/functions/TSMimeHdrPrint.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserClear.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMimeParserDestroy.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexCreate.en
reading sources... [ 58%] developer-guide/api/functions/TSMutexDestroy.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLock.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexLockTry.en
reading sources... [ 59%] developer-guide/api/functions/TSMutexUnlock.en
reading sources... [ 59%] developer-guide/api/functions/TSNetAccept.en
reading sources... [ 60%] 
developer-guide/api/functions/TSNetAcceptNamedProtocol.en
reading sources... [ 60%] developer-guide/api/functions/TSNetConnect.en
reading sources... [ 60%] developer-guide/api/functions/TSPluginInit.en
reading sources... [ 60%] developer-guide/api/functions/TSRemap.en
reading sources... [ 60%] developer-guide/api/functions/TSSslContextFindBy.en
reading sources... [ 61%] 
developer-guide/api/functions/TSSslServerContextCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSTextLogObjectCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadCreate.en
reading sources... [ 61%] developer-guide/api/functions/TSThreadDestroy.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadInit.en
reading sources... [ 62%] developer-guide/api/functions/TSThreadSelf.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTrafficServerVersionGet.en
reading sources... [ 62%] developer-guide/api/functions/TSTransformCreate.en
reading sources... [ 62%] 
developer-guide/api/functions/TSTransformOutputVConnGet.en
reading sources... [ 63%] developer-guide/api/functions/TSTypes.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlCreate.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlDestroy.en
reading sources... [ 63%] developer-guide/api/functions/TSUrlFtpTypeGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlFtpTypeSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostGet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlHostSet.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlPercentEncode.en
reading sources... [ 64%] developer-guide/api/functions/TSUrlStringGet.en
reading sources... [ 65%] developer-guide/api/functions/TSUuidCreate.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnAbort.en
reading sources... [ 65%] 
developer-guide/api/functions/TSVConnCacheObjectSizeGet.en
reading sources... [ 65%] developer-guide/api/functions/TSVConnClose.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnClosedGet.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnFdCreate.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnIsSsl.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnRead.en
reading sources... [ 66%] developer-guide/api/functions/TSVConnReadVIOGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnReenable.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnShutdown.en
reading sources... [ 67%] 
developer-guide/api/functions/TSVConnSslConnectionGet.en
reading sources... [ 67%] developer-guide/api/functions/TSVConnTunnel.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWrite.en
reading sources... [ 68%] developer-guide/api/functions/TSVConnWriteVIOGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOBufferGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOContGet.en
reading sources... [ 68%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] 

Build failed in Jenkins: ubuntu_12_04-master » gcc,ubuntu_12_04,debug #2114

[jenkins]

See 


--
[...truncated 455 lines...]
checking sys/sysmacros.h presence... yes
checking for sys/sysmacros.h... yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking for stdint.h... (cached) yes
checking stdbool.h usability... yes
checking stdbool.h presence... yes
checking for stdbool.h... yes
checking sysexits.h usability... yes
checking sysexits.h presence... yes
checking for sysexits.h... yes
checking net/ppp_defs.h usability... yes
checking net/ppp_defs.h presence... yes
checking for net/ppp_defs.h... yes
checking ifaddrs.h usability... yes
checking ifaddrs.h presence... yes
checking for ifaddrs.h... yes
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking editline/readline.h usability... no
checking editline/readline.h presence... no
checking for editline/readline.h... no
checking ucred.h usability... no
checking ucred.h presence... no
checking for ucred.h... no
checking sys/statfs.h usability... yes
checking sys/statfs.h presence... yes
checking for sys/statfs.h... yes
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking sys/disk.h usability... no
checking sys/disk.h presence... no
checking for sys/disk.h... no
checking sys/disklabel.h usability... no
checking sys/disklabel.h presence... no
checking for sys/disklabel.h... no
checking linux/hdreg.h usability... yes
checking linux/hdreg.h presence... yes
checking for linux/hdreg.h... yes
checking linux/fs.h usability... yes
checking linux/fs.h presence... yes
checking for linux/fs.h... yes
checking linux/major.h usability... yes
checking linux/major.h presence... yes
checking for linux/major.h... yes
checking for sys/sysctl.h... yes
checking for sys/cpuset.h... no
checking for sys/mount.h... yes
checking for arpa/inet.h... yes
checking for netinet/ip.h... yes
checking for netinet/ip_icmp.h... yes
checking for 1-parameter version of pthread_setname_np()... no
checking for 2-parameter version of pthread_setname_np()... yes
checking for 2-parameter version of pthread_set_name_np()... no
checking for struct sockaddr.sa_len... no
checking for struct sockaddr_in.sin_len... no
checking for struct sockaddr_in6.sin6_len... no
checking for sys/capability.h... yes
checking for struct stat.st_mtimespec.tv_nsec... no
checking for struct stat.st_mtim.tv_nsec... yes
checking whether to enable transparent proxy... checking for TPROXY sockopt 
IP_TRANSPARENT... set to 19
checking for SO_PEERCRED socket option... yes
checking for SO_MARK socket option... yes
checking for IP_TOS socket option... yes
checking for loopback network interface... lo
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... char
checking IN6_IS_ADDR_UNSPECIFIED macro works... yes
checking for struct tcp_info... yes
checking search.h usability... yes
checking search.h presence... yes
checking for search.h... yes
checking for struct hsearch_data... yes
checking for hcreate_r... yes
checking for hsearch_r... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating cmd/Makefile
config.status: creating cmd/traffic_cop/Makefile
config.status: creating cmd/traffic_crashlog/Makefile
config.status: creating cmd/traffic_ctl/Makefile
config.status: creating cmd/traffic_layout/Makefile
config.status: creating cmd/traffic_manager/Makefile
config.status: creating cmd/traffic_top/Makefile
config.status: creating cmd/traffic_via/Makefile
config.status: creating cmd/traffic_wccp/Makefile
config.status: creating doc/Makefile
config.status: creating example/Makefile
config.status: creating iocore/Makefile
config.status: creating iocore/aio/Makefile
config.status: creating iocore/cache/Makefile
config.status: creating iocore/cluster/Makefile
config.status: creating iocore/dns/Makefile
config.status: creating iocore/eventsystem/Makefile
config.status: creating iocore/hostdb/Makefile
config.status: creating iocore/net/Makefile
config.status: creating iocore/utils/Makefile
config.status: creating lib/Makefile
config.status: creating lib/atscppapi/Makefile
config.status: creating lib/atscppapi/examples/Makefile
config.status: creating lib/atscppapi/src/Makefile
config.status: creating lib/atscppapi/src/include/atscppapi/shared_ptr.h
config.status: creating lib/bindings/Makefile
config.status: creating lib/perl/Makefile
config.status: creating lib/perl/lib/Apache/TS.pm
config.status: creating lib/records/Makefile
config.status: creating lib/ts/Makefile
config.status: creating lib/ts/apidefs.h
config.status: creating lib/ts/ink_config.h
config.status: creating lib/tsconfig/Makefile
config.status: creating 

Build failed in Jenkins: ubuntu_12_04-master » gcc,ubuntu_12_04,release #2114

[jenkins]

See 


--
[...truncated 454 lines...]
checking sys/sysmacros.h presence... yes
checking for sys/sysmacros.h... yes
checking math.h usability... yes
checking math.h presence... yes
checking for math.h... yes
checking for stdint.h... (cached) yes
checking stdbool.h usability... yes
checking stdbool.h presence... yes
checking for stdbool.h... yes
checking sysexits.h usability... yes
checking sysexits.h presence... yes
checking for sysexits.h... yes
checking net/ppp_defs.h usability... yes
checking net/ppp_defs.h presence... yes
checking for net/ppp_defs.h... yes
checking ifaddrs.h usability... yes
checking ifaddrs.h presence... yes
checking for ifaddrs.h... yes
checking readline/readline.h usability... no
checking readline/readline.h presence... no
checking for readline/readline.h... no
checking editline/readline.h usability... no
checking editline/readline.h presence... no
checking for editline/readline.h... no
checking ucred.h usability... no
checking ucred.h presence... no
checking for ucred.h... no
checking sys/statfs.h usability... yes
checking sys/statfs.h presence... yes
checking for sys/statfs.h... yes
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking sys/disk.h usability... no
checking sys/disk.h presence... no
checking for sys/disk.h... no
checking sys/disklabel.h usability... no
checking sys/disklabel.h presence... no
checking for sys/disklabel.h... no
checking linux/hdreg.h usability... yes
checking linux/hdreg.h presence... yes
checking for linux/hdreg.h... yes
checking linux/fs.h usability... yes
checking linux/fs.h presence... yes
checking for linux/fs.h... yes
checking linux/major.h usability... yes
checking linux/major.h presence... yes
checking for linux/major.h... yes
checking for sys/sysctl.h... yes
checking for sys/cpuset.h... no
checking for sys/mount.h... yes
checking for arpa/inet.h... yes
checking for netinet/ip.h... yes
checking for netinet/ip_icmp.h... yes
checking for 1-parameter version of pthread_setname_np()... no
checking for 2-parameter version of pthread_setname_np()... yes
checking for 2-parameter version of pthread_set_name_np()... no
checking for struct sockaddr.sa_len... no
checking for struct sockaddr_in.sin_len... no
checking for struct sockaddr_in6.sin6_len... no
checking for sys/capability.h... yes
checking for struct stat.st_mtimespec.tv_nsec... no
checking for struct stat.st_mtim.tv_nsec... yes
checking whether to enable transparent proxy... checking for TPROXY sockopt 
IP_TRANSPARENT... set to 19
checking for SO_PEERCRED socket option... yes
checking for SO_MARK socket option... yes
checking for IP_TOS socket option... yes
checking for loopback network interface... lo
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... char
checking IN6_IS_ADDR_UNSPECIFIED macro works... yes
checking for struct tcp_info... yes
checking search.h usability... yes
checking search.h presence... yes
checking for search.h... yes
checking for struct hsearch_data... yes
checking for hcreate_r... yes
checking for hsearch_r... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating cmd/Makefile
config.status: creating cmd/traffic_cop/Makefile
config.status: creating cmd/traffic_crashlog/Makefile
config.status: creating cmd/traffic_ctl/Makefile
config.status: creating cmd/traffic_layout/Makefile
config.status: creating cmd/traffic_manager/Makefile
config.status: creating cmd/traffic_top/Makefile
config.status: creating cmd/traffic_via/Makefile
config.status: creating cmd/traffic_wccp/Makefile
config.status: creating doc/Makefile
config.status: creating example/Makefile
config.status: creating iocore/Makefile
config.status: creating iocore/aio/Makefile
config.status: creating iocore/cache/Makefile
config.status: creating iocore/cluster/Makefile
config.status: creating iocore/dns/Makefile
config.status: creating iocore/eventsystem/Makefile
config.status: creating iocore/hostdb/Makefile
config.status: creating iocore/net/Makefile
config.status: creating iocore/utils/Makefile
config.status: creating lib/Makefile
config.status: creating lib/atscppapi/Makefile
config.status: creating lib/atscppapi/examples/Makefile
config.status: creating lib/atscppapi/src/Makefile
config.status: creating lib/atscppapi/src/include/atscppapi/shared_ptr.h
config.status: creating lib/bindings/Makefile
config.status: creating lib/perl/Makefile
config.status: creating lib/perl/lib/Apache/TS.pm
config.status: creating lib/records/Makefile
config.status: creating lib/ts/Makefile
config.status: creating lib/ts/apidefs.h
config.status: creating lib/ts/ink_config.h
config.status: creating lib/tsconfig/Makefile
config.status: creating 

[jira] [Work logged] (TS-4751) revalidation can skip updating the Age header

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4751?focusedWorklogId=26547=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26547
 ]

ASF GitHub Bot logged work on TS-4751:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 21:39
Start Date: 17/Aug/16 21:39
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

https://github.com/apache/trafficserver/pull/864


Issue Time Tracking
---

Worklog Id: (was: 26547)
Time Spent: 3h  (was: 2h 50m)

> revalidation can skip updating the Age header
> -
>
> Key: TS-4751
> URL: https://issues.apache.org/jira/browse/TS-4751
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> In {{HttpTransact::merge_and_update_headers_for_cache_update}}, the cached 
> {{Age}} header is only updated if the server response also contains an 
> {{Age}} header. If the revalidation response does not contain an {{Age}}, we 
> will retain the cache {{Age}} header which makes the document permanently 
> stale, causing a revalidation on every request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver pull request #864: TS-4751: Prune cached headers before mergin...

[jpeach]

Github user jpeach closed the pull request at:

https://github.com/apache/trafficserver/pull/864


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4751) revalidation can skip updating the Age header

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4751?focusedWorklogId=26546=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26546
 ]

ASF GitHub Bot logged work on TS-4751:
--

Author: ASF GitHub Bot
Created on: 17/Aug/16 21:07
Start Date: 17/Aug/16 21:07
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/864
  
 - Looks good


Issue Time Tracking
---

Worklog Id: (was: 26546)
Time Spent: 2h 50m  (was: 2h 40m)

> revalidation can skip updating the Age header
> -
>
> Key: TS-4751
> URL: https://issues.apache.org/jira/browse/TS-4751
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> In {{HttpTransact::merge_and_update_headers_for_cache_update}}, the cached 
> {{Age}} header is only updated if the server response also contains an 
> {{Age}} header. If the revalidation response does not contain an {{Age}}, we 
> will retain the cache {{Age}} header which makes the document permanently 
> stale, causing a revalidation on every request.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] trafficserver issue #864: TS-4751: Prune cached headers before merging the u...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/864
  
👍 - Looks good


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4412) Event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net

[Susan Hinrichs (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425212#comment-15425212
 ] 

Susan Hinrichs commented on TS-4412:


Diving back into emails on [~cschombu]'s issue.  I think that was different 
than this.  It looks like he was running into timing problems with a double 
buffer weirdness 6.0 through pre 6.2.  [~cschombu] I see that I didn't respond 
via email, but I dimly remember that [~amc] chatted with you on IRC (or at 
least I hope one of us did.  otherwise, apologies for not responding).

Looking at the current code, we still don't have a ntodo check to make sure we 
don't over-read.  We should do that to protect ourselves from resource 
exhaustion.  We should be able to get that in for 7.0.0.  

> Event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net
> --
>
> Key: TS-4412
> URL: https://issues.apache.org/jira/browse/TS-4412
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Oknet Xu
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> the {{ssl_read_from_net}} read data from socket and saved into MIOBuffer.
> It was designed to fill the MIOBuffer as much as possible, even execeed the 
> VIO {{nbytes}} setting.
> It will try to call {{SSLReadBuffer}} again and again until the MIOBuffer is 
> full or an error returned from {{SSLReadBuffer}}. The {{event}} will be set 
> to a error status if an error returned from {{SSLReadBuffer}}.
> But at the end of {{ssl_read_from_net}}, the {{event}} will be overwrited to 
> SSL_READ_READY or SSL_READ_COMPLETE depend on {{vio.ntodo()}} if this is one 
> success at least in {{SSLReadBuffer}} before an error.
> For example:
> The {{SSLNetVConnection::net_read_io}} could not get SSL_READ_EOS from 
> {{ssl_read_from_net}} and can not close the SSLNetVConnection immediately. 
> Because The {{event}} SSL_READ_EOS is overwrited.
> The SSLNetVConnection will be closed by timeout.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4012) tcp_reused log field doesn't work for http2

[Eric Schwartz (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425182#comment-15425182
 ] 

Eric Schwartz commented on TS-4012:
---

TS-3612 seems to have fixed this because HttpSM simply has access to the 
underlying netvc from the parent session.

> tcp_reused log field doesn't work for http2
> ---
>
> Key: TS-4012
> URL: https://issues.apache.org/jira/browse/TS-4012
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2, Logging
>Reporter: Eric Schwartz
>Assignee: Eric Schwartz
> Fix For: 7.0.0
>
>
> This is something we noticed at Yahoo!
> Because it uses the HttpClientSession transact_count, the tcp_reused log 
> field will not properly work for http2 and spdy, where the HttpClientSession 
> isn't reused. 
> We need to essentially count the number of initiated streams instead.
> We've got a fix that does this for HTTP2. With SPDY eventually dying off, 
> does it make sense to also submit a change to fix this for SPDY? We have code 
> to do this as well, but it currently involves an H2 dependency that might be 
> undesirable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4412) Event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-4412:
---
Summary: Event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net 
 (was: event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net)

> Event overwrited by SSL_READ_READY / COMPLETE in ssl_read_from_net
> --
>
> Key: TS-4412
> URL: https://issues.apache.org/jira/browse/TS-4412
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Oknet Xu
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>
> the {{ssl_read_from_net}} read data from socket and saved into MIOBuffer.
> It was designed to fill the MIOBuffer as much as possible, even execeed the 
> VIO {{nbytes}} setting.
> It will try to call {{SSLReadBuffer}} again and again until the MIOBuffer is 
> full or an error returned from {{SSLReadBuffer}}. The {{event}} will be set 
> to a error status if an error returned from {{SSLReadBuffer}}.
> But at the end of {{ssl_read_from_net}}, the {{event}} will be overwrited to 
> SSL_READ_READY or SSL_READ_COMPLETE depend on {{vio.ntodo()}} if this is one 
> success at least in {{SSLReadBuffer}} before an error.
> For example:
> The {{SSLNetVConnection::net_read_io}} could not get SSL_READ_EOS from 
> {{ssl_read_from_net}} and can not close the SSLNetVConnection immediately. 
> Because The {{event}} SSL_READ_EOS is overwrited.
> The SSLNetVConnection will be closed by timeout.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4405) Remove proxy.config.http.parse.allow_non_http ?

[Bryan Call (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425164#comment-15425164
 ] 

Bryan Call commented on TS-4405:


Sounds like we can remove this option

> Remove proxy.config.http.parse.allow_non_http ?
> ---
>
> Key: TS-4405
> URL: https://issues.apache.org/jira/browse/TS-4405
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.0.0
>
>
> This option, undocumented, seems pretty useless. As far as I can tell, it 
> allows the HTTP response to exclude e.g. HTTP/1.1. Does anyone actually use / 
> need this ? Seems that enabling would cause more harm than good?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4409) Config verify command doesn't check volume.config

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-4409:
---
Summary: Config verify command doesn't check volume.config  (was: config 
verify command doesn't check volume.config)

> Config verify command doesn't check volume.config
> -
>
> Key: TS-4409
> URL: https://issues.apache.org/jira/browse/TS-4409
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: James Peach
>Assignee: Sudheer Vinukonda
> Fix For: sometime
>
>
> The {{traffic_server -Cconfig_verify}} command doesn't verify 
> {{volume.config}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-4402) Some HTTP configs were added as MgmtInt, but should be MgmtByte

[Leif Hedstrom (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leif Hedstrom reassigned TS-4402:
-

Assignee: Leif Hedstrom

> Some HTTP configs were added as MgmtInt, but should be MgmtByte
> ---
>
> Key: TS-4402
> URL: https://issues.apache.org/jira/browse/TS-4402
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
>  Labels: newbie
> Fix For: 7.0.0
>
>
> Specifically I think these should be Byte's, to be consistent with the rest 
> of the internals:
> {code}
> MgmtInt attach_server_session_to_client;
> MgmtInt cache_open_write_fail_action
> {code}
> Now, changing this might break the same snapshot? [~jpe...@apache.org]
> Also, while going through these, a couple of overridable configs are marked 
> as MgmtInt in InkAPI.cc, where in fact they are MgmtByte (so the inverse 
> problem). I'll fix this as part of TS-4401.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4400) TSProxyStateSet persist cache clearing across restart

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-4400:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> TSProxyStateSet persist cache clearing across restart
> -
>
> Key: TS-4400
> URL: https://issues.apache.org/jira/browse/TS-4400
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: James Peach
> Fix For: 7.1.0
>
>
> If you use {{TSProxyStateSet}} and and pass the options to clear the cache, 
> these options are persisted so that subsequent restarts will also clear the 
> cache. This seems pretty bad and likely to cause accidents. The options 
> should be one-shot.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-4396) Off-by-one error in max redirects with redirection enabled

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-4396:
---
Fix Version/s: (was: 7.0.0)
   7.1.0

> Off-by-one error in max redirects with redirection enabled
> --
>
> Key: TS-4396
> URL: https://issues.apache.org/jira/browse/TS-4396
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, Network
>Reporter: Felix Buenemann
>Assignee: Zhao Yongming
> Fix For: 7.1.0
>
>
> There is a problem in the current stable version 6.1.1 where the setting 
> proxy.config.http.number_of_redirections = 1 is incorrectly checked when 
> following origin redirects by setting proxy.config.http.redirection_enabled = 
> 1.
> If the requested URL is not already cached, ATS returns the redirect response 
> to the client instead of storing the target into the cache and returning it 
> to the client.
> The problem can be fixed by using proxy.config.http.number_of_redirections = 
> 2, but we are only following one redirect, so this is wrong.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-4394) HttpSM should keep track of what states it has passed through

[Alan M. Carroll (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15425149#comment-15425149
 ] 

Alan M. Carroll commented on TS-4394:
-

I think {{history}} member of the {{HttpSM}} does this, I think.

> HttpSM should keep track of what states it has passed through
> -
>
> Key: TS-4394
> URL: https://issues.apache.org/jira/browse/TS-4394
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Thomas Jackson
> Fix For: sometime
>
>
> When implementing the fix for TS-4328 I needed to answer the question "did we 
> ever send bytes to the server". This should be relatively simple to answer-- 
> as there is a specific state that connects to origin and then sends the 
> request. At this point nothing in the SM keeps track of where we have been, 
> the closest we have are the milestones-- which we are apparently not happy 
> with using for any logic (only for metrics).
> So, the TLDR is that we'd like a mechanism in the HttpSM to see where the SM 
> has gone and its current state. This would be especially helpful for 
> debugging, as we would be able to tell what all the SM has done.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TS-4379) Log field for connections to origin

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call closed TS-4379.
--
   Resolution: Won't Fix
Fix Version/s: (was: sometime)

> Log field for connections to origin 
> 
>
> Key: TS-4379
> URL: https://issues.apache.org/jira/browse/TS-4379
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Eric Schwartz
>
> Simple log field for # of connections open to the origin server. Did this a 
> while back for some work we were doing to track the maximum number of 
> connections to a given origin across some traffic spikes. Thought someone 
> else might find it useful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)