[jira] [Created] (TS-3645) After TS-3033, some traffic_line command result in requested command failed
Dimitry Andric created TS-3645:
--
Summary: After TS-3033, some traffic_line command result in
requested command failed
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Reporter: Dimitry Andric
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message, the
diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message, the
command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at [commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in [commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number of
parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets cut
off in some way, possibly because the server is just shutting down at that
point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563640#comment-14563640
]
Dimitry Andric commented on TS-3645:
Note that when I locally revert [commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commitdiff;h=355c165]
and rebuild, the error messages disappear. As far as I can see, the commands
themselves still do what they are supposed to do.
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll reopened TS-3642: - I've been reviewing this and I think this mainly swishes the dirt around. The switched strings were obviously wrong but my testing shows that the overall result is that the new settings are ignored, that is you must use the old number `share_server_sessions` value to be effective. The root cause is that the records management does not provide any indication of whether the value is actually in records.config. For this reason if you don't have `share_server_sessions` set, the internal logic will behave as if you had it explicitly set to 2,overriding the new style values. This can't be fixed by switching the order back for the same reason. Not sure what to do about it, need to dig deeper. Also, I found that SessionSharingMatchStrings is wrongly ordered which is another problem. proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimitry Andric updated TS-3645:
---
Summary: After TS-3033, some traffic_line commands result in requested
command failed (was: After TS-3033, some traffic_line command result in
requested command failed)
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Reporter: Dimitry Andric
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
Stephane Bagneris created TS-3646: - Summary: chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Bug Reporter: Stephane Bagneris The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimitry Andric updated TS-3645:
---
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Affects Version/s: 6.0.0
5.3.0
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3645) After TS-3033, some traffic_line commands result in requested command failed
[
https://issues.apache.org/jira/browse/TS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3645:
--
Fix Version/s: 6.0.0
After TS-3033, some traffic_line commands result in requested command failed
--
Key: TS-3645
URL: https://issues.apache.org/jira/browse/TS-3645
Project: Traffic Server
Issue Type: Bug
Components: Management API
Affects Versions: 5.3.0, 6.0.0
Environment: RHEL 6.x, CentOS 6.x (on x86_64)
Reporter: Dimitry Andric
Fix For: 6.0.0
I recently upgraded from trafficserver 4.x to 5.3.0, and one thing that I
noticed was that certain traffic_line commands started printing requested
command failed. For example:
{noformat}
# trafficserver start
Starting Apache Traffic Server:[ OK ]
# traffic_line --status
Proxy -- on
# traffic_line --shutdown
error: the requested command failed: [11] Invalid parameters passed into
function call.
# traffic_line --startup
error: the requested command failed: [11] Invalid parameters passed into
function call.
{noformat}
Interestingly, even if the --shutdown command gives such an error message,
the diags.log file still shows that the server has shut down:
{noformat}
[May 28 22:03:03.539] Server {0x2abe4251d700} NOTE:
[ProcessManager::processEventQueue] Shutdown msg received, exiting
{noformat}
and the --status command also finds the same:
{noformat}
# traffic_line --status
Proxy -- off
{noformat}
Similar for the --startup command: though it gives the same error message,
the command seems to have actually worked.
I did some bisecting to find where this was introduced, and ended up at
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165]
(TS-3033: fix PROXY_STATE_GET). Before this particular commit, both
{{traffic_line --shutdown}} and {{traffic_line --startup}} work without
printing any error; after the commit, they both start printing requested
command failed.
If I look at all the work done in TS-3033, and the particular change in
[commit
355c165|https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=commit;h=355c165],
I would guess that some parts of the code are disagreeing about the number
of parameters for the PROXY_STATE_GET message.
Alternatively, there may be some sort of issue in the management API and/or
marshalling code, where a PROXY_STATE_GET message with two parameters gets
cut off in some way, possibly because the server is just shutting down at
that point?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3646: --- Fix Version/s: 6.0.0 chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: 6.0.0 The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3646: --- Issue Type: Improvement (was: Bug) chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: 6.0.0 The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3646: --- Component/s: Logging chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: 6.0.0 The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-3646: --- Affects Version/s: 5.3.0 chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Bug Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: 6.0.0 The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563943#comment-14563943 ] Sudheer Vinukonda commented on TS-3642: --- A few notes: *) I honestly don't understand the need to have a separate/new setting to replace the existing *proxy.config.http.share_server_sessions*. The existing setting has been working fine. It was indicated to me that the motivation behind the change was TS-1893, but, reading through that jira, I haven't found the need to change the *proxy.config.http.share_server_sessions* setting. That jira, AFAICT asks for a configuration control on the *match* and not the *pool*. Also, I am not sure, if it makes sense to remove the *disable* option for the existing *share_server_sessions* and move it to the *match* setting. *) Also, AFAICT, the new settings never worked until the coverity fix a020cb2943f78f77ba8c928001359e8a2440cd28, which went in 5.3.0. Prior to that, the old setting was always working (in 5.0.x/5.1.x/5.2.x) and has been active in production. So, I'd argue that it is essential to preserve that behavior in 5.3.x at least. proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563943#comment-14563943 ] Sudheer Vinukonda edited comment on TS-3642 at 5/29/15 12:02 AM: - A few notes: * ) I honestly don't understand the need to have a separate/new setting to replace the existing *proxy.config.http.share_server_sessions*. The existing setting has been working fine. It was indicated to me that the motivation behind the change was TS-1893, but, reading through that jira, I haven't found the need to change the *proxy.config.http.share_server_sessions* setting. That jira, AFAICT asks for a configuration control on the *match* and not the *pool*. Also, I am not sure, if it makes sense to remove the *disable* option for the existing *share_server_sessions* and move it to the *match* setting. * ) Also, AFAICT, the new settings never worked until the coverity fix a020cb2943f78f77ba8c928001359e8a2440cd28, which went in 5.3.0. Prior to that, the old setting was always working (in 5.0.x/5.1.x/5.2.x) and has been active in production. So, I'd argue that it is essential to preserve that behavior in 5.3.x at least. was (Author: sudheerv): A few notes: *) I honestly don't understand the need to have a separate/new setting to replace the existing *proxy.config.http.share_server_sessions*. The existing setting has been working fine. It was indicated to me that the motivation behind the change was TS-1893, but, reading through that jira, I haven't found the need to change the *proxy.config.http.share_server_sessions* setting. That jira, AFAICT asks for a configuration control on the *match* and not the *pool*. Also, I am not sure, if it makes sense to remove the *disable* option for the existing *share_server_sessions* and move it to the *match* setting. *) Also, AFAICT, the new settings never worked until the coverity fix a020cb2943f78f77ba8c928001359e8a2440cd28, which went in 5.3.0. Prior to that, the old setting was always working (in 5.0.x/5.1.x/5.2.x) and has been active in production. So, I'd argue that it is essential to preserve that behavior in 5.3.x at least. proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3643) TS-2944 changes logging format / breaks compatibility
[ https://issues.apache.org/jira/browse/TS-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3643: -- Fix Version/s: 5.3.1 TS-2944 changes logging format / breaks compatibility - Key: TS-3643 URL: https://issues.apache.org/jira/browse/TS-3643 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Affects Versions: 5.3.0 Reporter: David Carlin Fix For: 5.3.1 TS-2944 broke our log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3630) Fails to build with GCC 5 on Mac OS 10.10.3
[ https://issues.apache.org/jira/browse/TS-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3630: -- Fix Version/s: 6.0.0 Fails to build with GCC 5 on Mac OS 10.10.3 --- Key: TS-3630 URL: https://issues.apache.org/jira/browse/TS-3630 Project: Traffic Server Issue Type: Bug Components: Build Reporter: alex dunn Fix For: 6.0.0 Builds fine with Clang, but GCC produces a bunch of undefined symbol errors. Full build logs + system config: https://gist.github.com/dunn/e97fdb5f12baa8d3e097#file-03-make-L201 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3643) TS-2944 changes logging format / breaks compatibility
[ https://issues.apache.org/jira/browse/TS-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563996#comment-14563996 ] Leif Hedstrom commented on TS-3643: --- What do we do with this? Do we want to try to unbreak this in a 5.3.1 ? I'm gonna target this for v5.3.1, and let you duke this out with the RM and the community. TS-2944 changes logging format / breaks compatibility - Key: TS-3643 URL: https://issues.apache.org/jira/browse/TS-3643 Project: Traffic Server Issue Type: Bug Components: Configuration, Logging Affects Versions: 5.3.0 Reporter: David Carlin Fix For: 5.3.1 TS-2944 broke our log processing by changing cache result code from TCP_HIT to TCP_MEM_HIT for the majority of our responses. Additionally, TS-3036 is better. https://issues.apache.org/jira/browse/TS-3036?focusedCommentId=14561404page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14561404 Should TS-2944 be reverted since its redundant and breaks compatibility? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Created] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
This is by design. crc loses this information at times since its overloading with other info. chm is for the cache hit hierarchy , which today is only two levels but could in the future be more. On May 28, 2015, at 3:17 PM, Stephane Bagneris (JIRA) j...@apache.org wrote: Stephane Bagneris created TS-3646: - Summary: chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Bug Reporter: Stephane Bagneris The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-3637) Build errors on OS X / clang in I_Lock.h asserts.
[
https://issues.apache.org/jira/browse/TS-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-3637.
---
Resolution: Won't Fix
Build errors on OS X / clang in I_Lock.h asserts.
-
Key: TS-3637
URL: https://issues.apache.org/jira/browse/TS-3637
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Seems some compilers complain on the volatility of thread_holding not being
loaded in an ink_assert.
{code}
In file included from ./I_Continuation.h:40:
./I_Lock.h:350:15: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
./I_Lock.h:383:15: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
./I_Lock.h:421:17: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
3 errors generated.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-3637) Build errors on OS X / clang in I_Lock.h asserts.
[
https://issues.apache.org/jira/browse/TS-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-3637:
-
Assignee: Leif Hedstrom
Build errors on OS X / clang in I_Lock.h asserts.
-
Key: TS-3637
URL: https://issues.apache.org/jira/browse/TS-3637
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Seems some compilers complain on the volatility of thread_holding not being
loaded in an ink_assert.
{code}
In file included from ./I_Continuation.h:40:
./I_Lock.h:350:15: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
./I_Lock.h:383:15: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
./I_Lock.h:421:17: error: expression result unused; assign into a variable to
force a volatile load [-Werror,-Wunused-volatile-lvalue]
(void)(m-thread_holding);
~ ^~
3 errors generated.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563952#comment-14563952 ] Leif Hedstrom commented on TS-3646: --- This is by design actually. Even though there is (sometimes) overlap between the two, they are not the same. %chm will always show the cache hit / miss status, and the hierarchy information (currently RAM and disk only, but has future extensions possible). %crc has a significant overload of information, which can cause you to lose vital information. As an example, %crc can show a result of TCP_REFRESH_HIT. However, you can *not* tell if it was a RAM or a disk cache hit. This is partially why %chm was added. Maybe we should turn this into a documentation issue, and clarify the differences better? chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: 6.0.0 The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3635) ASAN failures when running traffic_server -R 1 ( regressions)
[ https://issues.apache.org/jira/browse/TS-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563971#comment-14563971 ] ASF subversion and git services commented on TS-3635: - Commit b39cd80de47d4034b1574f6b8b3da92721e5d8b2 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b39cd80 ] TS-3635 Fix some ASAN memory issues ASAN failures when running traffic_server -R 1 ( regressions) - Key: TS-3635 URL: https://issues.apache.org/jira/browse/TS-3635 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3635) ASAN failures when running traffic_server -R 1 ( regressions)
[ https://issues.apache.org/jira/browse/TS-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563972#comment-14563972 ] ASF subversion and git services commented on TS-3635: - Commit 4ce075de8666880498829d91473579f810333153 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4ce075d ] Add TS-3635 ASAN failures when running traffic_server -R 1 ( regressions) - Key: TS-3635 URL: https://issues.apache.org/jira/browse/TS-3635 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3629) TS corrupts Link: header in response
[
https://issues.apache.org/jira/browse/TS-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3629:
--
Component/s: Plugins
TS corrupts Link: header in response
Key: TS-3629
URL: https://issues.apache.org/jira/browse/TS-3629
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Felicity Tarnell
Assignee: Otto van der Schaaf
Fix For: 6.0.0
(Using 5.3.0 on 64-bit Linux.)
We have an origin that links a {{Link}} header in its response. Requesting
the document directly from the origin (nginx) shows the correct header:
{noformat}
by-staging-1:~# curl -Ix localhost:81 http://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 21 May 2015 10:04:54 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Content-Language: en
Link: http://plan-staging.torchboxapps.com/;
rel=canonical,http://plan-staging.torchboxapps.com/; rel=shortlink
{noformat}
However, requesting the same document from ATS, using the same origin,
truncates the header:
{noformat}
1 jobs exit 2 152!klamath:~/tbx/puppetcurl -I
https://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Date: Thu, 21 May 2015 10:06:01 GMT
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: pre-check=0
Content-Language: en
Link: https://plan-staging.torchboxapps.com/; rel=shortlink
Content-Length: 0
Age: 0
Connection: keep-alive
Strict-Transport-Security: max-age=15552000
Via: http/1.1 by-staging-1 (uScMsSf pSeN:t cCMi pSs )
X-Cache: miss
{noformat}
(The reason for http vs. https is that ATS is terminating SSL, and the origin
uses http only.)
{{tcpdump}} shows that in the ATS request, the backend is sending the correct
header:
{noformat}
16:37:02.145579 IP 127.0.0.1.38756 127.0.0.1.81: Flags [P.], seq 1:376, ack
1, win 342, options [nop,nop,TS val 66617043 ecr 66617043], length 375
0x: 4500 01ab f8b6 4000 4006 4294 7f00 0001 E.@.@.B.
0x0010: 7f00 0001 9764 0051 170d 8668 cc19 17f9 .d.Q...h
0x0020: 8018 0156 ff9f 0101 080a 03f8 7ed3 ...V..~.
0x0030: 03f8 7ed3 4845 4144 2068 7474 703a 2f2f ..~.HEAD.http://
0x0040: 706c 616e 2d73 7461 6769 6e67 2e74 6f72 plan-staging.tor
0x0050: 6368 626f 7861 7070 732e 636f 6d2f 2048 chboxapps.com/.H
0x0060: 5454 502f 312e 310d 0a41 7574 686f 7269 TTP/1.1..Authori
0x0070: 7a61 7469 6f6e 3a20 4261 7369 6320 zation:.Basic...
0x0080:
0x0090: 0d0a xx..
0x00a0: 5573 6572 2d41 6765 6e74 3a20 6375 726c User-Agent:.curl
0x00b0: 2f37 2e34 312e 300d 0a48 6f73 743a 2070 /7.41.0..Host:.p
0x00c0: 6c61 6e2d 7374 6167 696e 672e 746f 7263 lan-staging.torc
0x00d0: 6862 6f78 6170 7073 2e63 6f6d 0d0a 4163 hboxapps.com..Ac
0x00e0: 6365 7074 3a20 2a2f 2a0d 0a58 2d46 6f72 cept:.*/*..X-For
0x00f0: 7761 7264 6564 2d50 726f 746f 3a20 6874 warded-Proto:.ht
0x0100: 7470 730d 0a43 6c69 656e 742d 6970 3a20 tps..Client-ip:.
0x0110: 3932 2e32 312e 3135 332e 360d 0a58 2d46 92.21.153.6..X-F
0x0120: 6f72 7761 7264 6564 2d46 6f72 3a20 3932 orwarded-For:.92
0x0130: 2e32 312e 3135 332e 360d 0a56 6961 3a20 .21.153.6..Via:.
0x0140: 6874 7470 732f 312e 3120 6279 2d73 7461 https/1.1.by-sta
0x0150: 6769 6e67 2d31 5b43 3145 3346 3436 365d ging-1[C1E3F466]
0x0160: 2028 4170 6163 6865 5472 6166 6669 6353 .(ApacheTrafficS
0x0170: 6572 7665 722f 352e 332e 3020 5b75 5363 erver/5.3.0.[uSc
0x0180: 4d73 2066 2070 2065 4e3a 7420 6343 4d69 Ms.f.p.eN:t.cCMi
0x0190: 2070 2073 205d 290d 0a50 6167 6553 7065 .p.s.])..PageSpe
0x01a0: 6564 3a20 6f66 660d 0a0d 0a ed:.off
16:37:02.145588 IP 127.0.0.1.81 127.0.0.1.38756: Flags [.], ack 376, win
350, options [nop,nop,TS val 66617043 ecr 66617043], length 0
0x: 4500 0034 692a 4000 4006 d397 7f00 0001 E..4i*@.@...
0x0010: 7f00 0001 0051 9764 cc19 17f9 170d 87df .Q.d
0x0020: 8010 015e fe28 0101 080a 03f8 7ed3 ...^.(~.
0x0030: 03f8 7ed3..~.
16:37:02.240195 IP 127.0.0.1.81 127.0.0.1.38756: Flags [P.], seq 1:413, ack
376, win 350, options [nop,nop,TS val 66617052 ecr 66617043], length 412
0x: 4500 01d0 692b 4000 4006 d1fa 7f00 0001 E...i+@.@...
0x0010:
[jira] [Updated] (TS-3627) Count tx and rx bytes for WebSocket
[ https://issues.apache.org/jira/browse/TS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3627: -- Fix Version/s: 6.0.0 Count tx and rx bytes for WebSocket --- Key: TS-3627 URL: https://issues.apache.org/jira/browse/TS-3627 Project: Traffic Server Issue Type: New Feature Reporter: bettydramit Fix For: 6.0.0 How to count rx and tx per map websocket (ws and wss)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3629) TS corrupts Link: header in response
[
https://issues.apache.org/jira/browse/TS-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3629:
--
Fix Version/s: 6.0.0
TS corrupts Link: header in response
Key: TS-3629
URL: https://issues.apache.org/jira/browse/TS-3629
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Felicity Tarnell
Assignee: Otto van der Schaaf
Fix For: 6.0.0
(Using 5.3.0 on 64-bit Linux.)
We have an origin that links a {{Link}} header in its response. Requesting
the document directly from the origin (nginx) shows the correct header:
{noformat}
by-staging-1:~# curl -Ix localhost:81 http://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 21 May 2015 10:04:54 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0
Content-Language: en
Link: http://plan-staging.torchboxapps.com/;
rel=canonical,http://plan-staging.torchboxapps.com/; rel=shortlink
{noformat}
However, requesting the same document from ATS, using the same origin,
truncates the header:
{noformat}
1 jobs exit 2 152!klamath:~/tbx/puppetcurl -I
https://plan-staging.torchboxapps.com/
HTTP/1.1 200 OK
Date: Thu, 21 May 2015 10:06:01 GMT
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: pre-check=0
Content-Language: en
Link: https://plan-staging.torchboxapps.com/; rel=shortlink
Content-Length: 0
Age: 0
Connection: keep-alive
Strict-Transport-Security: max-age=15552000
Via: http/1.1 by-staging-1 (uScMsSf pSeN:t cCMi pSs )
X-Cache: miss
{noformat}
(The reason for http vs. https is that ATS is terminating SSL, and the origin
uses http only.)
{{tcpdump}} shows that in the ATS request, the backend is sending the correct
header:
{noformat}
16:37:02.145579 IP 127.0.0.1.38756 127.0.0.1.81: Flags [P.], seq 1:376, ack
1, win 342, options [nop,nop,TS val 66617043 ecr 66617043], length 375
0x: 4500 01ab f8b6 4000 4006 4294 7f00 0001 E.@.@.B.
0x0010: 7f00 0001 9764 0051 170d 8668 cc19 17f9 .d.Q...h
0x0020: 8018 0156 ff9f 0101 080a 03f8 7ed3 ...V..~.
0x0030: 03f8 7ed3 4845 4144 2068 7474 703a 2f2f ..~.HEAD.http://
0x0040: 706c 616e 2d73 7461 6769 6e67 2e74 6f72 plan-staging.tor
0x0050: 6368 626f 7861 7070 732e 636f 6d2f 2048 chboxapps.com/.H
0x0060: 5454 502f 312e 310d 0a41 7574 686f 7269 TTP/1.1..Authori
0x0070: 7a61 7469 6f6e 3a20 4261 7369 6320 zation:.Basic...
0x0080:
0x0090: 0d0a xx..
0x00a0: 5573 6572 2d41 6765 6e74 3a20 6375 726c User-Agent:.curl
0x00b0: 2f37 2e34 312e 300d 0a48 6f73 743a 2070 /7.41.0..Host:.p
0x00c0: 6c61 6e2d 7374 6167 696e 672e 746f 7263 lan-staging.torc
0x00d0: 6862 6f78 6170 7073 2e63 6f6d 0d0a 4163 hboxapps.com..Ac
0x00e0: 6365 7074 3a20 2a2f 2a0d 0a58 2d46 6f72 cept:.*/*..X-For
0x00f0: 7761 7264 6564 2d50 726f 746f 3a20 6874 warded-Proto:.ht
0x0100: 7470 730d 0a43 6c69 656e 742d 6970 3a20 tps..Client-ip:.
0x0110: 3932 2e32 312e 3135 332e 360d 0a58 2d46 92.21.153.6..X-F
0x0120: 6f72 7761 7264 6564 2d46 6f72 3a20 3932 orwarded-For:.92
0x0130: 2e32 312e 3135 332e 360d 0a56 6961 3a20 .21.153.6..Via:.
0x0140: 6874 7470 732f 312e 3120 6279 2d73 7461 https/1.1.by-sta
0x0150: 6769 6e67 2d31 5b43 3145 3346 3436 365d ging-1[C1E3F466]
0x0160: 2028 4170 6163 6865 5472 6166 6669 6353 .(ApacheTrafficS
0x0170: 6572 7665 722f 352e 332e 3020 5b75 5363 erver/5.3.0.[uSc
0x0180: 4d73 2066 2070 2065 4e3a 7420 6343 4d69 Ms.f.p.eN:t.cCMi
0x0190: 2070 2073 205d 290d 0a50 6167 6553 7065 .p.s.])..PageSpe
0x01a0: 6564 3a20 6f66 660d 0a0d 0a ed:.off
16:37:02.145588 IP 127.0.0.1.81 127.0.0.1.38756: Flags [.], ack 376, win
350, options [nop,nop,TS val 66617043 ecr 66617043], length 0
0x: 4500 0034 692a 4000 4006 d397 7f00 0001 E..4i*@.@...
0x0010: 7f00 0001 0051 9764 cc19 17f9 170d 87df .Q.d
0x0020: 8010 015e fe28 0101 080a 03f8 7ed3 ...^.(~.
0x0030: 03f8 7ed3..~.
16:37:02.240195 IP 127.0.0.1.81 127.0.0.1.38756: Flags [P.], seq 1:413, ack
376, win 350, options [nop,nop,TS val 66617052 ecr 66617043], length 412
0x: 4500 01d0 692b 4000 4006 d1fa 7f00 0001 E...i+@.@...
0x0010:
[jira] [Updated] (TS-3627) Count tx and rx bytes for WebSocket
[ https://issues.apache.org/jira/browse/TS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3627: -- Component/s: Metrics Count tx and rx bytes for WebSocket --- Key: TS-3627 URL: https://issues.apache.org/jira/browse/TS-3627 Project: Traffic Server Issue Type: New Feature Components: Metrics Reporter: bettydramit Fix For: 6.0.0 How to count rx and tx per map websocket (ws and wss)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-3630) Fails to build with GCC 5 on Mac OS 10.10.3
[ https://issues.apache.org/jira/browse/TS-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-3630: - Assignee: Leif Hedstrom Fails to build with GCC 5 on Mac OS 10.10.3 --- Key: TS-3630 URL: https://issues.apache.org/jira/browse/TS-3630 Project: Traffic Server Issue Type: Bug Components: Build Reporter: alex dunn Assignee: Leif Hedstrom Fix For: 6.0.0 Builds fine with Clang, but GCC produces a bunch of undefined symbol errors. Full build logs + system config: https://gist.github.com/dunn/e97fdb5f12baa8d3e097#file-03-make-L201 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3636) Parent Proxy Forward mode ts-full
[ https://issues.apache.org/jira/browse/TS-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3636: -- Fix Version/s: 6.0.0 Parent Proxy Forward mode ts-full - Key: TS-3636 URL: https://issues.apache.org/jira/browse/TS-3636 Project: Traffic Server Issue Type: Bug Components: Parent Proxy, TProxy Reporter: Faysal Banna Assignee: Alan M. Carroll Fix For: 6.0.0 Hello Guys. today i stumbled upon an issue with parent proxy, and let me describe what is going on. i have my cache working in forward proxy mode tr-full proxy.config.reverse_proxy.enabled 0 proxy.config.url_remap.remap_required 0 proxy.config.http.server_ports 8080:tr-full:tr-pass 8099 and in parent.config i have url_regex=.*distrowatch parent=77.75.92.61:8080 now if i do export http_proxy=127.0.0.1:8099 wget 'http://distrowatch.com' --delete-after i can see that the request was proxied to the parent cache in squid.log as shown below: 1432569647.049 823 127.0.0.1 TCP_REFRESH_MISS/200 157668 GET http://distrowatch.com/ - PARENT_HIT/77.75.92.61 text/html yet if i go as a client forwarded to the server from my laptop i issue wget --delete-after 'http://distrowatch.com' i get in squid.log 1432570157.718 62805 77.75.88.82 TCP_REFRESH_MISS/200 157598 GET http://distrowatch.com/ - DIRECT/distrowatch.com text/html i checked tcpdump on the interface between both caches and i had a result that ATS was sending parent proxies with origin ip addresses same as the client ip addresses . so i did a source-nat (SNAT) via iptables firewall on the interface itself and originated traffic as if originated from ATS itself in diags.log i could always see http parent proxy 77.75.92.61:8080 marked down in my believe parent proxy should not get client address unless asked for. since it should always reply to the ATS server so it should get ATS ip address and not client ip address regardless of being TProxied or not. unless someone can create some variable to enable disable such feature when contacting parent proxies. Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3646) chm log field and TCP_MEM_HIT are the same feature
[ https://issues.apache.org/jira/browse/TS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3646: -- Fix Version/s: (was: 6.0.0) Docs chm log field and TCP_MEM_HIT are the same feature Key: TS-3646 URL: https://issues.apache.org/jira/browse/TS-3646 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 5.3.0 Reporter: Stephane Bagneris Fix For: Docs The documented chm log field feature which will differentiate between RAM_HIT and DISK_HIT as already been implemented with the addition of TCP_MEM_HIT in the crc filed. Having both feature is redundant and confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3632) libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
[
https://issues.apache.org/jira/browse/TS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14562864#comment-14562864
]
Igor Galić commented on TS-3632:
we still have to merge this into 5.3.x
libwccp.a(WccpMsg.o): undefined reference to symbol MD5_Final
-
Key: TS-3632
URL: https://issues.apache.org/jira/browse/TS-3632
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 5.3.0
Reporter: Igor Galić
Assignee: Jean Baptiste Favre
Fix For: 6.0.0
When building ATS 5.3.0 on Ubuntu 11.04[1,2] a linking failure occurs
because of the ordering of the libraries:
{code}
libtool: link: c++ -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -pipe -Wall
-feliminate-unused-debug-symbols -fno-strict-aliasing -Wno-invalid-offsetof
-mcx16 -rdynamic -Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z -Wl,relro -Wl,-z
-Wl,now -o .libs/traffic_manager AddConfigFilesHere.o traffic_manager.o
StatProcessor.o StatType.o StatXML.o ../../mgmt/web2/libweb.a
../../mgmt/api/.libs/libmgmtapilocal.a
/«PKGBUILDDIR»/lib/ts/.libs/libtsutil.so -lssl -lcrypto -L/usr/lib
../../mgmt/.libs/libmgmt_lm.a ../../proxy/hdrs/libhdrs.a
../../lib/records/librecords_lm.a ../../lib/ts/.libs/libtsutil.so
../../iocore/eventsystem/libinkevent.a ../../proxy/shared/liberror.a
../../proxy/shared/libdiagsconfig.a -lresolv -ltcl8.5 -lhwloc -lm
../../lib/wccp/libwccp.a ../../lib/tsconfig/.libs/libtsconfig.so -lcap -lpcre
-lz -lcrypt -lpthread -lrt -ldl /usr/lib/x86_64-linux-gnu/libxml2.so
-Wl,-rpath -Wl,/usr/lib/trafficserver
/usr/bin/ld: ../../lib/wccp/libwccp.a(WccpMsg.o): undefined reference to
symbol 'MD5_Final@@OPENSSL_1.0.0'
/usr/bin/ld: note: 'MD5_Final@@OPENSSL_1.0.0' is defined in DSO
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so so
try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libcrypto.so:
could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[3]: *** [traffic_manager] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/cmd/traffic_manager'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/«PKGBUILDDIR»/cmd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [binary-arch] Error 2
{code}
[1]
https://wiki.debian.org/ToolChain/DSOLinking#Only_link_with_needed_libraries
[2] https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3644) Remove CHANGES file from repo
Phil Sorber created TS-3644: --- Summary: Remove CHANGES file from repo Key: TS-3644 URL: https://issues.apache.org/jira/browse/TS-3644 Project: Traffic Server Issue Type: Task Reporter: Phil Sorber This will be replaces with our online release notes in JIRA + a new step that is part of `make rel` that does something along the lines of `git shortlog CHANGES` for the tarball. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3644) Remove CHANGES file from repo
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3644:
Description: This will be replaced with our online release notes in JIRA +
a new step that is part of {{make rel}} that does something along the lines of
{{git shortlog CHANGES}} for the tarball. (was: This will be replaces with
our online release notes in JIRA + a new step that is part of {{make rel}} that
does something along the lines of {{git shortlog CHANGES}} for the tarball.)
Remove CHANGES file from repo
-
Key: TS-3644
URL: https://issues.apache.org/jira/browse/TS-3644
Project: Traffic Server
Issue Type: Task
Reporter: Phil Sorber
Fix For: 6.0.0
This will be replaced with our online release notes in JIRA + a new step that
is part of {{make rel}} that does something along the lines of {{git shortlog
CHANGES}} for the tarball.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3644) Remove CHANGES file from repo
[ https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber updated TS-3644: Fix Version/s: 6.0.0 Remove CHANGES file from repo - Key: TS-3644 URL: https://issues.apache.org/jira/browse/TS-3644 Project: Traffic Server Issue Type: Task Reporter: Phil Sorber Fix For: 6.0.0 This will be replaces with our online release notes in JIRA + a new step that is part of `make rel` that does something along the lines of `git shortlog CHANGES` for the tarball. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3644) Remove CHANGES file from repo
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3644:
Description: This will be replaces with our online release notes in JIRA +
a new step that is part of {{make rel}} that does something along the lines of
{{git shortlog CHANGES}} for the tarball. (was: This will be replaces with
our online release notes in JIRA + a new step that is part of `make rel` that
does something along the lines of `git shortlog CHANGES` for the tarball.)
Remove CHANGES file from repo
-
Key: TS-3644
URL: https://issues.apache.org/jira/browse/TS-3644
Project: Traffic Server
Issue Type: Task
Reporter: Phil Sorber
Fix For: 6.0.0
This will be replaces with our online release notes in JIRA + a new step that
is part of {{make rel}} that does something along the lines of {{git shortlog
CHANGES}} for the tarball.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3644) Remove CHANGES file from repo
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3644:
Assignee: Sudheer Vinukonda
Remove CHANGES file from repo
-
Key: TS-3644
URL: https://issues.apache.org/jira/browse/TS-3644
Project: Traffic Server
Issue Type: Task
Reporter: Phil Sorber
Assignee: Sudheer Vinukonda
Fix For: 6.0.0
This will be replaced with our online release notes in JIRA + a new step that
is part of {{make rel}} that does something along the lines of {{git shortlog
CHANGES}} for the tarball.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3644) Remove CHANGES file from git
[
https://issues.apache.org/jira/browse/TS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Sorber updated TS-3644:
Summary: Remove CHANGES file from git (was: Remove CHANGES file from repo)
Remove CHANGES file from git
Key: TS-3644
URL: https://issues.apache.org/jira/browse/TS-3644
Project: Traffic Server
Issue Type: Task
Reporter: Phil Sorber
Assignee: Sudheer Vinukonda
Fix For: 6.0.0
This will be replaced with our online release notes in JIRA + a new step that
is part of {{make rel}} that does something along the lines of {{git shortlog
CHANGES}} for the tarball.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3642) proxy.config.http.share_server_sessions not working
[ https://issues.apache.org/jira/browse/TS-3642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563100#comment-14563100 ] Phil Sorber commented on TS-3642: - Also include commit 349fb2f proxy.config.http.share_server_sessions not working --- Key: TS-3642 URL: https://issues.apache.org/jira/browse/TS-3642 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 5.3.0 Reporter: David Carlin Assignee: Sudheer Vinukonda Testing 5.3.0 and I noticed proxy.config.http.share_server_sessions = 1 no longer works. Saw a 10-15x increase in origin connections; there appears to be some reuse, I am seeing approximately 1.2-1.3 requests per origin connection. Setting proxy.config.http.server_session_sharing.pool = global restored expected behavior (Thanks [~sudheerv]!) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
