[jira] [Commented] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841057#comment-13841057 ] Wei Sun commented on TS-1146: - Looks good to me. Thanks. Only one comment as below: fail: delete ticket_key; ticket_key = NULL; // SSLReleaseContext() always delete ticket_key when releasing ctx. > RFC 5077 TLS Session tickets > > > Key: TS-1146 > URL: https://issues.apache.org/jira/browse/TS-1146 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach > Labels: A > Fix For: 5.0.0 > > Attachments: SSL_CTX_set_tlsext_ticket_key_cb.txt, > session_ticket.patch, session_ticket_review.patch > > > For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the > machines need to have the same server ticket. > See https://github.com/apache/httpd rev > 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (TS-2352) new_IOBufferData_internal() can't be used outside of event threads.
[
https://issues.apache.org/jira/browse/TS-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yunkai Zhang closed TS-2352.
Resolution: Fixed
> new_IOBufferData_internal() can't be used outside of event threads.
> ---
>
> Key: TS-2352
> URL: https://issues.apache.org/jira/browse/TS-2352
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.2.0
>
> Attachments: 0001-TS-2352-refine-THREAD_ALLOC-feature.patch
>
>
> My coworkers([~weijin] and [~happy_fish100]) are merging the code of cluster
> refine to master branch.
> But they found that new_IOBufferData_internal() in the new cluster threads
> are crashing after merged into master branch.
> The reason is that new_IOBufferData_internal() was changed by this commit:
> {code}
> commit 052da6724140c1a4721c5cf3f9b64810abb8
> Author: Bryan Call
> Date: Mon Jun 17 14:13:07 2013 -0700
> TS-1684 - Added more ProxyAllocators for faster and local memory
> allocation. Have seen a doubling in performance depending on the
> benchmark.
> Details in the ticket.
> ...
> @@ -352,7 +352,7 @@ new_IOBufferBlock_internal(
> #endif
>)
> {
> - IOBufferBlock *b = ioBlockAllocator.alloc();
> + IOBufferBlock *b = THREAD_ALLOC(ioBlockAllocator, this_ethread());
> ...
> }
> {code}
> After this commit, new_IOBufferData_internal() depends on *event threads* and
> can't be used by other normal threads.
> I'm going to refine this function.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2401) use Layout instead of system_config_directory
[
https://issues.apache.org/jira/browse/TS-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840971#comment-13840971
]
ASF subversion and git services commented on TS-2401:
-
Commit a1162d8368a3f6a3401a31983ac90181f5a11782 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a1162d8 ]
TS-2401: Add RecConfigReadLogDir() to wrap proxy.config.log.logfile_dir access
> use Layout instead of system_config_directory
> -
>
> Key: TS-2401
> URL: https://issues.apache.org/jira/browse/TS-2401
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2401.diff
>
>
> The global {{char system_config_directory[]}} makes it hard to link
> additional programs. We should be able to be replace all usages of this with
> the Layout API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2401) use Layout instead of system_config_directory
[
https://issues.apache.org/jira/browse/TS-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840973#comment-13840973
]
ASF subversion and git services commented on TS-2401:
-
Commit a514c64a35bebdd29237e73c6844604b77cd9a95 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=a514c64 ]
TS-2401: update CHANGES
> use Layout instead of system_config_directory
> -
>
> Key: TS-2401
> URL: https://issues.apache.org/jira/browse/TS-2401
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2401.diff
>
>
> The global {{char system_config_directory[]}} makes it hard to link
> additional programs. We should be able to be replace all usages of this with
> the Layout API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2401) use Layout instead of system_config_directory
[
https://issues.apache.org/jira/browse/TS-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840969#comment-13840969
]
ASF subversion and git services commented on TS-2401:
-
Commit 67306a71da65f135ff85c2f4d9b966122fa5590a in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=67306a7 ]
TS-2401: Remove system_config_directory
Remove all the places the global system_config_directory is used,
replacing it with Layout::get()->sysconfdir where appropriate.
> use Layout instead of system_config_directory
> -
>
> Key: TS-2401
> URL: https://issues.apache.org/jira/browse/TS-2401
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2401.diff
>
>
> The global {{char system_config_directory[]}} makes it hard to link
> additional programs. We should be able to be replace all usages of this with
> the Layout API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2401) use Layout instead of system_config_directory
[
https://issues.apache.org/jira/browse/TS-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840970#comment-13840970
]
ASF subversion and git services commented on TS-2401:
-
Commit b6288c446f65d48f047af8b57991d41203e4f2c0 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b6288c4 ]
TS-2401: Remove cache_system_config_directory
Remove the global cache_system_config_directory array. It was only
really being used for an error message. The only real place where
it could have been use already used Layout::sysconfdir.
> use Layout instead of system_config_directory
> -
>
> Key: TS-2401
> URL: https://issues.apache.org/jira/browse/TS-2401
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2401.diff
>
>
> The global {{char system_config_directory[]}} makes it hard to link
> additional programs. We should be able to be replace all usages of this with
> the Layout API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2401) use Layout instead of system_config_directory
[
https://issues.apache.org/jira/browse/TS-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840972#comment-13840972
]
ASF subversion and git services commented on TS-2401:
-
Commit ccc01b66370d4f617b8685b6ba755188344cc215 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ccc01b6 ]
TS-2401: update records.config layout documentation
> use Layout instead of system_config_directory
> -
>
> Key: TS-2401
> URL: https://issues.apache.org/jira/browse/TS-2401
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup, Core
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.2.0
>
> Attachments: TS-2401.diff
>
>
> The global {{char system_config_directory[]}} makes it hard to link
> additional programs. We should be able to be replace all usages of this with
> the Layout API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2352) new_IOBufferData_internal() can't be used outside of event threads.
[
https://issues.apache.org/jira/browse/TS-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840961#comment-13840961
]
Leif Hedstrom commented on TS-2352:
---
So this looks like it's finished? I'm marking this as 4.2.0, please close if
it's done.
> new_IOBufferData_internal() can't be used outside of event threads.
> ---
>
> Key: TS-2352
> URL: https://issues.apache.org/jira/browse/TS-2352
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.2.0
>
> Attachments: 0001-TS-2352-refine-THREAD_ALLOC-feature.patch
>
>
> My coworkers([~weijin] and [~happy_fish100]) are merging the code of cluster
> refine to master branch.
> But they found that new_IOBufferData_internal() in the new cluster threads
> are crashing after merged into master branch.
> The reason is that new_IOBufferData_internal() was changed by this commit:
> {code}
> commit 052da6724140c1a4721c5cf3f9b64810abb8
> Author: Bryan Call
> Date: Mon Jun 17 14:13:07 2013 -0700
> TS-1684 - Added more ProxyAllocators for faster and local memory
> allocation. Have seen a doubling in performance depending on the
> benchmark.
> Details in the ticket.
> ...
> @@ -352,7 +352,7 @@ new_IOBufferBlock_internal(
> #endif
>)
> {
> - IOBufferBlock *b = ioBlockAllocator.alloc();
> + IOBufferBlock *b = THREAD_ALLOC(ioBlockAllocator, this_ethread());
> ...
> }
> {code}
> After this commit, new_IOBufferData_internal() depends on *event threads* and
> can't be used by other normal threads.
> I'm going to refine this function.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2352) new_IOBufferData_internal() can't be used outside of event threads.
[
https://issues.apache.org/jira/browse/TS-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2352:
--
Fix Version/s: 4.2.0
> new_IOBufferData_internal() can't be used outside of event threads.
> ---
>
> Key: TS-2352
> URL: https://issues.apache.org/jira/browse/TS-2352
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.2.0
>
> Attachments: 0001-TS-2352-refine-THREAD_ALLOC-feature.patch
>
>
> My coworkers([~weijin] and [~happy_fish100]) are merging the code of cluster
> refine to master branch.
> But they found that new_IOBufferData_internal() in the new cluster threads
> are crashing after merged into master branch.
> The reason is that new_IOBufferData_internal() was changed by this commit:
> {code}
> commit 052da6724140c1a4721c5cf3f9b64810abb8
> Author: Bryan Call
> Date: Mon Jun 17 14:13:07 2013 -0700
> TS-1684 - Added more ProxyAllocators for faster and local memory
> allocation. Have seen a doubling in performance depending on the
> benchmark.
> Details in the ticket.
> ...
> @@ -352,7 +352,7 @@ new_IOBufferBlock_internal(
> #endif
>)
> {
> - IOBufferBlock *b = ioBlockAllocator.alloc();
> + IOBufferBlock *b = THREAD_ALLOC(ioBlockAllocator, this_ethread());
> ...
> }
> {code}
> After this commit, new_IOBufferData_internal() depends on *event threads* and
> can't be used by other normal threads.
> I'm going to refine this function.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2210) add API to get access to the client cert in the SSL Net VC
[ https://issues.apache.org/jira/browse/TS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840957#comment-13840957 ] Leif Hedstrom commented on TS-2210: --- [~bcall] Shall we close this as a dupe of TS-1584 ? > add API to get access to the client cert in the SSL Net VC > -- > > Key: TS-2210 > URL: https://issues.apache.org/jira/browse/TS-2210 > Project: Traffic Server > Issue Type: Improvement > Components: SSL, TS API >Reporter: Bryan Call > > In SSLNetVConnection SSL_get_peer_certificate(ssl) is called and client_cert > is set. There is a request from Brian France to get access to the client > cert. > He wants to be able to call X509_NAME_oneline(), X509_get_subject_name(), and > X509_get_issuer_name() on the cert. > Where the cert is set in the code: > iocore/net/SSLNetVConnection.cc:499:client_cert = > SSL_get_peer_certificate(ssl); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840954#comment-13840954
]
Leif Hedstrom commented on TS-2406:
---
Impossible to tell. Maybe something wrong in your SSL configuration? You'll
have to try to run traffic_server under gdb with Diagnostics on to get some
more information.
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840952#comment-13840952
]
Leif Hedstrom commented on TS-2305:
---
See e.g. TS-952
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
> Fix For: sometime
>
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
> Note: the host.db file keeps its 0 bytes size all the time
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2356) Add better way to show error messages in traffic_top
[ https://issues.apache.org/jira/browse/TS-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2356: -- Fix Version/s: 5.0.0 > Add better way to show error messages in traffic_top > > > Key: TS-2356 > URL: https://issues.apache.org/jira/browse/TS-2356 > Project: Traffic Server > Issue Type: Improvement > Components: Management >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 5.0.0 > > > When stats can't be found, in earlier versions, traffic_top would assert(). > I remove the asserts, but it would be nice to show error messages for knowing > there is a problem. > One thought I had was to display the error in the status/menu bar on the > bottom of the page. > Also, James though it was harsh to abort() if curl can't fetch the stats url, > so this can also be converted over to display an error. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2305:
--
Fix Version/s: sometime
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
> Fix For: sometime
>
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
> Note: the host.db file keeps its 0 bytes size all the time
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840951#comment-13840951
]
Leif Hedstrom commented on TS-2305:
---
Hmmm, so it's unsupported to run without HostDB. I'm not positive what is
happening here, but can you try with a config, even a minimal HostDB ?
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
> Note: the host.db file keeps its 0 bytes size all the time
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2358) DNS does not fail-over promptly for DNS server returning SERVFAIL
[ https://issues.apache.org/jira/browse/TS-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2358: -- Fix Version/s: sometime > DNS does not fail-over promptly for DNS server returning SERVFAIL > - > > Key: TS-2358 > URL: https://issues.apache.org/jira/browse/TS-2358 > Project: Traffic Server > Issue Type: Bug > Components: DNS >Affects Versions: 3.2.5 >Reporter: William Bardwell > Fix For: sometime > > Attachments: ats.dns.txt > > > If I have 2 dns servers listed in my resolv.conf and the first one is > returning SERVFAIL for something that I try to lookup, ATS takes a long time > to fail over, and won't do it for the first request to look something up. > Using normal system commands (host, ping etc.) with the same resolv.conf work > fine. > I tried various config values with out much improvement. I could make it > fail in 40sec instead of 60sec for the initial failure... > debug logs will be attached, doing one DNS and then waiting a while and doing > another. (Doing more before enough time has passed don't seem to help much.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2305) trafficserver restarts with !t_state.host_db_info.reverse_dns assert
[
https://issues.apache.org/jira/browse/TS-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2305:
--
Labels: crash (was: )
> trafficserver restarts with !t_state.host_db_info.reverse_dns assert
>
>
> Key: TS-2305
> URL: https://issues.apache.org/jira/browse/TS-2305
> Project: Traffic Server
> Issue Type: Bug
> Components: DNS
>Reporter: Sjaak Westdijk
> Labels: crash
>
> Running ATS 4.0.1 on OmniOS we observing a couple trafffic_server restarts on
> busy moments. At that time cpu load peakes and the system client throughput
> peakes to 1000Mbits. The messages in the system log are:
> FATAL: HttpSM.cc:2048: failed assert `!t_state.host_db_info.reverse_dns`
> and
> FATAL: HttpSM.cc:2049: failed assert`ats_is_ip(t_state.host_db_info.ip())`
> On the restart this in the diag.log
> {noformat}
> [Oct 29 12:03:21.892] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:21.954] Server {0x1} NOTE: ip_allow.config updated, reloading
> [Oct 29 12:03:21.980] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:21.980] Server {0x1} WARNING: header missing/corrupt:
> [hostdb.config] : reinitializing database
> [Oct 29 12:03:21.980] Server {0x1} NOTE: reconfiguring host database
> [Oct 29 12:03:21.981] Server {0x1} WARNING: unable to set file
> '/opt/ts/var/trafficserver/host.db' size to 25935872: 22, Invalid argument
> [Oct 29 12:03:22.019] Server {0x1} NOTE: cache clustering disabled
> [Oct 29 12:03:22.021] Server {0x1} NOTE: logging initialized[15],
> logging_mode = 3
> [Oct 29 12:05:10.011] Server {0x1} NOTE: traffic server running
> [Oct 29 12:05:26.915] Server {0x6} NOTE: cache enabled
> {noformat}
> This in the manager.log
> {noformat}
> [Oct 29 12:03:19.711] Manager {0x1} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
> Abort
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: [Alarms::signalAlarm] Server
> Process was reset
> [Oct 29 12:03:19.718] Manager {0x1} ERROR: (last system error 2: No such
> file or directory)
> [Oct 29 12:03:20.724] Manager {0x1} NOTE: [LocalManager::startProxy]
> Launching ts process
> [Oct 29 12:03:20.745] Manager {0x1} NOTE:
> [LocalManager::pollMgmtProcessServer] New process connecting fd '12'
> [Oct 29 12:03:20.745] Manager {0x1} NOTE: [Alarms::signalAlarm] Server
> Process born
> {noformat}
> This is the dns config in records.config
> {noformat}
> CONFIG proxy.config.dns.search_default_domains INT 0
> CONFIG proxy.config.dns.splitDNS.enabled INT 0
> CONFIG proxy.config.dns.max_dns_in_flight INT 2048
># Additional URL expansions for http DNS lookup
> CONFIG proxy.config.dns.url_expansions STRING NULL
> CONFIG proxy.config.dns.round_robin_nameservers INT 0
> CONFIG proxy.config.dns.nameservers STRING 127.0.0.1
> CONFIG proxy.config.dns.resolv_conf STRING /etc/resolv.conf
># This provides additional resilience against DNS forgery, particularly in
># forward or transparent proxies, but requires that the resolver populates
># the queries section of the response properly.
> CONFIG proxy.config.dns.validate_query_name INT 0
> {noformat}
> We are running a local dns server which is actually a forwarding server with
> a blockingzone for botnet sites.
> Note: the host.db file keeps its 0 bytes size all the time
>
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2411) TS Http byte get functions does not return the true number, for server response body byte get
[ https://issues.apache.org/jira/browse/TS-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2411: -- Fix Version/s: 4.2.0 > TS Http byte get functions does not return the true number, for server > response body byte get > - > > Key: TS-2411 > URL: https://issues.apache.org/jira/browse/TS-2411 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Reporter: Roee Gil >Assignee: Brian Geffon > Fix For: 4.2.0 > > > When using the example of null-transform, adding TS_EVENT_HTTP_TXN_CLOSE to > hooks, and counting byte number, I get: > // server -> proxy > TSHttpTxnServerRespHdrBytesGet(txnDB); > TSHttpTxnServerRespBodyBytesGet(txnDB); > // proxy -> client > TSHttpTxnClientRespHdrBytesGet(txnDB); > TSHttpTxnClientRespBodyBytesGet(txnDB); > 1. server side response body = 0 > 2. client side response body = (payload size) > when inspecting this issue, it seems that VConnection is downloading the > content but, this does not count in server response byte get -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2362: -- Fix Version/s: 4.2.0 > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 4.2.0 > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840948#comment-13840948 ] Leif Hedstrom commented on TS-2362: --- Marking this for v4.2.0 for now. > Backwards cache compatibility for 4.X (read 3.2) > > > Key: TS-2362 > URL: https://issues.apache.org/jira/browse/TS-2362 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Reporter: Alan M. Carroll >Assignee: Alan M. Carroll > Fix For: 4.2.0 > > > Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (TS-2420) Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK
[ https://issues.apache.org/jira/browse/TS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Sorber closed TS-2420. --- Resolution: Done > Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those > continuations in ET_TASK > - > > Key: TS-2420 > URL: https://issues.apache.org/jira/browse/TS-2420 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 4.2.0 > > > STAT_SYNC, CONF_SYNC, and REM_SYNC threads are for simple tasks that run in a > while (true) loop with a sleep that would more cleanly run in the ET_TASK > threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2420) Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK
[ https://issues.apache.org/jira/browse/TS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840915#comment-13840915 ] ASF subversion and git services commented on TS-2420: - Commit 853722820d0b36a540ae1ee069e73fbbcc488fc4 in branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8537228 ] TS-2420: Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK > Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those > continuations in ET_TASK > - > > Key: TS-2420 > URL: https://issues.apache.org/jira/browse/TS-2420 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 4.2.0 > > > STAT_SYNC, CONF_SYNC, and REM_SYNC threads are for simple tasks that run in a > while (true) loop with a sleep that would more cleanly run in the ET_TASK > threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2394) We need a performance tuning document
[ https://issues.apache.org/jira/browse/TS-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840908#comment-13840908 ] Leif Hedstrom commented on TS-2394: --- [~i.galic] Do we close this, or leave it open ? > We need a performance tuning document > - > > Key: TS-2394 > URL: https://issues.apache.org/jira/browse/TS-2394 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Igor Galić > Fix For: Docs > > > Traffic Server is a complex beast, we need a document that unifies and > links-back to all the different options that have an affect on its > performance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2414) cluster crash with ats 4.0.1
[ https://issues.apache.org/jira/browse/TS-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2414: -- Labels: crash (was: ) > cluster crash with ats 4.0.1 > > > Key: TS-2414 > URL: https://issues.apache.org/jira/browse/TS-2414 > Project: Traffic Server > Issue Type: Bug > Components: Clustering >Reporter: mailbaoer > Labels: crash > > my ats version is 4.0.1.when I use the cluster mode for ablout a week,one > node crashed,the traffic.out as follows: > [E. Mgmt] log ==> [TrafficManager] using root directory > '/opt/cdn/trafficserver' > [TrafficServer] using root directory '/opt/cdn/trafficserver' > NOTE: Traffic Server received Sig 11: Segmentation fault > /opt/cdn/trafficserver/bin/traffic_server - STACK TRACE: > /lib64/libpthread.so.0[0x3e5b40f500] > /opt/cdn/trafficserver/bin/traffic_server(ClusterVConnection::do_io_close(int)+0x94)[0x624fd4] > /opt/cdn/trafficserver/bin/traffic_server(VConnection::do_io(int, > Continuation*, long, MIOBuffer*, int)+0x7b)[0x5eeb5b] > /opt/cdn/trafficserver/bin/traffic_server(HttpCacheSM::close_read()+0x61)[0x537501] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::perform_cache_write_action()+0x352)[0x531912] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::handle_api_return()+0x430)[0x5353c0] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x2b0)[0x52b4e0] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x8b)[0x5314ab] > /opt/cdn/trafficserver/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8684] > /opt/cdn/trafficserver/libexec/header_filter.so(+0x2d4d)[0x2b6e24522d4d] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x116)[0x52b346] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::set_next_state()+0x84f)[0x53313f] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53534a] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x2b0)[0x52b4e0] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callback(int, > void*)+0x8b)[0x5314ab] > /opt/cdn/trafficserver/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8684] > /opt/cdn/trafficserver/libexec/header_filter.so(+0x2d4d)[0x2b6e24522d4d] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_api_callout(int, > void*)+0x116)[0x52b346] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::state_read_server_response_header(int, > void*)+0x398)[0x52eb28] > /opt/cdn/trafficserver/bin/traffic_server(HttpSM::main_handler(int, > void*)+0xd8)[0x5312b8] > /opt/cdn/trafficserver/bin/traffic_server[0x68006b] > /opt/cdn/trafficserver/bin/traffic_server[0x682a04] > /opt/cdn/trafficserver/bin/traffic_server(NetHandler::mainNetEvent(int, > Event*)+0x1f2)[0x67b642] > /opt/cdn/trafficserver/bin/traffic_server(EThread::process_event(Event*, > int)+0x8f)[0x6a30af] > /opt/cdn/trafficserver/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3a93] > /opt/cdn/trafficserver/bin/traffic_server[0x6a1f4a] > /lib64/libpthread.so.0[0x3e5b407851] > /lib64/libc.so.6(clone+0x6d)[0x3e5b0e890d] > [E. Mgmt] log ==> [TrafficManager] using root directory > '/opt/cdn/trafficserver' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bettydramit closed TS-2378.
---
Resolution: Fixed
same as TS-1547
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840909#comment-13840909
]
Neddy commented on TS-2406:
---
This is syslog
~# tail /var/log/syslog -n 50 | grep traffic
Dec 5 21:40:09 deimos traffic_manager[1538]: {0x7f30df399720} ERROR:
[Alarms::signalAlarm] Server Process was reset
Dec 5 21:40:11 deimos traffic_server[1585]: NOTE: --- Server Starting ---
Dec 5 21:40:11 deimos traffic_server[1585]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 4.1.2 - (build # 1168 on Dec 6 2013 at
08:59:38)
Dec 5 21:40:45 deimos traffic_server[1585]: {0x2af4494a8700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Dec 5 21:40:45 deimos traffic_server[1585]: {0x2af4494a8700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Dec 5 21:40:45 deimos traffic_server[1585]: {0x2af4494a8700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Dec 5 21:40:45 deimos traffic_server[1585]: {0x2af4494a8700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO error:
Connection reset by peer
Dec 5 21:41:41 deimos kernel: [3952337.327367] [ET_SSL 0][1592]: segfault at
8048 ip 00678b06 sp 2af4494a77d0 error 4 in
traffic_server[40+36]
Dec 5 21:41:41 deimos traffic_manager[1538]: {0x7f30df399720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Dec 5 21:41:41 deimos traffic_manager[1538]: {0x7f30df399720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Dec 5 21:41:41 deimos traffic_manager[1538]: {0x7f30df399720} ERROR:
(last system error 32: Broken pipe)
Dec 5 21:41:41 deimos traffic_cop[1126]: cop received child status signal
[1538 256]
Dec 5 21:41:41 deimos traffic_cop[1126]: traffic_manager not running, making
sure traffic_server is dead
Dec 5 21:41:41 deimos traffic_cop[1126]: spawning traffic_manager
Dec 5 21:41:41 deimos traffic_manager[1616]: NOTE: --- Manager Starting ---
Dec 5 21:41:41 deimos traffic_manager[1616]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 4.1.2 - (build # 1168 on Dec 6 2013 at
08:56:57)
Dec 5 21:41:41 deimos traffic_manager[1616]: NOTE:
RLIMIT_NOFILE(7):cur(3),max(3)
Dec 5 21:41:43 deimos traffic_server[1627]: NOTE: --- Server Starting ---
Dec 5 21:41:43 deimos traffic_server[1627]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 4.1.2 - (build # 1168 on Dec 6 2013 at
08:59:38)
Dec 5 21:43:05 deimos kernel: [3952421.691348] [ET_SSL 0][1634]: segfault at
8048 ip 00678b06 sp 2b040552e7d0 error 4 in
traffic_server[40+36]
Dec 5 21:43:05 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 11:
Segmentation fault
Dec 5 21:43:05 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
[Alarms::signalAlarm] Server Process was reset
Dec 5 21:43:07 deimos traffic_server[1660]: NOTE: --- Server Starting ---
Dec 5 21:43:07 deimos traffic_server[1660]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 4.1.2 - (build # 1168 on Dec 6 2013 at
08:59:38)
Dec 5 21:44:22 deimos kernel: [3952498.878321] [ET_SSL 0][1667]: segfault at
8048 ip 00678b06 sp 2b73bc7617d0 error 4 in
traffic_server[40+36]
Dec 5 21:44:22 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 11:
Segmentation fault
Dec 5 21:44:22 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
[Alarms::signalAlarm] Server Process was reset
Dec 5 21:44:24 deimos traffic_server[1831]: NOTE: --- Server Starting ---
Dec 5 21:44:24 deimos traffic_server[1831]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 4.1.2 - (build # 1168 on Dec 6 2013 at
08:59:38)
Dec 5 21:45:29 deimos traffic_server[1831]: {0x2b5eb04c4700} ERROR:
SSL::3:error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337
Dec 5 21:45:29 deimos traffic_server[1831]: {0x2b5eb04c4700} ERROR:
[SSL_NetVConnection::ssl_read_from_net]
Dec 5 21:45:52 deimos kernel: [3952588.626124] [ET_SSL 0][1838]: segfault at
8048 ip 00678b06 sp 2b5eb04c37d0 error 4 in
traffic_server[40+36]
Dec 5 21:45:52 deimos traffic_manager[1616]: {0x7fc00487a720} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Dec 5 21:45:52 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Dec 5 21:45:52 deimos traffic_manager[1616]: {0x7fc00487a720} ERROR:
(last system error 32: Broken pipe)
Dec 5 21:45:52 deimos traffic_cop[1126]: cop received child status signal
[1616 2
[jira] [Assigned] (TS-2354) improve documentation about different type of timeouts
[ https://issues.apache.org/jira/browse/TS-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2354: - Assignee: Leif Hedstrom > improve documentation about different type of timeouts > -- > > Key: TS-2354 > URL: https://issues.apache.org/jira/browse/TS-2354 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Daniel Vitor Morilha >Assignee: Leif Hedstrom > Fix For: Docs > > > Traffic Server provides different types of timeouts: > - dns > - connect > - no activity > - active > I found no documentation about the timeouts, specially no activity and active. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2354) improve documentation about different type of timeouts
[ https://issues.apache.org/jira/browse/TS-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2354: -- Fix Version/s: Docs > improve documentation about different type of timeouts > -- > > Key: TS-2354 > URL: https://issues.apache.org/jira/browse/TS-2354 > Project: Traffic Server > Issue Type: Task > Components: Documentation >Reporter: Daniel Vitor Morilha > Fix For: Docs > > > Traffic Server provides different types of timeouts: > - dns > - connect > - no activity > - active > I found no documentation about the timeouts, specially no activity and active. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2344: -- Fix Version/s: sometime > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie > Fix For: sometime > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.ext
[jira] [Updated] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2344: -- Assignee: Bryan Call > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie >Assignee: Bryan Call > Fix For: sometime > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended
[jira] [Updated] (TS-2394) We need a performance tuning document
[ https://issues.apache.org/jira/browse/TS-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2394: -- Fix Version/s: Docs > We need a performance tuning document > - > > Key: TS-2394 > URL: https://issues.apache.org/jira/browse/TS-2394 > Project: Traffic Server > Issue Type: Bug > Components: Documentation >Reporter: Igor Galić > Fix For: Docs > > > Traffic Server is a complex beast, we need a document that unifies and > links-back to all the different options that have an affect on its > performance. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2344) 404 error was logged while url redirect request was processed corrctly
[ https://issues.apache.org/jira/browse/TS-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840906#comment-13840906 ] Leif Hedstrom commented on TS-2344: --- [~bcall] Bryan, is this a Yahoo issue? Would yoiu mind taking a look at this ? It's not clear to me what the issue is, or if it it is an issue :). > 404 error was logged while url redirect request was processed corrctly > -- > > Key: TS-2344 > URL: https://issues.apache.org/jira/browse/TS-2344 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Eddie > Fix For: sometime > > > I am seeing a lot of entries in the error log for my url redirect request. > The request was processed correctly and I could see the expected response in > log as below: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed in the error log too, which > generates a lot of error logs (log rotation configured) and filling up disk > space pretty fast. > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 (also checked with I am seeing a lot of entries in > the error log for my url redirect request. The request was processed correctly > I could see the expected response in log as well: > 2013-11-08 18:23:37 301 FIN http://yahoo.com > http://www.yahoo.com/ > But log messages like following were printed too: > 20131108.18h23m37s RESPONSE: sent status 404 (Not Found on > Accelerator) for 'http:///' > 20131108.18h23m37s RESPONSE: sent status 301 (Redirect) > for 'http:///' > I watched my tcpdump log and did not see that the 404 error was sent out at > all. I am using ATS/3.2.4 and following > is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.log.extended2_log_enabled INT 0 > CONFIG proxy.config.log.extended2_log_is_ascii INT 1 > CONFIG proxy.config.log.extended2_log_name STRING extended2 > CONFIG proxy.config.log.extended2_log_header STRING NULL > CONFIG proxy.config.log.separate_icp_logs INT 0 > CONFIG proxy.config.log.separate_host_logs INT 0 > Is this a bug or is this a misconfiguration? Does anyone have any idea?) and > following is the log configuration. > CONFIG proxy.config.log.logging_enabled INT 3 > CONFIG proxy.config.log.max_secs_per_buffer INT 1 > CONFIG proxy.config.log.max_space_mb_for_logs INT 25000 > CONFIG proxy.config.log.max_space_mb_for_orphan_logs INT 25 > CONFIG proxy.config.log.max_space_mb_headroom INT 1000 > CONFIG proxy.config.log.hostname STRING localhost > CONFIG proxy.config.log.logfile_dir STRING var/log/trafficserver > CONFIG proxy.config.log.logfile_perm STRING rw-r--r-- > CONFIG proxy.config.log.custom_logs_enabled INT 1 > CONFIG proxy.config.log.squid_log_enabled INT 0 > CONFIG proxy.config.log.squid_log_is_ascii INT 0 > CONFIG proxy.config.log.squid_log_name STRING squid > CONFIG proxy.config.log.squid_log_header STRING NULL > CONFIG proxy.config.log.common_log_enabled INT 0 > CONFIG proxy.config.log.common_log_is_ascii INT 1 > CONFIG proxy.config.log.common_log_name STRING common > CONFIG proxy.config.log.common_log_header STRING NULL > CONFIG proxy.config.log.extended_log_enabled INT 0 > CONFIG proxy.config.log.extended_log_is_ascii INT 0 > CONFIG proxy.config.log.extended_log_name STRING extended > CONFIG proxy.config.log.extended_log_header STRING NULL > CONFIG proxy.config.l
[jira] [Assigned] (TS-2342) problem with cache.cache_responses_to_cookies value 0
[
https://issues.apache.org/jira/browse/TS-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-2342:
-
Assignee: Leif Hedstrom
> problem with cache.cache_responses_to_cookies value 0
> -
>
> Key: TS-2342
> URL: https://issues.apache.org/jira/browse/TS-2342
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Configuration
>Reporter: Paul Marquess
>Assignee: Leif Hedstrom
> Fix For: 4.2.0
>
>
> I’m attempting to configure TS (3.2.0 but the issue seems to be present in
> 4.0.2 as well) to disable caching for all content where a cookie is present.
> Setting cache.cache_responses_to_cookies to 0 looks like it should do that
> according to the comment in records.config
># cache responses to cookies has 5 options:
># 0 - do not cache any responses to cookies
># 1 - cache for any content-type
># 2 - cache only for image types
># 3 - cache for all but text content-types
># 4 - cache for all but text content-types except OS response
># without "Set-Cookie" or with "Cache-Control: public"
># See also cache-responses-to-cookies in cache.config.
> CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
> Unfortunately when I set cache.cache_responses_to_cookies to 0 in
> records.config I don’t see anything written to the cache at all.
> Am I correct in assuming that cache.cache_responses_to_cookies is intended to
> influence the caching of content only when a cookie is in play? So the
> behaviour I’m seeing is wrong?
> Looking in do_cookiesprevent_caching in HttpTransact.cc it looks like the
> test for the 0 use case (COOKIES_CACHE_NONE) is done too early. Below is the
> code
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> I don’t see any other tests in the code that check for cookies that would be
> triggered before do_cookiesprevent_caching is invoked, so surely the
> COOKIES_CACHE_NONE test needs to be done after the presence of cookies
> headers has been determined?
> So the code would become
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> // Know we have a cookie present at this point
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> // and cookie detected
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2342) problem with cache.cache_responses_to_cookies value 0
[
https://issues.apache.org/jira/browse/TS-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2342:
--
Fix Version/s: 4.2.0
> problem with cache.cache_responses_to_cookies value 0
> -
>
> Key: TS-2342
> URL: https://issues.apache.org/jira/browse/TS-2342
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Configuration
>Reporter: Paul Marquess
> Fix For: 4.2.0
>
>
> I’m attempting to configure TS (3.2.0 but the issue seems to be present in
> 4.0.2 as well) to disable caching for all content where a cookie is present.
> Setting cache.cache_responses_to_cookies to 0 looks like it should do that
> according to the comment in records.config
># cache responses to cookies has 5 options:
># 0 - do not cache any responses to cookies
># 1 - cache for any content-type
># 2 - cache only for image types
># 3 - cache for all but text content-types
># 4 - cache for all but text content-types except OS response
># without "Set-Cookie" or with "Cache-Control: public"
># See also cache-responses-to-cookies in cache.config.
> CONFIG proxy.config.http.cache.cache_responses_to_cookies INT 1
> Unfortunately when I set cache.cache_responses_to_cookies to 0 in
> records.config I don’t see anything written to the cache at all.
> Am I correct in assuming that cache.cache_responses_to_cookies is intended to
> influence the caching of content only when a cookie is in play? So the
> behaviour I’m seeing is wrong?
> Looking in do_cookiesprevent_caching in HttpTransact.cc it looks like the
> test for the 0 use case (COOKIES_CACHE_NONE) is done too early. Below is the
> code
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> I don’t see any other tests in the code that check for cookies that would be
> triggered before do_cookiesprevent_caching is invoked, so surely the
> COOKIES_CACHE_NONE test needs to be done after the presence of cookies
> headers has been determined?
> So the code would become
> // Can cache all regardless of cookie header - just ignore all cookie
> headers
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_ALL) {
> return false;
> }
> ...
> if (!response->presence(MIME_PRESENCE_SET_COOKIE) &&
> !request->presence(MIME_PRESENCE_COOKIE) && (cached_request == NULL
>||
> !cached_request->presence(MIME_PRESENCE_COOKIE))) {
> return false;
> }
> // Know we have a cookie present at this point
> // Do not cache if cookies option is COOKIES_CACHE_NONE
> // and cookie detected
> if ((CookiesConfig) cookies_conf == COOKIES_CACHE_NONE) {
> return true;
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840902#comment-13840902
]
Leif Hedstrom commented on TS-2378:
---
Cool, can you close this as a dupe of TS-1547 please ?
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-1411) Seg fault when using %
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-1411:
-
Attachment: cquuc segfault patch.txt
> Seg fault when using %
> -
>
> Key: TS-1411
> URL: https://issues.apache.org/jira/browse/TS-1411
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: RHEL 6.2 x86_64
>Reporter: David Carlin
>Assignee: Yunkai Zhang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt, cquuc
> segfault patch.txt
>
>
> I've been experiencing some segfaults during log rotation. The sequence of
> events is this.. log rotation occurs, then I get hundreds of dropping log
> buffer error msgs, then the segfault.
> This started occurring when I lengthened the default log format to include
> the unmapped URL and the user agent string:
> % % % %/% % % % %
> %/% % % % \"%<{User-Agent}cqh>\"
> In terms of frequency, we have a number of boxes and I probably see one of
> these crashed per day since the above change. Logs are rotated every 2 hours.
> I've had other log related segfaults, reported in TS-1330 - these new ones
> seem to have a different cause.
> [Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
> /home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
> was auto-deleted; 3148252 bytes were reclaimed.
> [Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
> /home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
> was auto-deleted; 14735520048 bytes were reclaimed.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [...]
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x383f00f500]
> /home/y/bin/traffic_server(LogAccess::marshal_mem(char*, char const*, int,
> int)+0x48)[0x58a118]
> /home/y/bin/traffic_server(LogAccessHttp::marshal_client_req_url_canon(char*)+0x20)[0x58c3f0]
> /home/y/bin/traffic_server(LogFieldList::marshal(LogAccess*,
> char*)+0x32)[0x59d5a2]
> /home/y/bin/traffic_server(LogObject::log(LogAccess*, char*)+0x399)[0x5a7ed9]
> /home/y/bin/traffic_server(Log::access(LogAccess*)+0x146)[0x58f506]
> /home/y/bin/traffic_server(HttpSM::update_stats()+0x630)[0x526c50]
> /home/y/bin/traffic_server(HttpSM::kill_this()+0x928)[0x52b548]
> /home/y/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x52b868]
> /home/y/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0xde)[0x56c3ee]
> /home/y/bin/traffic_server[0x673871]
> /home/y/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x847)[0x6756e7]
> /home/y/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x286)[0x66e076]
> /home/y/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x696ce4]
> /home/y/bin/traffic_server(EThread::execute()+0x4c3)[0x697673]
> /home/y/bin/traffic_server[0x695cb2]
> /lib64/libpthread.so.0[0x383f007851]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840900#comment-13840900
]
Leif Hedstrom commented on TS-2406:
---
so those messages aren't all that useful. If you look in your syslog
(/var/log/messages probably ?) do you not see a stack trace ? Or do you get a
core file you can run gdb on ?
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840895#comment-13840895
]
Neddy edited comment on TS-2406 at 12/6/13 3:06 AM:
Uploaded traffic.out
was (Author: neddy):
traffic.out
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840897#comment-13840897
]
Neddy edited comment on TS-2406 at 12/6/13 3:04 AM:
This is newly generated in /var/log/messages, traffic.out is attached
Dec 5 21:37:46 deimos kernel: [3952102.967654] [ET_SSL 0][1515]: segfault at
8048 ip 00678b06 sp 2b7825b9a7d0 error 4 in
traffic_server[40+36]
Dec 5 21:40:09 deimos kernel: [3952245.301981] [ET_SSL 0][1556]: segfault at
8048 ip 00678b06 sp 2b03f91457d0 error 4 in
traffic_server[40+36]
Dec 5 21:41:41 deimos kernel: [3952337.327367] [ET_SSL 0][1592]: segfault at
8048 ip 00678b06 sp 2af4494a77d0 error 4 in
traffic_server[40+36]
Dec 5 21:43:05 deimos kernel: [3952421.691348] [ET_SSL 0][1634]: segfault at
8048 ip 00678b06 sp 2b040552e7d0 error 4 in
traffic_server[40+36]
Dec 5 21:44:22 deimos kernel: [3952498.878321] [ET_SSL 0][1667]: segfault at
8048 ip 00678b06 sp 2b73bc7617d0 error 4 in
traffic_server[40+36]
Dec 5 21:45:52 deimos kernel: [3952588.626124] [ET_SSL 0][1838]: segfault at
8048 ip 00678b06 sp 2b5eb04c37d0 error 4 in
traffic_server[40+36]
was (Author: neddy):
This is newly generated logs, traffic.out is attached
Dec 5 21:37:46 deimos kernel: [3952102.967654] [ET_SSL 0][1515]: segfault at
8048 ip 00678b06 sp 2b7825b9a7d0 error 4 in
traffic_server[40+36]
Dec 5 21:40:09 deimos kernel: [3952245.301981] [ET_SSL 0][1556]: segfault at
8048 ip 00678b06 sp 2b03f91457d0 error 4 in
traffic_server[40+36]
Dec 5 21:41:41 deimos kernel: [3952337.327367] [ET_SSL 0][1592]: segfault at
8048 ip 00678b06 sp 2af4494a77d0 error 4 in
traffic_server[40+36]
Dec 5 21:43:05 deimos kernel: [3952421.691348] [ET_SSL 0][1634]: segfault at
8048 ip 00678b06 sp 2b040552e7d0 error 4 in
traffic_server[40+36]
Dec 5 21:44:22 deimos kernel: [3952498.878321] [ET_SSL 0][1667]: segfault at
8048 ip 00678b06 sp 2b73bc7617d0 error 4 in
traffic_server[40+36]
Dec 5 21:45:52 deimos kernel: [3952588.626124] [ET_SSL 0][1838]: segfault at
8048 ip 00678b06 sp 2b5eb04c37d0 error 4 in
traffic_server[40+36]
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840897#comment-13840897
]
Neddy commented on TS-2406:
---
This is newly generated logs, traffic.out is attached
Dec 5 21:37:46 deimos kernel: [3952102.967654] [ET_SSL 0][1515]: segfault at
8048 ip 00678b06 sp 2b7825b9a7d0 error 4 in
traffic_server[40+36]
Dec 5 21:40:09 deimos kernel: [3952245.301981] [ET_SSL 0][1556]: segfault at
8048 ip 00678b06 sp 2b03f91457d0 error 4 in
traffic_server[40+36]
Dec 5 21:41:41 deimos kernel: [3952337.327367] [ET_SSL 0][1592]: segfault at
8048 ip 00678b06 sp 2af4494a77d0 error 4 in
traffic_server[40+36]
Dec 5 21:43:05 deimos kernel: [3952421.691348] [ET_SSL 0][1634]: segfault at
8048 ip 00678b06 sp 2b040552e7d0 error 4 in
traffic_server[40+36]
Dec 5 21:44:22 deimos kernel: [3952498.878321] [ET_SSL 0][1667]: segfault at
8048 ip 00678b06 sp 2b73bc7617d0 error 4 in
traffic_server[40+36]
Dec 5 21:45:52 deimos kernel: [3952588.626124] [ET_SSL 0][1838]: segfault at
8048 ip 00678b06 sp 2b5eb04c37d0 error 4 in
traffic_server[40+36]
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2363) FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
[ https://issues.apache.org/jira/browse/TS-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2363: -- Labels: crash (was: ) > FATAL: Log.h:342: failed assert `!"Unknown file format type!"` > -- > > Key: TS-2363 > URL: https://issues.apache.org/jira/browse/TS-2363 > Project: Traffic Server > Issue Type: Bug >Affects Versions: 4.1.1 >Reporter: bettydramit > Labels: crash > Fix For: 4.2.0 > > > FATAL: Log.h:342: failed assert `!"Unknown file format type!"` > /usr/bin/traffic_server - STACK TRACE: > /usr/lib64/trafficserver/libtsutil.so.4(+0x14778)[0x2add96cb5778] > /usr/lib64/trafficserver/libtsutil.so.4(+0x12c5f)[0x2add96cb3c5f] > /usr/bin/traffic_server(_ZN3Log17flush_thread_mainEPv+0x3d7)[0x589ee7] > /usr/bin/traffic_server(_ZN24LoggingFlushContinuation9mainEventEiPv+0xd)[0x58d82d] > /usr/bin/traffic_server(_ZN7EThread7executeEv+0xc90)[0x6adca0] > /usr/bin/traffic_server[0x6ab96a] > /lib64/libpthread.so.0(+0x7851)[0x2add988ea851] > /lib64/libc.so.6(clone+0x6d)[0x2add998e094d] -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2363) FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
[
https://issues.apache.org/jira/browse/TS-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2363:
--
Description:
{code}
FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x14778)[0x2add96cb5778]
/usr/lib64/trafficserver/libtsutil.so.4(+0x12c5f)[0x2add96cb3c5f]
/usr/bin/traffic_server(Log::flush_thread_main(void*)+0x3d7)[0x589ee7]
/usr/bin/traffic_server(LoggingFlushContinuation::mainEvent(int,
void*)+0xd)[0x58d82d]
/usr/bin/traffic_server(EThread::execute()+0xc90)[0x6adca0]
/usr/bin/traffic_server[0x6ab96a]
/lib64/libpthread.so.0(+0x7851)[0x2add988ea851]
/lib64/libc.so.6(clone+0x6d)[0x2add998e094d]
{code}
was:
FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
/usr/bin/traffic_server - STACK TRACE:
/usr/lib64/trafficserver/libtsutil.so.4(+0x14778)[0x2add96cb5778]
/usr/lib64/trafficserver/libtsutil.so.4(+0x12c5f)[0x2add96cb3c5f]
/usr/bin/traffic_server(_ZN3Log17flush_thread_mainEPv+0x3d7)[0x589ee7]
/usr/bin/traffic_server(_ZN24LoggingFlushContinuation9mainEventEiPv+0xd)[0x58d82d]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0xc90)[0x6adca0]
/usr/bin/traffic_server[0x6ab96a]
/lib64/libpthread.so.0(+0x7851)[0x2add988ea851]
/lib64/libc.so.6(clone+0x6d)[0x2add998e094d]
> FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
> --
>
> Key: TS-2363
> URL: https://issues.apache.org/jira/browse/TS-2363
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.1.1
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> {code}
> FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib64/trafficserver/libtsutil.so.4(+0x14778)[0x2add96cb5778]
> /usr/lib64/trafficserver/libtsutil.so.4(+0x12c5f)[0x2add96cb3c5f]
> /usr/bin/traffic_server(Log::flush_thread_main(void*)+0x3d7)[0x589ee7]
> /usr/bin/traffic_server(LoggingFlushContinuation::mainEvent(int,
> void*)+0xd)[0x58d82d]
> /usr/bin/traffic_server(EThread::execute()+0xc90)[0x6adca0]
> /usr/bin/traffic_server[0x6ab96a]
> /lib64/libpthread.so.0(+0x7851)[0x2add988ea851]
> /lib64/libc.so.6(clone+0x6d)[0x2add998e094d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840896#comment-13840896
]
bettydramit commented on TS-2378:
-
[~zwoop] Looks the same
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2406) Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neddy updated TS-2406:
--
Attachment: traffic.out.bak
traffic.out
> Sig 11: Segmentation fault
> --
>
> Key: TS-2406
> URL: https://issues.apache.org/jira/browse/TS-2406
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.2.0
>Reporter: Neddy
> Labels: crash
> Attachments: traffic.out.bak
>
>
> I've noticed this today, still don't know why
> [Nov 27 21:10:49.280] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> [Nov 28 07:53:42.853] Manager {0x7f54eff15720} ERROR:
> [LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
> 11: Segmentation fault
> How can I trace this?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2363) FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
[
https://issues.apache.org/jira/browse/TS-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2363:
--
Fix Version/s: 4.2.0
> FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
> --
>
> Key: TS-2363
> URL: https://issues.apache.org/jira/browse/TS-2363
> Project: Traffic Server
> Issue Type: Bug
>Affects Versions: 4.1.1
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> {code}
> FATAL: Log.h:342: failed assert `!"Unknown file format type!"`
> /usr/bin/traffic_server - STACK TRACE:
> /usr/lib64/trafficserver/libtsutil.so.4(+0x14778)[0x2add96cb5778]
> /usr/lib64/trafficserver/libtsutil.so.4(+0x12c5f)[0x2add96cb3c5f]
> /usr/bin/traffic_server(Log::flush_thread_main(void*)+0x3d7)[0x589ee7]
> /usr/bin/traffic_server(LoggingFlushContinuation::mainEvent(int,
> void*)+0xd)[0x58d82d]
> /usr/bin/traffic_server(EThread::execute()+0xc90)[0x6adca0]
> /usr/bin/traffic_server[0x6ab96a]
> /lib64/libpthread.so.0(+0x7851)[0x2add988ea851]
> /lib64/libc.so.6(clone+0x6d)[0x2add998e094d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-1411) Seg fault when using %
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840894#comment-13840894
]
David Carlin commented on TS-1411:
--
The following patch written by Sean Cosgrave stabilizes the issue. He made a
point of saying its a band-aid and not a permanent fix however.
{noformat}
--- trafficserver-4.0.2/proxy/logging/LogAccessHttp.cc 2013-10-07
22:02:04.0 +
+++ trafficserver-4.0.2_mod/proxy/logging/LogAccessHttp.cc 2013-11-04
21:27:09.547218218 +
@@ -91,7 +91,9 @@
if (hdr->client_request.valid()) {
m_client_request = &(hdr->client_request);
-m_client_req_url_str =
m_client_request->url_string_get_ref(&m_client_req_url_len);
+char *url_string_ref =
m_client_request->url_string_get_ref(&m_client_req_url_len);
+m_client_req_url_str = (char *) m_arena.str_alloc(m_client_req_url_len +
1);
+ink_strlcpy(m_client_req_url_str, url_string_ref, (m_client_req_url_len +
1));
m_client_req_url_canon_str = LogUtils::escapify_url(&m_arena,
m_client_req_url_str, m_client_req_url_len,
&m_client_req_url_canon_len);
m_client_req_url_path_str =
m_client_request->path_get(&m_client_req_url_path_len);
{noformat}
> Seg fault when using %
> -
>
> Key: TS-1411
> URL: https://issues.apache.org/jira/browse/TS-1411
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.2.0
> Environment: RHEL 6.2 x86_64
>Reporter: David Carlin
>Assignee: Yunkai Zhang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: Log rotation segaults.txt, TS-1411 backtraces.txt
>
>
> I've been experiencing some segfaults during log rotation. The sequence of
> events is this.. log rotation occurs, then I get hundreds of dropping log
> buffer error msgs, then the segfault.
> This started occurring when I lengthened the default log format to include
> the unmapped URL and the user agent string:
> % % % %/% % % % %
> %/% % % % \"%<{User-Agent}cqh>\"
> In terms of frequency, we have a number of boxes and I probably see one of
> these crashed per day since the above change. Logs are rotated every 2 hours.
> I've had other log related segfaults, reported in TS-1330 - these new ones
> seem to have a different cause.
> [Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
> /home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
> was auto-deleted; 3148252 bytes were reclaimed.
> [Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
> /home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
> was auto-deleted; 14735520048 bytes were reclaimed.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [...]
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> [Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
> can't keep up.
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x383f00f500]
> /home/y/bin/traffic_server(LogAccess::marshal_mem(char*, char const*, int,
> int)+0x48)[0x58a118]
> /home/y/bin/traffic_server(LogAccessHttp::marshal_client_req_url_canon(char*)+0x20)[0x58c3f0]
> /home/y/bin/traffic_server(LogFieldList::marshal(LogAccess*,
> char*)+0x32)[0x59d5a2]
> /home/y/bin/traffic_server(LogObject::log(LogAccess*, char*)+0x399)[0x5a7ed9]
> /home/y/bin/traffic_server(Log::access(LogAccess*)+0x146)[0x58f506]
> /home/y/bin/traffic_server(HttpSM::update_stats()+0x630)[0x526c50]
> /home/y/bin/traffic_server(HttpSM::kill_this()+0x928)[0x52b548]
> /home/y/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x52b868]
> /home/y/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0xde)[0x56c3ee]
> /home/y/bin/traffic_server[0x673871]
> /home/y/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x847)[0x6756e7]
> /home/y/bin/traffic_server(NetHandler::mainNetEvent(int,
> Event*)+0x286)[0x66e076]
> /home/y/bin/traffi
[jira] [Commented] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840891#comment-13840891
]
Leif Hedstrom commented on TS-2378:
---
I'm thinking this might be a dupe of TS-1547. [~bettydreamit] Can you check /
verify ?
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2420) Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK
[ https://issues.apache.org/jira/browse/TS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2420: -- Assignee: Phil Sorber > Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those > continuations in ET_TASK > - > > Key: TS-2420 > URL: https://issues.apache.org/jira/browse/TS-2420 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber >Assignee: Phil Sorber > Fix For: 4.2.0 > > > STAT_SYNC, CONF_SYNC, and REM_SYNC threads are for simple tasks that run in a > while (true) loop with a sleep that would more cleanly run in the ET_TASK > threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2420) Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK
[ https://issues.apache.org/jira/browse/TS-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2420: -- Fix Version/s: 4.2.0 > Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those > continuations in ET_TASK > - > > Key: TS-2420 > URL: https://issues.apache.org/jira/browse/TS-2420 > Project: Traffic Server > Issue Type: Improvement >Reporter: Phil Sorber > Fix For: 4.2.0 > > > STAT_SYNC, CONF_SYNC, and REM_SYNC threads are for simple tasks that run in a > while (true) loop with a sleep that would more cleanly run in the ET_TASK > threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TS-2420) Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK
Phil Sorber created TS-2420: --- Summary: Remove STAT_SYNC, CONF_SYNC, and REM_SYNC threads and schedule those continuations in ET_TASK Key: TS-2420 URL: https://issues.apache.org/jira/browse/TS-2420 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber STAT_SYNC, CONF_SYNC, and REM_SYNC threads are for simple tasks that run in a while (true) loop with a sleep that would more cleanly run in the ET_TASK threads. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-1411) Seg fault when using %
[
https://issues.apache.org/jira/browse/TS-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1411:
--
Description:
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include the
unmapped URL and the user agent string:
% % % %/% % % % %
%/% % % % \"%<{User-Agent}cqh>\"
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones seem
to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.876] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x383f00f500]
/home/y/bin/traffic_server(LogAccess::marshal_mem(char*, char const*, int,
int)+0x48)[0x58a118]
/home/y/bin/traffic_server(LogAccessHttp::marshal_client_req_url_canon(char*)+0x20)[0x58c3f0]
/home/y/bin/traffic_server(LogFieldList::marshal(LogAccess*,
char*)+0x32)[0x59d5a2]
/home/y/bin/traffic_server(LogObject::log(LogAccess*, char*)+0x399)[0x5a7ed9]
/home/y/bin/traffic_server(Log::access(LogAccess*)+0x146)[0x58f506]
/home/y/bin/traffic_server(HttpSM::update_stats()+0x630)[0x526c50]
/home/y/bin/traffic_server(HttpSM::kill_this()+0x928)[0x52b548]
/home/y/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x52b868]
/home/y/bin/traffic_server(HttpTunnel::main_handler(int, void*)+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x673871]
/home/y/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x847)[0x6756e7]
/home/y/bin/traffic_server(NetHandler::mainNetEvent(int,
Event*)+0x286)[0x66e076]
/home/y/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x696ce4]
/home/y/bin/traffic_server(EThread::execute()+0x4c3)[0x697673]
/home/y/bin/traffic_server[0x695cb2]
/lib64/libpthread.so.0[0x383f007851]
was:
I've been experiencing some segfaults during log rotation. The sequence of
events is this.. log rotation occurs, then I get hundreds of dropping log
buffer error msgs, then the segfault.
This started occurring when I lengthened the default log format to include the
unmapped URL and the user agent string:
% % % %/% % % % %
%/% % % % \"%<{User-Agent}cqh>\"
In terms of frequency, we have a number of boxes and I probably see one of
these crashed per day since the above change. Logs are rotated every 2 hours.
I've had other log related segfaults, reported in TS-1330 - these new ones seem
to have a different cause.
[Aug 14 21:07:20.002] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/error.log_l30.ycs.a4e.yahoo.com.20120814.17h59m50s-20120814.20h00m00s.old,
was auto-deleted; 3148252 bytes were reclaimed.
[Aug 14 21:07:42.859] Server {0x2ae3a8887700} STATUS: The rolled logfile,
/home/y/logs/trafficserver/squid.blog_l30.ycs.a4e.yahoo.com.20120814.18h00m00s-20120814.20h00m00s.old,
was auto-deleted; 14735520048 bytes were reclaimed.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[Aug 14 21:07:42.865] Server {0x2ae3a8887700} WARNING: Dropping log buffer,
can't keep up.
[...]
[Aug 14 21:07:42.876] S
[jira] [Updated] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2378:
--
Fix Version/s: 4.2.0
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2378:
--
Labels: crash (was: )
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2378:
--
Description:
ats 4.0.1 centos x86_64
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
/lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
/usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
/usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
/usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
/usr/bin/traffic_server(HdrHeap::duplicate_str(char const*, int)+0x5e)[0x5b246e]
/usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
/usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
HTTPHdr*)+0x2de)[0x545c5e]
/usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
/usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
/usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x66)[0x51afb6]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
/usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
/usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
/usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
/usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
/usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
/usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
void*)+0x390)[0x52ef60]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
/usr/bin/traffic_server[0x6805bb]
/usr/bin/traffic_server[0x682f54]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
/usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
/usr/bin/traffic_server[0x6a240a]
/lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
/lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
{code}
was:
ats 4.0.1 centos x86_64
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
/lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
/usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
/usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
/usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
/usr/bin/traffic_server(HdrHeap::duplicate_str(char const*, int)+0x5e)[0x5b246e]
/usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
/usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
HTTPHdr*)+0x2de)[0x545c5e]
/usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
/usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
/usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x66)[0x51afb6]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
/usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
/usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
/usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
/usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
/usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
/usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
void*)+0x390)[0x52ef60]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
/usr/bin/traffic_server[0x6805bb]
/usr/bin/traffic_server[0x682f54]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
/usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
/usr/bin/traffic_server[0x6a240a]
/lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
/lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
>
[jira] [Updated] (TS-2378) merge_response_header_with_cached_header
[
https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2378:
--
Component/s: Core
> merge_response_header_with_cached_header
>
>
> Key: TS-2378
> URL: https://issues.apache.org/jira/browse/TS-2378
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: bettydramit
> Labels: crash
> Fix For: 4.2.0
>
>
> ats 4.0.1 centos x86_64
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500]
> /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895]
> /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a]
> /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3]
> /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e]
> /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*,
> int)+0x5e)[0x5b246e]
> /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*,
> MIMEField*, char const*, int, bool)+0x37)[0x5c0597]
> /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*,
> HTTPHdr*)+0x2de)[0x545c5e]
> /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993]
> /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712]
> /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1]
> /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x66)[0x51afb6]
> /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0]
> /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb]
> /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44]
> /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc]
> /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756]
> /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int,
> void*)+0x390)[0x52ef60]
> /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8]
> /usr/bin/traffic_server[0x6805bb]
> /usr/bin/traffic_server[0x682f54]
> /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92]
> /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f]
> /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53]
> /usr/bin/traffic_server[0x6a240a]
> /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851]
> /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2378) merge_response_header_with_cached_header
[ https://issues.apache.org/jira/browse/TS-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2378: -- Description: ats 4.0.1 centos x86_64 NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500] /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895] /usr/bin/traffic_server(MIMEHdrImpl::move_strings(HdrStrHeap*)+0x8a)[0x5bf29a] /usr/bin/traffic_server(HdrHeap::coalesce_str_heaps(int)+0xd3)[0x5b1cc3] /usr/bin/traffic_server(HdrHeap::allocate_str(int)+0x9e)[0x5b224e] /usr/bin/traffic_server(HdrHeap::duplicate_str(char const*, int)+0x5e)[0x5b246e] /usr/bin/traffic_server(mime_field_value_set(HdrHeap*, MIMEHdrImpl*, MIMEField*, char const*, int, bool)+0x37)[0x5c0597] /usr/bin/traffic_server(HttpTransact::merge_response_header_with_cached_header(HTTPHdr*, HTTPHdr*)+0x2de)[0x545c5e] /usr/bin/traffic_server(HttpTransact::merge_and_update_headers_for_cache_update(HttpTransact::State*)+0xe3)[0x548993] /usr/bin/traffic_server(HttpTransact::handle_cache_operation_on_forward_server_response(HttpTransact::State*)+0x892)[0x555712] /usr/bin/traffic_server(HttpTransact::HandleResponse(HttpTransact::State*)+0x191)[0x5609d1] /usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void (*)(HttpTransact::State*))+0x66)[0x51afb6] /usr/bin/traffic_server(HttpSM::handle_api_return()+0x3ba)[0x53579a] /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x2b0)[0x52b8f0] /usr/bin/traffic_server(HttpSM::state_api_callback(int, void*)+0x8b)[0x5318eb] /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44] /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc] /usr/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x116)[0x52b756] /usr/bin/traffic_server(HttpSM::state_read_server_response_header(int, void*)+0x390)[0x52ef60] /usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5316f8] /usr/bin/traffic_server[0x6805bb] /usr/bin/traffic_server[0x682f54] /usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x67bb92] /usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x6a356f] /usr/bin/traffic_server(EThread::execute()+0x4a3)[0x6a3f53] /usr/bin/traffic_server[0x6a240a] /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851] /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d] was: ats 4.0.1 centos x86_64 NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0(+0xf500)[0x2b98fc525500] /lib64/libc.so.6(memcpy+0x35)[0x2b98fd162895] /usr/bin/traffic_server(_ZN11MIMEHdrImpl12move_stringsEP10HdrStrHeap+0x8a)[0x5bf29a] /usr/bin/traffic_server(_ZN7HdrHeap18coalesce_str_heapsEi+0xd3)[0x5b1cc3] /usr/bin/traffic_server(_ZN7HdrHeap12allocate_strEi+0x9e)[0x5b224e] /usr/bin/traffic_server(_ZN7HdrHeap13duplicate_strEPKci+0x5e)[0x5b246e] /usr/bin/traffic_server(_Z20mime_field_value_setP7HdrHeapP11MIMEHdrImplP9MIMEFieldPKcib+0x37)[0x5c0597] /usr/bin/traffic_server(_ZN12HttpTransact40merge_response_header_with_cached_headerEP7HTTPHdrS1_+0x2de)[0x545c5e] /usr/bin/traffic_server(_ZN12HttpTransact41merge_and_update_headers_for_cache_updateEPNS_5StateE+0xe3)[0x548993] /usr/bin/traffic_server(_ZN12HttpTransact49handle_cache_operation_on_forward_server_responseEPNS_5StateE+0x892)[0x555712] /usr/bin/traffic_server(_ZN12HttpTransact14HandleResponseEPNS_5StateE+0x191)[0x5609d1] /usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x66)[0x51afb6] /usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x3ba)[0x53579a] /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x2b0)[0x52b8f0] /usr/bin/traffic_server(_ZN6HttpSM18state_api_callbackEiPv+0x8b)[0x5318eb] /usr/bin/traffic_server(TSHttpTxnReenable+0x404)[0x4b8d44] /usr/lib64/trafficserver/plugins/localdown.so(+0x2ebdc)[0x2b996c02ebdc] /usr/bin/traffic_server(_ZN6HttpSM17state_api_calloutEiPv+0x116)[0x52b756] /usr/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x390)[0x52ef60] /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x5316f8] /usr/bin/traffic_server[0x6805bb] /usr/bin/traffic_server[0x682f54] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x67bb92] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6a356f] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4a3)[0x6a3f53] /usr/bin/traffic_server[0x6a240a] /lib64/libpthread.so.0(+0x7851)[0x2b98fc51d851] /lib64/libc.so.6(clone+0x6d)[0x2b98fd1c194d] > merge_response_header_with_cached_header > > > Key: TS-2378 > URL: https://issues.apache.org/jira/browse/TS-2378 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: bettydramit > Labels: crash > Fix For: 4.2.0 > > > ats 4.0.1 ce
[jira] [Assigned] (TS-2395) Healthchecks plugin using 100% of CPU
[ https://issues.apache.org/jira/browse/TS-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2395: - Assignee: Leif Hedstrom > Healthchecks plugin using 100% of CPU > - > > Key: TS-2395 > URL: https://issues.apache.org/jira/browse/TS-2395 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: David Carlin >Assignee: Leif Hedstrom > Fix For: 4.2.0 > > > I had configured the healthchecks plugin to serve four healthchecks - they > come in pretty frequently, it can be hundreds per second. Use of the plugin > would peg every core to 100% in htop. Response times for the healthchecks > were often around 4 seconds. > The code from master was used to build the plugin. > perf top output showed the following: > 87.74% [kernel] [k] _spin_lock -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2395) Healthchecks plugin using 100% of CPU
[ https://issues.apache.org/jira/browse/TS-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2395: -- Fix Version/s: 4.2.0 > Healthchecks plugin using 100% of CPU > - > > Key: TS-2395 > URL: https://issues.apache.org/jira/browse/TS-2395 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: David Carlin > Fix For: 4.2.0 > > > I had configured the healthchecks plugin to serve four healthchecks - they > come in pretty frequently, it can be hundreds per second. Use of the plugin > would peg every core to 100% in htop. Response times for the healthchecks > were often around 4 seconds. > The code from master was used to build the plugin. > perf top output showed the following: > 87.74% [kernel] [k] _spin_lock -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2393) Use canonical OpenSSL function names rather than old compatibility defines
[
https://issues.apache.org/jira/browse/TS-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2393:
--
Assignee: Igor Galić
> Use canonical OpenSSL function names rather than old compatibility defines
> --
>
> Key: TS-2393
> URL: https://issues.apache.org/jira/browse/TS-2393
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> Clean out references to {{SSLeay}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2393) Use canonical OpenSSL function names rather than old compatibility defines
[
https://issues.apache.org/jira/browse/TS-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2393:
--
Fix Version/s: 4.2.0
> Use canonical OpenSSL function names rather than old compatibility defines
> --
>
> Key: TS-2393
> URL: https://issues.apache.org/jira/browse/TS-2393
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> Clean out references to {{SSLeay}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2393) Use canonical OpenSSL function names rather than old compatibility defines
[
https://issues.apache.org/jira/browse/TS-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840865#comment-13840865
]
Leif Hedstrom commented on TS-2393:
---
[~i.galic] This sounds like it might have been finished ? Marked it for v4.2.0.
> Use canonical OpenSSL function names rather than old compatibility defines
> --
>
> Key: TS-2393
> URL: https://issues.apache.org/jira/browse/TS-2393
> Project: Traffic Server
> Issue Type: Bug
> Components: Cleanup
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> Clean out references to {{SSLeay}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2397) Transaction State diagram is out-dated
[
https://issues.apache.org/jira/browse/TS-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840713#comment-13840713
]
Ethan Lai commented on TS-2397:
---
IMHO, there are 4 more hooks, but I'm not sure where and whether should we add
them in http transaction state or not.
TSHttpHookAdd: adds a global hook. You can globally add any hook except
for
- TS_HTTP_REQUEST_TRANSFORM_HOOK
- TS_HTTP_RESPONSE_TRANSFORM_HOOK
- TS_HTTP_RESPONSE_CLIENT_HOOK
TS_HTTP_LAST_HOOK _must_ be the last element. Only right place
to insert a new element is just before TS_HTTP_LAST_HOOK.
Session hook shall not be included in http transaction state diagram.
- TS_HTTP_SSN_START_HOOK
- TS_HTTP_SSN_CLOSE_HOOK
> Transaction State diagram is out-dated
> --
>
> Key: TS-2397
> URL: https://issues.apache.org/jira/browse/TS-2397
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: Docs
>
> Attachments: http-hooks-and-transactions.en.rst.patch,
> http-hooks-and-transactions.en.rst.patch,
> http-hooks-and-transactions_adding-hooks.en.rst.patch, http_state.png,
> http_txn_state_diagram.png
>
>
> as reported by [~yzlai] to users@
> {quote}
> I've found that the State transition in HTTP Transaction State Diagram may be
> incorrect.
> Per my http.* debug log,
> {code}
> (http) [0] State Transition: STATE_UNDEFINED -> API_READ_REQUEST_HDR
> (http) [0] State Transition: API_READ_REQUEST_HDR -> HTTP_API_PRE_REMAP
> (http) [0] State Transition: HTTP_API_PRE_REMAP -> HTTP_REMAP_REQUEST
> (http) [0] State Transition: HTTP_REMAP_REQUEST -> HTTP_API_POST_REMAP
> (http) [0] State Transition: HTTP_API_POST_REMAP -> CACHE_LOOKUP
> (http) [0] State Transition: CACHE_LOOKUP -> DNS_LOOKUP
> (http) [0] State Transition: DNS_LOOKUP -> API_OS_DNS
> {code}
> {{CACHE_LOOKUP}} is just after {{POST_REMAP}} and is ahead of {{DNS_LOOKUP}}.
> But in the State Diagram, {{CACHE_LOOKUP}} is after {{OS_DNS_HOOK}}.
> I'm using ats-4.0.1, it would be great if some body can correct the diagram.
> :)
> Many Thanks!
> -Ethan
> {quote}
> It would be really awesome if someone could update that. It would be even
> more awesome if that update it such that it's generated from "code", see
> http://www.opsschool.org/en/latest/meta/conventions.html and
> its code:
> https://raw.github.com/opsschool/curriculum/master/meta/conventions.rst as an
> example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (TS-2419) Don't close client connection when responding with a 204 and there is no body
[
https://issues.apache.org/jira/browse/TS-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-2419:
--
Assignee: Bryan Call
> Don't close client connection when responding with a 204 and there is no body
> -
>
> Key: TS-2419
> URL: https://issues.apache.org/jira/browse/TS-2419
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 4.2.0
>
>
> Currently ATS closes the client connection when returning a 204. In
> production I saw a 2x the number of requests per connection when not closing
> the connection on a 204 response. It the patch below I only close the
> connection if it is chunked encoding or content length not equal to 0.
> patch so far, untested:
> {code}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 049e672..ad3bbfd 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -6756,9 +6756,10 @@
> HttpTransact::handle_response_keep_alive_headers(State* s, HTTPVersion ver,
> HTTP
>} else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
> ka_action = KA_DISABLED;
>}
> - // some systems hang until the connection closes when receiving a 204
> - // regardless of the K-A headers
> - else if (heads->status_get() == HTTP_STATUS_NO_CONTENT) {
> + else if (heads->status_get() == HTTP_STATUS_NO_CONTENT &&
> + (s->current.server->transfer_encoding != NO_TRANSFER_ENCODING ||
> s->hdr_info.request_content_length != 0)) {
> +// some systems hang until the connection closes when receiving a 204
> regardless of the K-A headers
> +// close if there is any body response from the origin
> ka_action = KA_CLOSE;
>} else {
> // Determine if we are going to send either a server-generated or
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2419) Don't close client connection when responding with a 204 and there is no body
[
https://issues.apache.org/jira/browse/TS-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840678#comment-13840678
]
Bryan Call commented on TS-2419:
IRC conversation:
{code}
bcall: on 204's: Maybe related to chunking and/or content length? I.e. make
sure you have enough information to be sure you can reuse the KA connection
without client being confused about how much it has or should read
11:35
jkew left the room (quit: Quit: Leaving.).
11:35
zwoop
bcall: on the auth stuff: Don't we have some configurations related to this ?
bcall: e.g. what does proxy.config.http.cache.ignore_authentication do ?
11:39
bcall
I would have to look but I didn't see the config being used in the code I was
looking at
it might only use that options when it is trying to do a cache write - looking
more at it today
11:41
zwoop
ok
as for 204's, I'm ok for making that KA'able, with the caveat that you assure
that the client knows it's safe to do so. Look at some of other logic we have
there, such as the setting where we trust the content-length value.
i.e. allow 204's to be KA'able as long as we're certain about the content
length etc.
(the issue here is that we can stall clients if what the client expects and
what the client sees is not the same, and then the KA connection is in an
invalid state)
11:54
bcall
it doesn't seem like it stalls the client - since the request per con to the
client side doubles - meaning that more requests happened on that connection
we are doing a crazy amount of 204s
11:57
zwoop
bcall: I'm just saying your use of 204's might be ok, but that's not
necessarily true for all origins
11:57
zwoop
which is most likely why they have that in there
the lack of body together with a missing or wrong Content-Length: header could
probably cause havoc
11:58
bcall
this change only effects the client
11:58
zwoop
204's are empty docs right ?
11:58
bcall
11:58
yes
11:58
zwoop
client ?
the response comes from an oirgin, no ?
imagine this. Origin sends a 204 with a Content-Length: 1234
that will hang the client
11:58
bcall
yes, but we change the ka on the client connection
not on the server con
11:58
zwoop
right
that's a defense mechanism
to avoid hanging the client
12:00
bcall
it might be best to close the connection if we see chunking or content-length
from the origin
on a 204 response
12:01
zwoop
right
that's what I'm saying
{code}
> Don't close client connection when responding with a 204 and there is no body
> -
>
> Key: TS-2419
> URL: https://issues.apache.org/jira/browse/TS-2419
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Bryan Call
> Fix For: 4.2.0
>
>
> Currently ATS closes the client connection when returning a 204. In
> production I saw a 2x the number of requests per connection when not closing
> the connection on a 204 response. It the patch below I only close the
> connection if it is chunked encoding or content length not equal to 0.
> patch so far, untested:
> {code}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 049e672..ad3bbfd 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -6756,9 +6756,10 @@
> HttpTransact::handle_response_keep_alive_headers(State* s, HTTPVersion ver,
> HTTP
>} else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
> ka_action = KA_DISABLED;
>}
> - // some systems hang until the connection closes when receiving a 204
> - // regardless of the K-A headers
> - else if (heads->status_get() == HTTP_STATUS_NO_CONTENT) {
> + else if (heads->status_get() == HTTP_STATUS_NO_CONTENT &&
> + (s->current.server->transfer_encoding != NO_TRANSFER_ENCODING ||
> s->hdr_info.request_content_length != 0)) {
> +// some systems hang until the connection closes when receiving a 204
> regardless of the K-A headers
> +// close if there is any body response from the origin
> ka_action = KA_CLOSE;
>} else {
> // Determine if we are going to send either a server-generated or
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2419) Don't close client connection when responding with a 204 and there is no body
[
https://issues.apache.org/jira/browse/TS-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-2419:
---
Fix Version/s: 4.2.0
> Don't close client connection when responding with a 204 and there is no body
> -
>
> Key: TS-2419
> URL: https://issues.apache.org/jira/browse/TS-2419
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Bryan Call
> Fix For: 4.2.0
>
>
> Currently ATS closes the client connection when returning a 204. In
> production I saw a 2x the number of requests per connection when not closing
> the connection on a 204 response. It the patch below I only close the
> connection if it is chunked encoding or content length not equal to 0.
> patch so far, untested:
> {code}
> diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
> index 049e672..ad3bbfd 100644
> --- a/proxy/http/HttpTransact.cc
> +++ b/proxy/http/HttpTransact.cc
> @@ -6756,9 +6756,10 @@
> HttpTransact::handle_response_keep_alive_headers(State* s, HTTPVersion ver,
> HTTP
>} else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
> ka_action = KA_DISABLED;
>}
> - // some systems hang until the connection closes when receiving a 204
> - // regardless of the K-A headers
> - else if (heads->status_get() == HTTP_STATUS_NO_CONTENT) {
> + else if (heads->status_get() == HTTP_STATUS_NO_CONTENT &&
> + (s->current.server->transfer_encoding != NO_TRANSFER_ENCODING ||
> s->hdr_info.request_content_length != 0)) {
> +// some systems hang until the connection closes when receiving a 204
> regardless of the K-A headers
> +// close if there is any body response from the origin
> ka_action = KA_CLOSE;
>} else {
> // Determine if we are going to send either a server-generated or
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2419) Don't close client connection when responding with a 204 and there is no body
Bryan Call created TS-2419:
--
Summary: Don't close client connection when responding with a 204
and there is no body
Key: TS-2419
URL: https://issues.apache.org/jira/browse/TS-2419
Project: Traffic Server
Issue Type: Improvement
Components: HTTP
Reporter: Bryan Call
Currently ATS closes the client connection when returning a 204. In production
I saw a 2x the number of requests per connection when not closing the
connection on a 204 response. It the patch below I only close the connection
if it is chunked encoding or content length not equal to 0.
patch so far, untested:
{code}
diff --git a/proxy/http/HttpTransact.cc b/proxy/http/HttpTransact.cc
index 049e672..ad3bbfd 100644
--- a/proxy/http/HttpTransact.cc
+++ b/proxy/http/HttpTransact.cc
@@ -6756,9 +6756,10 @@ HttpTransact::handle_response_keep_alive_headers(State*
s, HTTPVersion ver, HTTP
} else if (HTTP_MAJOR(ver.m_version) == 0) { /* No K-A for 0.9 apps */
ka_action = KA_DISABLED;
}
- // some systems hang until the connection closes when receiving a 204
- // regardless of the K-A headers
- else if (heads->status_get() == HTTP_STATUS_NO_CONTENT) {
+ else if (heads->status_get() == HTTP_STATUS_NO_CONTENT &&
+ (s->current.server->transfer_encoding != NO_TRANSFER_ENCODING ||
s->hdr_info.request_content_length != 0)) {
+// some systems hang until the connection closes when receiving a 204
regardless of the K-A headers
+// close if there is any body response from the origin
ka_action = KA_CLOSE;
} else {
// Determine if we are going to send either a server-generated or
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2400:
--
Fix Version/s: (was: 5.0.0)
4.2.0
> Our default SSL cipher-suite advocates speed over security
> --
>
> Key: TS-2400
> URL: https://issues.apache.org/jira/browse/TS-2400
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, SSL
>Reporter: Igor Galić
> Fix For: 4.2.0
>
>
> Our default cipher-suite advocates speed over security:
> {code}
> RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
> {code}
> Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
> must be eradicated:
> https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
> We should by default advocate security, which means, we should advocate
> Perfect Forward Secrecy, which means we should also advocate OpenSSL >=
> 1.0.1e
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2400:
--
Assignee: Igor Galić
> Our default SSL cipher-suite advocates speed over security
> --
>
> Key: TS-2400
> URL: https://issues.apache.org/jira/browse/TS-2400
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, SSL
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: 4.2.0
>
>
> Our default cipher-suite advocates speed over security:
> {code}
> RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
> {code}
> Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
> must be eradicated:
> https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
> We should by default advocate security, which means, we should advocate
> Perfect Forward Secrecy, which means we should also advocate OpenSSL >=
> 1.0.1e
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2060) proxy.local.incoming_ip_to_bind is superfluous
[ https://issues.apache.org/jira/browse/TS-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2060: -- Fix Version/s: (was: 4.1.1) Docs > proxy.local.incoming_ip_to_bind is superfluous > -- > > Key: TS-2060 > URL: https://issues.apache.org/jira/browse/TS-2060 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Aidan McGurn >Assignee: Alan M. Carroll > Fix For: Docs > > > Why do ATS bother with this parameter?: > LOCAL proxy.local.incoming_ip_to_bind STRING 10.20.41.15 > Which is limited to 2 IP’s and is not associated with the port information - > This can all be achieved with: > CONFIG proxy.config.http.server_ports STRING > 3128:ipv4:tr-full:ip-in=10.20.41.15 3128:ipv4:tr-full:ip-in=10.20.50.27 > and with better granularity where we can assign individual ports to ip’s and > not limited to 2. > maybe this has already been taken out of ATS but if not why not? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2232) log rolling level should be changed from Status to Debug
[
https://issues.apache.org/jira/browse/TS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2232:
--
Summary: log rolling level should be changed from Status to Debug (was:
log level should be changed from Status to Debug)
> log rolling level should be changed from Status to Debug
>
>
> Key: TS-2232
> URL: https://issues.apache.org/jira/browse/TS-2232
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Yu Qing
>Assignee: Yu Qing
> Fix For: 4.1.1
>
> Attachments:
> 0001-TS-2232-log-level-should-be-change-from-Status-to-De.patch
>
>
> log rolling info should be dubug info because these info are useless in
> production environment.
> the output messages as:
> [Sep 16 06:41:00.065] Server {0x2b0fd4416700} STATUS: The rolled logfile,
> /var/log/trafficserver/error.log_test.20130916.01h39m58s-20130916.01h50m00s.old,
> was auto-deleted; 120849687 bytes were reclaimed.
> [Sep 16 06:50:00.014] Server {0x2b0fd4416700} STATUS: The logfile
> /var/log/trafficserver/error.log was rolled to
> /var/log/trafficserver/error.log_test.20130916.06h39m57s-20130916.06h50m00s.old.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2209) add support for lowercasing all substitutions in regex_remap
[ https://issues.apache.org/jira/browse/TS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2209: -- Issue Type: New Feature (was: Improvement) > add support for lowercasing all substitutions in regex_remap > > > Key: TS-2209 > URL: https://issues.apache.org/jira/browse/TS-2209 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 4.1.1 > > Attachments: ts-2209.diff > > > Add the option @lowercase_substitutions=1 to regex_remap to lowercase all the > matching substitutions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2179) Add the option to do lowercasing of the path in regex_remap
[ https://issues.apache.org/jira/browse/TS-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2179: -- Issue Type: New Feature (was: Improvement) > Add the option to do lowercasing of the path in regex_remap > --- > > Key: TS-2179 > URL: https://issues.apache.org/jira/browse/TS-2179 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Bryan Call >Assignee: Bryan Call > Fix For: 4.1.1 > > Attachments: ts-2178.diff > > > Add option $l to substitute a lowercased path -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-302) -fstrict-aliasing optimizer generates bad code
[
https://issues.apache.org/jira/browse/TS-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840620#comment-13840620
]
ASF subversion and git services commented on TS-302:
Commit 354fbc267e2bc2d522ac2d96a7b3b8b5b06fb438 in branch refs/heads/master
from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=354fbc2 ]
TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x
Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of
uin32_t. Simplify methods because of this."
This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.
This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable release.
> -fstrict-aliasing optimizer generates bad code
> --
>
> Key: TS-302
> URL: https://issues.apache.org/jira/browse/TS-302
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
>Reporter: Miles Libbey
>Assignee: Phil Sorber
>Priority: Minor
> Fix For: 6.0.0
>
> Attachments: no-no-fstrict-alias.patch, ts-302.patch
>
>
> (moving from yahoo bug 525119)
> Original description
> by Leif Hedstrom 4 years ago at 2005-12-16 08:41
> Not sure if this is a compiler bug or a code issue on our side, but enabling
> the
> -fstrict-aliasing optimization option generates faulty code. This optimization
> technique is enabled implicitly with -Os, -O2 and -O3, so for now I'm
> explicitly
> turning it off with
>-O3 -fno-strict-aliasing
> This solves the problem where the traffic server would return data of 0 or 1
> length out of the cache. This initially looked like the cache corruption
> problem, but is completely different and unrelated. The cache corruption
> problem
> has been fixed and closed.
> I'm opening this bug as a reminder, at some point we should isolate which code
> triggers the strict-aliasing problem, and confirm if it's a compiler bug or a
> problem in our code.
>
>
> Comment 1
> by Michael Bigby 4 years ago at 2005-12-16 09:07:40
> I'm recommending that we get Ed's input on this. He may some insight compiler
> issues...
>
>
> Comment 2
> by Leif Hedstrom 4 years ago at 2005-12-16 10:02:07
> That'd be great!
> We haven't had a chance yet to review the code that might be affecting this,
> it's obviously something with unions and how the compiler handles
> storage/alignment on the members.
>
>
> Comment 3
> by Ed Hall 4 years ago at 2006-03-03 11:46:52
> This is with gcc 2.95.3, correct? There have been a number of complaints
> around
> the 'net about problems with -fstrict-aliasing. I've not really looked very
> deeply into it, though I should mention that certain C code was known at the
> time to malfunction when by-the-standard aliasing rules were enforced
> (starting
> with the Linux kernel).
> In essense, the -fstrict-aliasing optimizations assume that any particular
> part
> of memory accessed via a specific type of pointer won't be accessed as another
> type. There are a set of optimizations that are safe only when it can be
> guaranteed that a given bit of memory hasn't been manipulated via pointer; if
> the compiler assumes that the rather arcane C aliasing rules have been
> followed
> ("aliasing" in this case meaning accessing a given bit of memory with more
> than
> one type of pointer), there are more situations where such optimizations can
> be
> applied. Code which uses type casts where unions might be more appropriate is
> the most likely to break aliasing rules.
> In any case, gcc 3/4 is less aggressive (and perhaps less buggy) in applying
> the
> C aliasing rules, and has added warnings for obvious violations. It's never
> been clear to me if gcc 2.95.3 was actually broken or not, or if there simply
> was a lot of code out there that ran afoul of the standard.
>
>
> Comment 4
> by Leif Hedstrom 4 years ago at 2006-03-03 12:50:22
> Actually, the problem only occured after we converted the code from gcc-2.9x
> to
> gcc-3.4.4. We have since cleared out a *lot* of compiler warnings (thousands
> and
> thousands), so maybe we should try again to compile without the
> -fno-strict-aliasing, and see if gcc will point us to some places where we do
> dangerous things. The code does some very scary things manipulating objects
> directly, by byte-offsets for instance.
> I think it's pretty easy to reproduce the problem, it basically renders the
> cache completely useless, returning objects of size 0 or 1.
>
>
> Comment 5
> by Ed Hall 4 years ago at 2006-03-03 16:44:04
> Ah, that makes sense. I just checked, and the -fstrict-aliasing option wasn't
> part of the -O2 optimizations on gcc 2.95, but g
[jira] [Commented] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840619#comment-13840619
]
ASF subversion and git services commented on TS-2384:
-
Commit 354fbc267e2bc2d522ac2d96a7b3b8b5b06fb438 in branch refs/heads/master
from [~psudaemon]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=354fbc2 ]
TS-2384: Regression in key-lookup code between 4.0.x and 4.1.x
Revert "TS-302: Fix HTTPCacheAlt to use INK_MD5 directly instead of arrays of
uin32_t. Simplify methods because of this."
This reverts commit c40c601c9167c4937f972daf7825821e527a5f67.
This breaks cache keys on certain builds. It's not clear why, but we
should remove this from 4.1.x so that we can have a stable release.
> Regression in key-lookup code between 4.0.x and 4.1.x
> -
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Igor Galić
>Assignee: Phil Sorber
> Fix For: 4.1.2, 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these
> objects downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means
> that the existing objects on the disks will stay in place, but we won't be
> able to find them, because we are looking in the wrong place. As such we
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in
> 304s.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2402) SSL v3 is disabled
[
https://issues.apache.org/jira/browse/TS-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-2402:
Component/s: SSL
> SSL v3 is disabled
> --
>
> Key: TS-2402
> URL: https://issues.apache.org/jira/browse/TS-2402
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 4.2.0
>Reporter: Neddy
> Fix For: 4.2.0
>
>
> Host OS: Debian x86_64
> ATS 4.2.0
> Usage: Reverse server SSL terminal
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 1
> CONFIG proxy.config.ssl.TLSv1 INT 1
> Error log:
> [Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
> SSL::3:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:337
> [Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2402) SSL v3 is disabled
[
https://issues.apache.org/jira/browse/TS-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840611#comment-13840611
]
James Peach commented on TS-2402:
-
I looked at the code that sets this and it appears correct.
> SSL v3 is disabled
> --
>
> Key: TS-2402
> URL: https://issues.apache.org/jira/browse/TS-2402
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SSL
>Affects Versions: 4.2.0
>Reporter: Neddy
> Fix For: 4.2.0
>
>
> Host OS: Debian x86_64
> ATS 4.2.0
> Usage: Reverse server SSL terminal
> CONFIG proxy.config.ssl.SSLv2 INT 0
> CONFIG proxy.config.ssl.SSLv3 INT 1
> CONFIG proxy.config.ssl.TLSv1 INT 1
> Error log:
> [Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
> SSL::3:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:337
> [Nov 27 16:35:32.759] Server {0x2b1b5d18d700} ERROR:
> [SSL_NetVConnection::ssl_read_from_net]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2255) TS should not flood printing after log space reach the limit
[
https://issues.apache.org/jira/browse/TS-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2255:
--
Issue Type: Improvement (was: Bug)
> TS should not flood printing after log space reach the limit
>
>
> Key: TS-2255
> URL: https://issues.apache.org/jira/browse/TS-2255
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Zhao Yongming
>Assignee: Yunkai Zhang
> Fix For: 4.1.1
>
> Attachments:
> 0001-TS-2255-TS-should-not-flood-printing-after-log-space.patch
>
>
> when log space reach the reserved head room and there is noway to remove some
> old log for more space, TS will print many log in traffic.out or diags.log,
> which will make great troube as those files is not rotated, may block the
> server from working after disk space exhausted.
> {code}
> [Sep 26 17:44:31.037] Server {0x2b0ff3363700} NOTE: logging space exhausted,
> can't write to:/var/log/trafficserver/error.log, drop this entry
> [Sep 26 17:44:31.689] Server {0x2b0ff2e5e700} NOTE: logging space exhausted,
> can't write to:/var/log/trafficserver/error.log, drop this entry
> [Sep 26 17:44:31.692] Server {0x2b0ff2e5e700} NOTE: logging space exhausted,
> can't write to:/var/log/trafficserver/error.log, drop this entry
> [Sep 26 17:44:32.200] Server {0x2b0ff3363700} NOTE: logging space exhausted,
> can't write to:/var/log/trafficserver/error.log, drop this entry
> [Sep 26 17:44:35.471] Server {0x2b0ff2b5b700} NOTE: logging space exhausted,
> can't write to:/var/log/trafficserver/error.log, drop this entry
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2265) Remove unsupported log tags
[
https://issues.apache.org/jira/browse/TS-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2265:
--
Issue Type: Improvement (was: Bug)
> Remove unsupported log tags
> ---
>
> Key: TS-2265
> URL: https://issues.apache.org/jira/browse/TS-2265
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 4.1.1
>
>
> There are a number of log tags, which are no longer supporter (or possible to
> support). They were used / defined only for various streaming protocols,
> which our core no longer supports.
> To avoid confusion, we should remove these. I could find three so far, which
> I'll remove:
> {code}
> prob
> prcb
> cgid
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2245) Fix the semantics and behavior of e.g. proxy.config.http.cache.ignore_accept_encoding_mismatch
[
https://issues.apache.org/jira/browse/TS-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2245:
--
Issue Type: Improvement (was: Bug)
> Fix the semantics and behavior of e.g.
> proxy.config.http.cache.ignore_accept_encoding_mismatch
> --
>
> Key: TS-2245
> URL: https://issues.apache.org/jira/browse/TS-2245
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 4.1.1
>
>
> These four configurations options where added to fix a real problem (content
> duplications in cache):
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_mismatch", RECD_INT,
> "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_language_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_encoding_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {RECT_CONFIG, "proxy.config.http.cache.ignore_accept_charset_mismatch",
> RECD_INT, "0", RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-1]", RECA_NULL}
> ,
> {code}
> However, as implemented, they are pretty much useless, and if enabled, have
> high risk of giving wrong content. To make things worse, they are global
> configurations, since they are not passable from the HTTPSM into the cache.
> I've examine the code thoroughly, and I actually think these configurations
> had the right intentions, but just implemented it wrong. What they really
> ought to have been is e.g.
> proxy.config.http.cache.relax_accept_encoding_match .
> What *should* happen (IMO) is that these four configs (ideally we'd rename
> them or make new ones) would check if there is no Vary: header in the cached
> entry. IF there is no Vary: header, *AND* one of these settings it set, we
> skip that matching that happens on the cache client header and the incoming
> client header entirely (give the match a score of 1.0). These configs should
> ideally also be per-remap overridable, but that requires code changes like
> TS-1919.
> A real use case scenario is this: Assume a content is always served by origin
> without Content-Encoding, or Vary: header. This would be typical for e.g. a
> PNG (image).
> Upon cache miss, if the first request comes with Accept-Encoding: gzip,
> everything is fine, and we serve this cached item to all clients thereafter.
> However, if the first request comes with no Accept-Encoding: header
> whatsoever, that response can not satisfy a response from a request with AE:
> gzip, so we get *at least* two copies of the same object in cache.
> I'm curious to get some input on this, and let me know if the explanations
> makes no sense. :)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2195) deprecate TSHttpTxnCacheLookupSkip
[
https://issues.apache.org/jira/browse/TS-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2195:
--
Issue Type: Improvement (was: Bug)
> deprecate TSHttpTxnCacheLookupSkip
> --
>
> Key: TS-2195
> URL: https://issues.apache.org/jira/browse/TS-2195
> Project: Traffic Server
> Issue Type: Improvement
> Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 4.1.1
>
>
> {{TSHttpTxnCacheLookupSkip()}} is in experimental, but can be implemented by
> stable API, {{TSHttpTxnConfigIntSet(txn, TS_CONFIG_HTTP_CACHE_HTTP, 0)}}.
> Let's deprecate this API for 4.1.0, and remove it for 5.0
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2226) header_rewrite ought to have a set-header operator
[ https://issues.apache.org/jira/browse/TS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2226: -- Issue Type: New Feature (was: Bug) > header_rewrite ought to have a set-header operator > -- > > Key: TS-2226 > URL: https://issues.apache.org/jira/browse/TS-2226 > Project: Traffic Server > Issue Type: New Feature > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.1 > > > Right now, the expectation is that if you really want to set a header, you > have to do > rm-header Foo-Header > add-header Foo-Header "bar" > Lame. The examples even has a set-header line, but there's no code for it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2155) Create new regex based RAT excludes, and update all licensing
[ https://issues.apache.org/jira/browse/TS-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2155: -- Issue Type: Improvement (was: Bug) > Create new regex based RAT excludes, and update all licensing > - > > Key: TS-2155 > URL: https://issues.apache.org/jira/browse/TS-2155 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.1 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-1766) resurrect unit test programs
[ https://issues.apache.org/jira/browse/TS-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1766: -- Issue Type: Improvement (was: Bug) > resurrect unit test programs > > > Key: TS-1766 > URL: https://issues.apache.org/jira/browse/TS-1766 > Project: Traffic Server > Issue Type: Improvement > Components: Cleanup, Core >Reporter: James Peach >Assignee: James Peach > Fix For: 4.1.1 > > > There are a lot of test source files in the source tree that are never built > into actual test programs. We should build these into standalone test > programs so that "make check" runs them as unit tests. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2266) Add a "make rat" target to top-level Makefile
[ https://issues.apache.org/jira/browse/TS-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2266: -- Issue Type: Improvement (was: Bug) > Add a "make rat" target to top-level Makefile > - > > Key: TS-2266 > URL: https://issues.apache.org/jira/browse/TS-2266 > Project: Traffic Server > Issue Type: Improvement > Components: Build >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 4.1.1 > > > This lets us easily run rat-reports anytime. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2323) add a .include directive to remap.config
[ https://issues.apache.org/jira/browse/TS-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2323: -- Issue Type: New Feature (was: Bug) > add a .include directive to remap.config > > > Key: TS-2323 > URL: https://issues.apache.org/jira/browse/TS-2323 > Project: Traffic Server > Issue Type: New Feature > Components: Configuration, Core >Reporter: James Peach >Assignee: James Peach > Fix For: 4.1.1 > > > For certain kinds of configuration, it would be convenient if remap.config > directly supported including additional files. This change implements a > ".include" directive that lets the operator split remap rules across multiple > configuration files. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2275) fix interim cache lossing data if the server process crash
[ https://issues.apache.org/jira/browse/TS-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2275: -- Issue Type: Bug (was: Improvement) > fix interim cache lossing data if the server process crash > -- > > Key: TS-2275 > URL: https://issues.apache.org/jira/browse/TS-2275 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 4.0.2 >Reporter: Zhao Yongming >Assignee: portl4t > Fix For: 4.1.1 > > Attachments: master.patch > > > the current interim cache device is not permanent storage, it is cleared on > each server restart, that is because we do not have a very good solution for > the storage consistence. > we have a patch under testing for that improvement. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840591#comment-13840591
]
John Paul Vasicek commented on TS-2299:
---
https://issues.apache.org/jira/browse/TS-2250 is blocking us from upgrading to
4.x, so my priorities have been focused elsewhere.
IIRC rebuilding with --enable-debug caused ATS to crash during start up after a
failed ATS assert in TSMimeHdrFieldAppend, I believe it was
ink_assert(field_handle->field_ptr->m_ptr_name) on line ~2724 in InkAPI.cc.
> ATS seg faults in MIMEScanner::mime_scanner_get
> ---
>
> Key: TS-2299
> URL: https://issues.apache.org/jira/browse/TS-2299
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP, MIME
>Affects Versions: 4.0.1
> Environment: RHEL 5.9
>Reporter: John Paul Vasicek
> Fix For: 4.2.0
>
>
> I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2aafe810683d]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
> (demangled)
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /lib64/libpthread.so.0[0x2ba86e67aca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x39f)[0x4d37cf]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8Plu
> ginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2ba86e67283d]
> /usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x46e)[0x4d389e]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840591#comment-13840591
]
John Paul Vasicek edited comment on TS-2299 at 12/5/13 9:31 PM:
https://issues.apache.org/jira/browse/TS-2250 is blocking us from upgrading to
4.x, so my priorities have been focused elsewhere.
IIRC rebuilding with \-\-enable-debug caused ATS to crash during start up after
a failed ATS assert in TSMimeHdrFieldAppend, I believe it was
ink_assert(field_handle->field_ptr->m_ptr_name) on line ~2724 in InkAPI.cc.
was (Author: jvasicek):
https://issues.apache.org/jira/browse/TS-2250 is blocking us from upgrading to
4.x, so my priorities have been focused elsewhere.
IIRC rebuilding with --enable-debug caused ATS to crash during start up after a
failed ATS assert in TSMimeHdrFieldAppend, I believe it was
ink_assert(field_handle->field_ptr->m_ptr_name) on line ~2724 in InkAPI.cc.
> ATS seg faults in MIMEScanner::mime_scanner_get
> ---
>
> Key: TS-2299
> URL: https://issues.apache.org/jira/browse/TS-2299
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP, MIME
>Affects Versions: 4.0.1
> Environment: RHEL 5.9
>Reporter: John Paul Vasicek
> Fix For: 4.2.0
>
>
> I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2aafe810683d]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
> (demangled)
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /lib64/libpthread.so.0[0x2ba86e67aca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x39f)[0x4d37cf]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8Plu
> ginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2ba86e67283d]
> /usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x46e)[0x4d389e]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {cod
[jira] [Updated] (TS-2145) Add metrics for log collation, e.g. messages sent and messages received
[
https://issues.apache.org/jira/browse/TS-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2145:
--
Issue Type: New Feature (was: Improvement)
> Add metrics for log collation, e.g. messages sent and messages received
> ---
>
> Key: TS-2145
> URL: https://issues.apache.org/jira/browse/TS-2145
> Project: Traffic Server
> Issue Type: New Feature
> Components: Logging
>Reporter: Yunkai Zhang
>Assignee: Yunkai Zhang
> Fix For: 4.1.1
>
> Attachments: 0001-TS-2145-Add-metrics-for-log-collation.V2.patch,
> 0001-TS-2145-Add-metrics-for-log-collation.patch
>
>
> Without accurate stats, we don't known whether the log is lost.
> This coming patch will be used to verify:
> 1) At log client side, how many logs genterated from HttpSM, how many logs
> sent to LogServer.
> 2) At log server side, how many logs received from LogClient, how many logs
> written to LogServers's disk.
> ==
> I have attached a patch. Let's show an example for the metrics collected by
> this patch:
> In this example, there are two machines: one log-client and one log-server.
> {code}
> 1) Clear old stats data in both client and server machines:
> $ /etc/init.d/trafficserver stop
> $ rm -rf /var/run/trafficserver/*.snap
> 2) Make logs_xml.config in log server empty.
> 3) Make logs_xml.config in log client looks like:
>
>
> :8085"/>
>
>
>
>
> 2) Start log server (with collation mode == 1, logging_enable = 3,
> squid_log_enabled = 0)
> [log-server]$ /etc/init.d/trafficserver start
> 3) Start log client (with collation mode = 0, logging_enable = 3,
> squid_log_enabled = 0)
> [log-server]$ /etc/init.d/trafficserver start
> 4) Use jtest do some request for log client.
> 5) Stop log client and for a while (so that all data in network have been
> sent to log-server).
> 6) Log client's metrics for logging:
> [log-client]# lynx -dump http://localhost:8080/stat/ | grep process.log
> proxy.process.log.event_log_error=0
> proxy.process.log.event_log_error_skip=0
> proxy.process.log.event_log_error_aggr=0
> proxy.process.log.event_log_error_fail=0
> proxy.process.log.event_log_access=4990275
> proxy.process.log.event_log_access_skip=0
> proxy.process.log.event_log_access_aggr=0
> proxy.process.log.event_log_access_fail=0
> proxy.process.log.num_sent_to_network=4990275
> proxy.process.log.num_received_from_network=0
> proxy.process.log.num_flush_to_disk=0
> proxy.process.log.bytes_sent_to_network=719149632
> proxy.process.log.bytes_received_from_network=0
> proxy.process.log.bytes_flush_to_disk=0
> proxy.process.log.bytes_written_to_disk=0
> proxy.process.log.log_files_open=0
> proxy.process.log.log_files_space_used=5330
> 7) Log server's metrics for logging:
> [log-server]# lynx -dump http://localhost:8080/stat/ | grep process.log
> proxy.process.log.event_log_error=0
> proxy.process.log.event_log_error_skip=0
> proxy.process.log.event_log_error_aggr=0
> proxy.process.log.event_log_error_fail=0
> proxy.process.log.event_log_access=0
> proxy.process.log.event_log_access_skip=20
> proxy.process.log.event_log_access_aggr=0
> proxy.process.log.event_log_access_fail=0
> proxy.process.log.num_sent_to_network=0
> proxy.process.log.num_received_from_network=4990275
> proxy.process.log.num_flush_to_disk=4990275
> proxy.process.log.bytes_sent_to_network=0
> proxy.process.log.bytes_received_from_network=719149632
> proxy.process.log.bytes_flush_to_disk=485256906
> proxy.process.log.bytes_written_to_disk=485256906
> proxy.process.log.log_files_open=1
> proxy.process.log.log_files_space_used=85215225070
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-498) Document new configuration for dedicated DNS thread
[ https://issues.apache.org/jira/browse/TS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-498: - Summary: Document new configuration for dedicated DNS thread (was: New configuration for dedicated DNS thread) > Document new configuration for dedicated DNS thread > --- > > Key: TS-498 > URL: https://issues.apache.org/jira/browse/TS-498 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom >Priority: Minor > Fix For: 4.1.1 > > > *) Experimental supoprt for a dedicated DNS thread. This can be >enabled with the records.config option > CONFIG proxy.config.dns.dedicated_thread INT 1 > This feature is possibly useful for very busy forward or transparent > proxies [TS-307]. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840583#comment-13840583
]
Leif Hedstrom commented on TS-2138:
---
I moved this out to v4.2.0 since it doesn't sound like this is fixed.
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2138) Using linux native-AIO, restarting ATS causes complete cache data loss
[
https://issues.apache.org/jira/browse/TS-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2138:
--
Fix Version/s: (was: 4.1.1)
4.2.0
> Using linux native-AIO, restarting ATS causes complete cache data loss
> --
>
> Key: TS-2138
> URL: https://issues.apache.org/jira/browse/TS-2138
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: bettydramit
>Assignee: weijin
> Fix For: 4.2.0
>
> Attachments: TS-2138.wj.diff, ts-3.3.5-40.spec
>
>
> ENV: centos 6 x86_64 gitmaster and
> http://people.apache.org/~zwoop/rel-candidates/trafficserver-3.3.5-dev.tar.bz2
> ./configure --enable-layout=Gentoo --libdir=%{_libdir}/trafficserver
> --enable-linux-native-aio --enable-reclaimable-freelist
>
> when restart ats ,my all hit data will be lost.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2235) url_print should NOT output "?" for empty query string
[ https://issues.apache.org/jira/browse/TS-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2235: -- Fix Version/s: (was: 4.1.1) 4.1.2 > url_print should NOT output "?" for empty query string > --- > > Key: TS-2235 > URL: https://issues.apache.org/jira/browse/TS-2235 > Project: Traffic Server > Issue Type: Bug > Components: MIME >Reporter: Yu Qing >Assignee: Yu Qing > Fix For: 4.1.2 > > Attachments: 0001-TS-2235-two-functions-should-be-changed-too.patch, > 0001-TS-2235-url_print-should-NOT-output-for-empty-query-.patch > > > the same problem with parameter and fragment parts. > for example: a remap plugin removes the query part (set query to empty), but > the remaped url end with "?". -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2397) Transaction State diagram is out-dated
[
https://issues.apache.org/jira/browse/TS-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840582#comment-13840582
]
Igor Galić commented on TS-2397:
from what I gather we're still missing something, according to [~yzlai], but I
don't know what, exactly, and where.
> Transaction State diagram is out-dated
> --
>
> Key: TS-2397
> URL: https://issues.apache.org/jira/browse/TS-2397
> Project: Traffic Server
> Issue Type: Bug
> Components: Documentation
>Reporter: Igor Galić
>Assignee: Igor Galić
> Fix For: Docs
>
> Attachments: http-hooks-and-transactions.en.rst.patch,
> http-hooks-and-transactions.en.rst.patch,
> http-hooks-and-transactions_adding-hooks.en.rst.patch, http_state.png,
> http_txn_state_diagram.png
>
>
> as reported by [~yzlai] to users@
> {quote}
> I've found that the State transition in HTTP Transaction State Diagram may be
> incorrect.
> Per my http.* debug log,
> {code}
> (http) [0] State Transition: STATE_UNDEFINED -> API_READ_REQUEST_HDR
> (http) [0] State Transition: API_READ_REQUEST_HDR -> HTTP_API_PRE_REMAP
> (http) [0] State Transition: HTTP_API_PRE_REMAP -> HTTP_REMAP_REQUEST
> (http) [0] State Transition: HTTP_REMAP_REQUEST -> HTTP_API_POST_REMAP
> (http) [0] State Transition: HTTP_API_POST_REMAP -> CACHE_LOOKUP
> (http) [0] State Transition: CACHE_LOOKUP -> DNS_LOOKUP
> (http) [0] State Transition: DNS_LOOKUP -> API_OS_DNS
> {code}
> {{CACHE_LOOKUP}} is just after {{POST_REMAP}} and is ahead of {{DNS_LOOKUP}}.
> But in the State Diagram, {{CACHE_LOOKUP}} is after {{OS_DNS_HOOK}}.
> I'm using ats-4.0.1, it would be great if some body can correct the diagram.
> :)
> Many Thanks!
> -Ethan
> {quote}
> It would be really awesome if someone could update that. It would be even
> more awesome if that update it such that it's generated from "code", see
> http://www.opsschool.org/en/latest/meta/conventions.html and
> its code:
> https://raw.github.com/opsschool/curriculum/master/meta/conventions.rst as an
> example.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (TS-2384) Regression in key-lookup code between 4.0.x and 4.1.x
[
https://issues.apache.org/jira/browse/TS-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-2384.
---
Resolution: Fixed
Closing, since this looks resolved for now. Open a new bug if you want to put
this code back in for a future release.
> Regression in key-lookup code between 4.0.x and 4.1.x
> -
>
> Key: TS-2384
> URL: https://issues.apache.org/jira/browse/TS-2384
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache
>Reporter: Igor Galić
>Assignee: Phil Sorber
> Fix For: 4.1.2, 4.2.0
>
>
> As reported on users@
> {noformat}
> ATS 4.0.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 6BA7E5696E9A9E7A1E05212E5264D3C4
> sync_serial 10836
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> {noformat}
> ATS 4.1.1
> Volume #1 - store='/dev/sda'
> first key 409542BD429764BEE60B0610B8924C4D
> key 34CEA58AC5FBA6D240C484307DE4C315
> sync_serial 10837
> write_serial388912
> header length 2480
> fragment type 1
> No of Alternates1
> {noformat}
> When run 4.1.1 all previously cached objects under 4.0.1 are MISS, these
> objects downloading from parent, and then they HIT again.
> *Note* This does not cause the cache to be reinitialized.
> It's just that the generated cache-lookup *key* is wrong in 4.1.x. This means
> that the existing objects on the disks will stay in place, but we won't be
> able to find them, because we are looking in the wrong place. As such we
> simply store the object again.
> That's *almost* the same for people running with a 60 TiB cache, because
> everything requested is also stored again,
> and after a while the old objects that have been lying around for a while
> will be rotated out so that's bad. People with
> tiny caches or very high turn overs might even notice the downward spike in
> 304s.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840577#comment-13840577
]
Igor Galić commented on TS-2400:
I think this can go into 4.2.x.
> Our default SSL cipher-suite advocates speed over security
> --
>
> Key: TS-2400
> URL: https://issues.apache.org/jira/browse/TS-2400
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, SSL
>Reporter: Igor Galić
> Fix For: 5.0.0
>
>
> Our default cipher-suite advocates speed over security:
> {code}
> RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
> {code}
> Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
> must be eradicated:
> https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
> We should by default advocate security, which means, we should advocate
> Perfect Forward Secrecy, which means we should also advocate OpenSSL >=
> 1.0.1e
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840574#comment-13840574
]
Leif Hedstrom commented on TS-2299:
---
John, any more details on this ?
> ATS seg faults in MIMEScanner::mime_scanner_get
> ---
>
> Key: TS-2299
> URL: https://issues.apache.org/jira/browse/TS-2299
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP, MIME
>Affects Versions: 4.0.1
> Environment: RHEL 5.9
>Reporter: John Paul Vasicek
> Fix For: 4.2.0
>
>
> I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2aafe810683d]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
> (demangled)
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /lib64/libpthread.so.0[0x2ba86e67aca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x39f)[0x4d37cf]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8Plu
> ginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2ba86e67283d]
> /usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x46e)[0x4d389e]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2299) ATS seg faults in MIMEScanner::mime_scanner_get
[
https://issues.apache.org/jira/browse/TS-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2299:
--
Fix Version/s: 4.2.0
> ATS seg faults in MIMEScanner::mime_scanner_get
> ---
>
> Key: TS-2299
> URL: https://issues.apache.org/jira/browse/TS-2299
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP, MIME
>Affects Versions: 4.0.1
> Environment: RHEL 5.9
>Reporter: John Paul Vasicek
> Fix For: 4.2.0
>
>
> I'm seeing segmentation faults in ATS 4.0.1, these seem to happen randomly:
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(_Z16mime_scanner_getP11MIMEScannerPPKcS2_S3_S3_Pbbi+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(_Z21http_parser_parse_reqP10HTTPParserP7HdrHeapP11HTTPHdrImplPPKcS6_bb+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(_ZN7HTTPHdr9parse_reqEP10HTTPParserP14IOBufferReaderPib+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8PluginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(_ZN8PluginVC18process_write_sideEb+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(_ZN8PluginVC12main_handlerEiPv+0x46e)[0x4d389e]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x3a9)[0x6cb979]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2aafe810683d]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
> (demangled)
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /lib64/libpthread.so.0[0x2aafe810eca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/local/bin/traffic_server - STACK TRACE:
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /lib64/libpthread.so.0[0x2ba86e67aca0]
> /usr/local/bin/traffic_server(mime_scanner_get(MIMEScanner*, char const**,
> char const*, char const**, char const**, bool*, bool, int)+0x2c2)[0x5cf752]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(http_parser_parse_req(HTTPParser*, HdrHeap*,
> HTTPHdrImpl*, char const**, char const*, bool, bool)+0x113)[0x5c4e73]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(HTTPHdr::parse_req(HTTPParser*,
> IOBufferReader*, int*, bool)+0x1a7)[0x5c11d7]
> /usr/local/bin/traffic_server(PluginVC::process_read_side(bool)+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(HttpSM::state_read_client_request_header(int,
> void*)+0x100)[0x5311c0]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x39f)[0x4d37cf]
> /usr/local/bin/traffic_server(HttpSM::main_handler(int, void*)+0xcc)[0x5383ac]
> /usr/local/bin/traffic_server(_ZN8Plu
> ginVC17process_read_sideEb+0x425)[0x4d1535]
> /usr/local/bin/traffic_server(EThread::process_event(Event*,
> int)+0x238)[0x6cb258]
> /usr/local/bin/traffic_server(EThread::execute()+0x707)[0x6cbcd7]
> /usr/local/bin/traffic_server[0x6cad1e]
> /lib64/libpthread.so.0[0x2ba86e67283d]
> /usr/local/bin/traffic_server(PluginVC::process_write_side(bool)+0x5ac)[0x4d1e6c]
> /usr/local/bin/traffic_server(PluginVC::main_handler(int,
> void*)+0x46e)[0x4d389e]
> /lib64/libc.so.6(clone+0x6d)[0x313bad503d]
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-1146) RFC 5077 TLS Session tickets
[ https://issues.apache.org/jira/browse/TS-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1146: Attachment: session_ticket_review.patch I had some more comments about style, but I decided to update the patch rather than do it in bug comments. Please take a look at my suggested changes and let me know what you think. > RFC 5077 TLS Session tickets > > > Key: TS-1146 > URL: https://issues.apache.org/jira/browse/TS-1146 > Project: Traffic Server > Issue Type: Improvement > Components: SSL >Reporter: James Peach >Assignee: James Peach > Labels: A > Fix For: 5.0.0 > > Attachments: SSL_CTX_set_tlsext_ticket_key_cb.txt, > session_ticket.patch, session_ticket_review.patch > > > For supporting RFC 5077 TLS Session tickets across a ATS cluster, all the > machines need to have the same server ticket. > See https://github.com/apache/httpd rev > 967d943b93498233f0ec81a5b48706fdb6892dfd -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2400) Our default SSL cipher-suite advocates speed over security
[
https://issues.apache.org/jira/browse/TS-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840568#comment-13840568
]
Leif Hedstrom commented on TS-2400:
---
I'm going to mark this for v5.0.0, unless someone feels differently. This feels
like something that's not a "compatible" change?
> Our default SSL cipher-suite advocates speed over security
> --
>
> Key: TS-2400
> URL: https://issues.apache.org/jira/browse/TS-2400
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, SSL
>Reporter: Igor Galić
> Fix For: 5.0.0
>
>
> Our default cipher-suite advocates speed over security:
> {code}
> RC4-SHA:AES128-SHA:DES-CBC3-SHA:AES256-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL
> {code}
> Worse yet, it still has RC4 in there, along with some other bad defaults. RC4
> must be eradicated:
> https://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx?Redirected=true
> We should by default advocate security, which means, we should advocate
> Perfect Forward Secrecy, which means we should also advocate OpenSSL >=
> 1.0.1e
--
This message was sent by Atlassian JIRA
(v6.1#6144)
